Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #10572 > unrolled thread

Getting started with AVR and C

Back to article view | Back to comp.arch.embedded

Contents

  Getting started with AVR and C Robert Roland <fake@ddress.no> - 2012-11-24 17:41 +0100
    Re: Getting started with AVR and C hamilton <hamilton@nothere.com> - 2012-11-24 09:55 -0700
      Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 10:39 +0100
    Re: Getting started with AVR and C Rene <a@b.c> - 2012-11-24 18:03 +0100
      Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-10 13:21 +0100
        Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-12-10 18:33 -0800
          Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-11 12:34 +0100
    Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-24 12:44 -0600
    Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:12 -0800
    Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-24 11:28 -0800
      Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:42 -0800
        Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-25 07:01 -0800
      Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 20:14 +0100
    Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 03:18 +0700
    Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 04:18 +0700
      Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-24 17:09 -0500
      Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-24 22:12 +0000
        Re: Getting started with AVR and C Dave Nadler <drn@nadler.com> - 2012-11-24 21:01 -0800
          statement / expression contexts in C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 12:54 +0700
        Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 13:37 +0700
          Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-28 14:49 +0000
          Re: Getting started with AVR and C Frank Miles <fpm@u.washington.edu> - 2012-11-28 17:53 +0000
            Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 18:05 +0000
              Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 12:56 -0600
                Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 21:45 +0000
                  Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 15:55 -0600
                  Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-29 01:35 +0100
                    Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 01:47 +0100
                      Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:24 +0100
                    Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 01:18 +0000
                      Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 20:07 -0600
                        Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:23 +0000
                          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:01 -0500
                            Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 19:19 +0000
                              Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 14:32 -0500
                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 11:44 -0800
                              Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 21:23 +0000
                                Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:15 -0800
                              Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 09:26 -0800
                                Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 13:22 -0800
                                  Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 14:10 -0800
                                    Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:16 -0800
                                  Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-11-30 17:36 -0500
                                    Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:18 -0800
                                  Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 10:08 +0200
                                    Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 00:45 -0800
                                      Re: Getting started with AVR and C Ed Beroset <beroset@mindspring.com> - 2012-12-01 08:00 -0500
                                        Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 13:22 -0800
                                          Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-01 17:33 -0800
                                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 17:43 -0800
                                              Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-02 14:13 -0800
                                              Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-04 20:34 -0500
                                                Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-04 18:25 -0800
                                                  Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 07:55 -0500
                                                    Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:11 -0800
                                                  Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-05 07:52 -0800
                                                    Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 11:02 -0500
                                                    Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 21:28 +0200
                                                      Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:21 -0800
                                                        Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:05 +0200
                                                          Re: Getting started with AVR and C Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2012-12-05 23:22 +0200
                                                            Re: Getting started with AVR and C Niklas Holsti <niklas.holsti@tidorum.invalid> - 2012-12-06 00:00 +0200
                                                    Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:17 -0800
                                                      Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:10 +0200
                                                        Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
                                                          Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-06 07:15 +0200
                                                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 21:52 -0800
                                                          Re: Getting started with AVR and C Lanarcam <lanarcam1@yahoo.fr> - 2012-12-06 20:59 +0100
                                                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-06 12:38 -0800
                                                            Re: Getting started with AVR and C George Neuner <gneuner2@comcast.net> - 2012-12-06 20:39 -0500
                                                              Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 22:31 -0500
                                                      Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-12-05 16:32 -0500
                                                        Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
                                                          Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-05 17:04 -0800
                                                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 22:01 -0800
                                                            Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-12-06 14:05 +0000
                                                              Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-06 10:28 -0800
                                                                Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 16:58 -0800
                                                            Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 07:34 -0800
                                                              Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 10:55 -0500
                                                                Re: Getting started with AVR and C Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-06 11:11 -0500
                                                            Re: Getting started with AVR and C Rocky <RobertGush@gmail.com> - 2012-12-06 21:38 -0800
                                                              Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-07 03:49 -0800
                                    Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 02:58 -0600
                                      Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 17:28 +0200
                                        Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 11:55 -0600
                            Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:17 +0200
                              Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 12:36 -0800
                                Re: Getting started with AVR and C Stephen Sprunk <stephen@sprunk.org> - 2012-11-29 16:22 -0600
                                  Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:36 -0800
                                Re: Getting started with AVR and C "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-12-11 10:53 +0100
                                  Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-11 14:53 +0000
                                    Unicode Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:25 +0700
                                    Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 14:30 -0500
                                      Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 12:24 -0800
                                        Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 18:02 -0500
                                          Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 15:45 -0800
                                            Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-16 22:55 -0500
                                              Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-16 23:20 -0800
                                          Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:27 +0200
                                        Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-17 11:17 +0000
                                          Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:07 +0000
                                      Re: Getting started with AVR and C Nobody <nobody@nowhere.com> - 2012-12-16 03:28 +0000
                                      Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-16 10:40 +0200
                    Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 02:31 +0000
                      Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 03:36 +0000
                        Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 03:55 +0000
                          Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-11-28 23:24 -0800
                      Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:37 +0100
                        Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:31 +0000
                          Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:44 +0100
                        Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 13:22 +0100
                          Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:32 +0000
                            Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:28 -0800
                        Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:20 +0000
                        Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:07 -0500
                          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:17 -0500
                            Re: Getting started with AVR and C pete <pfiland@mindspring.com> - 2012-11-29 18:25 -0500
                              Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 22:46 -0500
                                Re: Getting started with AVR and C lawrence.jones@siemens.com - 2012-11-30 11:47 -0500
                          Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:38 -0800
                            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 15:21 -0500
                Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 22:26 +0000
                  Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 17:32 -0600
                    Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 19:02 -0500
                      Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 18:29 -0600
                        Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:39 -0500
                          Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-29 00:59 -0600
                            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 07:57 -0500
                              Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-29 13:02 -0600
                            Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:19 +0000
                          Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-29 12:03 +0200
                            Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:39 +0000
                            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 08:04 -0500
                        Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:17 +0000
                Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:19 -0600
                  Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:44 -0500
            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 13:15 -0500
              Re: Getting started with AVR and C Arlet Ottens <usenet+5@c-scape.nl> - 2012-11-28 19:17 +0100
                Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:30 -0600
                  Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:29 +0000
                    Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-29 16:36 +0000
                      Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:40 +0200
                        Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 13:55 -0800
                          Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 22:06 +0000
                            Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 14:22 -0800
                        Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 21:59 +0000
                          Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-30 08:29 +0000
      Re: Getting started with AVR and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-25 05:41 -0800
      Re: Getting started with AVR and C Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 10:21 +0100
    Re: Getting started with AVR and C dbr@kbrx.com - 2012-11-24 21:49 +0000
      Re: Getting started with AVR and C MK <mk@nospam.co.uk> - 2012-11-25 12:24 +0000
        Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-11-26 00:08 +0000

Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]

