m (New page: = ** Currently a work in progress ** = = Overview = Choosing a processor core(s) plus additional hardware is a very complex decision and is a balance between: *How well the So...) |
|||
| Line 1: | Line 1: | ||
| − | = | + | = Overview = |
| − | + | Choosing a processor core(s) plus additional hardware is a very complex decision and is a balance between: | |
| − | + | *How well the SoC suits the problem at hand | |
| − | + | ||
| − | *How well the SoC suits the problem at hand | + | |
*The available experience or sources of help to develop it | *The available experience or sources of help to develop it | ||
| − | The main areas of interest are the fundamental architecture of the core, the peripheral modules available and the software environment. | + | The main areas of interest are the fundamental architecture of the core, the peripheral modules available and the software environment. |
| + | |||
| + | == Architecture == | ||
| + | |||
| + | Examples of architecture are ARM, MIPS, Intel x86, TMS320, AVR, MSP430 etc. The key things to consider are the data and address widths as well as the math capabilities of the processor. | ||
| + | |||
| + | === Data word size (8, 16, 32 or 64 bit) === | ||
| + | |||
| + | The larger the data word, the larger the math operation that can be carried out in one go. Also the larger the power cost. Bear in mind the internet is 32 bits (addresses and datatypes) so it is inefficient on microcontroller bit widths i.e. 8 or 16. | ||
| + | |||
| + | === Math capability === | ||
| + | |||
| + | Many processor architectures have no floating point math hardware and those that do often pay a heavy power price for it. Consider whether you can avoid most floating point math in favour of integer math. If not a hardware floating point unit may be a necessity. | ||
| + | |||
| + | === Memory: On chip or off chip and what is the capacity?<br> === | ||
| + | |||
| + | Does the chip have RAM and/or FLASH memory inside it? If not any design is going to have to have external RAM or FLASH on the PCB which will require high speed PCB engineering. This is a solvable problem but needs to be taken into account.If it is on chip ram can it hold the program you want to place on it?<br> | ||
| + | |||
| + | == Peripherals<br> == | ||
| + | |||
| + | Consider the problem at hand and whether the chip you have chosen has the necessary number of connections to the outside world of the right types or the ability to add extra connections. For this I mean everything from complex connections such as Zigbee, Wifi, Ethernet or USB to simpler connections such as GPIO, USART, SPI or I2C. <br> | ||
| + | |||
| + | If the chip doesn't have enough you will need to add to it and consider how you can do that.<br> | ||
| + | |||
| + | If any of the protocols are complex (TCPIP or USB for example) have you a protocol stack available as source code (much preferred) or compiled (better hope there are no bugs and it does what you want)?<br> | ||
| + | |||
| + | If any of the hardware interfaces are complex (Wifi, Ethernet or TCPIP ) do you have drivers available as source code (much preferred) or compiled (better hope there are no bugs and it does what you want)?<br> | ||
| + | |||
| + | == Software<br> == | ||
| + | |||
| + | This is probably the most important area of all.<br> | ||
| − | + | Two main models:<br> | |
| − | + | *"Bare Metal" programming - an empty system that will run only the program you put on it. Very little if any code is provided to get the processor going.<br> | |
| + | *Operating system programming - the system already runs an operating system with a driver stack. Any program you write will be run alongside other system services. <br> | ||
| − | === | + | === Bare Metal<br> === |
| − | + | Important points:<br> | |
| − | + | *Have you got the compilers and debuggers to create programs for the chip?<br> | |
| + | *Have you got a programming tool that can load the program into the chip?<br> | ||
| + | *Can you see into the chip memory and start and stop it running your program? This is often called "In circuit debugging" capability. I would not choose a processor without it.<br> | ||
| − | + | === Operating System<br> === | |
| − | + | *Again, have you got the compilers and debuggers to create programs for the chip?<br> | |
| + | *Have you got a method for inserting your program into the correct place in the chips filesystem?<br> | ||
| + | *Can you debug your running program? Can you debug better than simply having printf statements (or their equivalent?)<br> | ||
| + | *Can you get any kind of gauranteed timing if you need it? This is often a problem with operating systems. Typically inside linux or windows any kind of real time requirements (i.e. event A happening 0.5s after event B, typically an OS will give you A will happen 0.5s or more later than event B only) require writing a custom device driver. Not a trivial problem.<br> | ||
| − | + | <br> | |
Latest revision as of 11:58, 27 September 2011
Contents
Overview
Choosing a processor core(s) plus additional hardware is a very complex decision and is a balance between:
- How well the SoC suits the problem at hand
- The available experience or sources of help to develop it
The main areas of interest are the fundamental architecture of the core, the peripheral modules available and the software environment.
Architecture
Examples of architecture are ARM, MIPS, Intel x86, TMS320, AVR, MSP430 etc. The key things to consider are the data and address widths as well as the math capabilities of the processor.
Data word size (8, 16, 32 or 64 bit)
The larger the data word, the larger the math operation that can be carried out in one go. Also the larger the power cost. Bear in mind the internet is 32 bits (addresses and datatypes) so it is inefficient on microcontroller bit widths i.e. 8 or 16.
Math capability
Many processor architectures have no floating point math hardware and those that do often pay a heavy power price for it. Consider whether you can avoid most floating point math in favour of integer math. If not a hardware floating point unit may be a necessity.
Memory: On chip or off chip and what is the capacity?
Does the chip have RAM and/or FLASH memory inside it? If not any design is going to have to have external RAM or FLASH on the PCB which will require high speed PCB engineering. This is a solvable problem but needs to be taken into account.If it is on chip ram can it hold the program you want to place on it?
Peripherals
Consider the problem at hand and whether the chip you have chosen has the necessary number of connections to the outside world of the right types or the ability to add extra connections. For this I mean everything from complex connections such as Zigbee, Wifi, Ethernet or USB to simpler connections such as GPIO, USART, SPI or I2C.
If the chip doesn't have enough you will need to add to it and consider how you can do that.
If any of the protocols are complex (TCPIP or USB for example) have you a protocol stack available as source code (much preferred) or compiled (better hope there are no bugs and it does what you want)?
If any of the hardware interfaces are complex (Wifi, Ethernet or TCPIP ) do you have drivers available as source code (much preferred) or compiled (better hope there are no bugs and it does what you want)?
Software
This is probably the most important area of all.
Two main models:
- "Bare Metal" programming - an empty system that will run only the program you put on it. Very little if any code is provided to get the processor going.
- Operating system programming - the system already runs an operating system with a driver stack. Any program you write will be run alongside other system services.
Bare Metal
Important points:
- Have you got the compilers and debuggers to create programs for the chip?
- Have you got a programming tool that can load the program into the chip?
- Can you see into the chip memory and start and stop it running your program? This is often called "In circuit debugging" capability. I would not choose a processor without it.
Operating System
- Again, have you got the compilers and debuggers to create programs for the chip?
- Have you got a method for inserting your program into the correct place in the chips filesystem?
- Can you debug your running program? Can you debug better than simply having printf statements (or their equivalent?)
- Can you get any kind of gauranteed timing if you need it? This is often a problem with operating systems. Typically inside linux or windows any kind of real time requirements (i.e. event A happening 0.5s after event B, typically an OS will give you A will happen 0.5s or more later than event B only) require writing a custom device driver. Not a trivial problem.
