Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #10572 > unrolled thread
| Started by | Robert Roland <fake@ddress.no> |
|---|---|
| First post | 2012-11-24 17:41 +0100 |
| Last post | 2012-11-26 00:08 +0000 |
| Articles | 20 on this page of 153 — 47 participants |
Back to article view | Back to comp.arch.embedded
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 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Robert Roland <fake@ddress.no> |
|---|---|
| Date | 2012-11-24 17:41 +0100 |
| Subject | Getting started with AVR and C |
| Message-ID | <22t1b8pt63pcb3fks5ic03tsnlnhlm6ef1@4ax.com> |
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] | [next] | [standalone]
| From | hamilton <hamilton@nothere.com> |
|---|---|
| Date | 2012-11-24 09:55 -0700 |
| Message-ID | <k8qu5h$cb9$1@dont-email.me> |
| In reply to | #10572 |
On 11/24/2012 9:41 AM, Robert Roland 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? If you want to move on to 32bit AVR, no. If you want just 8bit AVR, try Atmel AVR Dragon (ATAVRDRAGON) AT $49 vs $99 its easier on the wallet. > > 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? There are so many projects on the AVR, using the WINAVR compiler, you can find a project your interested in copying and read the code they built. Google WINAVR to find where to download the compiler. There are good tutorials on getting the compiler to hook up to the Atmel Studio 6. Lots of FREE C books out there as well. hamilton
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2012-11-25 10:39 +0100 |
| Message-ID | <JoWdneclMeL_eizNnZ2dnUVZ8o2dnZ2d@lyse.net> |
| In reply to | #10573 |
On 24/11/12 17:55, hamilton wrote: >> 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? > > There are so many projects on the AVR, using the WINAVR compiler, you > can find a project your interested in copying and read the code they built. > > Google WINAVR to find where to download the compiler. > There are good tutorials on getting the compiler to hook up to the Atmel > Studio 6. > > Lots of FREE C books out there as well. > > hamilton WINAVR was the name of the package of the gcc compiler toolchain for the AVR, along with libraries, an editor, and a selection of utilities as a ready-to-install package for Windows. With Atmel AVR Studio 4 and before, you could set up AVR Studio to work with the toolchain from WINAVR. But now the gcc toolchain is provided with Atmel AVR Studio. You don't need to get WINAVR separately - indeed you should not do so, because it has not been updated for a long time. When you use the "built-in" compiler in AVR Studio, you are using gcc already. Most projects for "WINAVR" will work fine with recent versions of AVR gcc in AVR Studio 6, though there may be small differences. (The AVR gcc toolchain is also available from Atmel without AVR Studio, for Windows and Linux, and of course you can put together your own avr gcc toolchain if you want. But the package along with AVR Studio is going to be the simplest way for most users.)
[toc] | [prev] | [next] | [standalone]
| From | Rene <a@b.c> |
|---|---|
| Date | 2012-11-24 18:03 +0100 |
| Message-ID | <k8qulh$f78$1@dont-email.me> |
| In reply to | #10572 |
On 11/24/2012 05:41 PM, Robert Roland 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?
The AVR dragon is cheap and does it's job well. Don't know about the
JTAGICE3, can't give you a reason why to buy it or not.
> 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?
There is a book by Ivor Horton about C, a very thick one, that is not
bad. I am sure that there are many good tutorials around but also that
there are tons of crappy ones and especially for someone who is new to
the topic it may be difficult to distinguish between them, that way you
run the risk of loosing much time (it is never really wasted but when
there is a shortcut why not take that), perhaps someone can point you to
a good one that he or she has read him or herself. Most books about C
however are about writing pc programs and not firmware for an AVR or
other embedded devices. Off course the language remains the same but the
language itself is not complicated, the most important thing that one is
doing when programming is glueing library things together with own code.
Getting to know the libraries is what takes up most time. The libraries
that one uses in an embedded program often are often very different from
the ones that one would use to create a GUI based pc program. But this
is something that one learns when walking the path, seeking on the web
for info when needed. So I think I would recommend the book by Ivor
Horton ("Beginning C: From Novice to Professional" by Apress) to start
with and then just dive into deep water by setting yourself certain
goals and just start working on them, looking for info and/or help when
you need it.
Programming AVR's is great fun, I like it very much and I wish you a lot
of joy. Getting to know the basics about C may be a bit boring in the
beginning but when you get the hang of it, creativity will find it's way
into your work and that's were the real fun starts. By the way, C also
is very much fun, it is my favorite programming language. When you know
assembler (which I suppose you do from the PIC), you will recognize many
things.
Yours sincerely,
Rene
[toc] | [prev] | [next] | [standalone]
| From | Rene <a@b.c> |
|---|---|
| Date | 2012-12-10 13:21 +0100 |
| Message-ID | <ka4k4g$d88$1@dont-email.me> |
| In reply to | #10574 |
Hi again Robert, Yesterday I thought of something I thought I might add to my reply, in case you are still reading this thread. In C there are certain types, e.g. "int", but there is no law that says how an int is stored in memory. It may be 16 bits or 32 or whatever (the compiler chooses this). There are however also types that specify exactly how wide they are, these are in the header file inttypes.h. Then you can choose things like uint16_t or int32_t. Especially in embedded systems these are very handy but to be honest, I use them in every C program I write nowadays. You may not find this "type of types" mentioned in for example the book I recommended, in practice they are more of an embedded / low level stuff thing but like I said, I always use them and I thought it wouldn't be a bad thing to explicitely mention them to you. Good luck again! Sincerely, Rene
[toc] | [prev] | [next] | [standalone]
| From | Christopher Head <chead@is.invalid> |
|---|---|
| Date | 2012-12-10 18:33 -0800 |
| Message-ID | <20121210183335.32a5f334@kruskal.chead> |
| In reply to | #10749 |
On Mon, 10 Dec 2012 13:21:35 +0100 Rene <a@b.c> wrote: > In C there are certain types, e.g. "int", but there is no law that > says how an int is stored in memory. It may be 16 bits or 32 or > whatever (the compiler chooses this). There are however also types > that specify exactly how wide they are, these are in the header file > inttypes.h. Then you can choose things like uint16_t or int32_t. > Especially in embedded systems these are very handy but to be honest, > I use them in every C program I write nowadays. Agreed those are wonderful types for situations where they make sense, but they are actually in stdint.h, not inttypes.h. inttypes.h contains various related goop like the PRI/SCN macros and other bits and pieces. Chris
[toc] | [prev] | [next] | [standalone]
| From | Rene <a@b.c> |
|---|---|
| Date | 2012-12-11 12:34 +0100 |
| Message-ID | <ka75or$poh$1@dont-email.me> |
| In reply to | #10754 |
On 12/11/2012 03:33 AM, Christopher Head wrote: > On Mon, 10 Dec 2012 13:21:35 +0100 > Rene <a@b.c> wrote: > >> In C there are certain types, e.g. "int", but there is no law that >> says how an int is stored in memory. It may be 16 bits or 32 or >> whatever (the compiler chooses this). There are however also types >> that specify exactly how wide they are, these are in the header file >> inttypes.h. Then you can choose things like uint16_t or int32_t. >> Especially in embedded systems these are very handy but to be honest, >> I use them in every C program I write nowadays. > > Agreed those are wonderful types for situations where they make sense, > but they are actually in stdint.h, not inttypes.h. inttypes.h contains > various related goop like the PRI/SCN macros and other bits and pieces. > > Chris Hm, I had noticed myself that in a certain source file in which these types were used I had not included inttypes.h and it still worked. But I thought that probably it was included through some other included file. Obviously my assumption was wrong, my apologies for spreading this incorrect information and thanks to Chris for correcting it. Yours sincerely, Rene
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.please> |
|---|---|
| Date | 2012-11-24 12:44 -0600 |
| Message-ID | <Ca6dnT8Og6c6iCzNnZ2dnUVZ_tydnZ2d@web-ster.com> |
| In reply to | #10572 |
On Sat, 24 Nov 2012 17:41:02 +0100, Robert Roland 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? If you were anything other than an accomplished assembly programmer I wouldn't make this suggestion. But you are, so here goes: First, get yourself a copy of Harbison and Steele's "C, A Reference Manual". It _will not_ teach you how to program in C from scratch. It _will_ show you what the C compiler does (H & S are compiler writers) and what is ANSI C vs. your compilers peculiarities and extensions. Second, look for projects that already work. Some of the code will be good, some will be bad, so review what you find. What you're really looking for is help in getting C working in a bare-bones environment. Third, figure out how to get your compiler to emit assembly language instead of (or in addition to) object code. If you already code in assembly, then nothing will teach you C faster than looking at what the compiler generates from what you type in. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | me@linnix.info-for.us |
|---|---|
| Date | 2012-11-24 11:12 -0800 |
| Message-ID | <ab402335-742f-48eb-bfae-9f7654fc63d1@googlegroups.com> |
| In reply to | #10572 |
On Saturday, November 24, 2012 8:41:09 AM UTC-8, Robert Roland 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 > Here is a demo for programming PIC/AVR and wireless. http://youtu.be/MG2MCtA75o8 Stay tune, more coming up.
[toc] | [prev] | [next] | [standalone]
| From | mike <ham789@netzero.net> |
|---|---|
| Date | 2012-11-24 11:28 -0800 |
| Message-ID | <k8r75q$1uo$1@dont-email.me> |
| In reply to | #10572 |
On 11/24/2012 8:41 AM, Robert Roland 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? You say you want to learn. Ask yourself why. What are you gonna do with the knowledge when you get it? That can have a huge impact on your path. Makes little sense to learn how to program an AVR if your goal is to land a job programming a PC. With the AVR, you're more concerned about accessing the hardware directly. With a PC, you're more likely to need to manipulate a database. Electronics is a hobby for me. I write PC programs with visual basic. I learned to write PIC programs with PICbasic. Both languages just work. They require very little configuration. And lots of macros/subroutines exist to do your bidding. You configure it with checkboxes. My projects have evolved to building hardware interfaces and real-time stuff on a PIC that's connected to a PalmIII programmed in "dialect" that does the heavy lifting and touch GUI. I never attempted to do floating point math on the PIC...that's what the Palm is for. My development board has a character LCD and keyboard, but I haven't used them in years. All my programs have inline assembly code and are interrupt driven. I've found that software simulation is useless. Hardware debugging that has ANY impact on the program flow is more disruptive than helpful. The result is that I need a device programmer that makes it trivial to change the code and try again. A serial bootloader does that nicely. JTAG should do that if the required pins can be isolated. I've found a logic analyzer helpful debugging the relationship between some input and the failure symptom. On several occasions I sought to learn C. First with the PIC, the MSP430 and then Arduino. The C language is not difficult. If you can program in any language, C is a matter of different syntactical details. My difficulty with C was that C can't do much. It's all about the libraries. Coming from a BASIC background, I found it annoying that I couldn't even concatenate two strings without a library function call. On the surface, it's not difficult the second time you do it. The difficulty is determining that you need a function call, determining which library contains it, where to get it, how to include it with the correct parameters. No big deal the second time you do it. Pile up a dozen of these decisions, then try to figger out why it don't run. There are just too many unfamiliar development details to start from scratch. I also found that C took a lot more memory recall. I kept having to look up stuff that I hadn't used recently. What the newbie needs is a set of example programs. "Hello world" ain't gonna do it. Code snippets ain't gonna do it. I needed FULL programs that accessed the internal hardware functions of the chip with all the little details, includes, libraries and configuration details for the specific toolset already configured to compile and run. I messed around with the gcc microcontroller toolset. Never found the libraries I needed or any full tutorial on how to get all the tools installed and working. Lotsa tutorials on pieces, just not how to make it all work together. A process that took one line in PIC basic looked like it would take a LOT of work in C. Those built-in functions really simplify stuff. Toolsets that claim to just work cost big bucks. Available free demo versions are an option if the limits are acceptable. In my case, my attention span was shorter than the time it took to get a FREE development environment up and running. And it didn't see where it gave me any more capability than I had with the PIC. Motivation has a lot to do with success. I suggest you learn the basics of C on your PC. Maybe port to an AVR simulator. Then you'll be in a much better position to determine what hardware you want to buy. Sounds like the long way around, but I bet you get there faster and pull out less hair. Sorry, I can't help with more info. I gave up before I found anything FREE I could use. The devil is in the details... the details that everybody knows...except me...so they're not mentioned.
[toc] | [prev] | [next] | [standalone]
| From | me@linnix.info-for.us |
|---|---|
| Date | 2012-11-24 11:42 -0800 |
| Message-ID | <bb608783-56c5-4d42-976b-b7a4864ef154@googlegroups.com> |
| In reply to | #10577 |
> You say you want to learn. > Ask yourself why. What are you gonna do with the knowledge when you get it? > That can have a huge impact on your path. Makes little sense to > learn how to program an AVR if your goal is to land a job programming > a PC. With the AVR, you're more concerned about accessing the > hardware directly. With a PC, you're more likely to need to manipulate > a database. > Don't discourage someone trying to learn. You'll never know when it will be useful, even with limited capabilities like AVR. It's useful because the hardware is cheaper and lower power. For the project i posted, there are four development environments: 1. WinAVR/avr-gcc low end devices 2. MPLab/mips-gcc coordinator 3. MSVC++ bootloader/monitor 4. Android ADT remote interface All are necessary to put things together. http://youtu.be/MG2MCtA75o8
[toc] | [prev] | [next] | [standalone]
| From | mike <ham789@netzero.net> |
|---|---|
| Date | 2012-11-25 07:01 -0800 |
| Message-ID | <k8tbti$hsn$1@dont-email.me> |
| In reply to | #10578 |
On 11/24/2012 11:42 AM, me@linnix.info-for.us wrote: >> You say you want to learn. >> Ask yourself why. What are you gonna do with the knowledge when you get it? >> That can have a huge impact on your path. Makes little sense to >> learn how to program an AVR if your goal is to land a job programming >> a PC. With the AVR, you're more concerned about accessing the >> hardware directly. With a PC, you're more likely to need to manipulate >> a database. >> > > Don't discourage someone trying to learn. You'll never know when it will be useful, even with limited capabilities like AVR. It's useful because the hardware is cheaper and lower power. > Well, when you snip the conclusion... Life is all about priorities. I'm downloading the AVR Studio 6. Looks good on paper, we'll see how the function libraries look. I've been really spoiled by PICBasic that hides all the quirks of the PIC and automagically configures I/O and formats I/O data...but I do like the AVR architecture better. The OLIMEXINO-32U4 board looks good too. I'm still fighting with my cheaper side about paying $10 shipping on a $16 device that I don't really need. Be interesting to see which side wins. ;-) > For the project i posted, there are four development environments: > > 1. WinAVR/avr-gcc low end devices > 2. MPLab/mips-gcc coordinator > 3. MSVC++ bootloader/monitor > 4. Android ADT remote interface > > All are necessary to put things together. > > http://youtu.be/MG2MCtA75o8
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2012-11-25 20:14 +0100 |
| Message-ID | <rsadneoNs8eL8y_NnZ2dnUVZ8n6dnZ2d@lyse.net> |
| In reply to | #10577 |
On 24/11/12 20:28, mike wrote:> On 11/24/2012 8:41 AM, Robert Roland 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? > > You say you want to learn. Ask yourself why. What are you gonna do > with the knowledge when you get it? That can have a huge impact on > your path. Makes little sense to learn how to program an AVR if your > goal is to land a job programming a PC. With the AVR, you're more > concerned about accessing the hardware directly. With a PC, you're > more likely to need to manipulate a database. > > Electronics is a hobby for me. I write PC programs with visual > basic. I learned to write PIC programs with PICbasic. Both languages > just work. They require very little configuration. And lots of > macros/subroutines exist to do your bidding. You configure it with > checkboxes. > > My projects have evolved to building hardware interfaces and > real-time stuff on a PIC that's connected to a PalmIII programmed in > "dialect" that does the heavy lifting and touch GUI. I never > attempted to do floating point math on the PIC...that's what the Palm > is for. My development board has a character LCD and keyboard, but I > haven't used them in years. All my programs have inline assembly code > and are interrupt driven. I've found that software simulation is > useless. Hardware debugging that has ANY impact on the program flow > is more disruptive than helpful. The result is that I need a device > programmer that makes it trivial to change the code and try again. A > serial bootloader does that nicely. JTAG should do that if the > required pins can be isolated. I've found a logic analyzer helpful > debugging the relationship between some input and the failure > symptom. > For some types of embedded programming, debugging that interrupts the flow of operation will not work. For example, you don't want to set breakpoints in the middle of a motor controller algorithm. For other types of work, disruptive debugging is fine. And simulation is often very useful - don't generalise from your limited experience. > On several occasions I sought to learn C. First with the PIC, the > MSP430 and then Arduino. > > The C language is not difficult. If you can program in any language, > C is a matter of different syntactical details. My difficulty with C > was that C can't do much. It's all about the libraries. The rest of the programming world manages to vast amounts with the C language - with and without libraries. I've done professional embedded programming for 20 years, and I can count on one hand the number of times I've wanted to concatenate two strings on a small embedded system. If the only tool you are familiar with is a hammer, then you'll find it very difficult to use a screwdriver properly. If you come from a Basic background, and try to write your C systems as though C was "a bit like Basic, but can't do strings", then you will obviously have a lot of difficultly. > Coming from a BASIC background, I found it annoying that I couldn't > even concatenate two strings without a library function call. On the > surface, it's not difficult the second time you do it. The > difficulty is determining that you need a function call, determining > which library contains it, where to get it, how to include it with > the correct parameters. No big deal the second time you do it. Pile > up a dozen of these decisions, then try to figger out why it don't > run. There are just too many unfamiliar development details to start > from scratch. I also found that C took a lot more memory recall. I > kept having to look up stuff that I hadn't used recently. > > What the newbie needs is a set of example programs. "Hello world" > ain't gonna do it. Code snippets ain't gonna do it. I needed FULL > programs that accessed the internal hardware functions of the chip > with all the little details, includes, libraries and configuration > details for the specific toolset already configured to compile and > run. > > I messed around with the gcc microcontroller toolset. Never found the > libraries I needed or any full tutorial on how to get all the tools > installed and working. Lotsa tutorials on pieces, just not how to > make it all work together. There are /hundreds/ of "gcc microcontroller toolset" packages available - because gcc supports dozens of different targets, and there are lots of people making them. So such a blanket statement makes no sense. In particular, there are gcc-based toolsets that are hard to install, and some that are easy to install. All come with at least basic libraries, but some come with more advanced ones. Some come with ready-to-use debuggers, editors and IDEs, others expect you to provide them yourself. Some come with top-class commercial support (at a price), others are entirely free and provide top-class free support. (And others provide poor support, either free or paid-for.) In this particular case, AVR Studio 6 comes with a gcc toolchain. So assuming you are using Windows, the "tutorial on how to get it all installed and working" is "Download AVR Studio 6 from Atmel's website. Install it like any other Windows program by pressing "Next" a lot". It does not get any easier. > > A process that took one line in PIC basic looked like it would take a > LOT of work in C. Those built-in functions really simplify stuff. > > Toolsets that claim to just work cost big bucks. Available free demo > versions are an option if the limits are acceptable. I don't know where you are getting your information - I suspect it is from very limited or very biased experience. There /are/ toolchains that cost big bucks - and there are some toolchains (for some targets) that are /worth/ big bucks. But no one ever claims that "big bucks" means the toolchains are easy to use - and people seldom claim that they are easier to install or use than free toolchains (at least, ready-packaged free toolchains). People who are willing to spend big bucks on tools are willing to spend time learning to make the most of them - they are not looking for "click and drool" interfaces. > > In my case, my attention span was shorter than the time it took to > get a FREE development environment up and running. And it didn't see > where it gave me any more capability than I had with the PIC. > Motivation has a lot to do with success. > > I suggest you learn the basics of C on your PC. Maybe port to an AVR > simulator. Then you'll be in a much better position to determine > what hardware you want to buy. Sounds like the long way around, but I > bet you get there faster and pull out less hair. > > Sorry, I can't help with more info. I gave up before I found > anything FREE I could use. The devil is in the details... the > details that everybody knows...except me...so they're not mentioned.
[toc] | [prev] | [next] | [standalone]
| From | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| Date | 2012-11-25 03:18 +0700 |
| Message-ID | <86ip8u69g4.fsf@gray.siamics.net> |
| In reply to | #10572 |
>>>>> Robert Roland <fake@ddress.no> writes:
[...]
> 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?
Apart from using a "hardware" programmer, there's an option to
use a program that will interact with the MCU by directly
"bit-banging" a hardware PC port, such as RS-232 ("serial port")
or IEEE 1284 ("parallel port") one. Naturally, for RS-232 one'd
need a MAX3232 (MAX232, if only 5V operation is necessary), or a
similar IC.
The AVR serial programming interface is just four lines wide:
/Reset, Clock, Data-to-Device (MOSI), Data-to-Host (MISO.)
Unfortunately, /three/ of them are to be driven by the host,
while MAX3232 provides only two level converters for each
direction (and, generally, only two PC RS-232 lines are suitable
for bit-banging.) So, a typical circuit would use a resistor
and a Zener diode on the TxD RS-232 line for /Reset. For Clock
and MOSI, RTS and DTR are used, while for the MISO line, either
of the device-to-host lines (RI, DCD, DSR, CTS) may be used.
For the software, my preference is AVRDUDE [1]. Naturally, it
allows for an arbitrarily-wired serial bit-banging dongle. For
instance, the one I use is wired as follows:
--cut: avrduderc --
programmer
id = "msiprog";
desc = "Modified Lancos SI-Prog <http://www.lancos.com/siprogsch.html>";
type = serbb;
reset = ~3; # /TxD
sck = 7; # RTS
mosi = ~4; # /DTR
miso = ~8; # /CTS
;
--cut: avrduderc --
[1] http://nongnu.org/avrdude/
[...]
--
FSF associate member #7257
[toc] | [prev] | [next] | [standalone]
| From | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| Date | 2012-11-25 04:18 +0700 |
| Message-ID | <86boem66on.fsf@gray.siamics.net> |
| In reply to | #10572 |
>>>>> Robert Roland <fake@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.
Two aspects of C are probably to be highlighted:
* first of all, unlike some other, and higher-level, languages
(like Pascal, BASIC, etc.), C has a very concise set of
syntactic constructs; most of the power lies in libraries, and
should you end up using AVR Libc, be sure to check its
reference manual [1] (it isn't as good as the GNU C Library
manual I'm using for the most time I need information on C,
but it's still useful);
* the C constructs tend to be translated into assembly in a
rather straightforward manner (unless advanced optimization is
involved, that is); consider, e. g.:
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: */
Not to undermine its value, but as could be seen (I hope) from
this example, for the most part, C only manages registers and
memory (including function calling conventions) while the rest
of its /syntax/ is comparable to that of a library of assembly
language macros of some sort.
A cheat sheet for most of the C operators would probably be
something like the following (where a, b, c, ... are either
numeric literals, variable identifiers, or expressions.) Note
that whenever all the operands are integer, an integer operation
is performed. (So, 7 / 3 is 2.) The result is as wide as the
widest of the operands. (So, i + j is 0 if i is 255, j is 1,
and both are declared to be of the 8-bit unsigned integer
uint8_t type.)
Operation Value Side-effect
Operations free of side-effects
+ a a
- a - a
* a the value of the memory cell at address
a
& a the address of a (must be an "l-value")
~ a bitwise negated a
! a 1 if a is 0,
0 otherwise
a, b b
NB: a is evaluated first, its result discarded.
a + b a + b
a - b a - b
a * b a b
a / b a / b (quotient of)
a % b remainder of a / b
a & b a (bitwise and) b
a | b a (bitwise or) b
a ^ b a (bitwise exclusive or) b
a << b a times 2 ^b (shift left)
a >> b a times 2 ^(-b) (shift right)
a < b 1 if a is less than b,
0 otherwise
a > b 1 if a is greater than b,
0 otherwise
a == b 1 if a is equal to b,
0 otherwise
a <= b 1 if a is less than or equal to b,
0 otherwise
a >= b 1 if a is greater than or equal to b,
0 otherwise
Conditional operations
a && b a is evaluated;
if a is non-zero, the value is b;
otherwise, the value is 0, while b is
not evaluated at all
a || b a is evaluated;
if a is zero, the value is b;
otherwise, the value is a, while b is
not evaluated at all
a ? b : c a is evaluated first;
if a is non-zero, the value is b;
otherwise, the value is c;
the other ("unused") expression is not
evaluated
Operations with side-effects
NB: a must be an "l-value"
a++ a a set to a + 1
a-- a a set to a - 1
++a a + 1 a set to value
--a a - 1 a set to value
a = b b a set to value
a += b a + b a set to value
a -= b a - b a set to value
a *= b a b a set to value
a /= b a / b a set to value
a &= b a (bitwise and) b a set to value
a |= b a (bitwise or) b a set to value
a ^= b a (bitwise xor) b a set to value
a <<= b a times 2 ^b a set to value
a >>= b a times 2 ^(-b) a set to value
Naturally, both "=" and "," can be "nested", thus:
for (a = b = 0, c = 5; c > 0; a++, b++, c--) {
/* ... */
}
To note is that the for () <statement> form is just a short-hand
for a specific while () loop. For instance, the for ()
statement above can be rewritten as follows:
a = b = 0, c = 5;
while (c > 0) {
/* ... */
a++, b++, c--;
}
Thus, the only convenience of for () is that it allows for the
"at-the-end-of-the-loop" part to be written above the loop body
itself (i. e., together with the loop condition.)
One more thing to note is that there're two basic contexts: the
statement context, and the expression context. The switch from
the former to the latter usually takes place in obvious places,
while it isn't possible (in standard C; AFAIK) to switch from
the latter to the former. E. g.:
/* statement context */
while (a < 5 /* expression context */) {
/* statement context */
b = 4 /* expression context */ ;
/* NB: cannot switch back to the statement context, like: */
/* c = while (b > 0) { /* ... */ } ; */
}
As one may need a conditional operator in either context, C has
both the ?:-operator (see above), and (perhaps a more
conventional) if ():
if (a) {
/* the code here will be executed iff a is non-zero */
} else {
/* the code here will be executed otherwise */
}
The { }-grouping is only necessary if more than one statement is
needed as the body; otherwise, it may be elided, like:
if (a) b = c;
This allows for convenient nesting, like:
if (a) {
/* ... */
} else if (b) {
/* ... */
} else {
/* ... */
}
A similar idiom is possible for the ?:-operator just as well.
Consider, e. g.:
a = (b ? c
: d ? e
: f);
which is not dissimilar to more verbose (and error-prone):
if (b) {
a = c;
} else if (d) {
a = e;
} else {
a = f;
}
An example program for an AVR could be as follows.
#include <avr/io.h> /* for PORTB, DDRB, etc. */
#include <util/delay.h> /* for _delay_ms () */
/* global variable declarations; not necessary in this example */
static void
blink_led (void)
{
PORTB ^= (1 << PB0); /* toggle PB0 */
_delay_ms (500); /* wait for 0.5 s */
PORTB ^= (1 << PB0); /* toggle PB0 again */
_delay_ms (500); /* wait for 0.5 s more */
}
/* the main () function is the conventional program's entry point */
int
main ()
{
/* set up PB0 for output, all the other tri-stated */
DDRB = (DDRB0 << 1);
/* enter infinite loop */
while (1) {
/* call our function */
blink_led ();
}
/* never reached */
return 0;
}
For sure, there's over than a dozen of individual syntactic
constructs more (and then there's a handful or so of the
preprocessor #-directives, too), but I hope that with the above,
reading the sources would become a bit easier task.
[1] http://www.nongnu.org/avr-libc/user-manual/
--
FSF associate member #7257
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-11-24 17:09 -0500 |
| Message-ID | <k8rgi8$phk$1@dont-email.me> |
| In reply to | #10580 |
On 11/24/12 4:18 PM, Ivan Shmakov wrote:
> for (a = b = 0, c = 5; c > 0; a++, b++, c--) {
> /* ... */
> }
>
> To note is that the for () <statement> form is just a short-hand
> for a specific while () loop. For instance, the for ()
> statement above can be rewritten as follows:
>
> a = b = 0, c = 5;
> while (c > 0) {
> /* ... */
> a++, b++, c--;
> }
This is not completely correct in general. For instance if you replace
the /* ... */ with continue; then the for loop jumps from the continue
statement to the increment clause of the loop, but the while loop jumps
to the beginning of the loop body (causing an infinite loop).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-24 22:12 +0000 |
| Message-ID | <0.4196fd606ae8a0c4ce3e.20121124221204GMT.87zk26y7kb.fsf@bsb.me.uk> |
| In reply to | #10580 |
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Robert Roland <fake@ddress.no> writes:
>
> [Cross-posting to news:comp.lang.c, in the hope that someone
> could provide more suggestions, or correct me on C.]
I'll have a look...
<snip>
> [...] Note
> that whenever all the operands are integer, an integer operation
> is performed. (So, 7 / 3 is 2.) The result is as wide as the
> widest of the operands. (So, i + j is 0 if i is 255, j is 1,
> and both are declared to be of the 8-bit unsigned integer
> uint8_t type.)
No the return will be of type int in that case. The rules are rather
involved, but the gist of it is that everything "smaller" than an int
gets converted to an int. When the types involved are int or larger,
both get converted to the larger type. Mixed signed and unsigned types
generally result in the signed operand being converted to the type of
the unsigned operand (after promotion).
The standard takes pages to describe these rules, so there is no way I
can summarise them here with 100% accuracy. Given that you summary is
not short, it might be worth including them. You'd then need to say
to which operators they apply (for example they don't apply to the
shift operators).
> Operation Value Side-effect
>
> Operations free of side-effects
>
> + a a
> - a - a
> * a the value of the memory cell at address
> a
This rather reinforces a view of C are lower-level than it really is.
The result might not square with how people think of a memory cell (for
example, if a is a function pointer, or when it is pointer to a struct
type).
> & a the address of a (must be an "l-value")
> ~ a bitwise negated a
> ! a 1 if a is 0,
> 0 otherwise
You don't talk about array the indexing operator, [], not the function
call operator, (). there are others, too, like sizeof and cast
operators. In tabular summary, I don't think it hurts to be complete.
> a, b b
> NB: a is evaluated first, its result discarded.
> a + b a + b
> a - b a - b
> a * b a b
> a / b a / b (quotient of)
> a % b remainder of a / b
> a & b a (bitwise and) b
> a | b a (bitwise or) b
> a ^ b a (bitwise exclusive or) b
> a << b a times 2 ^b (shift left)
> a >> b a times 2 ^(-b) (shift right)
These ones are tricky because of all the corner cases (a shift equal or
greater than the operand size, a shift of a bit into the sign position,
a right shift of a negative quantity). In a summary like this may just
a footnote to "beware".
> a < b 1 if a is less than b,
> 0 otherwise
> a > b 1 if a is greater than b,
> 0 otherwise
> a == b 1 if a is equal to b,
> 0 otherwise
> a <= b 1 if a is less than or equal to b,
> 0 otherwise
> a >= b 1 if a is greater than or equal to b,
> 0 otherwise
>
> Conditional operations
>
> a && b a is evaluated;
> if a is non-zero, the value is b;
> otherwise, the value is 0, while b is
> not evaluated at all
> a || b a is evaluated;
> if a is zero, the value is b;
> otherwise, the value is a, while b is
> not evaluated at all
> a ? b : c a is evaluated first;
> if a is non-zero, the value is b;
> otherwise, the value is c;
> the other ("unused") expression is not
> evaluated
>
> Operations with side-effects
>
> NB: a must be an "l-value"
Yes and it might help to say which of the expression yield and lvalue.
For example, you can write ++*a but not ++!a. It's might well be
obvious, but you could have a column for "is an lvalue".
> a++ a a set to a + 1
> a-- a a set to a - 1
> ++a a + 1 a set to value
> --a a - 1 a set to value
> a = b b a set to value
> a += b a + b a set to value
> a -= b a - b a set to value
> a *= b a b a set to value
> a /= b a / b a set to value
a %=b is missing. But maybe it's better to generalise: a op= b and say what
op can be?
> a &= b a (bitwise and) b a set to value
> a |= b a (bitwise or) b a set to value
> a ^= b a (bitwise xor) b a set to value
> a <<= b a times 2 ^b a set to value
> a >>= b a times 2 ^(-b) a set to value
>
> Naturally, both "=" and "," can be "nested", thus:
In most tables of operators, you see both priority and associativity.
Assign ment does not yield an lvalue, so a = b = 0 only works because =
associates to the right a = (b = 0). Most C binary operators associate
to the left (i.e. a - b - c means (a - b) - c).
You could make a really rich summary table that shows priority,
associativity, whether the expression denotes an lvalue and what happens
to the operands (are they just promoted as for the shift operands or are
the "usual arithmetic conversions" applied as for + and *). I can see
why you would want to avoid too much detail in a simple explanation like
this, but it does seem like a useful thing to do.
> for (a = b = 0, c = 5; c > 0; a++, b++, c--) {
> /* ... */
> }
>
> To note is that the for () <statement> form is just a short-hand
> for a specific while () loop. For instance, the for ()
> statement above can be rewritten as follows:
>
> a = b = 0, c = 5;
> while (c > 0) {
> /* ... */
> a++, b++, c--;
> }
Provided that /* ... */ contains no continue statements (except as part
of a nested statement of course).
> Thus, the only convenience of for () is that it allows for the
> "at-the-end-of-the-loop" part to be written above the loop body
> itself (i. e., together with the loop condition.)
>
> One more thing to note is that there're two basic contexts: the
> statement context, and the expression context. The switch from
> the former to the latter usually takes place in obvious places,
> while it isn't possible (in standard C; AFAIK) to switch from
> the latter to the former. E. g.:
>
> /* statement context */
> while (a < 5 /* expression context */) {
> /* statement context */
> b = 4 /* expression context */ ;
> /* NB: cannot switch back to the statement context, like: */
> /* c = while (b > 0) { /* ... */ } ; */
> }
A sad omission for fans of BCPL!
> As one may need a conditional operator in either context, C has
> both the ?:-operator (see above), and (perhaps a more
> conventional) if ():
>
> if (a) {
> /* the code here will be executed iff a is non-zero */
> } else {
> /* the code here will be executed otherwise */
> }
>
> The { }-grouping is only necessary if more than one statement is
> needed as the body; otherwise, it may be elided, like:
>
> if (a) b = c;
>
> This allows for convenient nesting, like:
>
> if (a) {
> /* ... */
> } else if (b) {
> /* ... */
> } else {
> /* ... */
> }
>
> A similar idiom is possible for the ?:-operator just as well.
> Consider, e. g.:
>
> a = (b ? c
> : d ? e
> : f);
>
> which is not dissimilar to more verbose (and error-prone):
You will find disagreement about that parenthetical remark in comp.lang.c.
> if (b) {
> a = c;
> } else if (d) {
> a = e;
> } else {
> a = f;
> }
<snip example>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Dave Nadler <drn@nadler.com> |
|---|---|
| Date | 2012-11-24 21:01 -0800 |
| Message-ID | <2719d142-8f6e-4d24-bec2-9a8843f2c157@googlegroups.com> |
| In reply to | #10583 |
On Saturday, November 24, 2012 5:12:09 PM UTC-5, Ben Bacarisse wrote:
> > One more thing to note is that there're two basic contexts: the
> > statement context, and the expression context. The switch from
> > the former to the latter usually takes place in obvious places,
> > while it isn't possible (in standard C; AFAIK) to switch from
> > the latter to the former. E. g.:
> >
> > /* statement context */
> > while (a < 5 /* expression context */) {
> > /* statement context */
> > b = 4 /* expression context */ ;
> > /* NB: cannot switch back to the statement context, like: */
> > /* c = while (b > 0) { /* ... */ } ; */
> > }
>
> A sad omission for fans of BCPL!
>
> Ben.
Wow ! I last programmed in BCPL in late 1977.
And I still miss this construct !
Though I don't miss the Lvalue/Rvalue persnickity
business (though BCPL wasn't as silly as BLISS).
Thanks for the memories,
See ya, Dave
[toc] | [prev] | [next] | [standalone]
| From | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| Date | 2012-11-28 12:54 +0700 |
| Subject | statement / expression contexts in C |
| Message-ID | <86txsa1dcq.fsf_-_@gray.siamics.net> |
| In reply to | #10584 |
>>>>> Dave Nadler <drn@nadler.com> writes:
>>>>> On Saturday, November 24, 2012 5:12:09 PM UTC-5, Ben Bacarisse wrote:
[Cross-posting to news:comp.lang.c, and dropping
news:comp.arch.embedded from Followup-To:.]
[...]
>>> /* statement context */
>>> while (a < 5 /* expression context */) {
>>> /* statement context */
>>> b = 4 /* expression context */ ;
>>> /* NB: cannot switch back to the statement context, like: */
>>> /* c = while (b > 0) { /* ... */ } ; */
>>> }
>> A sad omission for fans of BCPL!
> Wow ! I last programmed in BCPL in late 1977. And I still miss this
> construct !
Well, it's available as a GCC extension [1] at the least.
Consider, e. g.:
$ cat < g4u68ss8m8usbkqkx33wtfwws8.c
/*** g4u68ss8m8usbkqkx33wtfwws8.c -*- C -*- */
#include <stdio.h> /* for printf () */
int
main ()
{
int a = ({
int x = 21, y;
if (1) {
y = 2 * x;
} else {
y = 13;
}
/* . */
y;
});
printf ("a = %d\n", a);
/* . */
return 0;
}
/*** g4u68ss8m8usbkqkx33wtfwws8.c ends here */
$ make g4u68ss8m8usbkqkx33wtfwws8
cc g4u68ss8m8usbkqkx33wtfwws8.c -o g4u68ss8m8usbkqkx33wtfwws8
$ ./g4u68ss8m8usbkqkx33wtfwws8
a = 42
$
[1] http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Statement-Exprs.html
> Though I don't miss the Lvalue/Rvalue persnickity business (though
> BCPL wasn't as silly as BLISS).
> Thanks for the memories,
--
FSF associate member #7257
[toc] | [prev] | [next] | [standalone]
| From | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| Date | 2012-11-28 13:37 +0700 |
| Message-ID | <86pq2y1bcy.fsf@gray.siamics.net> |
| In reply to | #10583 |
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>> Note that whenever all the operands are integer, an integer
>> operation is performed. (So, 7 / 3 is 2.) The result is as wide as
>> the widest of the operands. (So, i + j is 0 if i is 255, j is 1,
>> and both are declared to be of the 8-bit unsigned integer uint8_t
>> type.)
> No, the return will be of type int in that case. The rules are
> rather involved, but the gist of it is that everything "smaller" than
> an int gets converted to an int. When the types involved are int or
> larger, both get converted to the larger type.
Thus:
Generally, the result is as wide as the widest of the operands, or
"int", if no operand is wider than "int". The result then may be
truncated on function application or assignment. (For instance,
i += j is 0 if i is 1, j is 255, and both are declared to be of the
8-bit unsigned integer uint8_t type.)
> Mixed signed and unsigned types generally result in the signed
> operand being converted to the type of the unsigned operand (after
> promotion).
> The standard takes pages to describe these rules, so there is no way
> I can summarise them here with 100% accuracy. Given that you summary
> is not short, it might be worth including them. You'd then need to
> say to which operators they apply (for example they don't apply to
> the shift operators).
Perhaps. Though this seems to open yet another can of worms.
[...]
>> * a the value of the memory cell at address
>> a
> This rather reinforces a view of C are lower-level than it really is.
> The result might not square with how people think of a memory cell
> (for example, if a is a function pointer, or when it is pointer to a
> struct type).
Yes, but nowhere in the summary I talk about struct's (even
should they be regarded as one of the essential conveniences of
the language), and function pointers seem far too advanced a
concept for those just starting to use C. And yes, pointers in
C are typed, which made me hesitate to mention them at all in
this summary.
>> & a the address of a (must be an "l-value")
>> ~ a bitwise negated a
>> ! a 1 if a is 0,
>> 0 otherwise
> You don't talk about array the indexing operator, [], not the
> function call operator, (). there are others, too, like sizeof and
> cast operators.
... And also . and ->. But then, I've omitted both arrays and
structs altogether, and show function calls and variable
declarations only on examples.
> In tabular summary, I don't think it hurts to be complete.
Frankly, I've tried to focus on "consistency", not completeness.
That is, this summary was intended to provide an example of
"basic", "self-contained" C programming, even if unsuitable for
the majority of practical tasks.
[...]
>> a << b a times 2 ^b (shift left)
>> a >> b a times 2 ^(-b) (shift right)
> These ones are tricky because of all the corner cases (a shift equal
> or greater than the operand size, a shift of a bit into the sign
> position,
Shouldn't these issues be already familiar to those coming from
the embedded programming background?
> a right shift of a negative quantity).
Seems like an interesting case, indeed. (I fail to recall if I
ever needed to do that.)
> In a summary like this may just a footnote to "beware".
ACK, thanks.
[...]
>> Operations with side-effects
>> NB: a must be an "l-value"
> Yes and it might help to say which of the expression yield and
> lvalue. For example, you can write ++*a but not ++!a. It's might
> well be obvious, but you could have a column for "is an lvalue".
Indeed, thanks.
[...]
>> a += b a + b a set to value
>> a -= b a - b a set to value
>> a *= b a b a set to value
>> a /= b a / b a set to value
> a %= b is missing.
Indeed. Seems like quite a rarely used operator, though.
> But maybe it's better to generalise: a op= b and say what op can be?
It may have its merits, but as long as simple text search is
considered, it makes sense to mention the exact form of all the
operators. (Even if they share the description.)
[...]
>> Naturally, both "=" and "," can be "nested", thus:
> In most tables of operators, you see both priority and associativity.
> Assign ment does not yield an lvalue, so a = b = 0 only works because
> = associates to the right a = (b = 0). Most C binary operators
> associate to the left (i. e. a - b - c means (a - b) - c).
> You could make a really rich summary table that shows priority,
> associativity, whether the expression denotes an lvalue and what
> happens to the operands (are they just promoted as for the shift
> operands or are the "usual arithmetic conversions" applied as for +
> and *). I can see why you would want to avoid too much detail in a
> simple explanation like this, but it does seem like a useful thing to
> do.
Well, it seems like there already is such a table at [1].
My point is that, more often than not, one doesn't bother about
precedence: the arithmetics follows the usual rules (a + b * c =
a + (b * c)), and when the other operators are involved, it does
no harm to parenthesize the subexpressions to make the order
explicit.
[1] http://en.wikibooks.org/wiki/C_Programming/Reference_Tables#Table_of_Operators
>> for (a = b = 0, c = 5; c > 0; a++, b++, c--) {
>> /* ... */
>> }
>> To note is that the for () <statement> form is just a short-hand for
>> a specific while () loop. For instance, the for () statement above
>> can be rewritten as follows:
>> a = b = 0, c = 5;
>> while (c > 0) {
>> /* ... */
>> a++, b++, c--;
>> }
> Provided that /* ... */ contains no continue statements (except as
> part of a nested statement of course).
Indeed, I've missed this case. Thanks!
[...]
>> A similar idiom is possible for the ?:-operator just as well.
>> Consider, e. g.:
>> a = (b ? c
>> : d ? e
>> : f);
>> which is not dissimilar to more verbose (and error-prone):
>> if (b) {
>> a = c;
>> } else if (d) {
>> a = e;
>> } else {
>> a = f;
>> }
> You will find disagreement about that parenthetical remark in
> comp.lang.c.
My point here is that when one (for whatever reason) has to
rename "a", it's easier to forget to update all the "if"
branches in the former example than the single reference in the
latter.
The same logic dictates the preference for a += b; over more
"Fortran-friendly" a = a + b;.
--
FSF associate member #7257
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web