Probably. If not, create one.
--
Grant Edwards grante Yow! ... I think I'm
at having an overnight
visi.com sensation right now!!
Of course. it's not as fast as the real cycle-stealing DMA, but it's fast enough for e.g. floppy data.
I'm using it on an AT91R40008 running at 4 MHz (yes, less than
10 % of rated, due to power limitations) and collecting data from an A/D at hundreds of kHz. On another construction, FIQ fits the bill in refreshing a LCD panel at 70 kHz.-- Tauno Voipio tauno voipio (at) iki fi
Kind of ... This is the way to write the initial boot loader onto the Flash chip.
A boot loader is a piece of code running at the bottom of the Flash and getting the data in in whatever way it sees fit. Of course, the write to the Flash has to be done in a way suitable for the Flash chip. There is one complication, though: the Flash write code cannot run from the Flash being written, as the chip cannot be read during the erase or write cycle. The solution is to copy the core of the write code into RAM and run it from there.
In my constructions, there is a piece of boot code on the first Flash segment (also called sector). The rest of the Flash chip is handled as a disk with a simple file system. The boot code is able to read the file system and load an executable into the RAM and run it. Alternatively, the boot can read an executable binary from the outside (serial line or Ethernet/BOOTP/TFTP) and run it. The boot code is loaded with JTAG using the process above and all the rest is then loaded using the boot code or an utility program loaded by the boot.
The code is not as complicated as it sounds - I counted the instructions in my code for the AT91's: there are seven instructions in the part setting up the memory chip selects and remapping.
Yes, there are. You got a good answer from another poster.
I'm using my own kernel and TCP/IP stack.
Only the fact that is is tied on-chip to the built-in serial channels, and so unusable for other peripherals.
HTH
-- Tauno Voipio tauno voipio (at) iki fi
JTAG is a wonderful way to debug. I found that the "Angel debug monitor" on the Atmel eval boards seemed to have some issues with IAR embedded workbench. With JTAG, loading and debugging is very straightforward. I got the example project from uc-os11 from the web/and book running quite easily, even though I don't have much experience and the example code had some new features that were not supported in the older OS source code from the book. I made some slight change to allow it to compile, then it seemed to run fine.
I suggest that you go to the IAR website and look at their kickstart kits. That includes the JTAG interface and development board. The free IAR tools are limited to 32kB code size, which will get you started. It seems to me that CGG tool chain is only a realistic option if you have a lot of patience. I also believe that the efficiency is not the best relative to the specialist embedded compilers.
best regards, Johnny.
In general, the ARM core executes instructions in 1/2/3 cycles depending on whether memory is involved. Non-memory instructions nearly all take one cycle. If the memory system can't provide opcodes/data fast enough, the core stalls.
The Atmel AT91 ARM7 cores mostly use a 16 bit external bus and no caches. The ARM9 cores are nearly always cached and the memory system is usually optimised for SDRAM.
Of the ARM7 chips we have used, the Philips LPC2000 family's MAM unit is far and away the best solution for hard real-time systems. The downside is that it only works on internal Flash (up to 512k). The cached Sharp parts are pretty good too, providing you can live with the usual cache side-effects.
We're running embedded web servers (CGI and ASP, Telnet ...) on LPC2000 parts just using the internal Flash and RAM.
Until you say what you're going to do with the system, I can't say whether you eed a 'big' ARM or a 'little' ARM.
Stephen
-- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Check out
I've not used Atmel ARM parts but I have used the Phillips ones and the fundamental principles are the same,. I bought a Keil MBC2100 development kit which is based around an LPC2129 and has a serial port, CAN controller, a few LEDs, a pot and a couple of push switches to get you started. It costs about GBP75 for the board or GBP250 for the board and a JTAG programmer. It will accept programs via the serial port so you don't have to use JTAG but if you corrupt it's boot loader then you'll have to get the JTAG probe out.
It ran FreeRTOS quite comfortably and it only took a morning or so using the FreeRTOS on-line manual to get some tasks up and running. I even managed to get the serial port to send a few strings.
Samsung's ARM7 parts have a cache, and are pretty cheap (though in my experience the peripherals tend to be buggy). The Linksys WAPs run Samsung ARM7 parts and can be a cheap "development platform" for running uCLinux.
--
Grant Edwards grante Yow! I Know A Joke!!
at
visi.com
We used the S3C4510B a while ago. It had quite the nastiest Ethernet controller and very buggy code examples on the development CD. Apart from that, it was dirt cheap and our client is very happy. However, I have heard rumours about Samsung's commitment to commodity ARMs. Can anyone confirm/deny?
Stephen
-- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Yup, I've used that part as well as its 5V predecessor the '4500. The basic design of the controller wasn't too bad (it was a bit overly complex), but there were a couple nasty bugs. OTOH, the basic design of the internal UARTs was just plain f*&ked up. Whoever designed the UART had no idea how flow control on serial ports worked.
The sample code was mostly useless, and the "English" in the documentation was entertaining if not always informative.
The features/dollar (even with bugs) are hard to beat. Just ask Linksys (which I believe used the '4510 in a lot of WAPs).
--
Grant Edwards grante Yow! I FORGOT to do the
at DISHES!!
visi.com
Being able to collect A/D at hundreds of khz at 4Mhz using FIQ is excellent (assuming you have time left over to do something useful during the collection).
The ARM I'm currently working with (ADuC702x) has a 1Mhz 12 bit A/D, 50 cycle worst case FIQ latency, at top speed of 40Mhz thats 1.2 usec, at
4 Mhz it would be 12 usec, nowhere near fast to process an A/D at hundreds of kHz using FIQ like you are. I have to sit there and poll the A/D to collect the data at that rate.
It seems that your FIQ handler is in some way fishy (or the base code keeps FIQ off for long times).
Here's my fiq handler for the data collection: (It's written in GCC embedded assembly code)
/* FIQ bank register usage: r8, -> destination buffer, -> AIC set request r9, pixel pair counter r10, -> I/O read port r11, -> PIO output reset port r12, capture control bit r13, work register r14, return link register */ ".code 32\n" "fiq1:\t" "ldr r13,[r10]\n\t" /* get a pixel pair */ "str r13,[r8],#4\n\t" /* save it - bump pointer */ "subs r9,r9,#1\n\t" /* bump count - done? */ "subnes pc,lr,#4\n\t" /* no - dismiss */ "str r12,[r11]\n\t" /* stop capture & FIQ */ "ldr pc,fiq2\n" /* continue to completion */ "fiq2:\t.word fiq4\n" /* -> completion handler */
"fiq3:\n" /* handler end label */
/* Fast interrupt completion in normal text segment */ /* ------------------------------------------------ */
"fiq4:\n\t" "ldr r8,fiq5\n\t" /* -> AIC base */ "mov r13,%2\n\t" /* get AIC SWI bit */ "str r13,[r8,%3]\n\t" /* cause SWI */ "subs pc,lr,#4\n" /* dismiss the FIQ */
"fiq5:\t" ".word at91aic\n\t" /* -> AIC base */
------
The core handling is at the FIQ vector address (byte address 0x1e).
There are just 4 instructions in the fast loop: ldr for reading the data, str for storing it, subs for counting and subnes for dismissing the FIQ. The execution time is far under 50 clocks: after the initial interrupt latency, it should use 5 clocks.
-- Tauno Voipio tauno voipio (at) iki fi
Atmel ARMs w Flash has an internal Bootloader. The AT91RM9200 has also an internal bootloader, but it is different.
If you execute in Thumb mode, the memory controller will fetch two instructions per two clock cycles, so you get one instruction per clock cycle in average until you do a jump. Then you have a two clock cycle fetch. Executing from SRAM will ensure you always get 1 instruction per clock even in ARM mode.
No, Linux needs just more. If you want to run Linux, then the AT91RM9200 is a better choice.
The DMA allows you to send/receive large blocks of data, so you do not get so many interrupts. Each interrupt will have to handle more than one byte.
-- A. P. Richelieu
"Michael J. Noone" skrev i meddelandet news: snipped-for-privacy@g14g2000cwa.googlegroups.com...
It is on the web site now! You can compile code using any compiler as long as you can get header files.
-- A. P. Richelieu > -Michael >
Indeed it is - they must have posted it in the last day or two as I checked quite recently. But are header files for it available? I suppose now that the datasheet is released if they aren't already available they will be soon.
-Michael
Internal SRAM are ususally 32K to 64K.
Yes, external SDRAM chips upto 256M, most ARMs has SDRAM controller only. Some can stack dies, which can be argued as internal or external.
For a cheap arm 7 dev boards look at
boards are made by olimex but its a lot easier to buy from sparkfun.com
They also have a good range of sensors
Alex
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.