Request for help with embedded software design

[lpcware]

Content originally posted in LPCWare by IntStarFoo on Tue Oct 23 08:58:41 MST 2012
Hi All, I'm a hobby embedded programmer and I have a few questions... I have been playing with a set of LED holiday lights and trying to control them using an LPC1769 board from Embedded Artists.  A friend helped me get started with the tools, hardware and the initial code and I have been modifying it from there.

The signal to address one LED takes just under 1000us to send (a bunch of 1s and 0s represented by +5v low for 10us or 20us).  I have 50 bulbs, so the entire signal takes about 50ms every time I want to update the bulbs with a new color.  So, I configured a timer to interrupt every 1us then built the signal from there.

Everything works great!  I am able to address the bulbs, change colors and even create little light shows.  I decided to step it up a notch and purchased the EA Baseboard to add some user input functionality.  This is when I started running into trouble.  As "frame" points out below from another post, I am running out of processing power.

---

Quote: frame
Apart from the timer bug in the library, a 1us interrupt is a rather heavy load for the uC.
These are about 120 instructions (at max. speed), for servicing the interrupt AND doing anything else.
It might work if there is no other performance load, but don't be surprised if the code misbehaves
when adding modest functionality.

---

The baseboard includes a bunch of IO devices. 

I decided to use a rotary dial to allow the lights to be moved when a user turns the dial left or right.  [I]I poll the dial in my main loop and send the updated message to the lights when they change.[/I]

I decided to draw 50 squares on the OLED representing each LED and attempt to mimic the color with black and white shapes. [I]I redraw the entire thing every time the lights change. (I see much room for optimization here. with Bitmaps and buffering)[/I]

I decided to add the time and date on the OLED using the Real Time Clock.  [I]I created an RTC interrupt that occurs every 1 second and I draw the new time/date to the OLED using sprintf and a oled_writestring function from an example.  (again, much room for optimization.)[/I]

And... When I put it all together... I come up bubkis. 

Clearly, I need some optimizing in both the code and the design.

Does anyone have advice on how to set this all up?  Should I be using all timers?  No timers?  Polling?  Is it asking too much for a 120mhz processor to be able to do all of this at once? :eek:

Thanks,

IntStarFoo

[lpcware]

Content originally posted in LPCWare by graynomad on Thu Oct 25 09:11:24 MST 2012

---

Quote:
maybe they need delays like LCDs do because they are slow.

---

Nope, I only have the LPC1227 version of the base board code but there are no obvious delays in the oled.c there.

[lpcware]

Content originally posted in LPCWare by graynomad on Thu Oct 25 09:02:08 MST 2012

---

Quote:
I was under the impression this should be a solid stream of data.

---

Normally SPI is a continuous bit stream, there's something going on there.

I'd have a look into oled.c, I've not used OLEDs but maybe they need delays like LCDs do because they are slow.

[lpcware]

Content originally posted in LPCWare by IntStarFoo on Thu Oct 25 08:40:49 MST 2012

---

Quote:
How are you using SPI when the bits are different lengths?

---

Maybe I used the wrong terms.  There are several things happening. 

1.  Send Light Signal. Sent out when necessary (every 2 hours or whenever a user adjusts the clock) - This signal is sent out using TIMER0 configured with 10us interrupts.

2.  Poll for 1 second RTC Interrupt in main loop and redraw the time/date using Write to OLED function.

3.  Write to OLED.  This happens every second via some library code that appears to use the SPI bus.



I use a library in LIB_MCU oled.h/oled.c for drawing on the OLED.  Those functions use lpc17xx_ssp.h/lpc17xx_ssp.c that communicate with the actual hardware. When I send data to the OLED and watch [I]it[/I] with my scope, I see this...  The gaps between bytes don't make sense.  I was under the impression this should be a solid stream of data.
[IMG]http://i.imgur.com/gB2Mu.png[/IMG]

The signal I send to the lights (using TIMER0 set to 10us and interrupts) looks like this...
[IMG]http://i.imgur.com/xSOlq.png[/IMG]

