"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
Reply by David Brown●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 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 Ulf Samuelsson●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 foxchip●October 1, 20072007-10-01
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?
Reply by Anton Erasmus●October 1, 20072007-10-01
On Mon, 1 Oct 2007 14:45:14 +0200, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:
>"Habib Bouaziz-Viallet" <habib@mizar.systems> wrote in message
>news:4700dfec$0$30560$426a74cc@news.free.fr...
>> Le Mon, 01 Oct 2007 12:28:40 +0200, Meindert Sprang a �crit:
>>
>> > 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.
>> I'm not sure that this kind of translator really exist.
>> I already ported a custom driver (CompactFlash) from AVR to ARM. ARM
>> assembler is much more complex than the AVR's so i resigned to implement
>it
>> in ARM asm, i did it in C.
>>
>> BTW what sort of driver is it ?
>
>A software UART, running four RX channels, including a FIFO per channel and
>one TX channel. Taking up 40% of processor time on an 8MHz AVR.
>
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.
Regards
Anton Erasmus
Reply by Tim Wescott●October 1, 20072007-10-01
Meindert Sprang wrote:
> 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.
>
Such converters are common, and they're available in nearly every town
that has any high-tech activity at all. They're called "good assembly
language programmers".
Sorry for being a smart-ass, but that's the best you're going to do,
particularly since "driver" implies "close to the hardware", and the
hardware is going to be different.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
> "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.
Well, you may be right. But I think my advice stands, write it in C
first and try it. Look at the assembly output, do some timings.
> 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.
ARMs have the FIQ - I was able to get this running at >1MHz, using C,
on a ~40MHz device. I don't know what ARM variant you are using, but
the fastest is usually ARM mode (vs thumb) running out of on-chip RAM.
As for being able to do better than the compiler - all I know is that
gcc is better at ARM assembly than *I* am!
--
John Devereux
Reply by Meindert Sprang●October 1, 20072007-10-01
"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:4700e77c$0$3208$8404b019@news.wineasy.se...
> I wrote a 38400 baud software uart for an AVR with a 7.27 MHz clock,
> with interrupts at 153.6 kHz. With only 48 clock cycles between
> interrupts, it was worth writing the routing in assembly.
In my case, it is a software UART running four RX channels, including a FIFO
per channel and one TX channel. Taking up 40% of processor time on an 8MHz
AVR.
Meindert
Reply by Meindert Sprang●October 1, 20072007-10-01
"Habib Bouaziz-Viallet" <habib@mizar.systems> wrote in message
news:4700dfec$0$30560$426a74cc@news.free.fr...
> Le Mon, 01 Oct 2007 12:28:40 +0200, Meindert Sprang a �crit:
>
> > 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.
> I'm not sure that this kind of translator really exist.
> I already ported a custom driver (CompactFlash) from AVR to ARM. ARM
> assembler is much more complex than the AVR's so i resigned to implement
it
> in ARM asm, i did it in C.
>
> BTW what sort of driver is it ?
A software UART, running four RX channels, including a FIFO per channel and
one TX channel. Taking up 40% of processor time on an 8MHz AVR.
Meindert