Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Getting started with AVR and C

Reply
Thread Tools

Re: Getting started with AVR and C

 
 
Grant Edwards
Guest
Posts: n/a
 
      11-29-2012
On 2012-11-29, http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> wrote:
> On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
><(E-Mail Removed)> wrote:
>
>>Grant Edwards <(E-Mail Removed)> writes:
>>
>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:
>>>
>>>> It's certainly what I would expect from gcc-avr. There's no reason you
>>>> can't make a beautifully compliant, reasonably efficient compiler that
>>>> works well on the AVR.
>>>
>>> avr-gcc does indeed work very nicely as long as you don't look at the
>>> code generated when you use pointers. You'll go blind -- especially
>>> if you're used to something like the msp430. It's easy to forget that
>>> the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
>>> 16-bit pointers on the AVR requires a lot of overhead.

>>
>>Other problem with it is the separate program and data memory
>>spaces. Fine for small deeply embedded things but started to show strain
>>when I wanted a LCD display, menus etc. I would not use it for a new
>>project unless there was a very good reason, ultra-low power
>>perhaps. Cortex M3 is much nicer but the chips are much more complicated
>>of course.

>
> Except for self modifying code, why would one want data (program)
> access into program space (unless you are writing a linker or
> debugger) ??


The "program" space was flash (non-volatile). The "data" space was
registers and RAM (volatile). All non-volatile data (strings, screen
templates, lookup tables, menu structures, and so) has to be in flash
memory (IOW "program space"). It makes a _lot_ of sense to just use
directly from flash instead of copying it all to RAM when RAM is so
scarce.

> While working with PDP-11's in the 1970's, the ability to use separate
> I/D (Instruction/Data) space helped a lot to keep code/data in private
> 64 KiD address spaces.


But in a PDP11, Data space was plentiful, and constant data didn't
also have to reside in Instruction space (because that's the only
non-volatile storage you have).

On some parts there is some erasable non-volatile storage in data
space. But, it's always scarce, and putting stuff there that is never
to be altered is both wasteful and dangerous.

--
Grant Edwards grant.b.edwards Yow! I didn't order any
at WOO-WOO ... Maybe a YUBBA
gmail.com ... But no WOO-WOO!
 
Reply With Quote
 
 
 
 
Grant Edwards
Guest
Posts: n/a
 
      11-29-2012
On 2012-11-29, Jon Kirwan <(E-Mail Removed)> wrote:
> On Thu, 29 Nov 2012 22:40:41 +0200, (E-Mail Removed)
> wrote:
>
>>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>><(E-Mail Removed)> wrote:
>>
>>>Grant Edwards <(E-Mail Removed)> writes:
>>>
>>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:
>>>>
>>>>> It's certainly what I would expect from gcc-avr. There's no reason you
>>>>> can't make a beautifully compliant, reasonably efficient compiler that
>>>>> works well on the AVR.
>>>>
>>>> avr-gcc does indeed work very nicely as long as you don't look at the
>>>> code generated when you use pointers. You'll go blind -- especially
>>>> if you're used to something like the msp430. It's easy to forget that
>>>> the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
>>>> 16-bit pointers on the AVR requires a lot of overhead.
>>>
>>>Other problem with it is the separate program and data memory
>>>spaces. Fine for small deeply embedded things but started to show strain
>>>when I wanted a LCD display, menus etc. I would not use it for a new
>>>project unless there was a very good reason, ultra-low power
>>>perhaps. Cortex M3 is much nicer but the chips are much more complicated
>>>of course.

>>
>>Except for self modifying code, why would one want data (program)
>>access into program space (unless you are writing a linker or
>>debugger) ??
>>
>>While working with PDP-11's in the 1970's, the ability to use separate
>>I/D (Instruction/Data) space helped a lot to keep code/data in private
>>64 KiD address spaces.

>
> There are good reasons for self-modifying code space.


Nobody said anything about modifying code space.

The "data" that's put in code space is never modified (at least not
any any project I've ever seen).

It's not _modifying_ the progam space that's the issue (that is
generally only done for firmware updates, where the entire flash is
erased and reprogrammed).

