What happens when you combine eTextiles, LED multiplexing, tilt sensing, and finite state machines? Well, you get the "Battle Bracer." Check it out in today's edition of "Engineering Roundtable" with Nick Poole:
ReplaceMeOpen
ReplaceMeClose
The code for this project can be found here. As always, feel free to leave any comments or questions in the comments section below. We'll be back in a couple weeks with another episode of "Engineering Roundtable." Cheers!
Great explanation of a state machine lad!! Had the problem with using delays before. can't wait to see the code
Thanks! I'll get the code posted ASAP
Code is up now!
We used to call this type of coding "cooperative multi-tasking". Each process/state machine checks to see if it has anything to do in that moment/cycle, and then release the micro to the process. The key is always do a minimum step and move on. Data base searches are the hardest, because you can only search 1 or 2 records and move on, but leave a bookmark were you were in the search.
If two or more processes do something every .10 seconds, adjust them to do every 0.10, 0.11, 0.12, or every .10 start at .08, .09, .10 so when they all need to do something at the same time, the program does not "pause" in a noticeable manner.
Database searches are a great example of a difficult task for this type of architecture. They're especially rough if there's another task that depends on the result, and even worse if that task is supposed to occur at a regular interval.
At some point, writing your own multi-tasking scheme becomes a daunting task and you go on to discover that there are people writing RTOSs (Real-Time Operating Systems) for microcontrollers like the ATmega.
Seems like every time I visit sparkfun I learn a new programming trick.
Nice video and very helpful, but I do have to point out that your "state machine" is not a state machine at all. What you have described here is a scheduler where multiple activities get a small share of the processing power.
A state machine on the other hand refers to a programming construct which changes state based on information being presented to the system. For instance, if I were parsing html and I'm looking for an img tag, I would process each character in turn and then only go to the next state if the current character matches what I'm expecting. If it does not match what I'm expecting, my state machine would reset to the base state:
...
etc. Filling in the rest of that is an exercise for the reader.
Great video!
Very cool project! I also loved your explanation of state machine concept. I learned alot thanks.
HI-Z output is not needed for muxing, writing low for the driving pins of high for the sourcing pins is sufficient. Also state-machines has nothing to do with the multitasking explained, state-machines could be used here to make more complex gestures.
http://en.wikipedia.org/wiki/Finite-state_machine
I described it as a state machine because multitasking this way allows the code to be event driven, instead of sequential. Each module has a finite number of states. The serial module has 7 or 8, the weapon module has 2, the shield module has 5 or 6. The transitions are represented by the "grabpos" module. Maybe I didn't do a great job of explaining it, but I think you'd find, if you were to sit down and try to map this sketch out, that it is a state machine. But then, I don't have a degree in computer science (or anything else)
As for Muxing, you're absolutely right. I try to teach muxing in a way that makes it hard to screw up. Both you and the gentleman who posited that the diode properties of the LEDs aren't important to muxing are right, but only one at a time. Either you need to be driving LEDs (or non-polarize lamps with series diodes) OR you need to set your unused lines to HI-Z. When you're driving LEDs there's obviously no risk of current leaking back to the unused pins, but if you stick to the HI-Z method (or use intermediary transistors to break the circuit) you won't have a problem no matter what you're driving.
That's my reasoning anyway, you can't please everybody but thanks for watching anyway :D
Thank you for showing the projects. Time to make time and finish my own...
Finding the time is the hardest part of any project, lol
Is the multiplexing integral to powering that many LEDs directly through the lilly pad board? How many amps does the battery provide?
I haven't measured the current draw on the battery, I will say that the current sourced from any one I/O pin is limited by the controller. I only multiplexed these because it saved me time and pins but there is a power savings. Since the LEDs are only being lit one row at a time, there is significantly less current draw on the LilyPad. I would think that the LilyPad would have no problem lighting 12 LEDs at once (and far beyond) but the battery will last longer this way.
Both Multiplexing and Charlieplexing are great ways to save power on displays, when you consider that a light source can strobe as slowly as 50Hz and still seem to be "on," a good portion of that duty cycle is "waste". Why power 12 LEDs when you can power 1 LED and get the same effect :)
A word of warning, though, multiplexed displays do suffer from what's been called the "Dorito Effect." In other words, because they rely on persistence of vision, looking at a multiplexed display while eating a crunchy food (or riding in a shaky car) will cause the display to look jumbled because your eyes are vibrating and changing their position relative to the display at a rate faster than the refresh rate.
Cheers,
Thanks Nick! This really helped me understand the programming term, "state machine" that I have seen mentioned in dozens of blog posts. Also, thank you for explaining why I always see counters in programs that don't seem to do anything - they take the place of delays, that actually don't do anything!
I'm glad it helped! Yeah, State Machines are an elegant solution to the delay problem but if you're not careful you can write some really ugly code this way. There are libraries out there that help you manage state machines but really the best advice I can give is to modularize as much as possible.
Also, wow, 25 min. This wouldn't fit in a half-hour slot with commercials... My apologies for subjecting you all to this.
No worries! You could have gone on another 25 minutes, and I would have been happy to sit here and learn. Good talk, Nate!
Don't appologize, it's really good info!
The intro sentence listing the subtopics is very helpful for returning to the portions of the video of particular interest, particularly when it is complete and in order.
Great video and project. Charlieplexing, while a bit more complicated to wire, could have reduced the pin requirements for 12 LEDs down to just 4 pins... at the cost of a longer video trying to explain it and more complicated code... although the charlieplexing libraries out there are a big help. However, since you had the pins available, the KISS approach is almost always better. Next revision, team play with signal strength analysis for general enemy location and a wireless heads-up display!!!
Yeah, Charlieplexing rocks. I recently, as a personal project, made this poster to explain the concept.
The arduino due has been out for two days now, why haven't we seen a post about it? I'd like to pre order one at least. Not saying the round table isn't important, good job as always.
They aren't shipping yet and we aren't even allowed to add it to our site until today. Later today we'll have them available for preorder.
Ok thanks!
It's live now btw.