[lpcware]

Content originally posted in LPCWare by graynomad on Wed Oct 24 21:28:47 MST 2012
How are you using SPI when the bits are different lengths?

Now as I typed that I had an idea...

For each byte set the SPI frame size to N bits where

N = N_1_BITS + (N_0_BITS * 2)

Come up with a quick way to convert a byte to a uint16 with the 0 bits double width, ie occupying two bits each.

Spit the N-bit value out the SPI.

Once you convert an array of bytes to an array of ints using the doubling algorithm there's almost no processor involvement to transmit them and no timers required.

If the lights can tolerate some idle time between transmissions you don't even have to adjust the frame size.


Just thinkin' out loud here :)

[lpcware]

Content originally posted in LPCWare by IntStarFoo on Wed Oct 24 20:38:01 MST 2012
:)  Thanks.  I got the map as a gift a long time ago.  Maybe she was trying to tell me something.

I bumped the timer up to 10us and it works!  It's still a little slow.  Something weird I'm seeing with writing to the OLED is a pause between sending each byte over the SPI interface.  It sends 8 bits then waits then sends another 8 bits at a frequency of 10us.  I'm not sure what that pause is.  I don't think it's related to the 10us timer because it still looks the same when I change the timer or even disable it.

[lpcware]

Content originally posted in LPCWare by graynomad on Wed Oct 24 18:35:42 MST 2012
Neat, I thought those upside down maps were just a novelty thing we have here in Aus.

Anyway, as I said I reckon you could reduce your interrupts to 10uS, why are you using 1uS?

[lpcware]

Content originally posted in LPCWare by IntStarFoo on Wed Oct 24 11:00:50 MST 2012
Hi All,

Thanks for the advice and support.  A little extra info...  I found a great article on hacking GE G-35 Holiday Lights and followed the examples on this site to do it myself using the LPCXpresso.

So the signal I'm sending is actually 0 -> +3.3v pulses of 10us and 20us representing 1s and 0s.

My idea was to create a representation of daylight over my world map.  A sort of simple clock showing daylight and night.  I travel a lot and I decided it would be nice to see the position of the sun in the sky over a certain area at a certain time.

Here is a picture of the the setup. 
[IMG]http://i.imgur.com/tZEOCh.jpg[/IMG]

This is the Embedded Artists baseboard set up and running with the LPC1769.  I use the rotary dial to adjust the time on the RTC and use the RTC to decide how to set up the LED lights.  The OLED display is representing the 4x12 grid of LEDs as well as the Time and Date.
[IMG]http://i.imgur.com/rjR6kh.jpg[/IMG]

[lpcware]

Content originally posted in LPCWare by graynomad on Tue Oct 23 20:03:34 MST 2012
But it sounds like some weird drivers are being used.

---

Quote:
a bunch of 1s and 0s represented by +5v low for 10us or 20us

---

Is that the case IntStarFoo?

If not then certainly some shift regs may be in order, for that matter there are all manner of LED driver chips around.

[lpcware]

Content originally posted in LPCWare by daniel.widyanto on Tue Oct 23 19:55:30 MST 2012
Hi IntStarFoo,

First of all, congratz if you've gone so far :)

For controlling 50 LEDs (I assume it's LED, or is it truly normal bulbs with AC power source ?), I think the best is to use serial-in-paralel-out shift register. See http://www.nxp.com/documents/data_sheet/74HC_HCT595.pdf Then use the SSP peripheral to drive the 50 LED from the MCU.

[lpcware]

Content originally posted in LPCWare by graynomad on Tue Oct 23 19:00:25 MST 2012
A 1uS interrupt is a big ask under the circumstances.

---

Quote:
The signal to address one LED takes just under 1000us to send (a bunch of 1s and 0s represented by +5v low for 10us or 20us)

---

Straight away you could get an average 15x improvement by only interrupting every 10 or 20uS depending on the current bit length.