Simply _reading_ program space _as_data_ is problematic. If you've
got a lot of string constants or constant tables, you want to just
leave them in flash (program space) rather than copy them all to
(scarce) RAM on startup.

Now you need three-byte pointers/addresses to differentiate between
data at 0xABCD in data space and the data at 0xABCD in program space.
Three byte pointers is how some compilers solve that problem -- but I
don't think avr-gcc does that.

--
Grant Edwards grant.b.edwards Yow! I think my career
at is ruined!
gmail.com
 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      11-29-2012
On 29-Nov-12 14:36, Keith Thompson wrote:
> (E-Mail Removed) writes:
>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>>
>> On the Unicode list, I even suggested packing three 21 characters into
>> a single 64 bit data word as UTF-64

>
> I like it -- but it breaks as soon as they add U+200000 or higher, and
> I'm not aware of any guarantee that they won't.


I thought they had guaranteed they would never go above U+10FFFF, which
would break UTF-16.

> I've thought of UTF-24, encoding each character in 3 octets; that's
> good for up to 16,777,216 distinct code points.


AIUI, there are some DSPs with CHAR_BIT==24 (or was that 12?).

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
Jon Kirwan
Guest
Posts: n/a
 
      11-29-2012
On Thu, 29 Nov 2012 22:06:08 +0000 (UTC), Grant Edwards
<(E-Mail Removed)> wrote:

>On 2012-11-29, Jon Kirwan <(E-Mail Removed)> wrote:
>> On Thu, 29 Nov 2012 22:40:41 +0200, (E-Mail Removed)
>> wrote:
>>
>>>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>>><(E-Mail Removed)> wrote:
>>>
>>>>Grant Edwards <(E-Mail Removed)> writes:
>>>>
>>>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:
>>>>>
>>>>>> It's certainly what I would expect from gcc-avr. There's no reason you
>>>>>> can't make a beautifully compliant, reasonably efficient compiler that
>>>>>> works well on the AVR.
>>>>>
>>>>> avr-gcc does indeed work very nicely as long as you don't look at the
>>>>> code generated when you use pointers. You'll go blind -- especially
>>>>> if you're used to something like the msp430. It's easy to forget that
>>>>> the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
>>>>> 16-bit pointers on the AVR requires a lot of overhead.
>>>>
>>>>Other problem with it is the separate program and data memory
>>>>spaces. Fine for small deeply embedded things but started to show strain
>>>>when I wanted a LCD display, menus etc. I would not use it for a new
>>>>project unless there was a very good reason, ultra-low power
>>>>perhaps. Cortex M3 is much nicer but the chips are much more complicated
>>>>of course.
>>>
>>>Except for self modifying code, why would one want data (program)
>>>access into program space (unless you are writing a linker or
>>>debugger) ??
>>>
>>>While working with PDP-11's in the 1970's, the ability to use separate
>>>I/D (Instruction/Data) space helped a lot to keep code/data in private
>>>64 KiD address spaces.

>>
>> There are good reasons for self-modifying code space.

>
>Nobody said anything about modifying code space.


Sorry I didn't interpret things well.

>The "data" that's put in code space is never modified (at least not
>any any project I've ever seen).


I've needed writable code space. Thunking is one such
example.

>It's not _modifying_ the progam space that's the issue (that is
>generally only done for firmware updates, where the entire flash is
>erased and reprogrammed).


While I agree with the "generally" I don't agree that this
translates into 100%.

>Simply _reading_ program space _as_data_ is problematic. If you've
>got a lot of string constants or constant tables, you want to just
>leave them in flash (program space) rather than copy them all to
>(scarce) RAM on startup.


Indeed. Completely agreed.

Jon

>Now you need three-byte pointers/addresses to differentiate between
>data at 0xABCD in data space and the data at 0xABCD in program space.
>Three byte pointers is how some compilers solve that problem -- but I
>don't think avr-gcc does that.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-30-2012
glen herrmannsfeldt <(E-Mail Removed)> writes:
> In comp.lang.c Jon Kirwan <(E-Mail Removed)> wrote:
>> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
>> <(E-Mail Removed)> wrote:

