- Posts: 390
- Forum
- News, Announcements and Feedback
- Feedback & Questions
- PB, request for code review and merge back(2)
PB, request for code review and merge back(2)
- domcars0
- Offline
I agree with PB ....PhracturedBlue wrote: As I said. I've used it. It really doesn't feel that weird to me.
Thanks for your unbelievable work!
Devo 10 (+7e) owner. It's mine, please don't touch it with your big fingers
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Do you really prefer having all the spinboxes work backwards just so that the keyboard works the way you like it?
With your current code, the spinboxes all feel backwards. I am not sure why you are so concerned with the keyboard. It is very rarely used in the grand scheme of things.
If you are really so adamant, put it back the way it was, and I'll give you a build-time option so you can have the keyboard work your way. If enough people complain, I'll make it the default. Certainly I would need to make it configurable from the target/ dir so that the emulator and devo8 behave as they do today.
I know I said you could reverse the buttons, but now that I've tried it, I realize I was wrong about that. With the buttons reversed it will cause a lot of confusion. For instance, setting up virtual channels using the arrow buttons makes no sense. if a button is labeled 'L' on the Tx, it should be labeled 'L' in the GUI as well.
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.
- suvsuv
- Topic Author
- Offline
- Posts: 268
Currently I have another critical issue wanting your help.
I spent a whole day to port the telemetry config and telemetry test(telemetry monitor) pages. The telemetry config page is all done and test wiel with real devo10. However, after I flashed dfu with telemtest page into devo10, its LCD got screwed up and the firmware just doesn't boot.
Now I figure out the something is wrong inside the PAGE_TelemtestEvent(). If I have codes in this function commented out, everything is just fine, otherwise, the devo10 won't boot.
I have checkin codes into my repo. Please check them out (of coz don't merge to your repo now) and see if there are hardware conflicts between current telemetry settings and devo10. Thanks
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.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
I check all GUI_Redraw usages, the only place that might have problem is GUI_Redraw(listbox->scrollbar) in the GUI_DrawListbox method, however, this line won't be hit until entering the Load model or reorderlist pages. But the current issue is the devo10 cannot even boot.PhracturedBlue wrote: Sorry, I didn't get to this tonight. looking at the code though, it seems that you are running GUI_Redraw() on objects that aren't necessarily on screen, and that is likely to cause issues.
I reproduced this issue in another way, if you checkout rev. 898 from my repo and build a dfu, the devo can't boot. Then you can try rev.898, commented out few updates related to the Telemetry stuffs--ported from devo8's main_page, it just works
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
make clean TARGET=devo10
make TYPE=prd TARGET=devo10
That will do an optimized build, and if it works it would be useful info.
Also, please provide the dfu and list file for a build that is not working so I can compare (difference in compile version could be what is causing the discrepency)
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
You are right (but your previous command make prd is incorrect 。 The optimized build works, so we are in short of ROMPhracturedBlue wrote: both 898 and 899 work for me. We are starting to get low on memory though (Deviation uses a lot of stack space). It might be a good idea to try doing a:
make clean TARGET=devo10
make prd TARGET=devo10
That will do an optimized build, and if it works it would be useful info.
Also, please provide the dfu and list file for a build that is not working so I can compare (difference in compile version could be what is causing the discrepency)
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
I am building a script that will calculate stack usage, which should help give a better idea of where we stand.
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
1) Initially, I also suspected that the build might reach the limitation of ROM, however, the MCU's sheet mentions it has 256KB ROM and 48K RAM , but the debug build's size is only about 240KB and 22KB RAM. Where are the missing ROM?
2) Eventually the release build should be optimized , hence the release build 's size is only about 140KB, do we need to remove some redundant codes(all my traditional mixer files have been cut 2 days ago)?
Anyway, thanks for your help, the telemetry pages should be done today and request for your code review again
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
As I said, we're not out of ROM. You'll get an error when that happens. If we are out of RAM (and it is not a sure thing) then it is likely because of stack usage.
the summary that Make reports only includes RAM allocated to static variables. any temporary variables that are defined within functions are allocated on the stack, and thse are not accounted for (and can be very large). Additionally, the newc library does implement some malloc() calls (used for sprintf for instance) which go on the heap, and are also not accounted for.
If you have the ability to read from the UART, you can enable HEAP_DEBUG to see heap usage (but not in the prd builds, since those disable the PPM)
I'll get you some more detailed info later.
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
1) Synced with your latest update
2) Telemetry config and monitor pages are ported, but I don't have an RX to test against. I also want you to provide an option to let user fully shut-off or turn-on the telemetry monitoring in the TX
3) Improve the appearance of the scroll bar
4) Change the orientation of the horizontal bar: 100 is to the left and -100 is to the right, aligning the orientation of the AIL/RUDD sticks
5) Fix bugs
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
What is your reasoning here? Is it a concern about power? I've been considering creating a 2nd protocol 'Devo' and 'DevoTelem' to do exactly that, but I really don't see the benefit at the moment.suvsuv wrote: 2) ... I also want you to provide an option to let user fully shut-off or turn-on the telemetry monitoring in the TX
I understand your reasoning here, but overall i think it is the wrong answer. everyone expects bigger to be to the right. it is how all progress and bar-graphs are made. Maybe it would make sense for the ail/rud bars (only) to be reversed, but overall, this change isn't right.4) Change the orientation of the horizontal bar: 100 is to the left and -100 is to the right, aligning the orientation of the AIL/RUDD sticks
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
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.
- PhracturedBlue
- Offline
- Posts: 4402
FYI, you should remove your changes to main.c I think. If you compile an optimized build they aren't needed (I get the low power case always with an optimized build) and as I've shown elsewhere, they are at best a band-aid and don't correct the underlying issue.
Please Log in or Create an account to join the conversation.
- suvsuv
- Topic Author
- Offline
- Posts: 268
I just fixed some new found bugs, please have them merged to your trunk
1) Telemtest_page.c: should initialize scroll_bar, or the TX will hang when keeping pressing UP/DOWN in the 1st telemetry monitor page
2) Label.c: add 1 more line spacing
3) In the main.c , currently you set the initial brightness to 9, which leads to a visible flash light in booting the TX as most users might set the brightness to lower than 5. Just want to know what could happen in the devo8 if this initial value is set to 1 or 2
So far, all deviation 8 features , except for the scanner, are in the devo10, I am working on auto-dimm feature. The remaining known issue is that the more current consumption after manual binding, please let me know once you have further solution for it.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
setting it to 1 is fine.suvsuv wrote: 3) In the main.c , currently you set the initial brightness to 9, which leads to a visible flash light in booting the TX as most users might set the brightness to lower than 5. Just want to know what could happen in the devo8 if this initial value is set to 1 or 2
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.
- Forum
- News, Announcements and Feedback
- Feedback & Questions
- PB, request for code review and merge back(2)
- Home
- Forum
- News, Announcements and Feedback
- Feedback & Questions
- PB, request for code review and merge back(2)