-
2016.09.18: Feedback requested
09/18/2016 at 19:49 • 0 commentsThe digit manufacture is still moving (slowly). There were some complications regarding buried vias in the polyimide flex circuits that mandated a rework. Re-work is now completed with no significant size increase.
With the CPLD finished, the question I have for everyone is:
Should we release as a sensor-package-only kit?
This would mean that others would need to bring their own ideas about battery, CPU, comm module, etc. All that would be included would be the sensor package with a 20-pin connector. The digits and textile would be ready-to-wear, and demonstration code and full schematics would be supplied.
This would be a step away from a consumer-ready product, but considering the release of the ESP32, the improved PIC32MZ, and a few releases from Intel, those of you reading this may not want a compute platform imposed on you. Not only that, but the sensor package will potentially be releasable this year. And if I wait to release until the entire thing is done, it will take months longer.
Commentary, and opinions are invited.
-
2016.07.04: CPLD is ready-to-rock
07/04/2016 at 10:04 • 0 commentsFull write-up...
-
2016.06.13: CPLD patent filed
06/14/2016 at 07:02 • 1 commentI am now waiting on the USPTO to write me back and tell me what I screwed up.
But in all seriousness... it's a tremendous relief to be at this point.
How big a relief?I started designing r1 about 13 months ago, and received the populated main-boards in October (8 months ago).
Arguably, the CPLD contains the majority of the complexity of this project. Once (if?) I publish its schematics, you won't have to take my word for it. We're talking about BGA100 parts on a 6-layer PCB with buried vias, and accounting for ~70% of the trace-length in the board, the odds of recovery from a mistake made here approach zero.
Even partial-failure of this subsystem would mean a basically useless main board, and (~$2600 + 2 months) blown on a moment's oversight.
For an engineer that touches the physical world, "invoking GCC" might cost more than he makes in six months. So when you meet someone who routinely codes for 10+ hours in C, and their code not only compiles the first time, but does exactly what they meant it to do, this is one possible explanation for how they got that way.
And when you fund a project on your own dime, there are only so many stupid small mistakes you can make before economics kills your project. Any given millimeter of trace might be the thing that vaporizes thousands-of-dollars and the possibility of timely market-entry.
Do Not. Fuck. Up.
So until I could (in)validate the CPLD, nothing more could be decided about the future. And nearly everything else must be built before this particular piece could be tested.
So after about one year of experimenting on a working r0, planning, designing, and finally porting firmware, I proved my hardest hardware lemma to myself. The CPLD works.
This is not to say validation is complete. But it has passed enough tests to convince me that the design goals articulated here will all be met (if they aren't already). Software is going to be *much* cleaner. Hell... the initial working ported code already is cleaner, despite being a sad assemblage of hackery.
Why the patent?
I've never held the US patent system in high-esteem as-implemented. But until we have a blockchain-driven patent system that manages itself and pays inventors based on reference in open-source designs, the idea of purely-defensive patents will have to make-due. Provided my filing goes through, I will begin publishing full CPLD schematics and images alongside the firmware.
-
2016.06.13: More CPLD progress
06/13/2016 at 08:56 • 0 commentsValidated: clock-enable logic for the internal registers. I can now set configuration registers.
Validated: IRQ selection logic works. I can set the CPLD wakeup IRQ to any specific IRQ signal. One of these was wired to the config register for testing. I can trigger the wakeup_isr by listening to the appropriate signal, and then setting that signal in the config register.
Fortunately, simulation shows the same thing.Quartus reports:
Total logic elements 535 / 570 ( 94 % )
Total pins 76 / 76 ( 100 % )
UFM blocks 1 / 1 ( 100 % ) -
CPLD debugging, major milestone
06/07/2016 at 07:30 • 0 commentsI can now relaibly address registers inside the CPLD, which now releases the bus as expected. Another few nights of testing before I move to make the firmware use the SPI hardware, rather than bit-banging the GPIO.
-
CPLD debugging in-progress
06/06/2016 at 06:11 • 0 commentsThat's the r1 main board with no battery plugged into USB, a logic probe, and the JTAG dongle for the CPLD. The small purple PCB is the debug harness for the digits.
Things that work:
* Buffered clock selection (external vs internal), synchronous reset.* Basic chip-select functionality
* Tri-state SPI1 CS logic (after some argument).
* Address demux and cycle logic
Broken things:* IRQ aggregation state machine.
* SPI bus-master behavior is inconsistent.
* Software. Much of the infrastructure is improved, but the logical hook-up to the hardware SPI peripheral isn't there yet.
This is the part of the dev-cycle where two complex systems meet on a strand of copper wire. Getting this piece right will take some more time. But once I've finished, I can give some real-world transfer-rate benchmarks.
Onward.... -
2016.05.30: Firmware progress report​.
05/30/2016 at 02:54 • 0 commentsPorted IMU drivers, MQTT client, TCP, UDP support in firmware.
Much-needed condensation of constants and debug methods pertaining to bus transactions. I am due to write up a new blog post. But until then, here is my informal log of compile sizes over the course of last night. GCC was given -O2 for each build.
text data bss dec hex 372372 2796 9392 384560 5de30 Starting point. 371700 2796 9392 383888 5db90 After splitting uint16_t _class_state into two 8-bit fields. 371700 2796 9392 383888 5db90 After condensing 4 bools (RNBase) into the above-mentioned field. 371708 2796 9392 383896 5db98 After condensing 5 bools (CPLDDriver). 371572 2796 9392 383760 5db10 After striking old interrupt logic. New baseline. 370132 2796 9392 382320 5d570 After condensing 1 bool (ADP8866). 367472 2796 9392 379660 5cb0c After condensing 4 bools (i2c-device). 277096 2776 9216 289088 46940 More miscellaneous bool condensation... 277184 2776 9232 289192 469a8 After enum conversion and BusOp state abstraction. 277144 2776 9216 289136 46970 Condensed BTQueueOp into BusOpcode enum. 277140 2776 9216 289132 4696c Condensed SPIQueueOp into BusOpcode enum. 276608 2776 9216 288600 46758 CPLD audit results in cuts. New baseline. 276508 2776 9256 288540 4671c Condensed SPIBus op state defs into BusOp enum. 276476 2776 9260 288512 46700 Condensed I2C opcode into BusOp enum. 276712 2776 9260 288748 467ec STM32F7 I2CAdapter compiles again following condensation. 276640 2776 9300 288716 467cc Further condensation of SPIBusOp into BusOp. 276624 2776 9300 288700 467bc More inline migrations into BusOp. About to extend another op class. 276608 2776 9300 288684 467ac Preparing to move I2CBusOp into conformance with new base class. 276336 2776 9300 288412 4669c I2CBusOp now extends BusOp. 276536 2776 9380 288692 467b4 CPLD no longer extends SPIDeviceWithRegisters. 276832 2776 9380 288988 468dc Added some CPLD tests. 277836 2776 9380 289992 46cc8 Widespread preprocessor work. Repaired console parser. 263676 2776 9380 275832 43578 Same code base. Built without console support. 9380 289992 // With console support flag.... 9380 275832 // Without console support. That's resting stack load, and total firmware size, respectively. ~14KB of ballast that isn't needed in anything but a debug build.
[4:19 AM] jspark311 Ok... much cruftiness was lost. r1 simplified the firmware *dramatically*.
Now that the bus-ops are contained for the moment, I can turn my attention to the the god-awful SPIDeviceWithRegisters class (which I am about to rip out and shit-can for good).
Too much complexity.
No longer required to deal with the heterogeneous bus topology of r0.
PR'ing... Not a bad 24 hours....
ManuvrOS: +1,763 −1,062 (lines in commit)
Digitabulum: +459 −346 (lines in commit)
And the firmware running on the new r1 board....
==< Kernel >=================================== -- bootstrap_completed yes -- Digitabulum v0.0.1 Build date: May 26 2016 15:43:57 -- -- Current datetime -- millis() 0x00000001 -- micros() 0x00000000 -- _ms_elapsed 0 -- getStackPointer() 0x200484f4 -- stack grows down -- -- Queue depth: 0 -- Preallocation depth: 6 -- Prealloc starves: 0 -- events_destroyed: 0 -- burden_of_being_specific 0 -- idempotent_blocks 0 -- Lagged schedules 0 -- Total schedules: 1 -- Active schedules: 0 -- Subscribers: (10 total): 0: Kernel 1: CPLDDriver 2: LegendManager 3: I2CAdapter 4: ADP8866 5: RN4677 6: SDCard 7: IREmitter 8: HapticStrap 9: PMU
That's all of the drivers. The first 6 are nearly complete, and the PMU (power-management unit) can do some basic clock-scaling. The largest remaining task is direct hardware support.
jspark311: I can potentially make you an emulator in firmware now. lol
drquinn: woah, woudn't a firmware emulator be the actual glove?
jspark311: lol yeah. That's how close I'm getting.
drquinn: nice! can't wait to see where its at
jspark311: I have TCP, UDP, MQTT support in ManuvrOS now, so you could just connect with the browser.
drquinn: so you'd just have to snap on some TCP connector to the glove?
jspark311: No hardware involved... the firmware experiences a TCP socket in the same way as it does a bluetooth connection. So when the time comes, we just drop one transport class in for the other.
-
Back into some CPLD work....
03/15/2016 at 08:07 • 0 commentsWith r1's CPLD nearing completion, here is a quick re-cap of r0's design, and a list of improvements that have been made for r1.
http://manuvr.io/blog/2016/03/12/design-choices-cpld-layout-for-r0/
-
Completed r1 flex PCB design
03/12/2016 at 12:28 • 0 commentsI can fit four of my sensors on a US dime. I'd say this tech is ready to be truly wearable...
http://manuvr.io/blog/2016/03/12/completed-r1-flex-pcb-design/
-
2016.02.10: Manuvr Update!
02/11/2016 at 06:29 • 0 commentsWe've had a busy January. The entire Manuvr team is now in the San Francisco Bay area. Josh and I are now working full-time on Manuvr and related technologies for a major telecom company that will likely be the first deployment-at-scale, and who has agreed to keep their efforts open-source, and developer friendly. That will warrant a separate in-depth post once they clear us to release details.
We're very excited about our prospects of unifying some of the fractured landscape of standards, transports, protocols, and hardware; something the IoT realm sorely needs.
For my part, I've been hard at work debugging threading Manuvr's firmware under different threading models and imparting concurrency safety. I've made builds with both FreeRTOS on the Teensy3.1, and pthreads on linux. At present, the pthreads version is much more complete, but once I resolve a few more library congruency mis-matches the two threading models can be coded for against the same API.
Digitabulum has sat idle for the past few months as time was devoted to ManuvrOS and MHB. But that is changing as-of yesterday. We are back in communication with our fabricator, and they are eager to help us build the digit sensor circuits. The 3rd draft of the hardware has been sent to them for feasibility opinions. Realistically, we are probably 3 months away from having the full sensor package for r1 built, funds permitting.
The non-circuit hardware tasks have also been advancing in the past few months. Here are some renders of the casing parts...
...and the digit mold for the sensor package...
Major changes are underway. But we are still alive, and the project is still making steady progress. More to come!