Uri_ba's pit

new update in the works – and I’ve started working on input devices.

Hi Guys,
Just a quick update,

I’ve done some re-fracturing to the code making it more readable and easier to configure for those of you how prefer not to dig in too dip into the software more than they must.

I’ve still got some testing to finish, but I hope to get it out my the middle of the week.

I’ve also doing some work to make the FFI usable again on Uno,
Unfortunately the new font is eating more RAM that the Uno can handle – So I’ll be reverting uno users to the old standard font as it was originally – it will be less accurate – but the overhaul performance should be back to reasonable (as it was).

As it is, I’ll stop developing new things for the Uno, and this will be the last release the Uno is the default. I will leave all the current things for the uno, and I’ll make sure I maintain compatibility with it in the base things, but it will no longer be the default arduino.

The Micro (32u4 based stuff) – are the new minimum recommended for now – you can get a pair of “Pro Micro” clones for 10-15USB off ebay, so that is good enough IMHO.

I continue however to recommend getting a Due, or Due compatible board, if you are planning extensive use of this project in your pit.

As the project progress, the added CPU and RAM will git it a very obvious performance advantage.


Other then that…

I’ve started working on Input device, my first victim will be the ICP, I’m planning (for now) to use ATMEGA328P chips, clocked at 20Mhz as input devices using V-USB library.

As a first step, I’m going to rid myself of the need for a programmer, by burning the usnoobie firmware on them. usnoobie, allow the ATMEGA, with a press of a button on boot, to become an ASPusb programmer, and upload code to themselfs, allowing those input devices to be firmware upgrade-able without too much trouble.

another option I’m considering is using the previously mentioned “Pro Micro” as input devices using the LeoJoy project. as the 32u4 has native USB capability saving all the fuss for setting up a VUSB hardware rig. but I’ll get some experiense with both, and deside later down the road. so far using a custom hardware solution seems more attractive to me (just because.. :)) – but the simplicity of using a micro will probably win at some point down the road.


Uri_ba's pit

Solving my light Issues – initial thoughts

After trying to solve the light issues – I’ve decided to step back and look at the situation from another angle.

I have 4 OLED screens to drive – DED, PFL, CMDS and FFI
they are all using SPI – which means I’m low on I/O pins on Uno and Micro because of the need for CS for each screen.

My light situation is somewhat limited due to the same issue – If I go via SPI, I’ll need another CS pin for every device – and I’ll need to work around my issues with multiple SPI devices.

the Other option is keep the SPI for the OLEDs and swap all the lights to use I2C I/O expenders this will pretty much allow me to wire up everything and power it all via a single Arduino Due (due to the faster CPU and no memory issues). it will also allow me to overcome the issue I had with 3.3V logic on a 5V bus I have with the Due.

Uri_ba's pit

DEDuino – Some more performance tuning

I’ve been Working on some way to streamline performance as much as I could. The biggest performance limiter, is the drawing of the big screens (DED/PFD),

One of the tricks I’ve thought might help was to switch the display from 2 bit color mode to 1 bit (4 shades of “grayscale” to only “black and white”) theoretically – a 100% boost, it practice I have discovered I had a bug in the code all along. Apparently U8Glib has a switch to handle displays bigger then 240pixels, I’ve known about it but as long as I’ve been using the grayscale mode, I’ve been unaware of it (because the part that didn’t work was black). once I’ve switched to BW mode – it lit up casing stripes on the screen.

To fix this, and simply basic installation, I thought about including the entire U8Glib library, with the required change in the folder. Unfortunatly, the Arduino IDE does not allow this, So I’ll be including a ZIP file with the modified library for easy import into the IDE.

I’ve also found out that  my plan to flip the DED display (to allow better weight distribution in the case) is a very bad idea as putting in “rotate 180” on the screen almost halfs the FPS.

I’ll be working on this some more till the PCBs arrive – but I think this is pretty much the limit as far as my ability to optimize the code to improve refresh rate.