Newbie Qs about ARM Types and Lookup Tables in C I am an absolute newbie with ARM Processors and also i am overwhelmed with the choice of different controllers. I want to produce a simulator for engine control units (ECU) so i need at least two analogue outputs for the trigger pulse where i output the values of a lookup table which is located in flash AND can be altered (once during startup is enough). The exact form of this pulse is not important. Also i need about 8 (slow) analogue outputs (>=12bit), 16 digital IOs and 8 analogue inputs (>=12bit) I started with an Atmel XMEGA but it is a little too slow (although i overclocked it to 48MHz) The xmega gets the trigger form from a Matlab GUI over the Serial interface. It stores this array in the flash memory. In an interrupt it reads one byte of this array and writes it to the DAC. More or less the same is with digital outputs. The Matlab GUI does all the calculation (for ex. counter tics for a specific rpm) and the communication protocol (CRC) and sends the raw data to the controller What i need: .) I am interested in the ARM Cortex M3 and M4 types. How fast is a port manipulation and can i do it in an interrupt with little latency? .) Can i write a table to flash from inside the code at runtime or is there enough RAM? .) How fast is the DAC? .) Which chip should i use (in terms of support and development chain) ? I thought about Atmel AT91SAM3X8E which is on the arduino due but also the Teensy boards are nice with cortex M4 and M4F. My calculations are (worst case): max rpm: 10000 1/min = 167 1/s old BMW 137 tooth on trigger wheel => 23kHz 4 Samples per sinewave => fsample = 92kHz vertical resolution <= 8bit (can be two bits) 4Samples per tooth 137 teeth 2 rotations = 1096 Values Thank you for any suggestions.
Robert O. wrote: > What i need:... almost all brands have nice methods to manipulate port pins: direct output to the ports, pin set and reset registers where you can selectively address one or more pins while the other remain unchanged and in some brands even fields of boolean variables, which represent the pins. To write to the flash is usually NOT preferable. Use instead a controller with builtin EEPROM. Not all brands have a DAC. So you need to read the manual. What Chip? The toolchains can handle nearly ALL of them. So it's your decision. But if you want a hint, I say so: prefer a Cortex M4F, because this is not really expensive and you have a floating point arithmetics in hardware. Usual clock frequencies are in the range of 72 MHz and above, so you have plenty power for your project. With such clock speeds you should not have big problems with interrupt frequencies of 92 kHz. I myself avoid chips from atmel and texas and infineon. I prefer the LPCxxx chips from NXP but do not really like the MKxxxx (Kinetis) from former Freescale. But they are usually cheaper. I also like the STM32Fxxx from ST. On both brands (LPC and STM) you will find a nonvolatile bootloader on the chip, what is very convenient, because the programming does usually need nothing more than a serial line or USB. Look also to Nuvoton, they meanwhile have a internet shop and the have interesting and rather cheap Cortex chips. But they have usually NO bootloader. W.S.
Robert O. wrote: > .) I am interested in the ARM Cortex M3 and M4 types. How fast is a port > manipulation and can i do it in an interrupt with little latency? Port control is outside of the scope of the ARM Cortex Core. It is up to the implementation by ST, NXP, Atmel, ... and those implementations differ widely in capabilities and mechanics, e.g. regarding multi-bit control. Yes, it may be done in interrupts and ARM implementation of the Cortex age usually have a pretty fast access to the ports, though it may differ even within a manufacturers family. > .) Can i write a table to flash from inside the code at runtime Flash control is implementation defined, but all implementation I know of support flash, which is writable by the application. I don't remember an ARM having a true EEPROM, so ether use Flash for persistent storage, or external storage. However you cannot use flash to frequently store large intermediate data sets, as erasing flash is way too slow and its erase count is limited. On the other hand, RAM capacity varies widely and I hope you did not expect us to present an industry wide device comparison sheet. > .) How fast is the DAC? You'll have to look at the datasheets.
:
Edited by User
Thank you for the replies. > "Port control is outside of the scope of the ARM Cortex Core. It is up to > the implementation by ST, NXP, Atmel, ... and those implementations > differ widely in capabilities and mechanics, e.g. regarding multi-bit > control" That is exactly one of my problems. It is nearly impossible to compare all the ARM chips regarding these special functions. The writing of the flash was a necessity in the XMEGA. If i have enough RAM it shouldn't be a problem to keep the array in RAM. I know about the degradation of Flash memory. For now i have the following Chips: K66 Family (MK66FX1M) from NXP (Cortex M4F - Teensy 3.6) LPC4337 also from NXP (Dual Core M4/M0) STM32F407 from ST Cortex M4 with DSP SAM3X8E from Atmel Cortex M3 From Atmel i already have Atmel Studio 7.0. Which debugger do i need? Which programmer do i need? Is ther a standard for programmer? I've heard of a JTAG standard but i am not sure if this is for debugging or programming. On the one hand i don't want to buy any software because i don't do a lot of programming, on the other hand i don't want to struggle with the setup of development enviroment. I already found some ressources but i am not sure if they are ARM specific or vendor specific (like LPC only or STM only) It's all very confusing :)
The low-level debugging / programming interface is standardized by ARM. Historically, JTAG used to be the preferred transport, while recently, SWD (serial-wire debug) is often implemented in parallel to JTAG, or even only SWD. Since ARM standardized the protocol, simple bit-bang JTAG adapters (like, based on FT2232's MPSSE) can usually be used in a vendor independent way, using e.g. OpenOCD as the middleware. I'm not quite sure about the implementation of SWD through this kind of lowcost adapters, but I seem to remember it's recently been implemented in OpenOCD, too. Of course, each vendor usually has their own set of tools to program and debug the devices, and each will tell you that you can only use it for their own controllers. However, due to the standardization by ARM, you actually can use an Atmel-ICE to program or debug an STM32, or an STlink to program or debug an Atmel ARM – but of course, none of the vendor software would support that. However, with OpenOCD it can be done. ;-) (Been there, done that.) As for your tables, comparing the Flash and RAM sizes of each model should be easy enough, and you might quickly find out that most of the ARM Cortex-Ms on the market will yield you enough RAM for your application. I don't think the actual core (CM0, CM3, CM4) does really matter much for your application. The most important thing you'd have to compare when walking the various vendors might be the DACs as this is quite a bit specific for your application. Keep in mind that almost all ARMs provide a peripheral DMA engine you could use to feed your DAC with a continuous data stream.
Hi, WRT tools, please look at this link: http://embdev.net/topic/384016#new I have use it successfully - Eclipse based, + CDT + gdb for arm, with OpenOCD.
Thank you for your replies. I just got two STM32F4 Board from a friend. I guess i'll start with ST :) and go from there.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.