a hobby class on microcontrollers
in [Embedded]
|
Prev: STUDIOT::Re: low-power-cons, low-cost, uP+DSP combo for H.264 videoencoding & control/monitor application
Next: Multimeter Clock – Styled after the Simpson 260 Multimeter
From: Jon Kirwan on 5 Jul 2010 04:36 On Sun, 04 Jul 2010 22:16:37 -0400, DJ Delorie <dj(a)delorie.com> wrote: >On 07/04/2010 05:31 PM, linnix wrote: >>I don't think you can do much with GCC in 2K. > >What makes you think that? If the people who did the backend port did a >good job, gcc produces assembler that's as good as (sometimes better >than) what you could do manually. There are a number of reasons why that is both true and untrue. A lot depends on the application space, of course. There are some advantages to assembly coding that c compilers cannot reach, as yet. For example, most c compilers I've experienced are not nearly as flexible as assembly in adapting caller/callee protocols -- there are some immutable aspects that a c compiler _must_ depend upon. Also, there are many semantics available in assembly that simply are not, in c. And besides, a human can perform unique on-the-fly topology transformations of algorithms that are well beyond c compiler technology I'm aware of and which themselves cannot be re-expressed back into some new c syntax. I think there has been a thread or two on that topic here, as well. On the the other hand, a c compiler is a lot better than a human at some things, too. And these can make up a lot of ground. So don't get me wrong. It just seems a little careless to write that a good backend is sufficient to produce something as good as (or better than) hand coding. That may be necessary, but it isn't always sufficient. Jon
From: Walter Banks on 5 Jul 2010 07:14 Jon Kirwan wrote: > Assembly code and skill can do a lot with a little. This triggered a a idea you may want to consider. Many years ago in a university setting I was teaching programming to engineering students and we were using the M6808. Early in the course I subsetted the instruction set to a fully functional but subset of the instruction set. For example all of the instructions dedicated to the first page of memory could be eliminated. There are lots that can be eliminated. Most memory to memory operations and in some cases addressing modes. This resulted in a fully functional processor (less efficient code) This approach made understanding the instruction set much easier and reduced potential for instruction usage errors. I modified the assembler we used to accept only the subset instruction set and provided processor documentation for the subset instruction set. Regards walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
From: Jon Kirwan on 5 Jul 2010 07:48 On Mon, 05 Jul 2010 07:14:29 -0400, Walter Banks <walter(a)bytecraft.com> wrote: >Jon Kirwan wrote: > >> Assembly code and skill can do a lot with a little. > >This triggered a a idea you may want to consider. Many >years ago in a university setting I was teaching programming to >engineering students and we were using the M6808. Early in >the course I subsetted the instruction set to a fully functional >but subset of the instruction set. For example all of the instructions >dedicated to the first page of memory could be eliminated. >There are lots that can be eliminated. Most memory to memory >operations and in some cases addressing modes. > >This resulted in a fully functional processor (less efficient code) >This approach made understanding the instruction set much easier >and reduced potential for instruction usage errors. I modified >the assembler we used to accept only the subset instruction set >and provided processor documentation for the subset instruction >set. Yes, that could be done (and is done still) in first year college CS classes (last I checked, which was perhaps 3 years ago.) I'm not exactly trying to reach that crowd, but it does remind me -- a mix of low level with high level 'instructions', such as IN <reg> which might activate the keyboard and accept a line of input and convert the decimal-ASCII entry into a binary register value. Nothing like that _really_ exists, of course. But it focuses the teaching on ALU logic and arithmetic basics and sweeps away complicating I/O and peripheral type issues. Maybe that is part of what you meant, too. Still, I'm mostly focused upon "action, lights, fire, smoke, explosions, and sparkly things" part of this to get attention and interest flowing. I want logic and maybe the need for arithmetic to sneak up on them and become an interest because it helps them blow something up or make fire or generate sparks or ... well, I want them to laugh and enjoy the time. If they actually _do_ become more interested in going further, _then_ I'll be there to help on that score. When they ask, not before, seems better to me. Jon
From: linnix on 5 Jul 2010 13:51 On Jul 5, 4:48 am, Jon Kirwan <j...(a)infinitefactors.org> wrote: > On Mon, 05 Jul 2010 07:14:29 -0400, Walter Banks > > > > <wal...(a)bytecraft.com> wrote: > >Jon Kirwan wrote: > > >> Assembly code and skill can do a lot with a little. > > >This triggered a a idea you may want to consider. Many > >years ago in a university setting I was teaching programming to > >engineering students and we were using the M6808. Early in > >the course I subsetted the instruction set to a fully functional > >but subset of the instruction set. For example all of the instructions > >dedicated to the first page of memory could be eliminated. > >There are lots that can be eliminated. Most memory to memory > >operations and in some cases addressing modes. > > >This resulted in a fully functional processor (less efficient code) > >This approach made understanding the instruction set much easier > >and reduced potential for instruction usage errors. I modified > >the assembler we used to accept only the subset instruction set > >and provided processor documentation for the subset instruction > >set. > > Yes, that could be done (and is done still) in first year > college CS classes (last I checked, which was perhaps 3 years > ago.) I'm not exactly trying to reach that crowd, but it > does remind me -- a mix of low level with high level > 'instructions', such as IN <reg> which might activate the > keyboard and accept a line of input and convert the > decimal-ASCII entry into a binary register value. Nothing > like that _really_ exists, of course. But it focuses the > teaching on ALU logic and arithmetic basics and sweeps away > complicating I/O and peripheral type issues. Maybe that is > part of what you meant, too. > > Still, I'm mostly focused upon "action, lights, fire, smoke, > explosions, and sparkly things" part of this to get attention > and interest flowing. I want logic and maybe the need for > arithmetic to sneak up on them and become an interest because > it helps them blow something up or make fire or generate > sparks or ... well, I want them to laugh and enjoy the time. > If they actually _do_ become more interested in going > further, _then_ I'll be there to help on that score. When > they ask, not before, seems better to me. > > Jon The local instructor I am working with is building a simple monitor on the demo board. So far, we have it toggling the leds between red and green and printing the port states to the virtual com port. PB7 PB6 PB4 PC7 PC6 PC4 PC2 PD5 PD4 PD2 PD1 OFF OFF OFF OFF OFF OFF OFF OFF ON OFF OFF We are working on commands such as "IN PB7" and "OUT PB7 ON". That should give students a simple way to check out their hardware designs without programming. More advanced students would want to implements their own custom commands for the serial port and spi port. The basic virtual com port firmware on the AVR takes around 8K, and you can't build any USB device with less than 6K. Since the boot loader itself takes 4K, minimum workable chip is 16K. 32K chip is less than $1 more, so why bother with smaller chips. Of course, if you are not dealing with USB target, we have some 8K boards (4K user) available for $4.30 (price matching with TI). See http://linnix.com/udip
From: -jg on 5 Jul 2010 16:27
On Jul 5, 8:24 pm, Jon Kirwan <j...(a)infinitefactors.org> wrote: > Either way, I plan on implementing a simple language where I > can take into account criticisms and suggestions and tailor > it to what I learn in the process. If I am careful and > crafty, I may be able to make something usable that fits into > a small space. > > > Whether that would mean 1024 words would be sufficient for a > very simple system remains to be learned. In any case, this > still fails to take into account that I want the students > able to enter programs they write. And that requires space, > as well. It's possible that it doesn't have to be much and > it could be in the sram, too. But yes, I may find the limit > of 1024 words too restrictive. Which is why I hope larger > parts will be available that will fit that board (if I decide > to go that way.) > > I need to put work out the scope and details more before I > have much more to add. "implementing a simple language" sounds like painting yourself into a corner, if not done very carefully. If it was me, I'd try and 'hook into' as much tested existing resource as I could, before heading off to plow green fields ;) Target Source-STEP/Watch debug would be VERY high on that list. Next would be some PC Source-step ability too, but here a careful subset of any PC language is fine. -jg |