Mine came with the LOCK bits set. I had to do a full chip erase (
avrdude ... -e) before I could re-program it.
Mine came with the LOCK bits set. I had to do a full chip erase (
And now despite not writing anything to the flash I have a blank screen. sighs Grrrr. There isn’t some reset mode other than simply removing the power source is there?
Flashed my first sketch. So the hardware is fine, but very confused how I would have destroyed it’s abiltity to function from the factory just by playing around with READING the flash/EEPROM using avrdude. Is the pogopin connection thing so flakey that if you just let it slip a little you can hose the whole thing during READ operations?
Any progress? Did you figure out where the power switch is wired to?
Answer: Bit 2 (0x04) of port D it appears. (hardware interrupt INT2)
I had a few spares i sent out. Board files are posted to make your own, and i uploaded them to OSH park too.
good idea. should have read your post, I just wasted time trying to track down the SS pin forgetting it’s configurable.
It might be possible to get a thin pcb that fits under and is held in place by the battery cover. Then there’s room add a microsd slot and lipo charging circuit too (not saying i have time to do this, just that i would if i did)
Yes, its all implemented in the arduboy2 code I uploaded.
So wait, is the screen 384x160 or 384x136? I see different things in the specs and the code provided.
The controller handles 384x160 and has the memory for that size, but the visible area of the screen of the SMART Response XE is 384x136
Care to share the source? I’d like to work on the performance characteristics and a ready to go example that’s meant to run fast would be great. In watching the video you can tell it’s running way, way slower than on an Arduboy.
It was just hopper that I downloaded from the arduboy site.
I’m not sure if that was for arduboy or arduboy2 ? library.
You can download the files on the link at the top of this thread. I recently uploaded them again.
From a brief look through your code it looks as though you’re handling rxbuf wrong. It looks like you’re expecting to use it like a circular buffer, but your tail index will just go out of bounds.
The circular buffer index variables are uint8_t and the buffer size is 256. It wraps around without having to mess with it.
The problem is with the first packet received which makes the system reset. That’s the only issue I need help with. I’ll find+fix any remaining bugs once I understand why it can’t receive any data over RF.
Ok, Hopper seems to use Arduboy (vs Arduboy2) and I didn’t want to take the time to figure out how to compile it (so many other things to do), but I did rewrite the render off the top of my head for someone else who wants to play with it. This should pretty easily be 2x faster than the original if not much better:
It’s also exactly how you’d want to code it in assembler if you needed even more speed. I’d have to read the decompiled output first to see how well C does with it before deciding if there is value in dropping down to assembler. From past experience this type of C should compile pretty tightly.
This renders the screen in columns to avoid doing any repeat work. I’ve also unwrapped the innermost loop to avoid any time wasted shifting bits and allow the timings of the SPI commands to be super-optimized. Of course to see this as fast as possible each of the SPOUT’s would need to be tuned with exactly the proper amount of NOPs instead of just checking the status register (which will always result in waste).
I included SPOUT1 2 and 3 because the timings are going to be different for each. Since SPOUT3 is at the very end of the loop and a lot more work will be done after it before the SPI bus is used again it likely needs far less NOP padding than SPOUT1. SPOUT2 likewise needs less padding than SPOUT1 because the boolean comparison is about to happen for the next pixel and that itself will burn 3 cycles or so easy.
If anyone has any questions feel free to ask.
And of course you’d want to make sure you’re running the SPI bus at CLK/2 not CLK/4.
All things considered most of the remaining inefficiencies of this approach should be swallowed up in the SPI wait states… so if someone wanted a high speed graphics library for the XE you actually would be in pretty good shape to borrow the Arduboy’s, use the fast Sprite rendering methods, and expand your screen another 4 pixels vertically (if you wanted).
Of course it could never achieve the same maximum speed – the Arduboy only has to push 1024 bytes for a full screen and we have to push 17,000 or so for the same screen (blown up) on the XE… so it’s hardly a fair fight.
Ah yes, you’re quite right, I didn’t see that.
Is it resetting on response of any packet at all or one specific packet?
I found the problem - I had changed the fuse bits for my makefile, but hadn’t changed them in the board definition file, so avrdude was telling the isp programmer the wrong info. I’ve got the wireless working now and just need to fix the protocol.
Update: Things are moving forward. I’m going to pound on this until I figure it out. The handshaking starts to work, then quits. I’ll have time this weekend to really dig in. Having a display helps with debugging
After many hours and sleepness nights of pouring over the datasheets, learning more about IEEE 802.15.4, and trying different things out, I finally have a better understanding of the wireless stability/reliability issues I was seeing.
Apparently the SparkFun RadioFunctions.h ‘library’ (that probably most of us have seen and are using) only uses the radio in basic or simple mode and DOES NOT perform any type of auto-ack or auto-retry. So, if a message isn’t delivered properly the first time, it is lost and there is no way for the transmitter to know it didn’t go through (without manual ack/retry in the software layer)!
In order to add the auto-ack and auto-retry functionality that this radio can support, we have to use the radio in advanced mode (RX_AACK_ON and TX_ARET_ON). This requires the use of an actual IEEE 802.15.4 frame that adds in additional header information like destination addressing that is used for packet filtering.
I have a proof-of-concept working that emulates most of the STK500 protocol and can pretty reliably read the entire flash and eeprom contents over wireless.
It consists of one sketch that is loaded to a S.R. XE with a serial port and acts as a dumb serial <-> wireless proxy. There is another sketch that is loaded to a different S.R. XE that emulates the STK500 protocol and can be queried with avrdude from the pc connected to the first S.R. XE.
This is not yet a bootloader, but could fairly easily be turned into one. If nothing else, it should provide a more stable radio library than what is available from SparkFun. I will post code later after I clean it up a bit and try to resolve one last bug that I am still seeing.
I am going to be out of town again this weekend, so other than posting the code later tonight, I probably won’t be able to do much more with this for a few days, but maybe others will be able to benefit from it in the meanwhile.
I really would love to see a dedicated Smart Response XE library that includes many of the powerful drawing functions from thr Arduboy2 library.
Did you see my comment on simply reusing the Arduboy code as-is?.. if all you wanted is 3x2 “doubled” views…
Yeah, I saw that. I mean, it’s what I used for Midnight Wild, but I think a dedicated library would include support for all the alphanumeric and modifiers keys. Plus, it’s ugly stretching the screen.