Smart Response XE Re-purposed into Arduboy

(serisman) #202

Man, I go out of town for one weekend and miss all the fun! :frowning:
But, I’m really happy to see progress on the wireless bootloader concept! :slight_smile:

I’m not sure why the ‘transmit’ end (i.e. RF-to-serial proxy) needs to know anything about the protocol at all. Ideally it would be a ‘dumb’ and transparent proxy, and leave the protocol up to other layers. This would mean no changes to avrdude (it just sees a serial port like normal).

My thought was to queue up any received serial data until we can fill the (max) 127 byte buffer (or a timeout occurs) and transmit that over RF. We can then forward any received RF data directly to the serial port (the data was already batched up by the TX side which decided how large the RF packet was).

Something along these lines:

void loop() {
  uint8_t data[RF_BUFFER_SIZE];
  uint8_t length;
  if (Serial.available()) {
    delay(10); // Let the UART RX buffer build up a bit more

    length = 0;
    while (Serial.available() && length < RF_BUFFER_SIZE) {
      data[length++] =;
    radioWrite(data, length);

  if (radioAvailable()) {
    length = 0;
    while (radioAvailable()) {
      data[length++] = radioRead();
    Serial.write(data, length);

I was playing around with this concept a bit tonight, and it works… mostly.

I seem to be getting a lot of dropped packets, which might be why you were fighting with the bootloader needing so many attempts to a get a successful upload.

I did find that changing channels around and setting MAX_FRAME_RETRIES (in XAH_CTRL_0) to 15 (the max) helped a bit, but so far this is not as reliable as I think it should be.

It might take an additional transport layer (with better retry logic) on top of the raw radio to get something usable.

(Josh Goebel) #203

That would be disappointing. That’s what I understand the additional MAC layer stuff built into the hardware was designed to avoid (auto-retry, etc). So the software could stay simpler. But you might be right.

(Josh Goebel) #204

Of course you wouldn’t want to have to modify avrdude. I just thought the transmission layer could be a bit smarter (and faster) with a basic knowledge of the underlying wire protocol (just the message packets, not the commands, etc)… but you’re right, that wouldn’t be a strict requirement. The wire protocol is also designed to smoothly detect errors and such things in message packets, so that would be a double insurance against the basic sanity checks built into the wireless stuff.

If we’re going to do this might as well make it as reliable as possible.

(Josh Goebel) #205

Finally just got my hands on these and realized there is no enter key. Grrrr. Anyone have any ideas how to setup the keyboard for use as a mini-computer? Using a soft-key seems weird. Remapping Del to enter seems weird since then you need to find a new delete - though I’d probably like delete on a softkey better than enter - the placement would feel better I think. So weird. LOL.

(Holmes) #206

I still think the buttons in the right-side of the screen would be best for an OK/Enter, Cancel/Back, Clear, Home, and Menu/Options buttons. Maybe the bottom-right could be the Enter key since it would be lined up with the text you are typing (like in a terminal).

Of course, you still need a return key for linebreaks, so maybe Shift+Space? Sys+Space is marked as a Menu option. Maybe Shift+Del could be line clear and Sys+Del could be linebreaks? It would be a little counter-intuitive and potentially frustrating if you accidentally forget to use the Sys key.

(Larry Bank) #207

FYI - there’s also a 1Mb SPI FLASH chip on the XE receiver unit (U2) connected to PORTD bit 7 of the MCU

New photo by Larry Bank

(Holmes) #208

Does this mean they based the flasher for these units off of the receiver?

(Larry Bank) #209

What do you mean by “flasher”?

I’m not sure why they put 1Mb of Flash memory on the receiver and the keyboard units. I guess they planned to have tons of data stored on there (fonts, dictionary, ?).

I asked the board designer and will post his answer if he responds.

Got confirmation. The SPI flash was to receive over the air updates, verify the data, then flash it to the MCU.

(Holmes) #210

This is so awesome! I know some folks with quite a few units, so this upload method will surely help them out tremendously!

(Holmes) #211

Now I wanna implant one of these MicroSD card readers… May need some guidance as to how this could best be connected for simple IO.

(Larry Bank) #212

Connect the SPI as usual and use one of the exposed test points (e.g. TDI) as the chip select.

(Holmes) #213

Not sure what that would quite mean. Lol. I am such a newb.

(Larry Bank) #214

I may need to get the “wisdom of the crowd” here to help with the wireless bootloader. I’ve run into some strange crashing problems when trying to use the wireless from within the bootloader. If I can’t get it working tomorrow, I’ll share the code and you guys can hopefully help.

(Simon) #215

Is @securelyfitz selling these?

(Larry Bank) #216

I still have a few left over; DM me for info if you want some.

(Simon) #217

Will do!     

(Josh Goebel) #218

OK, why can’t I read the default flash contents? I was going to save the factory firmware for reference later (or even reflashing) if needed but avrdude (after going thru a full progress bar) only writes a 12 byte file. I"m using:

avrdude -c usbtiny -p m128rfa1 -U flash:r:flash.hex:i -v

Is this a fuse or lock bit or something I can fix or is the default firmware just not possible to download?

(Larry Bank) #219

Did you try to dump the firmware before changing the bootloader? Writing a new bootloader erases the entire flash memory, not just the bootloader area.

(Josh Goebel) #220

I haven’t written anythign to the device. Plan was to first backup the existing contents. I was able to download the content of EEPROM (all FFs) without any difficulty.

(Larry Bank) #221

It might be hiding in the SPI Flash too. The author told me that it was used to do OTA updates and the firmware was first written wirelessly to the SPI flash, verified, then written to the ATmega.