Part 29: Assignment #11: Cool Dad!!!!!!!!!!!!!
Cool Dad!!!!!!!!!!!!!
We get it, Joe - you vape.
There's a few questionable design decisions that jump out at me already, reading this. First off: who's broadcasting the color-changing radio signals? This feels like the sort of promotional item that only lights up, or at least, in any meaningful color pattern, at Cool Dad concerts.
Second off is the interrupt requirement. The design I'm thinking about has a 'dispatcher' MC to translate radio signals, then a MC for each of the LED's pins (Red, Green, and Blue), each of which tracks the time and turns off appropriately - but just sending the pulse level and time to the individual-color MCs won't work so well, as each MC also has to be on the alert for an interrupt signal.
I'm not even sure if I can do this, with the allowed board space - though if so, it'll make for a complicated wiring diagram. I'll experiment and see what I come up with.
[ ~ ]
This one took me a day to sort out, and there's a lot to explain here.
The first MC is, as I'd initially planned, the dispatcher. It sends the color pulse value to each small MC on their individual XBus lines, then sends the time value to all the small MCs the same way. The small MC code was a lot harder to create, and for a while it wouldn't narrow down to 9 lines of code. (Can you imagine doing this with 3 MC6000s on the right side? Could everything even fit?)
All three small MCs have the same code, which waits for a signal, passes it on to the output (and acc for the counter), then sets up a loop that only ends if acc is 0 or p0 is on.
p0 - which connects all the MCs to one another - is the interrupt signal I mentioned above. When the dispatcher MC is receiving a new command, it sets p0 to alert MCs that are in the middle of pulsing something else. It's timed so that the dispatcher will always set p0 before the small MCs test for it - whereupon the small MCs will finish up immediately and get the XBus values. (The dispatcher then clears p0 before sending the new time so that the MCs go back to normal.)
This was a remarkably unpleasant amount of work to do, but I'm sure Joe will be happy with it.
[ ~ ~ ]
Joe wasn't happy with it. More specifically, Joe promised Cool Dad's people a maximum quote that my design doesn't actually hit. (In case you're wondering, ¥14, 1.2K avg power. Yikes!) He wants me to try and make it cheaper, if I can pull it off. How on earth am I supposed to do that?
I'll try and look at the design again. That power usage has me concerned. Maybe I can at least find a way to improve that, and that'll help?
[ ~ ~ ~ ]
It's still ¥14, but it only uses 447 power - and it's a lot easier to understand! The key was to only keep track of the timer once, in the dispatcher. This removes the need for an interrupt pin (the dispatcher MC has to check for radio signals every time unit anyway), and the instructions saved from sending the timer to three different MCs lets the MC6000 work to keep track of the timer in-chip.
(I do have to put the radio input in dat now to free up acc for the timer, but it's a minor change.)
The small MCs are now basically XBus-to-simple-output converters.
Now I just need a way to do away with some parts, and I can stop Joe from being nervous right outside my cubicle...
[ ~ ~ ~ ~ ]
Sometimes being too close to the problem means the answer is staring you in the face and you don't realize.
I had two simple I/O pins on the dispatcher MC that I wasn't using, so I could do away with two of the converter MCs and just send the output directly. Hey presto - ¥8, 377 avg power. And the one-MC6000-and-attendants train rides again!
Now time to get this job out of here.
...... all that work and ......
I have come to the conclusion that whenever Joe pitches a product, it will be a piece of overcomplicated kitsch at best, and a boondoggle like this at worst.
Sadly, I still have to listen to the guy.
