- Posts: 22
Devo 12
- thloh85
- Offline
Please Log in or Create an account to join the conversation.
- Eriskio
- Offline
- Posts: 19
PB, only a word: FANTASTIC! SPECTACULAR JOB!
It is always possible to save models on PC before firmware upgrade to be able to restoring them, isn't?
Some work indeed, but this way it is always possible test new firmware without losing models, I think.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
You can use the STM DFuSE tool to download the entire SPI Flash image (and then restore it the same way), but youneed to be careful not to use it for 'upgrading' the firmware, since it will not work for that. I don't think this is generally a workable solution.
There are 2 alternatives:
1) I can write my own DFuSE upgrade tool. I've been thinking about that for a while now. It would:
* give a solution to Windows, Mac, and Linux folks
* prevent the accidental 'upload' that corrupts your DFU
* prevent installing a firmware for the wrong Tx
* Allow easy backup/restor of the config/models
2) We could have Deviation preserve the space used by Walkera's config/model files. This is what we do fro the Devo 8/10. But the Devo12 and 7e have a smaller flash chip, and this will eat into the space available for icons and models if I do it on the Devo12.
Please Log in or Create an account to join the conversation.
- Eriskio
- Offline
- Posts: 19
PhracturedBlue wrote: 2) We could have Deviation preserve the space used by Walkera's config/model files. This is what we do fro the Devo 8/10. But the Devo12 and 7e have a smaller flash chip, and this will eat into the space available for icons and models if I do it on the Devo12.
Actually (and IMHO) I think it is not necessary to be able to "store" all configurations in memory (both walkera and deviation versions".
I think the problem could be limited just the time to migrate from one software to another, move all parameters, check they work correctly or for debug purposes.
From a RC pilot point of view it has no sense to go back and forth from a software to another, except for debugging and behaviours comparison.
I mean (and I think) that the migration should be some sort of "definitive" thing (if anything is working as expected ).
So, I vote for the first solution! Even if it an further effort for you... and we all will have to say "thanks" to you in some way...
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
The Walkera configuration takes up 61 * 4096 = 250kB of a 2MB flash chip I believe. That is 60 models + the config data.
In Deviaton, the current usage is 380kB for the base system (since the media is not part of the filesystem, and is by far the largest part). If we were to preserve the walkera config, that would leave us ~1.5MB for icons. The current icons are 96x96 and take up 18kb (20kb on disk). So you can get ~70 model icons onto Deviation with 100 model files. Of course we may go to a larger icon size for the Devo12 eventually which would reduce that. Not preserving the Walkera model/config would enable another 10 or so model icons.
So likely I will go to (2) before release. It makes it easier for folks to try Deviation, see if they like it, and then go back if they don't. Just common courtesy. At the moment it doesn't actually limit us significantly.
Please Log in or Create an account to join the conversation.
- RandMental
- Offline
- Posts: 521
My wish list for such a USB / PC support application:
1) Model - Upload
2) Model - Download
3) Model - New Model from template
4) Model - Edit (existing model)
5) Model - Copy (duplicate existing model)
6) Model - Compare (to another model)
7) Model - Archive (to PC disk)
8.) Upgrade - Uploading Deviation Firmware, dfu files and file system
9) etc
Edit: Of course they will all be running Deviation firmware!
Please Log in or Create an account to join the conversation.
- Ustas69
- Offline
- Posts: 6
Please Log in or Create an account to join the conversation.
- Sid3ways
- Offline
- Posts: 9
Please Log in or Create an account to join the conversation.
- Babay
- Offline
PhracturedBlue wrote: 1) I can write my own DFuSE upgrade tool. I've been thinking about that for a while now. It would:
* give a solution to Windows, Mac, and Linux folks
* prevent the accidental 'upload' that corrupts your DFU
* prevent installing a firmware for the wrong Tx
* Allow easy backup/restor of the config/models
I agree on the first solution, because for Linux still does not have a normal tool to update the firmware. I have use a virtual machine just for this.
Please Log in or Create an account to join the conversation.
- Eriskio
- Offline
- Posts: 19
Babay wrote:
PhracturedBlue wrote: 1) I can write my own DFuSE upgrade tool. I've been thinking about that for a while now. It would:
* give a solution to Windows, Mac, and Linux folks
* prevent the accidental 'upload' that corrupts your DFU
* prevent installing a firmware for the wrong Tx
* Allow easy backup/restor of the config/models
I agree on the first solution, because for Linux still does not have a normal tool to update the firmware. I have use a virtual machine just for this.
Ya, actually the big difference than makes the first solution preferable is not (limited to) the number of models you could store in memory but the others concept PB exposed (and Babay quoted): portability, safety, ease of use.
Please Log in or Create an account to join the conversation.
- Hexperience
- Offline
- Posts: 588
There are 10 types of people in this world. Those that understand binary and those that don't.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
The 'emulator' is actually just a different target (like devo6, devo8, devo10) that builds against fltk. So it isn't really na emulator at all, but is a native build for the PC. As such, it isn't possible to load a firmware into it.
Please Log in or Create an account to join the conversation.
- Hexperience
- Offline
- Posts: 588
There are 10 types of people in this world. Those that understand binary and those that don't.
Please Log in or Create an account to join the conversation.
- Ustas69
- Offline
- Posts: 6
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
FDR wrote: Cool!
What's next? F7 or F4?
I think it has not sence at all. Devo F7 has not graphical interface, it looks like text subtitles on video display.
Please Log in or Create an account to join the conversation.
- RandMental
- Offline
- Posts: 521
What is next?
I believe once we have this version stable and released, including code to make full use of the Devo12 larger screen) we should look at a few enhancements to Deviation environment applicable to all TX versions:
1) Formal support for PPM output and Simulators like Phoenix, Realview, etc
2) Support for a Trainer function betweeen two Deviation TX's
3) PC based support environment.
4) ....
PB, any thoughs on this and where you want to take this?
(EDIT: I know we have PPM support, but PB still needs to sign it off)
Please Log in or Create an account to join the conversation.
- Wene001
- Offline
- Posts: 277
Please Log in or Create an account to join the conversation.
- FDR
- Offline
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
* Properly calculate battery voltage
* Add a low-pass filter to handle ADC noise. I'm almost positive this noise is due to bad route paths on the Devo12 circuit board, so there's nothing else to do about it
* Add PPM output of trainer port
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Development
- Devo 12