It has non-matching solder and paste layers, via requirements, ground requirements, and all of that is down to four decimal places in mm. I believe that I've fixed the chip mounting issue, repaired the faulty power switch issue, and rerouted audio and grounds enough to eliminate the popping issue on RF transmit. I spent nearly three days not writing software and revising the PCB. Fortunately, on the hardware side of things, we're about 90% there. Our Kickstarter has been incredibly successful, and now that we're sold out, I've got this long, long spreadsheet with about thirty items on it that need finishing. Many problems, but we're getting there.*Crosses fingers* I think I got it this time. We're still torture-testing the badge though and will probably have a few more sets of changes before DEF CON. The fight sequences are fast and tight, and for the most part the badge doesn't deadlock anymore waiting for moves. In any event, we now have some very nice radio networking code that works well on ARM machines. "I have moved, and after you get that understood this game round is over.") We needed the txqueue, because sometimes we have to tell one badge more than one thing in a row (i.e. Only being able to have one packet in the queue was killing us, but needing the queue at all was an indication that Stop and Wait really wasn't Stop and Wait. DO NOT put your thread to sleep, you will drop packets and life will suck.ģ) Written in the txqueue ring buffer in from day one. Because to do animations I would paint a frame and then do a chThreadSleep() - Nothing in your device should go to sleep if the same thread is processing the damn network. Okay, this right here is the #1 reason our badge had problems. I did it in the game thread, this was stupid.Ģ) Written my animations in a way that didn't impact networking. Writing that was hard, but writing a version that played nice with our graphics was harder.ġ) Move packet handling to a different thread. Our protocol is "Stop and Wait ARQ, with Time Outs (TO), and a small (four packet deep) Circular TXQueue." As you may know from your college networking textbooks (I had to go back and read mine), SaW ARQ is very inefficient but can be written with a very small memory footprint. We don't have the RAM for sliding window ACKs and generally our protocol is closer to Stop and Wait ARQ. When you are attempting to recreate the same protocol on a tiny 48Mhz system with barely any stack space or RAM (16KB, OMFG.) you learn to appreciate what you have in your average TCP/IP stack.Ĭurrently the protocol on the badge could be described much like TCP/IP, minus, well, the good stuff in TCP/IP. It is a remarkably well designed protocol and has served us well for many years. Well, first off, you should be very grateful that you get to use TCP/IP on the Internet every day. The last attempt, which I am still on now has taken about three weeks of off and on, but very serious critical thinking. I've written and rewritten the networking code about five times for the fight game. Our generic postings have moved to out Kickstarter Updates, but I'll try to keep the more technical ones here. Hello! It's been a couple of months since we've posted here, but here's some fun technical tidbits for you to think about.
0 Comments
Leave a Reply. |