On 01/07/2017 08:05 PM, Tim Wescott wrote:
On Sat, 07 Jan 2017 19:26:21 -0500, bitrex wrote:
On 01/07/2017 04:55 PM, Tim Wescott wrote:
On Sat, 07 Jan 2017 15:57:57 -0500, bitrex wrote:
On 01/07/2017 02:55 PM, John Larkin wrote:
On Sat, 7 Jan 2017 13:16:53 -0500, bitrex
On 01/07/2017 12:43 PM, ARM wrote:
Hi folks, great group, wondering recomendations for projects for
a Assembler course.
Students from System engeneering.
Backgorunds microcontroller Arduino, chsarp, labview, java and
And will like to implement in RaspberryPI (GNU AS,LD and Bash)
have the basic 12 programs
but really just
basics, not list of projects ...
I view a good project in RaspberryPi bare-metal in a video:
Assembly Chess on Raspberry Pi (without any OS)
But I can't pretend to do all projects dedicated one RPI ignoring
the OS, so ..
Finally I thinking of using Assembler inside an Android program.
(for optimization or do some interfacing)
Thanks for you valuable time. All coments welcome. Thanks
Well, I do know writing ARM assembly is about as pleasant as
punching yourself in the kidneys repeatedly. So there's that.
Kamakaze pilots and ARM compiler writers have a lot in common.
I can understand wanting to _understand_ assembly language for
embedded processors, and maybe use it on some 8 bit architectures,
but as even the lowliest ARM Cortex is like 50MHz and 64k of RAM it
seems like a very self-punishing exercise to write an entire project
I even use C++ on some 8 bit AVR projects. So long as you're
careful/clever about your memory management and don't use a ton of
very heavyweight STL containers or a lot of runtime
polymorphism/virtual methods (runtime polymorphism is bad) it works
fine. std::vector is nice to have and works fine.
Even modern 8 bit processors are not yer dad's 8 bit processors.
Except in the cases of very small processors (like, less than 1K of
ROM) or very C-unfriendly processors, I think it's better to just
stick to C.
Even for a sub 1K-ROM processor that's C-friendly it may be better to
use C that's carefully written to avoid pulling in any library code.
I'm fortunate enough to have never had to do a serious project using
one of those itty bitty ones.
I've done a tiny bit with a PIC12. But what was needed could have been
done just as well with a PAL -- it's just that I had a PIC12
development kit in my junkbox.
Is there even a C compiler available for the PIC12 series? Using ASM for
those devices is probably sensible as IIRC the ISA for that line isn't
really optimized for C, while all the AVR devices share a common core
architecture which was intended from the outset to lend itself to
compilers generating optimal ASM from C for it. But the PIC will usually
beat AVR on price/product longevity last I checked. (the old debate)
Some of the abstractions that C++ provide are really nice to have in the
embedded world. For example "policy based design":
lets you do things like the thing I did with a display driver I wrote a
while ago: you have a common "core" class for the particular
architecture you're targeting that handles all the generic "low level"
stuff for driving any kind of display (essentially, timing and
bit-banging the pins/sending data over a I2C/SPI bus), and then you can
write "plug ins" at a higher level of abstraction for different types of
So if on one project you need to use a 7 segment display, and on another
a 2 line LCD, etc. you only need to rewrite the higher level policy, and
plug it in to the base class. The base class functions as an
"abstraction" of any type of display that you can stream characters to
the same way you would a terminal console, and the policy handles the
Yes to all of that. In addition, at least the last time that I went