Smart Response XE Re-purposed into Arduboy

(serisman) #383

Your PE’s came with a XE receiver??? Interesting… I didn’t think they were compatible.

My PE’s came with a ‘PE receiver’ (03-00099-21) that has the same CC2430 MCU as the PE clickers, as well as a CP2102 USB-to-serial IC.

I might not have posted to this thread, but it was fairly easy to re-program the CP2102 to have a more standard configuration and device manager name (using a software tool), and I have successfully re-programmed the CC2430 with my own firmware (right now it just blinks the LEDs and sends data on the UART) using nothing but a spare Arduino (

I have some extra ‘PE’ receivers available if anyone wants one for a reasonable price.

(Larry Bank) #384

bit of news - I had my backpack stolen when I visited California last week and lost some very expensive stuff, one item was my nRF52840 dongle. I was making good progress in making it act as a wireless hub for the XE’s. I ordered a new one and will resume my work when I get it next week. The code I wrote was not backed up yet, but I know what I have to do. Every other project I was working on was backed up except that one :frowning:

I got some nice cheap OLED displays today that will make a perfect “hat” to attach to the dongle for debugging.
New photo by Larry Bank

(serisman) #385

@bitbank - I received your package of two newer CC2533 based PE clickers today (thanks again), and just finished testing and checking in all my changes to make the newer MCUs work with my two code repos.

There were changes to the Arduino CC_Flash sketch (, the CC.Flash .NET application ( as well as my Smart-Response-PE library and sample applications (

You should be all good to go at this point.

(djoslin) #386

Hello everyone. I’ve been following this thread closely for a couple of weeks. I finally got around to flashing my Smart Response XE last night, and everything was working great. This morning, in my haste, I flashed the arduboy game CircuitDude to the Smart Response XE without making any alterations to it.

Since I had is0-mick’s modified Arduboy library I assumed the worst-case scenario being that it just didn’t work. However after flashing it, I can’t seem to get it to do anything. Since the screen is the only form of output I have I’m not sure if the whole thing is bricked or not. I can still reflash it fine using ICSP.

Any suggestions on things I can try?

I should mention that I am not great with the hardware side of things.


Hi, Not sure how you flashed it. Could you have overwritten the bootloader?

(djoslin) #388

I might have overwritten the bootloader.

I’m programming it through an Arduino Uno Rev3 with the following settings:
Board: ATmega128RFA1 Dev Board
Programmer: “Arduino as ISP”

I’ve soldered a female header to the ISP pins in the same configuration as crait (I was using his images as reference).

Since the Uno is 5v, could that be an issue?
I’m not connecting any power to the ISP headers, instead using AAA batteries.

I’ve tried the burn bootloader option, which appears successful.
I’ve tried the ‘Upload Using Programmer’ option many times on many different sketches. This worked last night, and seems to work tonight.

I’ve tried adding either a 1uF capacitor or a 10uF capacitor between the arduino uno’s reset<–>ground. This doesn’t change anything.

I’ve tried adding either a 1uF capacitor or a 10uF capacitor between the programmer and the RST pin. This causes an error on attempting to burn the bootloader or upload a sketch (pastebin dot com/aRunYmMP).

I’ve tried burning the two example sketches from is0-mick, as well as bitbank2’s support library (github dot com/bitbank2/SmartResponseXE) with a simple hello world.

I’m running out of ideas, any help would be much appreciated.

(Larry Bank) #389

It’s probably not a good idea to power the device from batteries (regulated to 3.3v) and drive the ISP header from 5v I/O. When programming through the ISP header, take out the batteries and power it from the programming pins.

If you didn’t smell the release of the “magic smoke”, your device is probably ok.

Have you attached UART0 or UART1? Then you could use the Arduino IDE to upload sketches directly.

If you have a discrete LED and a reasonable resistor (150-330 ohms), you can connect it to one of the “TDx” test points and write a simple sketch to blink it.

I’ve got plenty of XE devices left over if you need more :slight_smile:

(djoslin) #390

Hooray! Thanks for the tip, I appreciate your help. it has been revived.
It’s so simple in retrospect, I was just afraid of powering it with 5v.

(djoslin) #391

Has anyone figured out a way to read the frame buffer of the ST7586S? According to the datasheet you have to set the R/W bit high. I don’t see it on the pinout but it looks like there may be undocumented connections. It would be a shame to use up ~7KB of SRAM unnecessarily.


AFAIK the display RAM can only be read in parallel mode and not in serial mode as it is used. This is common for most displays.

(Josh Goebel) #393

Yep, if it’s serial you’re out of luck.

(serisman) #394

Definitely seems true for SPI serial, but not necessarily for I2C serial.

I ran across this a few weeks ago:

While browsing the SH1106 datasheet [2] I noticed that the I2C interface not only supports writing data to the display, but also reading data back from the display, making it possible to have a full 128x64 graphics display without needing any RAM buffer.

I2C is going to be slower than SPI, and I’m not sure how easy it would be to convert these devices/displays anyway. But, an interesting approach nonetheless.

EDIT: In looking at the datasheet for the ST7586S, it looks like it isn’t directly SPI or I2C but has a hybrid 4 or 3 wire serial neither of which appear to support reading from the display. The 3-wire is close to SPI, but has a combined data in/out pin and uses 9 bits instead of the more standard 8 bits. The 4-wire does use 8 bits but still has a combined data in/out pin, and uses the additional A0 line to transfer the 9th bit. Weird.

(Josh Goebel) #395

Oh? Pretty sure the code we’ve been using on the device is either SPI or I2C library.

(serisman) #396

That’s what I thought too, but looking at pages 16/17 of the datasheet ( I don’t know how that would work.

I’ll have to dig in further later (unless someone else can clarify for us).

Maybe we are using 4-wire mode, using SDA as only data out (cause we can’t read anyway), and just not sending the A0 bit?

EDIT: Close. It looks like the code treats the A0 bit as a separate D/C (data/command) line. So, we are using 4-wire mode with hardware SPI. The 4-wires end up being: CS, MOSI, SCK, and ‘A0’ (i.e. D/C).


Cool I didn’t notice that in the SH1106 datashheet before. That means using I2C the SH1106 has 256 bytes bits of general purpose ram :slight_smile: (only 128x64 of the 132x64 RAM is displayed)

(Josh Goebel) #398

Wouldn’t that be only 128 bytes?


Ehh… actually it’s 256 bits (132-128) * 64. so it’s just 32 bytes :blush:

(Josh Goebel) #400

How is that addressable exactly? Since the rest of the ram is “pages” of 8 pixels tall… To match it would have to be 64 bytes or 64 locations with only 4 bits addressible which would be kinda of weird…


The SH1106 has 8 pages of 132 colums of which colums 2 to 129 are visible. Columns 0,1 and 130,131 are not visible. So the first 2 bytes and the last 2 bytes on each page can be used as general purpose ram. There are 8 pages. so 32 bytes in total.


I’d like to share my bits of code I’ve been working on for the smart response XE. In particular, to get dot-precise text and simple graphics instead of writing the whole columns. (programmed in AtmelStudio)

I’m looking for suggestions or feedback :wink: