GUI

More
11 Aug 2012 01:56 #1059 by PhracturedBlue
Replied by PhracturedBlue on topic 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.

Please Log in or Create an account to join the conversation.

More
11 Aug 2012 18:50 #1060 by FDR
Replied by FDR on topic Re: GUI

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...

Please Log in or Create an account to join the conversation.

More
11 Aug 2012 21:19 - 11 Aug 2012 21:21 #1061 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI

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
Last edit: 11 Aug 2012 21:21 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
12 Aug 2012 23:30 - 12 Aug 2012 23:33 #1063 by sutaburosu
Replied by sutaburosu on topic Re: GUI
PB, you laid your cards on the table earlier w.r.t. your dedication to the project; to set reasonable expectations I think I should do the same now.

I'm not a professional programmer, and creating/maintaining big projects is not one of my strengths. I've been a geek for >20 years, and a sysadmin for >10. I've written tools for my business using Bash/sed/awk, PHP, Postgres, Perl (a long time ago). I'm pretty comfortable using svn but hg is new to me. I've written a total of about 25,000 lines of C as a means of prototyping demo effects . I've had very pleasing results after scattering a little inline assembly (with proper clobbers, of course) to help with GCC's sub-optimal ARM output.

I'm very busy right now, but I hope to find time in a few weeks to play around with some ideas I have. I've researched the ARMv7-M architecture. OK, so we have the Thumb2 opcodes only; not a problem. I'm having trouble finding details on exactly how slow each type of storage is. I'm guessing CPU: a jet-engine on a skateboard, RAM: v. fast, ROM: quite fast, Flash: slow, Screen: v.v. slow

PhracturedBlue wrote: It takes about 280msec to draw the entire screen with a non-transparent bitmap.

