GUI

FDR wrote: 8. Something is fishy with the trim settings saving: it leave out the trim3, or if I set it up again for the rudder trimlh-/trimlh+, then it writes RUD as source instead of it's code...

should be fixed

9. After reseting a model data, paging puttons of the model page don't work, I have to exit to the main page first...

fixed

I think I prefer outright bugs reported through bitbucket. it is easier for me to keep track of them there.

If there is discussion needed, this is still the best place though.

PhracturedBlue wrote: With regards to using 0 for transparency, this isn't the bottleneck. There are 2 things that control the speed of refresh:
1) the speed of reading from SPI flash
2) the speed of writing to the display

LCD pixel access is not very efficient, and you cannot choose to skip a pixel when streaming writes, so having transparency is expensive if it is used a lot. The code is about as efficient as possible handling transparency today.

Reading from the Flash is not very fast, and bitmaps are quite large (relativelyu speaking). We pay a significant penalty for supporting bitmaps in the code.

It takes about 280msec to draw the entire screen with a non-transparent bitmap.
The time is almost perfectly linear to the number of pixels drawn. So the fastest display possible is to only incrementally draw what needs it, and to draw shapes (not bitmaps). We've done this as much as possible already with the current code, but refresh is still slow. It has virtually nothing to do with the performance of the code though, it is now almost entirely related to the speed of the SPI and FSDM bus.

Yep, I think there is room to refining.
While a toggle is displayed quite fast, the clearing of it takes a lot of time, because it redraws the whole background, and all the objects on it.
If we could support the partial redrawn of the background, we could do it with the known rectangle of the control that needs redrawing...

FDR wrote: Yep, I think there is room to refining.
While a toggle is displayed quite fast, the clearing of it takes a lot of time, because it redraws the whole background, and all the objects on it.
If we could support the partial redrawn of the background, we could do it with the known rectangle of the control that needs redrawing...

That is done on purpose.
Generally there are2 cases when a widget is removed:
1) I'm changing pages. I need to redraw the entire page anyway
2) The widget was temporarily on this page. I need to redraw everything because it may obscure something underneath.
There may be a couple places where neither of these are true, but they seemed rare enough that the current rules are acceptable.

Edit: The 'toggle' icon is a special case, and we probably should handle it better

If you write the entire screen as fast as possible, it appears to take ~30msec. That is a measurement I took early in the process (mid April) and I'm not 100% confident in it, but it is probably in the ballpark:
www.rcgroups.com/forums/showthread.php?t...ht=doom#post21345448

