- Posts: 31
What to do?
- kohansey
-
Topic Author
- Offline
Less
More
11 Jul 2012 19:20 #472
by kohansey
What to do? was created by kohansey
Hey guys, I have been reading through your forums and have the project emulator working. I would like to first thank you guys for letting me in on this project. I would like to get started right away. Unfortunately I don't have a Devo yet to do any development, so I was wondering what could I work on something that doesn't require the TX to test. Is there a TODO list, bug list or need to implement feature list? I don't want to step on anyone's toes. If you could point me in the right direction, I try to help as much as possible.
Please Log in or Create an account to join the conversation.
- FDR
-
- Offline
11 Jul 2012 19:41 #473
by FDR
Replied by FDR on topic Re: What to do?
Hi!
Since nowadays PhracturedBlue is doing the programming alone, any help would be welcome.
I think the GUI part is where the most help is needed, and it can be done in the emulator without a tx.
If you have read the GUI thread, you already know what we are after...
Since nowadays PhracturedBlue is doing the programming alone, any help would be welcome.
I think the GUI part is where the most help is needed, and it can be done in the emulator without a tx.
If you have read the GUI thread, you already know what we are after...
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4402
12 Jul 2012 06:09 #476
by PhracturedBlue
Replied by PhracturedBlue on topic Re: What to do?
The first thing you should do is to make sure you can build and run the emulator. You can play around with it to get a feel for what it can do.
There are several things you could work on:
1) You said you were planning to use a Devo12. If that is the case, you might want to start working on the devo12 emulator. It will be nearly identical to the devo8 emulator, with (that I know of) the following changes:
* screen is 480x272
* more switches
* more flash
The big deal here will be the screen. We either need to develop a different GUI for the 12, or we need to figure out how to abstract the one we have for it. But also we may need to move stuff around so that we can share files between the devo8 and devo12
2) There are several things needed for the current firmware (all non-graphical items will be shared by all future supported transmitters):
* failsafe
* timers
* heli-settings (swash type)
* alarm
* Model icons
3) We are currently trying to figure out how to setup the gui to work with the Tx buttons. At the moment it is only accessible by the touch-screen. Any ideas on how to deal with that are welcome
Once you get going, my preference is that you create a bitbucket account and setup hg to pull from my branch and push to yours. I can then review and pull changes from your branch into mine.
My main development philosophy is:
* try to keep the code always buildable
* keep the capabilities abstracted from the hardware. Anything hardware specific should be in target/<model> and should have an abstracted API.
* keep the code as modular as possible
* Use a consistent coding style across the entire project
As I'm sure you are aware, RAM is at a premium in uC development. We have no 'malloc', and I work to keep static allocation to a minimum.
There are several things you could work on:
1) You said you were planning to use a Devo12. If that is the case, you might want to start working on the devo12 emulator. It will be nearly identical to the devo8 emulator, with (that I know of) the following changes:
* screen is 480x272
* more switches
* more flash
The big deal here will be the screen. We either need to develop a different GUI for the 12, or we need to figure out how to abstract the one we have for it. But also we may need to move stuff around so that we can share files between the devo8 and devo12
2) There are several things needed for the current firmware (all non-graphical items will be shared by all future supported transmitters):
* failsafe
* timers
* heli-settings (swash type)
* alarm
* Model icons
3) We are currently trying to figure out how to setup the gui to work with the Tx buttons. At the moment it is only accessible by the touch-screen. Any ideas on how to deal with that are welcome
Once you get going, my preference is that you create a bitbucket account and setup hg to pull from my branch and push to yours. I can then review and pull changes from your branch into mine.
My main development philosophy is:
* try to keep the code always buildable
* keep the capabilities abstracted from the hardware. Anything hardware specific should be in target/<model> and should have an abstracted API.
* keep the code as modular as possible
* Use a consistent coding style across the entire project
As I'm sure you are aware, RAM is at a premium in uC development. We have no 'malloc', and I work to keep static allocation to a minimum.
Please Log in or Create an account to join the conversation.
- kohansey
-
- Offline
Less
More
- Posts: 31
12 Jul 2012 14:59 #485
by kohansey
Replied by kohansey on topic Re: What to do?
I have already been able to pull the repo into my bitbucket account (kohansey) and checked out the sources. I have the devo 8 emulator up and running and also have it building in Eclipse. You are correct, I am planning on purchasing the Devo 12s so I can fly my BNF MiniCP. I am stilling trying to sell some of my helis to cover the cost, but in the meaning time, I think I can work with the emulator.
I have started to look over the code for the GUI and can already see some areas that need to be abstracted more. I have access to a commercial GUI library called emWin. It is specifically designed for low footprint embedded products. My job's license agreement prevents me from directly using the library, but it doesn't stop me from taking it as an example that we can use in our firmware.
Your coding guidelines are right on point with my own, so I don't see an issue there.
I have been working with small and embedded micros for the past 10 years, so I am familiar with the limitations of memory and processing power. I am not familiar with mercurial, so I am not sure how to setup a pull request. I am found TortioseHg which is a lot like the utility for SVN, which I am familiar with.
I have started to look over the code for the GUI and can already see some areas that need to be abstracted more. I have access to a commercial GUI library called emWin. It is specifically designed for low footprint embedded products. My job's license agreement prevents me from directly using the library, but it doesn't stop me from taking it as an example that we can use in our firmware.
Your coding guidelines are right on point with my own, so I don't see an issue there.
I have been working with small and embedded micros for the past 10 years, so I am familiar with the limitations of memory and processing power. I am not familiar with mercurial, so I am not sure how to setup a pull request. I am found TortioseHg which is a lot like the utility for SVN, which I am familiar with.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4402
12 Jul 2012 16:20 #487
by PhracturedBlue
Replied by PhracturedBlue on topic Re: What to do?
You can find instructions on working with setting up different pull and push paths here:
wiki.alliedmods.net/Mercurial_Tutorial
Mercurial commands aren't that different than SVN, but the big difference is how repositories are handled. When you 'pull' or 'clone' you are creating/updating your local repository. It is fully functional and needs no internet connection to be able to do commits to. when you 'push' you are updating a rmeote repostory so others can see your changes.
So a normal mode of work would be:
1) read in any upstream changes: hg pull
2) make code changes and test
3) check in changes: hg commit
4) repeat from (2) as needed
5) update bitbucket with your changes: hg push
Because of the distributed nature, merges are more interesting than in SVN of course.
I don't work with uC in my day job, and have no background in GUI development. Matcat was nice enough to build the current GUI framework, but we're certainly open to improvements. Just remember that the code is licensed under GPL3, so no code can be incorporated from commercial libraries.
The only other thing to remember is that we'll eventually support the Devo10 and even Devo7 transmitters. While maybe it is possible to scale the GUI down to the Devo10, my plan had always been to develop a much simpler GUI for that system (though I'm open to options). So my best-case was to be able to use the same gui frmaework for the Devo 6, 8, and 12 (all of which have color touch-screens). FDR has general Tx specs here:
rc.fdr.hu/devo.php
Anyhow, I'm certainly open to suggestions/alternatives
wiki.alliedmods.net/Mercurial_Tutorial
Mercurial commands aren't that different than SVN, but the big difference is how repositories are handled. When you 'pull' or 'clone' you are creating/updating your local repository. It is fully functional and needs no internet connection to be able to do commits to. when you 'push' you are updating a rmeote repostory so others can see your changes.
So a normal mode of work would be:
1) read in any upstream changes: hg pull
2) make code changes and test
3) check in changes: hg commit
4) repeat from (2) as needed
5) update bitbucket with your changes: hg push
Because of the distributed nature, merges are more interesting than in SVN of course.
I don't work with uC in my day job, and have no background in GUI development. Matcat was nice enough to build the current GUI framework, but we're certainly open to improvements. Just remember that the code is licensed under GPL3, so no code can be incorporated from commercial libraries.
The only other thing to remember is that we'll eventually support the Devo10 and even Devo7 transmitters. While maybe it is possible to scale the GUI down to the Devo10, my plan had always been to develop a much simpler GUI for that system (though I'm open to options). So my best-case was to be able to use the same gui frmaework for the Devo 6, 8, and 12 (all of which have color touch-screens). FDR has general Tx specs here:
rc.fdr.hu/devo.php
Anyhow, I'm certainly open to suggestions/alternatives
Please Log in or Create an account to join the conversation.
- kohansey
-
- Offline
Less
More
- Posts: 31
12 Jul 2012 17:30 #488
by kohansey
Replied by kohansey on topic Re: What to do?
Thank you for that helpful information. You are completely right, no commercial library can be used. I will try to keep the use of external libraries to a minimum.
For suggestions, I would like to offer having a GUI layer that knows nothing about widgets. This layer will interface with the LCD hardware driver. The GUI will handle the logic and algorithms for drawing a simple shape and pass the data off to the LCD driver to output to the display. The next layer up would be the widgets. These widgets are simple place holders that retain the screen information and use a functor that points to a target specific routine for the display. So for instance, we would have color touch panel target, and a monochrome dot matrix target. The target device will be responsible for selecting and initializing the appropriate target display layer on top of the GUI. For instance, if the target is the Devo8, then the Devo8 port will setup the color touch panel with a 320x240 resolution. If the target is the Devo10, then the Devo10 port will setup and monochrome layer and so on. The color touch panel layer should have an interface that gets feed the touch events from the touch hardware. If a touch position corresponds to a widget, the widget will interpret the touch and send a touch GUI event which can be captured by the device specific application. If the action is a button press, the application will know what screen it is on and know how to handle the press.
I think we should abstract the buttons and touches into another layer. In this layer, each button is assigned an action from a lookup table. This will allow us to create a mapping table that can be A. hardcoded to the specific target, or B. accessible from the FS so the end-user can modify a text file? to make their own mapping. for instance, button 1 will map to the ENTER action, button 2 will be EXIT, and so on. Most buttons are only used for navigation so it should be easy to come up with a set of actions that can be mapped to a button.
Hopefully I didn't lose you there. So for me, the first thing I would do is rework the GUI so it only draws simple shapes and then expand from there.
For suggestions, I would like to offer having a GUI layer that knows nothing about widgets. This layer will interface with the LCD hardware driver. The GUI will handle the logic and algorithms for drawing a simple shape and pass the data off to the LCD driver to output to the display. The next layer up would be the widgets. These widgets are simple place holders that retain the screen information and use a functor that points to a target specific routine for the display. So for instance, we would have color touch panel target, and a monochrome dot matrix target. The target device will be responsible for selecting and initializing the appropriate target display layer on top of the GUI. For instance, if the target is the Devo8, then the Devo8 port will setup the color touch panel with a 320x240 resolution. If the target is the Devo10, then the Devo10 port will setup and monochrome layer and so on. The color touch panel layer should have an interface that gets feed the touch events from the touch hardware. If a touch position corresponds to a widget, the widget will interpret the touch and send a touch GUI event which can be captured by the device specific application. If the action is a button press, the application will know what screen it is on and know how to handle the press.
I think we should abstract the buttons and touches into another layer. In this layer, each button is assigned an action from a lookup table. This will allow us to create a mapping table that can be A. hardcoded to the specific target, or B. accessible from the FS so the end-user can modify a text file? to make their own mapping. for instance, button 1 will map to the ENTER action, button 2 will be EXIT, and so on. Most buttons are only used for navigation so it should be easy to come up with a set of actions that can be mapped to a button.
Hopefully I didn't lose you there. So for me, the first thing I would do is rework the GUI so it only draws simple shapes and then expand from there.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4402
12 Jul 2012 17:54 #489
by PhracturedBlue
the code is currently designed as:
hardware<-screen<-gui<-page
* The hardware layer in target/devo8/lcd.c actually talks to the hardware. It provides a pixel-based API
* The screen layer draws primitives: boxes, circles, bitmaps, fonts. It provides an API to these that are generally not hardware dependent.
* The gui layer is responsible for widgets. Their display is configurable from a txt file or from the API (depending on the widget).
* The page layer is where all the layout happens. This defines which widgets are placed on which page (and where)
I'd like to see a proof of concept of your idea so I can better understand. If you want to create a simple page with only one or 2 widgets to give me an idea of how you'd separate the layers, that would likely be really helpful.
Replied by PhracturedBlue on topic Re: What to do?
I may be a little lost, how is this different then the 'screen' layer I have now?kohansey wrote: For suggestions, I would like to offer having a GUI layer that knows nothing about widgets. This layer will interface with the LCD hardware driver.
the code is currently designed as:
hardware<-screen<-gui<-page
* The hardware layer in target/devo8/lcd.c actually talks to the hardware. It provides a pixel-based API
* The screen layer draws primitives: boxes, circles, bitmaps, fonts. It provides an API to these that are generally not hardware dependent.
* The gui layer is responsible for widgets. Their display is configurable from a txt file or from the API (depending on the widget).
* The page layer is where all the layout happens. This defines which widgets are placed on which page (and where)
I've been moving in this direction, but I'm not sure it requires a separate layer. the BUTTON API should be easily configured by the user. I'm not sure it makes sense to do the same for the touch API.I think we should abstract the buttons and touches into another layer. In this layer, each button is assigned an action from a lookup table. This will allow us to create a mapping table that can be A. hardcoded to the specific target, or B. accessible from the FS so the end-user can modify a text file? to make their own mapping.
Hopefully I didn't lose you there. So for me, the first thing I would do is rework the GUI so it only draws simple shapes and then expand from there.
I'd like to see a proof of concept of your idea so I can better understand. If you want to create a simple page with only one or 2 widgets to give me an idea of how you'd separate the layers, that would likely be really helpful.
Please Log in or Create an account to join the conversation.
- kohansey
-
- Offline
Less
More
- Posts: 31
12 Jul 2012 17:59 #490
by kohansey
Replied by kohansey on topic Re: What to do?
Ah, I missed the screen layer, I assumed it was LCD -> GUI -> layout. I'll spend some more time reviewing the code, then try to come up with something to help demonstrate my concept.
Please Log in or Create an account to join the conversation.
Time to create page: 0.068 seconds
-
Home
-
Forum
-
General
-
General Discussions
- What to do?