Smart Response XE Re-purposed into Arduboy


#182

I know when we were looking at making this into a zigbee sniffer, we found an 802.15.4 arduino compatible library (well this actually makes a compatible library from the atmel distribution)
If it’s an use to anyone.

And the 2.6.1 distribution

https://www.dresden-elektronik.de/fileadmin/Downloads/Produkte/6-Software/AVR2025_MAC_v_2_6_1.exe

Mick


(Owen Trueblood) #183

I took some hi-res scans of the PCB: https://hackaday.io/project/160664-smart-response-xe-reverse-engineering/log/151505-high-res-scan-of-pcb … I’m planning on tracing out a schematic next, but won’t be sad if someone beats me to it.


(Larry Bank) #184

Latest news:
I’m working on a wireless bootloader that will be handy for wired updates as well. I’ve got options 1-3 working. It waits for you to decide before running the resident program. Should I add a timeout? Any other ideas?

Now to implement #4 :slight_smile:


#185

Might be better to execute the default program at power up, unless a key is held at which point you’d show the boot menu instead.


(Holmes) #186

Yes, but doesn’t this go back to the problem of the unit never being fully off?


(Josh Goebel) #187

Sym-Shift-Del - reboot :wink:


(Larry Bank) #188

Yes, but doesn’t this go back to the problem of the unit never being fully off?

True - every program will need to have sleep/wakeup logic baked in


(Larry Bank) #189

Today I’m working on the wireless part of the bootloader. My first idea is to have the PC-connected part (a SMART Response receiver/head-unit or XE unit with exposed serial port) have knowledge of the serial protocol so that it can gather each “message” together before transmitting it. Otherwise I would have to send an RF packet for each byte. I’m reading about the protocol here: http://ww1.microchip.com/downloads/en/AppNotes/doc2591.pdf


(Josh Goebel) #190

I’d think your transmitter could be fairly dumb (turn on all the ACK and auto-resend stuff of course) and then your receiving end would just need a little logic to queue up “long” command sequences. For example if you’re pushing 512 bytes and then a “write” command you could just stream them all as fast as possible in transmit (~100 bytes at a time or so?) and then on the receiving end you’d realizing it’s a “complex” command and queue up the full sequence in a buffer until you see “write” come across the wire, in which case you’d execute.

Of course many commands require responses so you might be transmitting only a few bytes across the wire and then waiting until you receive a response from the remote before proceeding, etc.


(Larry Bank) #191

For now, I’m trying it this way:

The part connected to the PC gathers up each complete command and transmits it in one shot. The receiver also gathers its command packets together and transmits them in one shot. They both are careful not to transmit while the airwaves are busy. It may slow down the transmission a little, but it should work. Right now I’m just fighting with getting the bootloader to upload successfully (takes many tries) and having the code work.
P.S. I’m not trying to replace avrdude; I’m just simulating the serial link between the PC and the device.


(Josh Goebel) #192

OK I actually read enough of the document now. I was thinking of some other protocol before I think. STK500 wraps everything in it’s own wire protocol. So you just have to ensure those packets go back and forth reliably. The firmware limitations of STK500 help you there since your packets are likely never going to be larger than 300 bytes or so.

Then on the transmit end you have a dummy STK500 stack that reads [over serial] in messages (perhaps checks their checksum or other basic maintenance) and then passes them over the wireless. Your transmit end actually doesn’t need to understand anything about the protocol other than the message format actually…

Then on the receive end you have a REAL STK500 stack that pulls commands off the wireless (probably again guarantees their basic sanity - checksum, sequence) and then runs them against the hardware. I imagine if the Arduino ISP programmer impliments the 500 stack you’d already have most of the code - you’d just be wiring up the wireless bits and letting the rest of the proven code do it’s job.


(Josh Goebel) #193

Is the wireless stuff really slow? I’ve never played with Zigbe stuff before.


(Larry Bank) #194

Wireless is fast, but everything still has to be sent+received through the PC’s serial port at the standard baud rate, so I’m just adding my own additional delay to ferry it through wireless.


(Josh Goebel) #195

Can anyone explain to me the reasoning behind the DDRAM’s insane column layout of 3/3/2 bits per pixel vs what seems logical to me of 2 bits per pixel (4 pixels per column)? Seems wasteful and also harder to work with.

Since AVR has nibble assembler instructions one could imagine a very efficient code to render 8 bits (8 pixels black and white, Arduboy) to 8 bits (4 pixels B/W, XE).

addr = byte & 0x0F
x = lookup_table[addr] // nibble -> byte
spiwrite(x)
swap byte // switch nibbles
addr = byte & 0x0F
x = lookup_table[addr] // nibble -> byte
spiwrite(x)

This crazy 3/3/2 stuff though, Iim not sure what to make of it.


(Josh Goebel) #196

That’s certainly convenient now that I’ve reviewed the LCD documentation. Avoids the whole 3 pixel per byte problem nicely.


(Larry Bank) #197

Agreed - it is inconvenient from a programmer’s perspective. I’m guessing that Sitronix did it because it made the RAM scanning/refresh easier (128 bytes across is a nice easy power of 2 for counters and address lines). My character drawing and rectangle routines do everything in groups of 3 pixels (e.g. 9x8, 12x16, 15x16 fonts).


(Josh Goebel) #198

Except you can set the address counters (begin/end) arbitrarily and it works just fine… so it’s not like they are hard-wired for some performance reason.


(Larry Bank) #199

I just updated my Github repo with the following changes:

  1. Added support for erasing, writing and reading from the external SPI flash chip (MX25L1005C). You must erase by sector (4K bytes), write in pages (256 bytes) and read any amount.
  2. Added a new font size (FONT_MEDIUM = double sized 6x8 = 12x16)
  3. Removed unprintable characters (first 32) from font data to reduce footprint
  4. Added replacement GPIO functions to simplify port access (mypinMode, mydigitalWrite, mydigitalRead). These functions use the port name as the pin number. For example, The CS_Flash line is PORTD, bit 3 and would be referred to as pin 0xD3.
  5. Simplified the LCD initialization to use a table of commands and parameters instead of discrete calls to “SendCommand”

You can get the latest code here: https://github.com/bitbank2/SmartResponseXE

I wrote a quick sketch to test the flash memory functions. I just erased sector 0, wrote page 0 with some random data and then verified that I could read it back.

New photo by Larry Bank


(Larry Bank) #200

New idea…Use an ARM SBC (e.g. Orange Pi) since it has exposed SPI. Connect the SPI of the ARM board to a SMART Response XE or head unit to use as an RF transceiver (faster than serial access). The SPI port can be driven at 4Mhz to send data wirelessly to the device. The Arduino IDE can run on ARM Linux and the avrdude program can be replaced by my own code which takes the hex file of your sketch and uploads it MUCH faster and over wireless to the XE. Thoughts?

I could also create an uploader which writes a bunch of separate programs into the SPI Flash at 16 or 32K boundaries and the bootloader can then present a menu to choose which one to run.


#201

.v.Nice!
.v.Now this looks like a computer now…
._.Crait think you got what it takes to get the ORE here?
Maybe not ORE, just some low-level OS to maybe type some notes in (or play huge-screen asteroids and games!)
ORE will obviously be nicer, but there is more work to do.
Appreciating the effort.