I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and am monitoring the system with an oscilloscope. By comparing the clock pulses to the read/write pulses, I'm finding that single-byte store and read operations are taking literally 50-100 clocks. Naturally this is unacceptable for any purpose, and is obviously a sign of something being majorly wrong. I've read all the literature on the ARM I can find including all of Atmel's documentation and white papers. Does anyone have any idea what this might be?
ARM7TDMI Instructions Taking 50-100 Clocks
Feb 04, 2004
3 Replies
Does this implementation of the ARM7 also include programmable timing for its memory interface (duration of reads, writes etc). I know the two devices that I've used allow this.
I think you've got it. The AT91R40807 that I used starts up the system with 8 wait states on CS0. One of the first steps in the boot process is to set an appropriate number of wait states for the speed of the memory actually in use.
Another factor may be in the reading and storing of single bytes. On a system with 16-bit memory width, single-byte reads and stores can take some extra cycles while the bytes get properly aligned. Storing a single byte may become a read-modify-write operation.
The OP didn't say whether the 50 to 100 clocks was the length of a single read or write cycle, or the time for a complete read-modify-write cycle.
Mark Borgerson
"Alex Varanese" skrev i meddelandet news: snipped-for-privacy@posting.google.com...
If you run the AT9155800A at 32 kHz then your performance will drop somewhat. It would help if you told us which chip and clock frequency you use.
Best Regards,
Ulf Samuelsson ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required