#10640

On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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.

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I could
                                  at               ever get started in the
                              gmail.com            credit world?

[toc] | [prev] | [next] | [standalone]

#10642

Grant Edwards <invalid@invalid.invalid> writes:

> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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.


-- 

John Devereux

[toc] | [prev] | [next] | [standalone]

#10652

On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
<john@devereux.me.uk> wrote:

>Grant Edwards <invalid@invalid.invalid> writes:
>
>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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.

 

[toc] | [prev] | [next] | [standalone]

#10654

On Thu, 29 Nov 2012 22:40:41 +0200, upsidedown@downunder.com
wrote:

>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
><john@devereux.me.uk> wrote:
>
>>Grant Edwards <invalid@invalid.invalid> writes:
>>
>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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. The
first and most obvious would be an operating system loading a
program into memory. While the O/S does this, the memory is
treated as data. A more meaningful example for small embedded
applications, perhaps, is the ability to modify interrupt
vectors pointing at code. If the processor refers to I space
only for interrupt vectors, it may not be possible. And there
are times when you have externally available code (large
external serial-access memory (low pin count), for example,
used to store code blocks infrequently needed and where the
internally supplied flash just isn't big enough.)

In embedded, there are reasons. For operating systems, there
are also reasons. And I am tapping only what is on the tip of
my tongue and using no imagination, right now.

Jon

[toc] | [prev] | [next] | [standalone]

#10656

On 2012-11-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Thu, 29 Nov 2012 22:40:41 +0200, upsidedown@downunder.com
> wrote:
>
>>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>><john@devereux.me.uk> wrote:
>>
>>>Grant Edwards <invalid@invalid.invalid> writes:
>>>
>>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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            

[toc] | [prev] | [next] | [standalone]

#10658

On Thu, 29 Nov 2012 22:06:08 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2012-11-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>> On Thu, 29 Nov 2012 22:40:41 +0200, upsidedown@downunder.com
>> wrote:
>>
>>>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>>><john@devereux.me.uk> wrote:
>>>
>>>>Grant Edwards <invalid@invalid.invalid> writes:
>>>>
>>>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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.

[toc] | [prev] | [next] | [standalone]

#10655

On 2012-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
><john@devereux.me.uk> wrote:
>
>>Grant Edwards <invalid@invalid.invalid> writes:
>>
>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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!

[toc] | [prev] | [next] | [standalone]

#10663

Grant Edwards <invalid@invalid.invalid> writes:

> On 2012-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>> On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>><john@devereux.me.uk> wrote:
>>
>>>Grant Edwards <invalid@invalid.invalid> writes:
>>>
>>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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

[toc] | [prev] | [next] | [standalone]

#10587

On Nov 24, 9:18 pm, Ivan Shmakov <oneing...@gmail.com> wrote:
> >>>>> Robert Roland <f...@ddress.no> writes:
>
>         [Cross-posting to news:comp.lang.c, in the hope that someone
>         could provide more suggestions, or correct me on C.]
>
> [...]
>
>  > 2. Where do I start learning C?  Is there a good online tutorial
>  > somewhere?  I'd also be willing to buy a book.  Is there one that
>  > stands out as the best?
>
>         Frankly, I don't quite understand how did I learn C myself.
>         FWIW, there were hardly any good book on that that I've read.

K&R?

[toc] | [prev] | [next] | [standalone]

#10595

On Sun, 25 Nov 2012 04:18:32 +0700, Ivan Shmakov <oneingray@gmail.com>
wrote:


>   int8_t i;                    /* not necessarily translated; may force
>                                   the compiler to "allocate" a register
>                                   (say, r7), or a memory cell */
>   i = 3;                       /* ldi r7, 3 */
>   i += 2;                      /* adi r7, 2 */
>   i++;                         /* inc r7    */
>   if (i < 9) {                 /* cpi r7, 9 ;  brge else_a */
>     int8_t j = 5;              /* ldi r8, 5 */
>     while (j >= 3) {           /* while_a:
>                                   cpi r8, 3
>                                   brlt end_while_a */
>       PORTB ^=  1;             /* in  r9, PORTB
>                                   eoi r9, 1
>                                   out PORTB, r9 */
>     }                          /* jmp while_a
>                                   end_while_a: */
>   }                            /* else_a:   */

for me 

>   i = 3;                       /* ldi r7, 3 */
>   i += 2;                      /* adi r7, 2 */
>   i++;                         /* inc r7    */

are the same
one call "r7", "i" and are the same

for the remain i possibly prefer my macroized 
part of the right side

than in the right side one can controll better the stack...

>[1] http://www.nongnu.org/avr-libc/user-manual/

[toc] | [prev] | [next] | [standalone]

#10581

Possibly the best, certainly the first, book on C is "The C Programming 
Language" by Kernighan & Ritchie.

Hul

Robert Roland <fake@ddress.no> wrote:
> I am quite used to playing with PICs and JAL v2. I use the PicKit3 for
> programming and debugging.

> Now I want to learn C and AVR. I thought it may be a good idea to do
> both at the same time.

> I already have a device with an ATMEGA168 in it. I want to write my
> own firmware for this device.

> I have installed the Atmel Studio 6 and downloaded the data sheet for
> the '168. Now I need a programmer/debugger. This is purely for hobby
> use, so I can't blow too much money on it.

> So, I have a couple of questions:

> 1. Which programmer/debugger should I buy? The JTAGICE3 is acceptably
> priced and appears to be very capable. Any reason to not get that one?

> 2. Where do I start learning C? Is there a good online tutorial
> somewhere? I'd also be willing to buy a book. Is there one that stands
> out as the best?
> -- 
> RoRo

[toc] | [prev] | [next] | [standalone]

#10586

On 24/11/2012 21:49, dbr@kbrx.com wrote:
> Possibly the best, certainly the first, book on C is "The C Programming
> Language" by Kernighan & Ritchie.
>

I'll second that - in fact it's not only the best book on C but the best 
book introducing ANY programming language.

(But for embedded stuff on an AVR it's not the whole story !)

Michael Kellett

[toc] | [prev] | [next] | [standalone]

#10592

MK <mk@nospam.co.uk> wrote in
news:mpqdnQCeHpt0kC_NnZ2dnUVZ8oydnZ2d@bt.com: 

> On 24/11/2012 21:49, dbr@kbrx.com wrote:
>> Possibly the best, certainly the first, book on C is "The C
>> Programming Language" by Kernighan & Ritchie.
>>
> 
> I'll second that - in fact it's not only the best book on C but the
> best book introducing ANY programming language.
> 
> (But for embedded stuff on an AVR it's not the whole story !)
> 
> Michael Kellett
> 
> 

Thirded, but for most embedded stuff one specifically wants the SECOND
EDITION which was rewritten for the ANSI C89/ISO C90 standard.   That's
much closer to the dialect of C many cross-compilers for small embedded
systems use. 

Also see "The C Book" (free, online, ANSI C89/ISO C90) - not quite as
clear as K&R but pretty good indeed. 
<http://publications.gbdirect.co.uk/c_book/> 

-- 
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED) 
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk 
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL

[toc] | [prev] | [standalone]

Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]

Back to top | Article view | comp.arch.embedded

csiph-web