>
>>><snip>
>>>Claims have frequently been made on
>>>comp.lang.c that, while the C standard allows CHAR_BIT != 8, the

>
> As I remember the stories, the CRAY-1 had 64 bit char.

[...]

That may well be true; I never used a Cray-1. (And there was more
emphasis on Fortran, or should I say FORTRAN, than on C.)

By the time I started using Crays, they were running Unicos, Cray's
version of Unix, so they pretty much had to have CHAR_BIT==8.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-30-2012
Stephen Sprunk <(E-Mail Removed)> writes:
> On 29-Nov-12 14:36, Keith Thompson wrote:
>> (E-Mail Removed) writes:
>>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>>>
>>> On the Unicode list, I even suggested packing three 21 characters into
>>> a single 64 bit data word as UTF-64

>>
>> I like it -- but it breaks as soon as they add U+200000 or higher, and
>> I'm not aware of any guarantee that they won't.

>
> I thought they had guaranteed they would never go above U+10FFFF, which
> would break UTF-16.


You're right. <http://www.unicode.org/faq/utf_bom.html> says:

Both Unicode and ISO 10646 have policies in place that formally
limit future code assignment to the integer range that can be
expressed with current UTF-16 (0 to 1,114,111).

>> I've thought of UTF-24, encoding each character in 3 octets; that's
>> good for up to 16,777,216 distinct code points.

>
> AIUI, there are some DSPs with CHAR_BIT==24 (or was that 12?).


--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      11-30-2012
Grant Edwards <(E-Mail Removed)> writes:

> On 2012-11-29, (E-Mail Removed) <(E-Mail Removed)> wrote:
>> On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>><(E-Mail Removed)> wrote:
>>
>>>Grant Edwards <(E-Mail Removed)> writes:
>>>
>>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:
>>>>
>>>>> It's certainly what I would expect from gcc-avr. There's no reason you
>>>>> can't make a beautifully compliant, reasonably efficient compiler that
>>>>> works well on the AVR.
>>>>
>>>> avr-gcc does indeed work very nicely as long as you don't look at the
>>>> code generated when you use pointers. You'll go blind -- especially
>>>> if you're used to something like the msp430. It's easy to forget that
>>>> the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
>>>> 16-bit pointers on the AVR requires a lot of overhead.
>>>
>>>Other problem with it is the separate program and data memory
>>>spaces. Fine for small deeply embedded things but started to show strain
>>>when I wanted a LCD display, menus etc. I would not use it for a new
>>>project unless there was a very good reason, ultra-low power
>>>perhaps. Cortex M3 is much nicer but the chips are much more complicated
>>>of course.

>>
>> Except for self modifying code, why would one want data (program)
>> access into program space (unless you are writing a linker or
>> debugger) ??

>
> The "program" space was flash (non-volatile). The "data" space was
> registers and RAM (volatile). All non-volatile data (strings, screen
> templates, lookup tables, menu structures, and so) has to be in flash
> memory (IOW "program space"). It makes a _lot_ of sense to just use
> directly from flash instead of copying it all to RAM when RAM is so
> scarce.


Yes, that is precisely it. The AVRs especially tended to have lots of
flash but little RAM. Access to program memory is possible on the AVR,
but you have to use special attribute modifiers everywhere and the
resulting objects become incompatible with the standard libraries, so
you have to write special versions of these...

Another thing is that, being an 8 bit machine, int and short operations
are not atomic. So you have to be very careful about protecting
variables shared with interrupt handlers (or other tasks in a preemptive
system). Good practice anyway of course but a modern CPU like Cortex M3
is a lot more forgiving since even 32 bit load/store operations are
atomic.

[...]


--

John Devereux
 
Reply With Quote
 
Boudewijn Dijkstra
Guest
Posts: n/a
 
      12-11-2012
Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson <(E-Mail Removed)>:
> (E-Mail Removed) writes:
>> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
>> <(E-Mail Removed)> wrote:
>>
>>> On 11/29/2012 10:23 AM, Grant Edwards wrote:
>>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:

