Auto update will kick-in next time you launch the app.
Application now support “auto start” – check the “Advanced tab”.
Context menu added to systray.
DLL was merged into the EXE – no need to have the dll anymore.
still on the TODO list:
allow program to start minimized.
following a bug report, I’ve done some changes to the connector app.
apearantly due to a BMS issue, the app does not recognize you have entered the cockpit during ramp start, casing the DED to show “Falcon not ready” message.
I’ve reverted to an old workaround I’ve used in early development, it’s ugly, but it works for now.
I’ve pushed the update, and you should be getting a request to update next time you launch the connector app.
while at it, I’ve found an issue in the self updating routine, which will be addressed at a future update.
sorry for the inconvenience,
Yet another patch for the code.
this release has focused on two things.
1. Making the code easier to handle for the novice.
2. Bringing the performance of the Uno back to acceptable level.
To achieve this, a new “config.h” file was created, bringing together all the important settings and features (I’ve even tried to get everything properly documented…).
Please note that the default is now “Arduino Micro” – as it is in my opinion that minimum required board (due to the Uno Memory constraints). If you with to use an Uno (or a Mega as some are doing – please make sure to select the proper option)
To get the performance back to the uno the code now intentionally disabling RealFFI and Bezel options (regardless of what “config.h” says). This can be overridden via the “fuelflow.h” file – but please note there is a performance impact.
As always, links for the download are at the download page.
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.
After the release of 1.1.3 I’ve learned some more about the limitation of the Project in regards to features with arduino models.
1. You MUST use Arduino IDE 1.5.x as the earlier version (1.0.x) compiles the code differently (which causes some odd annoying bugs.)
2. Arduino Uno has too little memory to handle too many things. Uno is the default for the project, as it is the most common model. it is NOT however the recommended model, the bare minimum is the Arduino Micro (which has 512 bytes of extra memory over the Uno). Due is highly recommended (and the entire project will soon shift towards it – but for now Micro is the Dev board I’m working with).
The biggest flaw with the Uno for now is that the RealFFI mode can only be used on an Uno if the FFI is the only screen active. If you have a DED/PFL enabled, the Uno does not have enough RAM to render the FFI frame correctly. however, because of the displays are using the same display and font enabling both DED and PFL is not a problem. you can even have the FFI enabled in “BMS render” mode without issues.
And as a bonus for hanging on so long some clips of DEDuino around the world! 🙂
From Italy we have “Cool hand”‘s DED box:
From Australia (the one with the Kangaroos),
we have “Moon”‘s prototype with a temporary paper bezel.
And from Korea we have “Mace”
And his video can be found on one of his forum Posts
And thank you for all the support!
I hope this will be the last of the 1.1.X line
in this Version the FFI has come full circle and has been completly overhauled with the help of the community.
It now includes a new display mode dubbed “RealFFI” that renders like the real thing (rather then mimicing the BMS FFI behavior as before). Both version are available, with the Performance advantage on the BMS render mode.
New link for downloads, and it’s here to stay 😉
A real FFI: