Been looking through all this stuff and just realized I bought three units from you. Too bad I didn’t contact you through here first! Those ebay fees are killer. Hoping to do some interesting things with my new toys!
Sorry about that. I communicated in several places (twitter, my blog, discord (Sudomod) and here) to contact me directly, but I can’t be too pushy about avoiding eBay if I still want to use eBay
When I get the PE clickers and get my software working on them, I’ll offer the extras at cost (around $2 each).
I just pushed up some changes including a buffered display library.
You can now draw text and bitmaps anywhere on the screen (not just on page boundaries).
The demo application also has ‘next_frame’ support and scrolls the bitmaps around.
The buffered display library was a learning experience in how these 8051 CPUs and the SDCC compiler manages the different memory types. The buffer had to be put into XDATA, which requires some compiler attributes. It makes sense (and seems obvious) now, but took a while to get there.
Hmm. I measured the power consumption of a unmodified SMART Response XE with a reprogrammed one. When both are powered on, the unmodified one consumes only around 0.5mA (RF not active) while the other, reprogrammed one takes whole 4mA, sometimes up to 6mA. (no difference between a simple LCD demo or the flash completly erased)
Any ideas how they squeezed the power consumption down?
( On a sidenote - is there a discord chat/server around the Smart … devices? )
Welcome to the discussion. The trick with any embedded platform is to get your work done and then put the CPU to sleep. The original firmware does this well. The display doesn’t use much power when static and the CPU only needs to wake up periodically to check the keyboard. The bootloader and library I wrote don’t do much in the way of power management, so you’re seeing the power draw for a fully active CPU.
If you’d like to join an active discussion of this topic, I and several other “makers” talk about the XE on the ‘Arduino’ channel of the Sudomod discord server. Here’s an invite:
The smart pens are probably an accessory for a “smart board”, a digital whiteboard that is used as an input device (motion/touch sensitive with the use of these pens and an eraser) in conjunction with a projector to “draw” on top of documents and presentation slides. I remember using them in high school and early college. Basically a fancy, expensive replacement for overhead transparency.
@bitbank - Not sure if you started using this code yet, but I just pushed up a major re-organization of all the code.
- The example applications moved to an /examples sub-directory
- There are now /lib and /include sub-directories that are more optimized for reuse between the examples and other projects
- The shareable code (i.e. /lib) now compiles to a .lib library module, and the optional methods are in separate source files
- This allows SDCC to pull in only the methods that are actually used. Otherwise every method, whether used or not, will be included in the final .bin file. This is a weird quirk with SDCC that doesn’t exist for gcc.
Bought some Smart Response PEs and they arrived today. Spend about 2 hours trying to upload the code using CC.Flash (Chip ID could be read but couldn’t Read or Write to Flash). While looking through the cc2430 datasheet I saw the CHIP_ERASE command. Ran it and was able to Write to Flash (Lock Bits were on before CHIP_ERASE).
Added a button in the GUI to send Chip Erase.
Did a fork (https://github.com/GabyPCgeeK/CC.Flash) and submitted a pull request.
Yeah, sorry about that. I should have mentioned that.
Thanks . But you may want to fork the original and submit a PR there. The original author already merged my changes in, so I may close down my fork and re-open if I have more changes later.
(Among other things,) I just updated my repo with much more fully featured keypad support.
It now exposes similar methods as Arduboy, i.e.:
The list of buttons are defined in include/keypad.h:
The example/hello-world-clicker sample application has been updated to provide more information on button presses as well. I have the screen inverting/reverting on pressing/releasing the Enter key as well.
I’m close to being able port a simple game over to this hardware.
I appreciate all of your efforts. I had to cancel the original SMART PE set order (with the pens) because ebay messed it up and didn’t recognize that I had paid. I found a better set that’s brand new and sealed. I’ll start messing with them when they arrive. I was thinking that I need to create some kind of clothes pin jtag connector so that I don’t have to solder anything to the boards. Something like this:
In the mean time, I’m working on porting my game emulators to the ODROID-GO. The ones that ship with it are so colossally bad that they need to be replaced…
I made some more updates to the repo. There are a bunch more drawing routines as well as a few more utility methods and some bug fixes.
This repo now contains enough to port a simple Arduboy game!
Here is my version of HANGMAN! for this hardware:
I did this mostly just to see what it would take. The conversion was fairly simple, but that’s largely because the game is fairly simple to begin with and doesn’t make use of any C++ features. I did have to adapt the display layout to 128x48 instead of 128x64.
On the positive side, this device has 64 kB of flash, 8 kB of RAM, 8 kB of EEPROM, and runs at 32 MHz. These are all roughly double (or more) compared to the Arduboy. It also has built-in RF wireless, and sips power (largely because of a LCD instead of OLED display)!
But, generally this hardware isn’t a good option for porting Arduboy games too because:
- It doesn’t work with the Arduino environment, meaning potentially a large amount of code re-writing
- SDCC doesn’t contain a C++ compiler
- The LCD is only 128x48 and is a bit slow (30 fps feels about right)
- It is also a bit hard to read depending on background lighting conditions
- Also, the hardware designer screwed up and seems to have reversed the SCK and MOSI pins (from what the hardware SPI supports), so we have to bit-bang the LCD
- The keypad buttons are not really laid out with a d-pad or a/b buttons in mind
- There is no speaker/buzzer or RGB LED
Still, it is really cool seeing an Arduboy game running on a device that cost me less than $1.
Also, this port is only using 10,429 bytes of flash and 837+256 bytes of RAM! That is compared to 16,858 bytes of flash and 1,328 bytes of RAM of the Arduboy version. I’m sure a bit of that is because this port doesn’t have EEPROM or audio support and is probably missing some other features, but still it is interesting to see the difference.
OMG, why have I not seen this before.
Oops, I was wrong. This has 8 Kbit, not 8 kB of EEPROM. So, only 1 kB of EEPROM.
But, support for reading/writing the EEPROM has now been added to the repo.
Added Intel Hex (.ihx, .hex) file support to my fork of CC.Flash https://github.com/GabyPCgeeK/CC.Flash.
Need people to test it.
Advantages of Intel Hex:
Seems to be the default output of SDCC.
Smaller/Faster uploads. makebin seems to generate a file larger than the actual code length.
Looks like you guys have been having fun with other hardware…
I’ve been messing with a smart meter remote display (with touch screen) which I’ve had laid around for a while.
It’s got a ETRX357 zigbee module, but I’ve removed that after capturing the SPI traces to the display and touch controller, and replaced it with an esp8266.
After writing a driver for the display, and touch screen I’ve got this:
Great idea! I like your addition of being able to reset the MCU through the GUI too.
I’m curious if you actually notice a faster upload though? When I was looking through the CC.Flash code it looked like it ignores ‘empty’ pages anyway. So, even though the .bin is larger than it needs to be, I think most of it gets bypassed. But, maybe the progress bar is more useful now?
I also tried increasing the baud rate and reducing some of the delays, but I’m not sure if it really helped much. I’ll try and take some timing measurements later.
I’ll try it out later this afternoon.
You might want to move the chip erase button out of the read/write section and add a confirmation modal. I think it is to close to the write button where it currently is. Maybe put it above/below the Chip ID stuff? Also, I don’t think the verify button does anything right now. Maybe it should get removed?
Keep posting other interesting hardware platforms. In some ways, learning how to re-purpose a device to do something different than intended is more fun than starting from scratch.
After testing it takes the same time to upload. It seemed faster because the ProgressBar moves “faster”.
Added confirmation to chip erase and moved buttons around a little bit.
I’ve been working in getting the ‘Verify’ button functional (close to finishing it).