So yes, if we removed all bitmaps, we could significantly speed up performance. Writing a solid color is not important, as the speed to write a pixel is independent of color.
Changing the x/y location costs ~ as long as writing 5-10 pixels, so you want to draw as many pixels as possible in a row as possible (note that teh display uses windowing, so you can fill a window on the display without any repositioning commands except the 1st one.

You are right that we could improve performance by removing the BMP and/or filesystem support, but these are also some of the biggest benefits of the deviation firmware. we could possibly split the difference, allowing color control without bitmaps, I suppose, but I am not yet too concerned with display performance.

By the way, the filesystem and paging support has minimal overhead. opening a file takes less than 1msec, as does switching ROM pages within the filesystem.

As for performance.
RAM and ROM read is at CPU speed (72mhz). RAM write is the same.

Compile error:

FDR wrote: Compile error:

+ Building 'emu_devo8.exe'
objs/emu_devo8-w32/main.o: In function `main':
C:\MinGW\msys\1.0\home\FDR\src\deviation\src/main.c:45: undefined reference to `
A7105_Initialize'
objs/emu_devo8-w32/flysky_a7105.o: In function `flysky_cb':
C:\MinGW\msys\1.0\home\FDR\src\deviation\src/protocol/flysky_a7105.c:127: undefi
ned reference to `A7105_WriteData'
C:\MinGW\msys\1.0\home\FDR\src\deviation\src/protocol/flysky_a7105.c:131: undefi
ned reference to `A7105_WriteData'
collect2: ld returned 1 exit status
make: *** [emu_devo8.exe] Error 1

fixed.
But I currently have A7105 support enabled. you may want to turn that off as I'm not sure it is compatible with the CYRF6936.

Comment out:
#define PROTO_HAS_A7105
in target/devo8/devo8_target.h

OK, thanks!

BTW the emulator' model page lists the last protocol as "J6ProFlysky"

wuselfuzz wrote: I started rewriting some stuff in my fork last weekend, partly to squish some bugs, but mainly to get a better understanding of the code.

To be blunt, I disagree with some of the programming techniques used in the original code.

I have no problem with you reimplementing whatever you like.
If you find a bug, let me know, and I will address it. If you want to make architectural changes I'm all ears, and I'm receptive to pull requests as long as I agree with them. I think I've already made my position clear on the GUI: I really have little interest on working on it any more than I absolutely have to.

FDR:
You filed a bug about how the trims work. I wanted some more feedback on how you think it should work.
currently the trims are stored with the tx settings. thus they are restored when you start the Tx, but are not changed when you switch models. I could save them with the model data, in which case when switching models, you'd get back your previous trim values, or I can zero them out when switching models.
Which would you prefer?

PhracturedBlue wrote: FDR:
You filed a bug about how the trims work. I wanted some more feedback on how you think it should work.
currently the trims are stored with the tx settings. thus they are restored when you start the Tx, but are not changed when you switch models. I could save them with the model data, in which case when switching models, you'd get back your previous trim values, or I can zero them out when switching models.
Which would you prefer?

They definitely need to be stored separately for each model!
On switching models they should be saved to the model data (with all the other model data changes) just like at shutdown, and the newly loaded model trim values be applied.
If the new one doesn't have trims configured, then they should be set to zero.

wuselfuzz,
Rather than trying to enhance what we have, it sounds more like you want to take this project in your own direction. Maybe it is your intention, or maybe I'm inserting a tone into your message that isn't actually there, but either way it is fine. If so, is much like what er9x did with the th9x source, and is the whole point of open source.

Your philosophy and mine seem to be diverging, but let's see..
1) Agreed. I'll take this change

2) The protocols do not interact with the mixer at all, so I'm not really sure what you are trying to get at here. I also prefer having the channels shown in receiver order personally, but I'm certainly open to other options if they prove easier to use. I don't think fixing the channel order has any benefit until there is a GUI to back it up though.

3) I see no value in using an input array vs the callback function we have now. There is really no difference between them. The mixer can be self-referential and so cannot solely use inputs to generate outputs. Otherwise the big difference between your definition and what we have s that you need an intermediate array of mixer values and to select between the inputs and mixer outputs during mixing. I can understand architecturally why that may seem cleaner, but I think it will complicate the mixer logic further.

4) I much prefer having each radio be implemented independently (each with their own state machine) than trying to coerce potentially very different protocols into a common framework.

5) I've already discussed the GUI. If you can provide something better with equivalent functionality I'm all for it.

And from your previous post:
Handling the buttons in a single handler requires a very different GUI design than what we have, unless I misunderstand you. I don't see any reasonable way to do it with the current architecture, so I'll be interested to see what you come up with.

The thing you didn't discuss at all was throwing the mixer away and providing an alternate solution. It is the most obvious change to make because the mixer is probably the most controversial part of the Deviation firmware. It is very complicated and difficult to configure for end users. It is also very flexible and powerful. Maybe it is on your list and you just didn't want to spring it on us all at once

I merged all of wuselfuzz's current changes, as they looked good.
there were several bugs in the touch and button code which I fixed, as well as getting the emulator working again.
The changes were quite extensive (although functionality change we minimal) so hopefully there aren't many regressions. If there are, they should be easier to find, as his code is easier to understand.

PhracturedBlue wrote: I merged all of wuselfuzz's current changes, as they looked good.
there were several bugs in the touch and button code which I fixed, as well as getting the emulator working again.
The changes were quite extensive (although functionality change we minimal) so hopefully there aren't many regressions. If there are, they should be easier to find, as his code is easier to understand.

Note: You need to reload your models/ dir (or remove 'mode=' from the model files)

I would like some more functions to be able to choose from: MIN, ZERO (or "0"), and MAX, i.e. -100, 0, +100.
They would be useful setting constant values (with the help of simple scale and/or offset) much easier, then a 3 point curve.

I created a 'Fixed' curve that can be used for creating constants. Use 'offset' to move it up and down