THE MINISTRY of EDUCATION and SCIENCE of RUSSIAN FEDERATION SAMARA STATE AEROSPACE UNIVERSITY I. A. Kudryavtsev, D. V. Kornilin Radio complexes for flight monitoring and control of the micro/nanosatellites Electronic Lecture Notes SAMARA 2011 Authors: Kudryavtsev Ilya Alexandrovich, Kornilin Dmitry Vladimirovich Kudryavtsev, I. A. Radio complexes for flight monitoring and control of the micro/nanosatellites = Радиотехнические комплексы контроля полета и управления микро/наноспутников [Electronic resource] : Electronic Lecture Notes / I. A. Kudryavtsev, D. V. Kornilin; The ministry of Education and Science of Russian Federation, Samara State Aerospace University. - Electronic text and graphic data. (1,1 Mb). - Samara, 2011. - 1 CD- ROM. The notes are intended for the students, studying on the educational program 010900.68 (Applied mathematics and physics). Notes deal with the important aspects of the circuitry's design and programming issues. Notes are developed in the Interuniversity Space Research Department © Samara State Aerospace University, 2011 CONTENTS 1 INTRODUCTION......................................................................................................4 2 FLIGHT COMPUTER...............................................................................................5 3 ARM7TDMI ARCHITECTURE.................................................................................7 3.1 Pipelining.......................................................................................................................................................7 3.2 Memory access...............................................................................................................................................8 3.3 Instruction modes..........................................................................................................................................8 3.4 ARM registers...............................................................................................................................................8 3.5 Processor modes..........................................................................................................................................10 3.6 Exceptions....................................................................................................................................................10 4 INSTRUCTION SET...............................................................................................13 4.1 Addressing modes.......................................................................................................................................13 4.2 ARM Instruction set...................................................................................................................................13 5 VECTORED INTERRUPT CONTROLLER............................................................17 5.1 Bus architecture..........................................................................................................................................18 6 LPC21XX FEATURES...........................................................................................18 6.1 Memory map...............................................................................................................................................18 6.2 Memory acceleration module (MAM).......................................................................................................19 6.3 Phased Locked Loop (PLL)........................................................................................................................20 7 INTERFACES........................................................................................................22 8 SIGNAL PROCESSING.........................................................................................23 9 COMMUNICATIONS..............................................................................................25 10 INTERFERENCE IMMUNITY.............................................................................30 1 Introduction We all realize, that micro/nanosatellite without electronics inside is simply a box of metal. Microsatellite with electronic systems inside or without them will never return to the Earth, so reliability and operational functions of electronic systems determine its actual value. We shall speak about these systems and subsystems, discuss main approaches, popular among the developers and some special tricks. Today we shall talk about microcontrollers, to help you successfully perform laboratory trainings, power systems, analog electronics and some aspects of circuitry development. Here, in Russia we believe, that to understand smth., one needs to be familiar with the history of the question, at least briefly. Electronics is relatively young, so most of its main achievements were reached at last century. The main element transistor is invented by three sci- entists, working in Bell Labs: Here you can see also their brainchild. William Schokley is known also for the idea of MOSFET, that was realized a bit later. Prof. Schokley was also known for his racist opinions, for which he was condemned by his colleagues. Nevertheless they all had won Nobel prizes for their contribution to the electronics. John Kilby is known as an inventor of the germanium based integrated circuit, which was a generator. Robert Noyce had offered silicon based IC and a planar process, which was signifi- cantly more appropriate for the production. Bob Widlar is mostly known as an inventor of the first integrated operational amplifier, whose circuit you can see here. Here, in Russia we had the analog of this circuit, and I had even a little experience, working with it. It was unstable, output stage could easily had been burnt, so I hadn’t liked it, but soon we have got a lot of much more good chips. Bob Widlar is also known for his eccentric deeds, for example once he had brought a sheep in his Mercedes to trim the lawn near the National Semiconductors’ office. Allegedly he had later sold the animal to the nearest restaurant. When something didn’t worked properly, he usually had got a special hammer and had thoroughly destroyed the model into the dust. His colleagues named that process “wid- larising”. We can describe main typical functions, essential to this equipment as following: 1. Power control 2. Communication 3. Collecting, processing and storing data 4. Auxiliary functions, providing specific needs Regardless of the destination of the equipment, it has to be reliable and compact, besides that developers usually try to make hardware, which consumes possibly less power and radiates less heat. Space conditions also require broad temperature range and a tolerance to low pressure. 2 Flight computer Of course, satellite needs a control center, which aim is to coordinate the operation of dif- ferent systems; usually we call it board computer. Hardware and software of this computer is ex- tremely important issue to discuss and we shall start from it. The second reason is the timetable of our school, due to which you will have a special training just after lunch. We can offer two main approaches to the development of flight computer. First one is to buy the ready processor board, which includes CPU, memory and necessary peripherals. We can now find many different solutions here with various performance, price and fea- tures. It is a simple way, because it saves our efforts, but it has its own drawbacks. At first, we can hardly find a solution, completely corresponding to our purposes and conditions, like power consumption, size etc. and we should accommodate our solution to this hardware and software. Secondly we should use hardware and software, recommended by vendor, and this fact can limit our opportunities. Here, for instance we have useful peripherals, powerful CPU, a lot of memory and seven useless (in space) USB ports. By the way, let’s look at the first slide, and then at the last. Has anybody seen anything suspicious? Then once again and look at the temperature range. Another way is to develop our own hardware/software, capable to interact with our pe- ripherals and to solve our limited set of tasks. Here we can save power, make the PCB of any desired size and so on, but we need to develop the mainboard, which may be a separate problem. We can also use a compromise solution – to use a so-called mezzanine board, including usually CPU, memory and only limited set of peripherals. Such boards have usually a little size and we can develop our own mainboard with necessary peripherals, perfectly satisfying our re- quirements. Some of you will deal with such board during laboratories. If you want to develop flight computer, you should solve two main groups of problems: software and hardware. Hardware problems are usually not so various, so we’ll begin from soft- ware. Here are two main ways of thinking too. The first way is to develop our own software “ab ovo”, and it will perform only limited set of tasks, necessary for our board equipment. This way provides us with an opportunity to use all the performance possibilities, that a processor have, but the drawback is poor flexibility. To add the feature or to remove can require full revision of the software. Advantage of this approach is a full control over your software and perhaps, exclu- sive efficiency (if you know, what are you doing certainly). Another way is to use an operating system, like Windows Embedded, FreeRTOS and so on. Using OS simplifies the process of software development, but usually requires extra re- sources and limits user in its control over CPU. Nevertheless, when having modern CPUs, using also OS seems quite seducing. It is particularly evident, when we need to implement complicated interfaces, like TCP/IP, CAN etc. Using OS requires additional knowledge of its structure and features, so we shall limit our trainings by the first way of thinking. You also need to know the main difference between GPOS and RTOS. RTOS can guar- antee to some of your tasks an uninterruptible execution and GPOS cannot. Windows’s task scheduler, for instance, provides a preemptive execution, which guarantee, that all the tasks get their time quanta of CPU’s time, therefore no task cannot have an opportunity to be executed continuously. It is a good idea for powerful CPUs and home computers, but can be a problem for some specific missions. Choice of the language is the most subjective problem. I know the software developer, who is involved in the creation of the satellites, who uses only Basic. The arguments for the choice of language are simple – having an experience with it, availability of the compiler, coop- eration with colleagues, requirements to the software. Software developer usually uses high-level languages (mostly C or C++ or Java) or as- sembler language. Assembler language allows making more perfect code, using minimum re- sources, but it also requires much more efforts from developer. Using C, we can solve many problems really faster and simpler, but we cannot guarantee that compiler software will translate our listing into CPU instructions perfectly and it can cause less efficiency and larger code size. Again, taking into account the characteristics of modern CPUs and compilers, most part of de- velopers uses C/C++, but sometimes implementing part of your programs in assembler language can be very efficient. Answer to this question is complicated due to the large choice of CPUs on the market. Actually, overwhelming majority of the engineers solve this problem subjectively. Main reasons are usually following: I have an experience in working with CPU/MCU, I have this CPU on my shelf, I have an integrated development environment for this CPU or maybe my chief insists on applying this CPU. For example, our laboratories are based on NXP CPUs only because we have these development boards. By the way, start with a development board significantly simplifies and accelerates the development. I can also add, that ARM7 is a widespread CPU platform, and having experience with one of these processors you can freely transfer your solution to another clone of ARM7. ARM7TDMI (LPC2148) is 32-bit RISC MCU with rich set of peripherals almost for every purpose, which you can imagine. Its main drawback is large interrupt latency, which de- preciates MCU’s own performance. Another drawback, which has been annoyed many develop- ers is a poor implementation of RS-485 mode in UART. Newer versions, named CORTEX, have improved the situation in both cases. CORTEX-M0, which is installed in laboratory trainings, is a low power version of CORTEX, which can be particularly useful in nano- and picosatellites with poor power capabilities. Well, what do we need to know about these MCUs to develop software for our missions? First of all, to create efficient software, we need to know MCU’s features. We’ll limit these features by only some general details of ARM processors. ARM is a company, which invents and creates only pure architectures without creating a single processor. But it sells licenses on their cores to other companies – vendors of the chips. Essentially every vendor adds some features to their chips, leaving the core untouched. ARM architectures are ubiquitous and having an experience with one clone, you can migrate to another one without serious problems. LPC2148 has a lot of on-chip peripheral modules, internal RAM and FLASH memory, connected by several buses. Please, pay your attention on the fact, that a lot of peripherals divide one separate bus, while memory is connected to the core via another bus. USB and vectored in- terrupt controller are connected to the third bus. Remark, that interrupt controller is not a part of core, which results in some disadvantages. CPU has a real-time clock with a separate clocking system and battery power. RTC can operate as a separate device, when CPU is switched off and it can awake CPU with its signal in the predetermined moments. Watchdog timer increases the reliability of processor operation. It is a counter, which can generate reset signal for the proces- sor, if activated. The idea is in the regular clearing this counter by the software, when CPU oper- ates properly. If some reason causes hanging of the CPU, WDT wouldn’t be cleared in time and processor will be reset. I2C, SPI, SSP modules support serial interfaces, USART provide stan- dard operations with interfaces of type RS-232. ADC/DAC can be used for analog signal proc- essing. Timers can be used for generating pulses of certain duration and measuring of time inter- vals, PWM modules can provide simple and efficient method of control for actuating devices. LPC2148 can run at frequencies up to 60MHz. CORTEX-M3 has better bus performance and some advanced features, like USB Host/OTG support, DMA controller etc. LPC1768 can run at frequencies up to 100MHz. You can see, that here interrupt controller is already included in the core. CORTEX-M0 is a truncated low-cost and low-power version of CORTEX-M3, running at 50MHz and keeping main advantages of CORTEX architecture. 3 ARM7TDMI architecture ARM7TDMI is 32bit RISC general purpose processor with Von Neumann memory struc- ture. It is realized on the base of v4T architecture. Main CPU’s features: • 3-stage pipeline, which provides one clock execution time for sequential instructions (in- cluding multiplication); • Two instruction sets: ARM and THUMB. In ARM mode CPU executes 32bit instruc- tions, in THUMB mode — 16bit instructions; • Load and Store architecture; • Debugging interfaces - JTAG and ETM. 3.1 Pipelining In order to improve performance a three stage pipeline is used, this allows multiple instructions to be processed simultaneously. The pipeline has three stages, Fetch, decode and execute. The hard- ware of each stage is designed to be independent so up to three instructions can be processed simul- taneously. The pipeline is most effective in speeding up sequential code. However a branch instruc- tion will cause the pipeline to be flushed marring its performance. As the pipeline is a part of CPU it is transparent for the software developer. Nevertheless it is important to remember one thing: Program Counter (РС) points to the prefetched in- struction, not to the executed, so developer should properly determine the offset. 3.2 Memory access ARM7TDMI-S has Von Neumann architecture with a single 32bit data bus, used for the instructions and data transfers. Only load and save instructions can access memory. Memory system uses one of the two following mapping schemes: • Big-endian • Little-endian. Least significant byte of the word is kept in the lowest memory address (that is equal to the address of the low half-word and the whole 32bit word). Most significant byte of the word is kept in the highest memory address (that is equal to the address of the low half-word and the whole 32bit word). 3.3 Instruction modes ARM7TDMI has two modes: ARM mode CPU is executing 32bit ARM instructions. Thumb mode CPU is executing 16bit Thumb instructions. The Thumb instruction set must always be entered by running a Branch exchange or branch link exchange instruction and NOT by setting the T bit in the CPSR. Thumb instructions are essentially a mapping of their 32 bit cousins but unlike the ARM instructions, they are un- conditionally executed except though for branch instructions. Thumb instructions only have unlimited access to registers R0-R7 and R13 – R15. A re- duced number of instructions can access the full register set. Thumb has a much higher code density than ARM code, needing some 70% of the space of the latter. However in a 32-bit memory, ARM code is some 40% faster than Thumb. However it should be noted that if you only have 16-bit wide memory then Thumb code will be faster than ARM code by about 45%. Finally the other important aspect of Thumb is that it can use up to 30% less power than ARM code. Remark 1: In Thumb mode Program Counter (PC) is increased by 4 between instructions, unlikely increase by 8 in ARM mode. Branching instructions (BX) are used to enter the 16-bit Thumb instruction set. Both the branch and branch-with-link (BLX) may perform an exchange between 32-bit and 16-bit instruction sets and vice versa. Remark 2: Switching between ARM and Thumb modes concerns neither processor’s mode nor content of the registers. Remarks 3: Exception’s processing is being executed in ARM mode. When exception is oc- curred in Thumb mode, processor switches to ARM mode automatically. Switching to the Thumb mode back is performed also automatically, when exception processing is completed. 3.4 ARM registers The programmer’s model of the ARM 7 consists of 15 user registers, as shown in Fig. 3, with R15 being used as the Program Counter (PC). Since the ARM 7 is a load-and-store architecture, an user program must load data from memory into the CPU registers, process this data and then store the result back into memory. Unlike other processors no memory to memory instructions are avail- able. R15 is the Program Counter. R13 and R14 also have special functions; R13 is used as the stack pointer, though this has only been defined as a programming convention. Unusually the ARM in- struction set does not have PUSH and POP instructions so stack handling is done via a set of instruc- tions that allow loading and storing of multiple registers in a single operation. Thus it is possible to PUSH or POP the entire register set onto the stack in a single instruction. R14 has special signifi- cance and is called the “link register”. When a call is made to a procedure, the return address is automatically placed into R14, rather than onto a stack, as might be expected. A return can then be implemented by moving the contents of R14 into R15, the PC. For multiple calling trees, the contents of R14 (the link register) must be placed onto the stack. In addition to the 16 CPU registers, there is a current program status register (CPSR). This contains a set of condition code flags in the upper four bits that record the result of a previous in- struction, as shown in Fig 4. In addition to the condition code flags, the CPSR contains a number of user-configurable bits that can be used to change the processor mode, enter Thumb processing and enable/disable interrupts. Saved Program Status Register – SPSR keeps the same set of the flags, as CPSR after any event, triggering an exception. If in this moment CPU was in User mode, the mode would change and CPSR would saved into SPSR. After completion of the exception’s processing CPSR is restored from SPSR, making possible the continuation of user’s routine. Remark 4: SPSR is present in all modes, except User and System. М4-М0 bits define six processor modes with specific register sets. The CPSR and SPSR are only accessed by two special instructions to move their contents to and from a CPU register. No other instruction can act on them directly. Thumb registers are the part of ARM registers. In Thumb instructions only three bits are installed to point the number of register, so one can directly access only R0-R7 (low registers). R8-R12 (high registers) are available only via special load instructions, like MOV. There are no MSP и MRS instructions in Thumb mode, so changing of CPSR and SPSR is only possible via indirect addressing. If it is needed to modify user bits in CPSR, one should switch to ARM mode. 3.5 Processor modes The ARM 7 architecture has a total of six different operating modes, as shown below. These modes are protected or exception modes which have associated interrupt sources and their own register sets. User: This mode is used to run the application code. Once in user mode the CPSR cannot be written to and modes can only be changed when an exception is generated. FIQ: (Fast Interrupt reQuest) This supports high speed interrupt handling. Generally it is used for a single critical interrupt source in a system IRQ: (Interrupt ReQuest) This supports all other interrupt sources in a system Supervisor: A “protected” mode for running system level code to access hardware or run OS calls. The ARM 7 enters this mode after reset. Abort: If an instruction or data is fetched from an invalid memory region, an abort exception will be generated Undefined Instruction: If a FETCHED opcode is not an ARM instruction, an undefined in- struction exception will be generated. The User registers R0-R7 are common to all operating modes. However FIQ mode has its own R8 –R14 that replace the user registers when FIQ is entered. Similarly, each of the other modes has their own R13 and R14 so that each operating mode has its own unique Stack pointer and Link register. The CPSR is also common to all modes. However in each of the exception modes, an additional register - the saved program status register (SPSR), is added. When the processor changes the current value of the CPSR stored in the SPSR, this can be restored on exit- ing the exception mode. 3.6 Exceptions Entry to the Exception modes is through the interrupt vector table. Exceptions in the ARM processor can be split into three distinct types.