Looking for resources on Learning Hardware Programming

Hi Guys,
I have lurked around on this forum for years, am building my 3rd and 4th Shruthi, amongst a whole load of other DIY music stuff however, I have reached the point in my skills and building that it is becoming imperative to learn to program. I don’t want to learn C or C++ from a book that is going to stick me in a windows machine and learn impractical exercises, I want to learn on hardware, like Atmega, or PIC. Essentially, I want to be able to program my own nifty gadgets most likely much simpler than the Shruthi and WTPA, but still adequate. Is there/are there any REALLY good resources to self teach programming? I have programmed a little bit, but I was younger, and it didn’t seem to make sense. I am a much better learner now and can generally pick things up pretty fast. Any tips?

Look here - Thats whats inside this Gadget

I doubt very seriously that you’ll get something that is both a good intro to programming and also happens to teach it on Atmega or PIC. Could be totally wrong though.

I love these “head first” books. You can get all snobby and say they’re childish, repetitive, and annoying, but I personally like books that spell things out for me, have nice pictures, etc. instead of forcing me to strain my brain through them.

Then you can move on to arduino where you can jump into the hardware side. book

@ randy909

these books seem pretty good actually. I am the same way, I need stuff spelled out for me. I like the dummies books a lot because of that. I definitely feel like arduino is a good step forward, especially because it already uses an atmega.

@all
Where did you guys learn to program?

@n8Bit

My Father showed me when i was about 8 on a Commodore 8064 - 2 Years before the C=64 was released…
BTW i know what social isolation is: being the only kid with a 1540 (yeah - no 1541) DiskDrive while all others only have Datasettes…

Im about to switch to arduino, maybe ill do a BananaChart Guide to Programming :wink:

Figured it out myself by poking at the computer and looking at the programs in magazines which were written in BASIC (not the 99% that were lines of DATA machine code and a 10 lines loader :D). There were some BASIC programs in my maths textbook too, really caught my eye especially the graphics stuff in the geometry chapters. So I started with basic on school computers, then VB on my dad’s “laptop”, then 68k assembly on a friend’s amiga, then pascal on my PC (finally!), then Scheme because my sister was doing some in college, then x86 assembly, then C, then C+, then python… and other languages since then… The common pattern is that I have always set myself a goal when I wanted to learn a language, so it has always been “learn enough VB to do a Windows fractal plotter” or “learn enough scheme to make a french grammar checker” or "learn enough C+ to make a BeOS granular synthesis app"… It sort of helps to have a goal in mind - whenever you read something you can try to make it fit in your plans.

I have studied computer science in college so it helps - understanding how code is getting compiled or interpreted, what a CPU instruction set looks like, how the OS handles memory - how OSes work…

For AVR, I started by looking at some arduino sketches, and then at the source code of the “wiring” library to see what those “setPin” actually did and find the bridge between the code and the hardware. It’s there that I found all those references to memory mapped peripherals/ports registers, and then I read the ATmega datasheet, and then I “unlearned” everything arduinoish.

Something like the Shruthi-1 firmware is not an easy feat - you need to think low-level enough to consider very OSey things, but high level enough to organize all the features reasonably well. The level of complexity is too high if you don’t do much planning, so you need to have coded something similar before to know the mistakes… There are actually things I did wrong on the Shruthi and I am not repeating those mistakes on upcoming projects…

@pichenettes
If you did something wrong on the Shruthi its so well hidden that nobody ever will know…

Yea think of all the tb-303 “mistakes”!

I learned in college for the most part (comp sci degree). Messed around with commodore and very early ibm pc in (gw) basic. The IBM had a 20 meg harddrive which was cool at the time (most machines still ran straight from floppies or cartridges). But I wasn’t super interested in programming in high school, music much more so.

Programming is hard. Sure, small stuff can be simple and easy, but as things grow the complexity will quickly get out of hand if you don’t structure things well and structuring things well is hard. At the hobbyist level you should be fine though unless you’re wanting to build something complex. You will quickly fill in the 80 of the 80/20 and you’ll doubtfully ever get the 20 without going back to school. Few people have the patience to get through books like this on their own. I’m not sure it’s worth the effort anyway - it would depend on what you’re doing.

Take Oliver’s advice, decide on a goal and learn to that goal. Learning for learning’s sake can get boring real quick.

My best advice: learn to write unit tests as soon as you know what a function is. Write unit tests for everything you do. Programming is much easier when you do it this way. This book looks like a good place to start.

I totally agree about the unit-test thing but sadly it doesn’t play well with embedded development.

First, it is not a beginner project to set up a project that can cross-compile on both avr and a desktop system (I used to did it for the Shruthi codebase for the first 3-4 months then gave up). You’ll need to reimplement or mock plenty of avr-isms, like pgm_read_byte… and emulates or IO (or write mocks for them).

Secondly, standard practices used for mocking out I/O (dependency injection) add layers of abstraction that have a memory/code size/CPU impact on small targets. The only way to go through that is to rely heavily on C++ templates and the policy pattern to do “compile-time glueing” between bits of code (for example an UART receiver > a MIDI bytestream decoder > and a synth engine receiving MIDI commands). Then you get good isolation between layers, good for testing ; with no overhead (everything gets inlined at compile time). Should we expect a beginner to practice that? I don’t think so!

Finally, audio-synthesis related projects are notoriously difficult to unit-test for the DSP part. Say you change the implementation of an oscillator algorithm with a more efficient implementation using an approximation - but this new implementation causes a 90° phase shift in the signal. Totally fine, but will break the unit test.

I surely miss working on easier to test projects!

@fcd72: You reminded me of my first computer. It was ZX Spectrum 48K clone Robik when I was 13. First we can’t connect it to TV, so i try to blindtype BASIC code from manual, which plays Gustav Mahler’s Funeral March :smiley: And it works from n-th try! So i’m using it as beeping musical device for some time, until I’ve connect it to TV using RF modulator from broken NES. Year or two later, tired from loading sounds from my room, parents have gifted me the floppy drive with controller for my birthday, but I could not connect it unfortunately. That clone was not fully compatible with Sinclairs ZX. I was VERY envious of the few guys with the floppy drives. So that was my first steps in “real” programming. Before that was a programmable calculator =)

1) Cross-compiling puts hair on your chest :slight_smile:

2) The current crappy 8-bit MCU’s will soon all be replaced with screaming-monster ARM chips from the smart phone market. I say abstract away. When you hit the limits you’ll be good enough to use templates :slight_smile: (I both love and hate templates. I once had a 1000+ line error message from a template that crashed the compiler. Static duck-typing is so cool though!)

3) I find it’s all about choosing the right things to test. There’s always the ability to over-assert yourself into a big mess. If I were unit testing an oscillator I would probably just make sure there was a signal and no core dump for the edge cases.

C’mon, we should be encouraging unit testing! :slight_smile: