1. Home
  2. Embedded Programming
  3. ARM7TDMI Instructions Taking 50-100 Clocks

ARM7TDMI Instructions Taking 50-100 Clocks

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?

Reply to
Alex Varanese
Loading thread data ...

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.

Reply to
Graeme

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

Reply to
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
Reply to
Ulf Samuelsson

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.