Y-Box: more DFU, and beyond

Werner Almesberger werner at almesberger.net
Mon Mar 31 18:55:16 EDT 2014


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



More information about the discussion mailing list


interactive