Hello World, microcontrolled lighting prototype is working!

Madman Lighting · Post by **Madman Lighting** » Fri Nov 17, 2006 10:18 pm

Hi all,

OK, I"m just blowing my horn a bit but I just hafta. After months of work the first prototype "Delux Flasher" is alive and blinking. This is the same product I have now, but now there's a Freescale microcontroller making the lights blink under software control, with a few improvements like the whole thing is smaller, flatter, etc.

Whats the big deal? Well, this is my very first prototype with a working microcontroller! I designed the board, etched the board, drilled the thru holes, wired them, placed all the surface mount parts, and it actually works.

Now I can actually say that soon I will have a working product that can blink (almost) any way you can think under software control.

Am I crazy? Not sure, ask my wife!

Thanks!

-John C.

jwrjr · Post by **jwrjr** » Sun Nov 19, 2006 11:38 pm

I've been using microcontrollers in models for years now, and they are the easiest (and most versatile) way to control model lights that I can think of.

Madman Lighting · Post by **Madman Lighting** » Mon Nov 20, 2006 11:35 am

Thats what I found too once I did the cost/benefits analysis. I cost compared using dedicated logic vs microcontroller and microcontrollers won hands down, except for the simplest projects.

You just need to know a little more to use them and I know C so I'm good to go.

-John C.

tetsujin · Post by **tetsujin** » Mon Nov 20, 2006 12:01 pm

Madman Lighting wrote:You just need to know a little more to use them and I know C so I'm good to go.

Glad to hear the new product's coming along nicely.. Microcontrollers are fun stuff - though I'm going to think twice before working with surface mount controllers without a printed board again. :)

I'm curious - how do you manage timing on the controllers you use? With the low-end-ish PICs I use it's mostly done by counting assembly instructions and creating busy loops - with C you can't count instructions as easily - do you still use busy loops, and just try to calibrate them experimentally, or is there a better timing facility that you take advantage of?

Madman Lighting · Post by **Madman Lighting** » Mon Nov 20, 2006 12:36 pm

I use a micro that has built in a 32.768 kHz clock and a modulo timer plus prescaler that can generate an interupt to the micro. Instead of counting asm instructions and busy loops I figure out the frequency at which things should happen and have the timer generate an interrupt. The main loop actually does nothing more than feed the internal watchdog timer that automatically resets the micro if the program crashes. Neat thing about this architecture is you can reprogram the timer on-the-fly so you can change how fast things happen as you want. The other neat thing is this micro has low power modes so after I toggle the LEDs to their new state, I can put the micro to sleep to save power. Interrupt wakes micro up again next time around. Neat stuff!

-JC.

macfrank · Post by **macfrank** » Mon Nov 20, 2006 1:07 pm

I use Assembly language on the smaller AVR micros I use (mainly for space) and C for the larger projects. The GNU C compilers that have been ported to a given processor usually have header files that allow direct access to the various timers in the chip. If not, just drop in some assembly language to do the same. The overhead caused by C is minimal, and not even an issue when it comes to blinking lights or similar devices that are tied to human perception.

The AVR and Freescale (ex-Motorola) micros are good matches for C. I don't know about the PIC- at least the early 'F84 class.

Frank

tetsujin · Post by **tetsujin** » Mon Nov 20, 2006 4:43 pm

macfrank wrote:The AVR and Freescale (ex-Motorola) micros are good matches for C. I don't know about the PIC- at least the early 'F84 class.

I can tell you about that...

The so-called "mid-range" PICs (16-series, like the old discontinued 16F84 or the more current 16F628 I use now) basically are no good for C because they have limited stack and addressing functionality. (Your call stack can't get too deep, you can't put non-static local variables on the stack, and if you want to implement a stack using the processor's memory, it's a bit of a hassle because to read and write arbitrary RAM locations like that you need to feed the address into particular registers, and then read or write particular registers that then act as a "window" to the memory location you addressed) Nevertheless, SDCC supports compiling for the mid-range PICs (though not too well, last I checked.)

More modern PIC lines like the 18F have the features that are needed for C compilers to work much more comfortably, I believe. And now they have another new family of PICs, the 24 series - I don't know too much about those.

jwrjr · Post by **jwrjr** » Mon Nov 20, 2006 11:39 pm

On the pics, it is (usually) easier to use one of the timers and update the outputs in the interrupt service routine. That makes it much easier to use already-written software and adapt it to something new.
I program in assembler, so I wouldn't know about C. However, it is easy to implement lookup tables on the 'pic18f's which can be very useful for really odd sequencing.