This page is about different ARM processors
All new designs use STM32 (mostly STM32F4 and STM32F103 but code is rather portable to other STM32 microcontrollers.)
- allow more outputs and inputs (digital and analog inputs): strong on ADC and DMA
- easier configuration (eg. VR/HALL selection in config, not during ordering)
- better diagnostics
- more communication channels and bandwidth (with very little overhead)
- more room for future development (more than 90% of CPU cycles and SRAM free, and plenty of flash also)
First deploying to projects that are very well prepared (thematically), will likely make use of some special features (even if not strictly needed initially), and not extremely demanding schedule, and project owner is cooperative (preparing thematically; doing bench-tests before trying live; willing to edit some ini files if needed).
OLD: atmel AT91SAM7A3 (instead of the old plan, LPC2129).
- 100 pin is enough for nice functionality (possibly without the proven LBUS)
- non-BGA
- nice functionality. Atmel was always strong with the peripherals, and with the ARM core it's an unbeatable combination
- nice ADC (16 channels, 10 bit) and DMA for everything (called PDC)
- nice networking with CAN, UARTS and USB
- the only drawback is no-EEPROM, so we need to bridge this with some software (storing config and tables in flash)
The page ArmProcessorSubsitution contains a mapping of a GenBoard/VerThree port on a Philips LPC2119. The chip seems to me too tight. (Alexei)
The ancient page had some info:
http://www.squirrelpf.com/msavr/index.php?page=BrainStorming
on-chip peripherals - was used as checklist when looking for uC candidates
The following points are important from my point of view:
the usage is obvious in most cases, check GenBoard/VerThree
- FLASH, mandatory ? 128 kbyte for basic functions. We use MMC for noncritical (black-box, logging) stuff
- SRAM, how much 16 kbyte+
- ADC, >= 10bit 4 onchip. We use MCP3208 for bigger boards or 144pin version with 8 ADC channels.
- external interrupt: not needed, that's only useful with input capture. ARM ITC seems to be very rich
- DAC: 2 channels would help, but not available. Any ideas for external chip? (we used PWM and RC filter on v3.x)
- core frequency is likely not an issue as it's always enough
- watchdog (always present)
- external 8bit ports not needed, 4 bit LBUS is fine (for 259 chips)
- external SPI port
- digital I/O not critical, the LBUS is fine, see above
- serial port (1+)
- USB generally not available: we use USB-RS232 or USB-CAN
- CAN 2+ MUST
- timer-related functions, see below
Timer related
datasheet from page 214.... (and pinout)
- It seems we want to use the timer0 and timer1 for input capture and eventqueue with high period
- CAP1.x does not conflict that bad as CAP0.x (ADC input channels).
- we want 3 of MAT1.x for precise timed chip-enable signals for 259 chips. That allows to have dead-sharp timing (with some firmware tricks).
- the 4th match register T1MAT4 will be used to generate EventQueue interrupt
- we only need 3 PWMs badly: 1 for injector PWMing and 2 for WBO2 pump (1 for each WBO2 channel). It comes nice to have extra PWMs, eg. for general purpose analog output.
YESS. This chip is awesome!
We have 8 input captures available: CAM / crank, crank-backup + 4 wheels + freqoutput MAP possible with 8 input captures!
PWM-ing uses it's own timer (at adress 0x14000) NOT Timer0/Timer1. The manual is confusing, but if you look at the registers and addresses (eg. page 230 of 306), it will be clear.
We'll use 40 .. 80 usec PWMing period .
Little guy needed or not?
Aren't we using an AVR (IO chip) to take care of Injector PWMing and flyback control? I feel that the IO chip is the best way to avoid pin mapping conflicts with the ARM boards. -Jörgen
No, it seems functionality per board was shrinked so much we don't need an AVR helper script. Pinmapping will be relatively easy, the only thing I asked is we
- leave AINx free for ADC inputs.
- control 259 latch enable with output-match capable outputs.
Even with arbitrary pinmapping it's _much_ less software than with a helper AVR chip, so we don't use that if not absolutely necessary.
packaging
- xQFP, 64 .. 144 pins ?
- pin pitch (anything 0.5, 0.635, 0.65, 0.80 mm OK)
- prototyping, how to solder: not a major criteria, we use professional production for prototypes too, since we need 20+
- forget xQFP - PGA changer
price
availability, product maturity
I'm against new products like Motorola MAC71xx, the first version is always buggy
- development tools: GCC port is available for ARM7
- compilers, debuggers, assemblers, simulators: does anyone uses simulators ?, not often. In the future, we'll make prototype on PC (C or java)
- flashers, real-time debug
- it seems all ARM cores have a JTAG (TAP) access to main real-time debugging features
- relatively cheap ($150) boxes are available to access TAP, do we need them or is it simple to make them ?
The MCU choice:
Philips LPC
- LPC2119: 128k, 16k, 2xCAN, 4x10bit ADC, [LQFP64] [Usermanual] [Datasheet]
- LPC2292: 256k, 16k, 2xCAN, 8x10bit ADC [LQFP144]
- LPC2294: 256k, 16k, 4xCAN, 8x10bit ADC, LQFP144
- OKI [ML67Q2301] ? LQFP144, 4.5-5.5V, 384K, 16K, 4xCAN is DEAD, it never made to market
- Atmel: only BGA are with flash, rejected
- Motorola MAC71xx: not mature, rejected ?
- TI ?
- Cirrus Logic ? no ADC, BGA only, rejected
- ST: very similar to Philips LPC. 64pin package, 4 timers, 4x10bit ADC, USB or CAN, one 3v power. Inputs not 5v tolerant. BUT: eval kits developped 2 floors below my office :-)
- XC166 (someone put it on the bad page? oh, it's not ARM) could be acceptable but not enough reasons listed to switch from LPC2119
- design our own: (just kidding :-)
See also:
- strategy at VemsFrontier/Boards
- http://j2me.fritjof.net/ a very interesting site for realtime JAVA, including ARM and FPGA implementations
- search for Wiggler JTAG ARM keywords. We might need a small board for uploading to the ARM flash.