How long to simply clear the framebuffer to 0, without any flash and filesystem overheads? And how long to 0 an equivalent amount of RAM (I know there's only 32KB)? I've been too pusillanimous to flash my Devo8 yet, or I'd try to answer these questions for myself.

Some things I'd like to try:
  • Drop all the BMP cruft. Presumably we need only Xres and Yres in addition to the bitmap data.
  • Move all bitmaps into a single resource file (with a block of pointers at the start), to eliminate wasted flash bandwidth reading slack space due to block/page sizes.
  • A 640-byte buffer would permit each line to be composited in RAM, eliminating overdraw bandwidth on the link to the screen.
  • I know you already have windowed plotting modes. Using the composition buffer would help implement bitmap compression without mangling the code too much: RLE compress each line of the bitmap separately, and ship a table of pointers to the RLE data for each scan line (deduplicating identical lines, of course!).
  • Cache a couple of pages of Flash in all that spare RAM we've got lying around doing nothing :dry:
  • Switch to 8-bit colour, and immediately halve the size of the bitmaps and framebuffer for double the performance. :P
Last edit: 12 Aug 2012 23:33 by sutaburosu.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 00:34 #1064 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
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.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 00:37 #1065 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
As for performance.
RAM and ROM read is at CPU speed (72mhz). RAM write is the same.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 05:57 #1066 by FDR
Replied by FDR on topic GUI
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

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 06:15 #1067 by PhracturedBlue
Replied by PhracturedBlue on topic GUI

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

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 08:00 #1068 by FDR
Replied by FDR on topic GUI
OK, thanks!

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

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 08:21 #1069 by wuselfuzz
Replied by wuselfuzz on topic GUI
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.

For example, I tried to look into this issue bitbucket.org/PhracturedBlue/deviation/i...er-page-to-the-right

While I have a general understanding of how page switching works, and how callbacks for button handling work, it's IMO hard to grasp what's really going on there.

IMO, a button handler generating button press events that are going to a single event handler for each page would be simpler, easier to understand design.

Also, stuff like this
if (last_buttons && button_time++ >= 4 && (button_time & 0x01)) {
...

makes me cringe. "Increment button_time, and if the non-incremented value is larger or equal than 4 and odd, then do..."
#include <stdio.h>

int main() {
   int i=5;
   printf("i++: %d\n", i++);
   i=5;
   printf("++i: %d\n", ++i);
   return 0;
}
Output:
i++: 5
++i: 6

Brian Kernighan wrote: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.


Alright, enough ranting. We'll see where this goes. I still appreciate all the work you guys put into this project.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 08:35 #1071 by sutaburosu
Replied by sutaburosu on topic Re: GUI

PhracturedBlue wrote: So yes, if we removed all bitmaps, we could significantly speed up performance.

Please don't misunderstand me; I'm not proposing removing bitmap support, but rather trying to improve the performance of the existing code.

The USB mass-storage is a neat feat, and I can see it being popular with users. The only change I want to make from a user's perspective is that they'd copy a 'compiled' theme file to the Devo, rather than a folder full of BMPs. The theme file will contain compressed, headerless bitmaps and associated meta-data.

Thanks for all the information. It's reassuring to see there's a possible ~10x speed-up. That will no doubt lure me into trying to attain such an improvement. 30ms to fill the screen is a useful speed. I'll have trouble resisting writing graphical hacks for it! ;-)

I'm well versed in optimising graphics routines for a fast ARM stuck between two slow busses. This will be fun for me.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 14:56 #1072 by PhracturedBlue
Replied by PhracturedBlue on topic GUI

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.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 15:09 #1074 by PhracturedBlue
Replied by PhracturedBlue on topic GUI
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?

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 15:16 #1075 by FDR
Replied by FDR on topic GUI

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.

Please Log in or Create an account to join the conversation.

More
13 Aug 2012 20:07 #1078 by wuselfuzz
Replied by wuselfuzz on topic GUI

PhracturedBlue wrote: 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.


Alright, here's some stuff I have on my mind:

1. Transmitter mode. I already moved that to the transmitter settings from the model settings. Switching between Mode 1 and Mode 2 requires a hardware change (only a mechanical one, but it still stands :) ), and downloading a model that has mode 1 set on your mode 2 tx and not being careful might leave you up with something like this: wuselfuzz.de/images/funjet/IMG_1407.JPG

2. I'd define a fixed channel order for the mixer outputs (TREA...) and do the reordering in the protocol stack. This removes an unneccessary dependency of the mixer to the output protocol.

3. Some renaming and restructuring: I'd define an array, similar to Channels[], that provides all input values (sticks, switches), in a defined order (e.g. Inputs[0]=throttle stick, Inputs[1]=rudder stick, ..., Inputs[5]=Flight mode switch, ...). This array should already be reordered for Tx mode, calibrated etc. The mixer module should then solely use those Inputs[] and generate an Outputs[] (or Channels[], this would be the same) array, passed to the radio stack.

4. Radio. IMO, this requires some extensions. The radio stack should consist of a state machine, having the states init (i.e. reset and init CYRF), setup (i.e. WK non fixed id binding), transmit (i.e. taking the Outputs[] array and sending radio packets) and bind (i.e. DSM2 rx binding).

Instead of the ChannelMap, I'd create an array of protocol descriptors like this:
struct ProtocolDescriptor {
    enum Protocols              protocol; 
    enum ProtocolChannelOrder   channel_order;
    char                        *name;
    u32                         max_channels;    
    u32                         packet_dt; // duration between packet transmissions, in usec
    u32                         (*init)();
    u32                         (*setup)();
    u32                         (*transmit_packet)();
    u32                         (*bind)();
};

5. GUI. Ugh.

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.


I would like to say "dito" pretty much, but it still needs to be stable. So, uh, yeah, I'll probably rip down the GUI to the bare minimum in my fork soon, so I have something to work with.

Please Log in or Create an account to join the conversation.

More
14 Aug 2012 00:35 #1079 by PhracturedBlue
Replied by PhracturedBlue on topic GUI
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 :)

Please Log in or Create an account to join the conversation.

More
14 Aug 2012 02:51 #1080 by PhracturedBlue
Replied by PhracturedBlue on topic GUI
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.

Please Log in or Create an account to join the conversation.

More
14 Aug 2012 03:31 #1081 by PhracturedBlue
Replied by PhracturedBlue on topic GUI

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)

Please Log in or Create an account to join the conversation.

More
15 Aug 2012 11:56 #1087 by FDR
Replied by FDR on topic GUI
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.

Please Log in or Create an account to join the conversation.

More
15 Aug 2012 13:52 #1090 by PhracturedBlue
Replied by PhracturedBlue on topic GUI
I created a 'Fixed' curve that can be used for creating constants. Use 'offset' to move it up and down

Please Log in or Create an account to join the conversation.

Time to create page: 0.150 seconds
Powered by Kunena Forum