On Oct 1, 11:50 am, Anton Erasmus <nob...@spam.prevent.net> wrote:> On Mon, 1 Oct 2007 14:45:14 +0200, "Meindert Sprang"> Just be aware that overall an AVR is much better than an ARM at bit> banging. Some variants of ARM MCUs are very slow at bit banging.Besides clock rates why are some ARM slower at bit banging?
AVR to ARM
Started by ●October 1, 2007
Reply by ●October 1, 20072007-10-01
Reply by ●October 2, 20072007-10-02
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> skrev i meddelandet news:4700e24b$0$25203$e4fe514c@dreader15.news.xs4all.nl...> "John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message > news:87ejgfgkzm.fsf@cordelia.devereux.me.uk... >> "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> writes: >> >> > Hi All, >> > >> > I am about to port an application from an AVR to an ARM. Most of the > code is >> > written in C but one particular driver is written in AVR assembler. I > was >> > wondering if a converter exists to translate AVR assembler to ARM > assembler >> > code. I find it easier to get to grips with new a new assembler syntax > by >> > starting with an existing piece of code instead of writing it from > scratch. >> >> Just rewrite it in C. >> >> If you really want it in assembler, you can then look at the compiler >> output! But I expect C on the arm will be faster than assembly on the >> AVR (unless you are deliberately running the ARM at low clock speed). > > I don't know. In my experience, some things are better written in > assembler. > In this case, the driver consists of an interrupt handler running at 19200 > Hz on an 8MHz AVR.On the ARM (running at 30MHz), I want to have it run at > 153,600Hz simply because the handler (a software UART) needs to run at > 38400 > baud instead of 4800 baud. And this driver is written so compact that I > cannot believe a C compiler could do any better. A compiler can only make > certain generic assumptions while I as a programmer know what the driver > is > supposed to do and I can for instance reserve certain registers to speed > up > things. >Seems to be a bad idea to run a S/W UART at 38,400 BAUD. You can get at least 4 H/W UARTs with a SAM7A3 and at 30 MHz, it can run zero waitstates from flash. The SAM7 will have DMA support, so there should be very little overhead. You should be able to run this at Mbit speed without much hassle. If you want to have a cheaper version, then you can use one of the SAM7S series chips, soon down to 16 kB code. 3 H/W USARTs with DMA support, and the last UART is best implemented using the Synchronous Serial Controller, which also has DMA support. One possible implementation is to let the transmitter run one bit per clock, with manually insertion of start stop bits, and then let the receiver work at a higher rate to allow multiple samples per bit. The RXD signal needs to be connected to an external interrupt, so when you receive a character, then the start bit will trigger the external interrupt. The interrupt routine will disable the external interrupt and start a timer, which times out at the end of the stop bit. The timer interrupt will analyze the received data to check for false start bit, and if start bit OK, it will look at selected bits of the oversampled RXD. It will also reenable the external interrupt to prepare for the next character. Obviously, the SSC UART should run at a higher priority than the H/W UARTs. Will you have yet another communication channel to multiplex the UART data (USB?)> Meindert >-- Best Regards, Ulf Samuelsson
Reply by ●October 2, 20072007-10-02
Hi Meindert, I think you will have little luck finding an automatic translator. Your application works near the limits of the source platform, and is probably structured (and highly optimized) towards it. It may even depend on cycle-exact behaviour. If any, the best reasonably expectable results of a translator would be just a rough approximation to your final result. It's probably quicker to split the problem into two parts. The core part (which detects edges and samples the bits) should be done in hand- written ARM assembler. The rest (which doesn't have any critical timing requirement) could be done in C, or with an automatic translator if you find any. Note that often changes to the algorithm help improve the performance. For your application I see two options for performance improvements: 1. If you have enough edge detectors and timer interrupts, you don't have to oversample the RX channels. You can detect the start bits using the edge-detector, and then program timer-interrupts to catch the middle of each received bit. On ARM, there's just one (well, two) interrupt vector, so you can handle all timer interrupts at once and thus avoid adding up latency to an otherwise very slow worst case. 2. If you prefer the oversampling method, and have enough memory, there's no need to do the processing within the interrupt. You can just sample the pins to a circular memory buffer and do offline processing. The buffer should be large enough to hold at least one complete RX symbol. An EOR run reveals edges (start bit). Once found, the middles of each bit can be read at a fixed memory offset. Using this method, the time-critical ASM portion of your code is about 10 lines. Regards, Marc
Reply by ●October 2, 20072007-10-02
foxchip wrote:> On Oct 1, 11:50 am, Anton Erasmus <nob...@spam.prevent.net> wrote: >> On Mon, 1 Oct 2007 14:45:14 +0200, "Meindert Sprang" > > Just be aware that overall an AVR is much better than an ARM at bit >> banging. Some variants of ARM MCUs are very slow at bit banging. > > Besides clock rates why are some ARM slower at bit banging? >Some ARM devices have their IO ports on a slower internal bus, so there can be a fair number of clock cycles latency for bit-banging. The same thing applies to some other 32-bit cpus.
Reply by ●October 3, 20072007-10-03
"David Brown" <david@westcontrol.removethisbit.com> skrev i meddelandet news:4702104f$0$3196$8404b019@news.wineasy.se...> foxchip wrote: >> On Oct 1, 11:50 am, Anton Erasmus <nob...@spam.prevent.net> wrote: >>> On Mon, 1 Oct 2007 14:45:14 +0200, "Meindert Sprang" >> > Just be aware that overall an AVR is much better than an ARM at bit >>> banging. Some variants of ARM MCUs are very slow at bit banging. >> >> Besides clock rates why are some ARM slower at bit banging? >> > > Some ARM devices have their IO ports on a slower internal bus, so there > can be a fair number of clock cycles latency for bit-banging. The same > thing applies to some other 32-bit cpus. >Production AT32uC3k chips will toggle I/O at 66 MHz. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
