Jack Ganssle

re embedded vs digital design

Yeah, embedded was what I was talking about and trial&error was what I was worried about. What I've seen people write up is a lot more difficult than software in general. I remember one had severe application issues when it ran with instant on that were eventually resolved as the PLL's not synced up. They put a delay in to let them warm up. Program worked fine. Seen some stuff in immunity-aware programming talking of similar issues. A comprehensive, free collection of stuff like that with tips would be a boon to hobbyists and pro's alike.

re book recommendations

Thank you. I'm already on Ganssle's newsletter. Good stuff in it. I've been published in one or two. Ancient hardware factored into my recommendations for two:

http://www.ganssle.com/tem/tem277.html

http://www.ganssle.com/tem/tem262.html

Ganssle confirmed that one SOC was taking the approach where it had a badass ARM Cortex plus a M0 for interrupts and such. It's claims were like a watered down version of Channel I/O. Cheap, too. :)

Btw, here's your 1-bitter. The link saying datasheet and VHDL design has the PDF's and code. The manual might have tricks worth remembering on other architectures.

http://www.linurs.org/mc14500.html

re Bitsavers

I already have over 10,000 papers from CompSci on my computer, a subset I read instead of skimmed. I keep planning to go through BitSavers to find more interesting stuff but afraid of accumulating useless junk. I just keep putting it off. I…

I personally found Kent Beck's book very tedious and boring. In it , simple classes are bludgeoned into submission through the over use of tests.

From Ganssle's article at http://www.ganssle.com/articles/deconstructing%20xp.htm

"XP's motivating guru, Kent Beck, also has a new book out. Test Driven Development (Addison Wesley, 2003, ISBN 0-321-14653-0) focuses on XP's testing practice.

I bought the book because I'm fascinated with testing. It's usually done as an afterthought, and rarely hits the hard conditions. Unit tests are notoriously poor. The programmer runs his new function through the simplest of situations, totally ignoring timing issues or boundary conditions. So of course the function passes, only to inflict the team with agony when integrated into the entire system. XP's idea of writing the tests in parallel with the code is quite brilliant; only then do we see all possible conditions that can occur.

Beck argues for building tests first and deriving the code from these tests. It's sort of like building a comprehensive final exam and then designing a class from that. An intriguing idea.

But X what if the test is wrong? Test driven development (TDD) then guarantees the code will be wrong as well.

Worse, TDD calls for building even the smallest project by implementing the minimal functionality needed to do anything. Need a function to compute the Fibonacci series? Create the simplest possible test first X in this case, check to see that fibonnaci(0) is 0.…

I recently started playing with MSP430's. They are fun devices and I think there are lots of possibilities with those. I have no real experience with other uC's so I can't say anything about others or compare. Having said that, here are some very basic impressions:

TI's example code is often confusing and over-engineered. It is much better to find advice on blogs and forums instead.

The community has some great individuals that will produce great examples and tutorials. Unfortunately, it is very far removed from places like GitHub. Almost all code is shared directly in the forums at 43oh.com.

There are a couple of big projects surrounding MSP430's. Energia is, from what I understand, an Arduino-like IDE which lets you program at a much higher level, but at the cost of some performance. When you only have 512 bytes of RAM, it may or may not be an issue. Another one is BSP430 which is a lower level set of libraries. It promises much higher level abstractions at the cost of small performance penalties. I found the tutorials to be rather terse, but I may need to give it more time.

Outside of those big projects, there is lots of duplication of effort. It is typical to see 3-5 different implementations of bit-banging UART drivers that are all slightly different. I am no exception, as I started writing my own little set of libraries for dealing with various peripherals.

Lastly, a lot of the tutorials out there either use the register names directly (P2IE, P1SEL, etc) or…

How are they poor choices? Methinks you're just looking in wrong places if they're languages you want to continue using at a job.

Embedded is hot right now, so sign up for the Jack Ganssle's Embedded Muse Newsletter http://www.ganssle.com/tem-subunsub.html. The jobs are going to be mostly US based, but some place to start.

And look for companies that you know are going to be using C/CPP from their products. Even if they don't have jobs posted, find someone on the engineering team via GH, FB, LinkedIn, their blogs, guessing their email address, conferences, where ever and email them a nice note talking about their products and how you'd love to work with them if they have a position open.

If you can engineer a piece of code, I feel you can also socially engineer your way to a contact somewhere you want to work.

Else if you really want to be some "rockstar" web developer (and I only ever use that term as a pejorative), then start using a relevant language, and learn how to talk to employers about how your deep C/CPP experience is actually an advantage that no other diploma-mill code-school grad is going to have.

It's never more depressing then when you've hauled in a candidate for a review because they've got great past experience, but the candidate has zero ability to relate that experience to conversation at hand.

A while back (I'd guess about 15 years ago, so suddenly I feel old), Jack Ganssle (http://www.ganssle.com/tem-subunsub.html) said he was selling his embedded tooling company, SoftAid because after doing it for so long, he had gotten tired of "pushing the same bits around."

At the time, I simply couldn't understand that. Sure, I hadn't been writing code as long as he had, but I couldn't imagine enjoying anything more than that. I absolutely loved twiddling bits and watching mechanical systems do what my code told it to.

Fast forward to now. I still really enjoy software/hardware/mechanisms/coding/design etc., but if I had to give it up tomorrow, I know I could find something I love just as much.

It's a really big world and there are a lot of sandboxes to play in.

`wait_for_next_tick();` in any microcontroller-based embedded system will put the CPU to sleep, often lowering your overall power consumption from the mA range it uses while actively running, to the uA range.

Some systems, like those based on coin cells, will completely shut down the chip, leaving only a single timer or input active, and when triggered will turn back on and initialise the entire CPU again to handle the input/timer. Some microcontrollers give you a small allocation of you can preserve under these conditions. That's how you get year+ runtimes on tiny batteries.

Edit: if you want to nerd out on this, I would start with Jack Ganssle's excellent guide: http://www.ganssle.com/reports/ultra-low-power-design.html