I've now placed all the components and tested some more of them. This is what the complete board looks like:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd0-fnt.jpg Details: - wheel: works in general, but the button is sometimes "slow". Not yet sure what causes this. Could be a cracked trace, a problem in the component, or a firmware problem, e.g., overly aggressive clock gating.) - boost converter: works but I noticed that, when disabled, Vout = Vin. This seems to be a low resistance path, which would mean that high leakage of anything on the 3.3 V rail could drain the battery. In this case, a FET to cut off that part or the entire rail would be needed. The 3.3 V rail feeds the display and the memory card. The memory card already has a FET (but see below). For the OLED, the design relies on its own power-saving capabilities. Early tests with the MCU-less board have shown a substantial standby current (114 uA) into the OLED, well above the 1-3 uA the data sheet specifies. If further testing confirms this, the FET may be needed. Nothing to worry about, but needs looking into when analyzing the standby power consumption. - speaking of FETs, when the battery is low, the voltage difference between the MCU's supply and the 3.3 V rail should be large enough to open the memory card's FET. In other words, it will stop working as an off switch. The easiest way to fix this is probably by adding an n-FET and a pull-up resistor. Again, nothing major. - OLED: that one gave me a bit of trouble. First, I had a short beteen two connector pads, causing the system to draw up to 500 mA (which I eventually let it do, to find at least what part was heating up). That took me a while to find. Then I had stupidly mislabeled the D/nC signal as CnD and faithfully copied the inverted logic into the firmware. Suspecting that the display didn't work because of the previous short, I replaced it, only to find that it may still have been perfectly good. Ah well. The OLED has another surprise: there are tiny little traces left and right from the pads on the FPC. If there's exposed copper under that area, it could be shorted to ground. Of course, I have a trace just there. I solved this by trimming the FPC in the prototype and by moving the trace out of harm's way in the layout. The OLED now works. I found that, when hammering it quite a bit, the content jumps vertically about once every 1000 screen updates on average. Not sure yet what causes this. Probably a software problem. - RF: I completed that circuit as well and wrote a driver that can read the chip version and the RNG. Still have to do actual over-the-air transmissions and send the clock to the MCU, but I don't expect surprises there. The last major components that aree not verified yet are USB and the memory card. The memory card should be easy (I can reuse the tiny MMC driver of the Antorcha/Tornado project) but USB will be its usual pain. Then, power needs a closer look. The things to check there are: - operation under USB power, - operating current at 3.0 V (nominal battery voltage), - operating current at 2.0 V (battery cut-off voltage), - standby current at 3.0 V, - standby current at 2.0 V. This includes putting the MCU into deep sleep (and waking it up again), and optimizing GPIO settings and such to minimize leakage. My goal is to have an overall standby current below 10 uA, which would make the battery last for over two years. It may be possible to achieve a much lower standby current, in the order of just a few uA, but we'll see. Another thing that needs verifying is whether all the signals needing special functionality (e.g., interrupts, SPI, wakeup) are indeed on pins with that functionality. Right now, I'm doing everything with bit-banging and polling. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