>>
>>>> ... Trying to impliment
>>>> any sort of communications protocol with that was fun.

>>
>> Using left/right shifts and AND and OR operations work just fine.
>> Works OK with different CHAR_BIT and different endianness platforms.
>> Do not try to use structs etc.
>>
>>> Thanks for that information. Claims have frequently been made on
>>> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
>>> existence of such implementations is a myth. I'm glad to have a
>>> specific counter example to cite.

>>
>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>>
>> On the Unicode list, I even suggested packing three 21 characters into
>> a single 64 bit data word as UTF-64

>
> I like it -- but it breaks as soon as they add U+200000 or higher


Not really. You can use the spare bit to indicate a different packing.

> , and I'm not aware of any guarantee that they won't.
>
> I've thought of UTF-24, encoding each character in 3 octets; that's
> good for up to 16,777,216 distinct code points.


I hope that, when the galactic discovery is underway that would make this
amount of code points necessary, software engineering will have evolved
beyond the point of humans worrying about bit widths and encodings.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      12-11-2012
"Boudewijn Dijkstra" <(E-Mail Removed)> writes:

> Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson <(E-Mail Removed)>:
>> (E-Mail Removed) writes:
>>> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
>>> <(E-Mail Removed)> wrote:
>>>
>>>> On 11/29/2012 10:23 AM, Grant Edwards wrote:
>>>>> On 2012-11-29, Tim Wescott <(E-Mail Removed)> wrote:
>>>
>>>>> ... Trying to impliment
>>>>> any sort of communications protocol with that was fun.
>>>
>>> Using left/right shifts and AND and OR operations work just fine.
>>> Works OK with different CHAR_BIT and different endianness platforms.
>>> Do not try to use structs etc.
>>>
>>>> Thanks for that information. Claims have frequently been made on
>>>> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
>>>> existence of such implementations is a myth. I'm glad to have a
>>>> specific counter example to cite.
>>>
>>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>>>
>>> On the Unicode list, I even suggested packing three 21 characters into
>>> a single 64 bit data word as UTF-64

>>
>> I like it -- but it breaks as soon as they add U+200000 or higher

>
> Not really. You can use the spare bit to indicate a different packing.
>
>> , and I'm not aware of any guarantee that they won't.
>>
>> I've thought of UTF-24, encoding each character in 3 octets; that's
>> good for up to 16,777,216 distinct code points.

>
> I hope that, when the galactic discovery is underway that would make
> this amount of code points necessary, software engineering will have
> evolved beyond the point of humans worrying about bit widths and
> encodings.


UTF-8 is the way forward isn't it?

--

John Devereux
 
Reply With Quote
 
Ivan Shmakov
Guest
Posts: n/a
 
      12-14-2012
>>>>> John Devereux <(E-Mail Removed)> writes:
>>>>> "Boudewijn Dijkstra" <(E-Mail Removed)> writes:
>>>>> Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson:


[...]

>>> I've thought of UTF-24, encoding each character in 3 octets; that's
>>> good for up to 16,777,216 distinct code points.


>> I hope that, when the galactic discovery is underway that would make
>> this amount of code points necessary, software engineering will have
>> evolved beyond the point of humans worrying about bit widths and
>> encodings.


> UTF-8 is the way forward isn't it?


I doubt it is. FWIW, it requires three octets for Cyrillic,
while UTF-16 requires only two. Personally, I'd try to use the
latter whenever possible (which means: anywhere, unless OS
interaction issues are deeply involved in the matter.)

--
FSF associate member #7257
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Denon avr-3300 problem gbozovic11@yahoo.com DVD Video 1 10-20-2005 09:56 PM
AVR core and patents avishay VHDL 0 06-09-2005 01:10 PM
AVR's 2005 Audio-Video Predictions Diane Sherwin DVD Video 0 12-31-2004 01:28 AM
ANN: ESF support for the Atmel AVR 8-Bit RISC microcontroller j.laws@ieee.org C++ 0 07-26-2004 09:46 PM
Denon AVR 5803 Setup Question Joseph Atsmon DVD Video 2 11-03-2003 07:38 AM



Advertisments