Creating and uploading FX data to the flash chip is now also much easier.
When using the Arduino IDE:
Install the Arduboy FX Arduino plugin With this plugin the FX data can be build and uploaded through the Arduino Tools menu.
For alternative methods:
fxdata-build.py is a Python tool that parses a special format text file and creates a C header file to include with your project and a fxdata .bin file that can be uploaded to the FX flash chip.
fxdata-upload.py is a Python tool that uploads the fxdata .bin file.
uploader-gui.py is a Python GUI tool to upload hex files, flashimages and fxdata .bin file.
Ah nooo… forget it. I just missed to flash my .hex again. I had an old version burned before and just flashed the flashcard binary but did not update the sketch in the progmem…
I get the following warning when compiling my code:
src/cart.h: At global scope:
src/cart.h:56:17: warning: always_inline function might not be inlinable [-Wattributes]
static void disable() __attribute__((always_inline)); // deselects external flash memory and ends the last command
Anyone knows how to fix this. I can probably just remove the attribute but obviously the intention was to always inline it. Does it work for others?
Whenever there’s an #include, the preprocessor reads the file and dumps its contents into the place where the #include was.
If Arduboy2.h happens to be included before cart.h then there won’t be any problems.
If it hasn’t been included before cart.h then there will be errors because cart.h won’t be able to access the macros/identifiers that it needs.
This applies to every translation unit, and each .cpp file is treated as a separate translation unit.
So if one .cpp file ends up including Arduboy2.h first then it won’t have a problem, but another might include cart.h first and then that .cpp file would have a problem.
This is why it’s good practice to always reference every single .h file that a file explicitly/directly needs, regardless of whether it seems redundant.
It’s also good practice to include the minimal header that will give the feature(s) that you want.
(Which is why a lot of my code uses stddef.h - it’s the minimal file for getting size_t.)
displayOn and displayOff are functions.
Or were you thinking of something else?
Yes I do. I’ll try again later as I like to recreate errors.
Comparing with a light switch. You can turn the light on and off by flipping the lever.
By enabling and disabling I mean inserting or taking the lever out. the light can be on or off. But without the lever you can not control the light.
by disabling the OLED chipselect pin the OLED display will no longer listen to SPI data. By enabling the chipselect pin again it will listen to SPI data again.
Both the flash chip and OLED display share the same SPI bus. So only one device should be selected at a time (unless you know what you are doing )
Sorry about that. I shall try to be more explicit.
Here’s something to toy with. drawbitmap supports masked ‘sprites’ @bateske, when I drag and drop an .arduboy file onto a message it doesn’t auto play. So I’ve added the Iframe bit again.
removed iframe code (after being possessed by @bateske)
Press B to toggle show/hide position. Press and hold B to move background instead of chompies. press and hold A for single step movement. Reduced frame rate to 60fps so it runs (hopefully) smoother in ABE.
Actually it totally works and I’ve been possessed by @bateske to have it in my post here:
Good to know When I drag and dropped the .arduboy file, I just kept seeing the Fm logo (tried a couple of times)
Yep huge bitmaps can be draw as plain bitmaps or masked now. Also want to add a few other modes. like inverse and so. But first I want to add support for irregular pixel heights. so you can have tiles like 10x10 or 20x20 or so. I didn’t get that working yet.
That explains it
@bateske, you should try put the files on Arduboy, rip out the cart and reinsert it. Then you’ll know I’m not cheating