Y-Box: more DFU, and beyond

Ron K. Jeffries rjeffries at gmail.com
Mon Mar 31 22:35:42 EDT 2014

Most excellent. Impressive progress.
Remind me does your design have any way one might (with software changes)
be able to hack connection to an I2C device and/or another SPI device?

I think answer is "no" and that's cool and understandable giveb design

So what is the next similar MCU model that will offer more pins for serial
connections to sensors.

My thought is when Anelok is complete and a shipping product will it be
feasible for somone (not me, as I lack required skills) to take your time.
design and modify for similar NXP mcu that has more ports available.

Your work with e.g. DFU support can be leveraged for use cases different
than Anelok but uses e.g. the disolay and input wheel and the radio.

This could evolve into a really cool maker platform.

Ron Jeffries
On Mar 31, 2014 4:01 PM, "Werner Almesberger" <werner at almesberger.net>

> I wrote:
> > This boot loader only handles the KL25/26 so far. For the CC2543,
> > I'll have to add a function that flashes it via the debug interface
> Done.
> > and teach my DFU implementation to support alternative settings.
> Done as well, even with names (which are a messy to implement,
> given the way USB handles strings):
> # dfu-util -l
> ...
> Found DFU: [20b7:ae71] devnum=0, cfg=1, intf=0, alt=0, name="KL26"
> Found DFU: [20b7:ae71] devnum=0, cfg=1, intf=0, alt=1, name="CC2543"
> Now I can flash the firmware of both chips conveniently via DFU
> and will need the test fixture (for SWD or the CC2xxx debug
> protocol) only for boot loader changes (or for new prototypes.)
> I also wrote a simple implementation of the communication between
> the two chips (one-way for now), found a bug in my handshake
> protocol (improvised around it), and can now control either LED
> with a user-space utility over USB.
> Next: make the protocol bi-directional and enable it to send more
> than just one byte. And then it'll be time to actually put the
> radio to use.
> I'm not quite sure yet how far I want to go with the radio at the
> moment. One possibility would be to just send something and see
> if I can pick up the signal (*), without actually trying to
> decode the bits.
> (*) E.g., with atben/atusb and this tool:
>     http://downloads.qi-hardware.com/people/werner/wpan/rssi-clip.ogg
>     http://downloads.qi-hardware.com/people/werner/wpan/rssi-still.png
>     They work in the same band but use a different modulation.
> Else, I could make another Y-Box and test proper sending and
> receiving. But that would take time and add relatively little
> information.
> Another possibility would be to try to capture or even send some
> BTLE frames. That would not only verify that the transceiver's
> RF side works but it would also prove that it is able to
> communicate with a BTLE device. Alas, this also means the largest
> amount of work.
> Once RF is confirmed to work, I can go back to Anelok, continue
> with checking its power consumption, and then also make yet
> another prototype board to find out whether a "touch strip"
> would be a viable alternative to the wheel.
> With RF, power, and input method checked off my list, I will
> then finally be able to proceed to making the next version of the
> Anelok prototype.
> - Werner
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20140331/43e49ae9/attachment.htm>

More information about the discussion mailing list