Part 26: Assignment #9: Little Help?

Little Help?



Ooh, this sounds like a fun project. A game controller! A low-end game controller, if Carl is to be believed, but who cares I'm finally working in the games biz

Er. (ahem) Anyway. On to the spec.






From the looks of this, this probably isn't doable with one MC alone (not enough simple I/O ports). Which is good! It'll give me a chance to practice my XBus chip-coordinating skills.

[ ~ ]



 

Not bad for a first try! As usual, cost is a priority (it seems to be that way with a lot of clients...), and all that empty space in the first MC is really making me wish that I could just use a MC4000. Sadly, I can't see any obvious way to save a pin from the first MC as long as it's responsible for getting the X and Y values. (I did try connecting both the radio's pins to the same XBus pin on the MC, but that gave me an error.)



What the design's actually doing is pretty straightforward for the 'get and send the x/y' values bit. For the next part, the MC6000 pings the small MC by the buttons, which does the calculation for the third item in the data packet and returns that on the same wire (where it gets promptly sent up the chain).

Looking at this, the ping-response architecture I've just set up... I'm inspired. I could extend this! Be right back.

[ ~ ~ ]



   

Here's the modular version. Both of its stats are worse than the original (¥8 / 262 avg power VS ¥9 / 333 avg power), but it's built so cleanly! Everything is nice, commented, discrete. The dispatcher MC4000X at the top pings the other two and gets back the X/Y values and the A/B button calculation, and sends them... and I even managed to use every port on the top MC!
(This is my first time using a MC4000X, by the way.)

This is almost certainly not going to be the version I submit to the client. But making it was refreshing; a balm for my soul.
[sigh] Anyway, back to work.

I've started to notice that, in general, the more chips I add, the greater the power usage is likely to be. I'm reconsidering my initial assessment that this job couldn't be done with just one MC - as long as the buttons (which are on/off inputs) get turned into values with an expander, I no longer have the port shortage that got me to split the design off into two MCs in the first place. I'll try making that design and see how it stacks up.

[ ~ ~ ~ ]





The masked avenger single MC6000 strikes again. The pattern I had previously noticed continues to hold true, as this version is cheaper than my original, and about as power-efficient (¥6, 264 avg power). The only downside comes to readability in the A/B calculation section, where I'm exploiting the full power of the MC's conditional flags to get the job done properly.



And that, as they say, is a wrap.



You know, there have been a lot of jobs lately where it's looked like two full MCs were the way to go - but a single MC6000 and attendants proved to be the most efficient solution. I wonder when I'm going to stop being able to use this design pattern?

By the way, David introduced me to Xiaomei. She seems really nice, kind of nerdy in her interests - when we weren't talking (when I got up to order, etc) she was chatting to David about what David says are various popular TV shows. (I have to take it on David's say-so, 'cause they were talking in Chinese.)