Advanced Search

Just a quick help:
This forum engine has live preview. There are two buttons on the far right toolbar to display it below the editbox or beside it.

PhracturedBlue wrote: I can see a few options here:

1) We could just stick with the DEVO8 format. This doesn't seem ideal as I heard that the DEVO6 and 12 use different formats

2) We could use an API in the firmware that can read multiple formats, thus allowingthe upload of model data for any supported radio

3) We could write translators on the host side to convert to our own format before upload, and use only that on the Tx. the problem with this is that it may be difficult to support radio-radio model transfer which I think is supported by walkera?

1. Yep, all DEVOs use different model data "format", if we can call it a format anyway.
It is a simple binary storage, optimized for size. For example the throttle curve output value's range is from 0.0% to 100.0% in 0.5% steps, so they use one byte for it witch range is from -100 to +100. Nice, isn't it?

2. Yes, I think this would be the best solution. It could be used for the wireless transfer (from tx to tx) too...
The only problem, we don't know all the formats.
It can be reverse engineered from the fw itself, or in the change-and-compare way I do now, but both are very time consuming. Yeah, and the second approach needs all kind of tx...

3. Walkera's wireless model data transfer is half legged too: it only works between two identical tx type. I guess they simply send out the binary model data and save it on the other side after some checks... It is the lazy way: they do not care about their other own formats.


The possible fourth option would be the side-config, which meant we use the original DEVO format for the functions it supports, and a separate config "file" for each model data to store the added features.
I don't really like this, it is only explainable if we only would like to hack in some features into the original fw.

This is what we seem to have so far:
1) Ability to write to the LCD screen. We have routines for writing text (ascii only), and a simple graphical framework (from the adafruit project) that supports lines, rectangles, circles, triangles, etc

2) Ability to control the back-light brightness

3) Ability to read all buttons and sticks. The switches are not yet supported but I'll get to that shortly

4) Ability to read/write/erase the SPI Flash

5) Ability to talk to the radio

6) Ability to read from the touchscreen

7) Ability to write to the USART

8 ) Ability to measure battery voltage

9) The TX can act like a USB thumb-drive

10) Support for an internal filesystem such that files written by the PC can be read by the firmware

11) The ability to draw BMP files (both opaque and transparent)

12) An initial GUI framework

13) Ability to generate sound through the speaker

We do not yet have code to support:
* Channels other than the sticks
* More?
We only support the DEVO8 at the moment. Additionally, the code can be compiled on a PC with FLTK to make it easier to do GUI development.

FDR wrote: About the model data:
I made some progress in discovering the model data. I know the meaning of 582 bytes of the total 912. This is all that needed for a heli config. (If I haven't missed something... )
I still have a feeling, that this format will be a limiting factor after some time. It's definitely not nice or universial, but it is at least small...
One possible way to keep some compatibility would be to use a side-config in the rest of the 4KB model data, but that would be ugly too.
Spectrum's model config is in plain text (at least the downloaded part), but it is about 11KB!

Another option would be full custom format, and make an own updater, which can convert them, but if we want to keep the wireless model data transfer feature, then the tx itself should be able to convert too.
I think it deserves a separate topic...

I can see a few options here:

1) We could just stick with the DEVO8 format. This doesn't seem ideal as I heard that the DEVO6 and 12 use different formats

2) We could use an API in the firmware that can read multiple formats, thus allowingthe upload of model data for any supported radio

3) We could write translators on the host side to convert to our own format before upload, and use only that on the Tx. the problem with this is that it may be difficult to support radio-radio model transfer which I think is supported by walkera?

Ok, so to summarize where we seem to stand.

It seems we've all agreed on this:

* The code guidelines I've got in the 'DEVELOPERS' file is fine. C++ will be discouraged and minimized but is not verboten.

* The code will remain GPLv3

* We'll do all development on gcc

* We'll use an HAL (hardware abstraction layer) API for bare-metal, and additionally a separate API for GUI work

* We'll keep FDR's portal as the primary site. I forgot about the stupid moderation on 9xforums. Yeah, that is a no-go.

* We'll name the project 'Deviation' (I like it too). We'll keep it on bitbucket and in mercurial since noone seems to mind.

We need further discussion about the following:
* We need a logo. We can keep FDR's but I'm not sure if it is too close to the Devention logo (copyrighted font?).

* Should we treat the Flash as a file-system? I really like this idea. It also provides a clean abstraction layer should we ever target a system that uses SDCards or whatever.

* What should we do about an RTOS? I'd propose we start without one. I don't see that it will provide much benefit as things are today. We can always change our mind as the GUI work progresses.


On the forums side, I'd say we need at least 2 forums:
1) A user forum for general questions and chat
2) A developers forum for discussion of coding
We could add a 3rd 'Hardware' forum for stuff like reversing, It would make it easier to search

I'd also like to have a 'Preview' button on my posts. It helps me see if I've got the formatting right. Is that possible?

I'd prefer if FDR keeps his maintenance role. I have no experience running a forum, and don't really want to learn.

Edit: Some references for filesystem ideas:
Here's a bunch for the STM32:
sites.google.com/site/stm32discovery/stm...-for-stm32-cortex-m3
Whefs/whio_epfs virtual filesystem:
code.google.com/p/whefs/
fossil.wanderinghorse.net/wikis/whio/?page=whio_epfs
Tiny u-fat for arduino (limit of only 16 files probably makes this a no-go):
arduinonut.blogspot.com/2008/04/ufat.html
From what I've seen so far, 'Petite FATfs' (from the 1st link) looks like a contender. It is tiny, uses very little RAM, and seems to have sufficient features for our needs. if not Chan's FatFS (the big-brother of petite FATFs) would definitely meet our needs.
My searching seems to indicate a heavy bias towards FAT for embedded applications.

rcH4x0r wrote: .....
C3: Generally I like 'word games' so Deviation is appealing but I'm fine with Whippet too. We definitely need a logo....

It'not too important for me personally, but it should be decided before doing the design and go public.

rcH4x0r wrote: C4: I'm happy with FDR's setup. I had a fairly poor experience of the moderation on the 9xforums, I admit I got over excited and double posted but deleting both my posts and telling me to wait for the first to be approved before posting again was dumb. I wont be using that forum again

Same here!
I didn't know it is moderated, so I have posted the same thing three times.

The problem is, that moderated approach is awfully slow...

rcH4x0r wrote: .....
>>We should also define a clean API for different radio protocols so that we can easily add new ones as well.

Absolutely. PHY drivers and protocol engines should be "drop in" modules with generic interfaces top & bottom. One day it should be possible to swap old Walkera/new Walkera/DSM2 protocol modules with just a recompile (or even dynamically ie through a menu selection while the code is running). This will also help if other devs want to create modules.

IMO the whole reason of the custom fw is supporting different protocols.
They should be switchable at runtime, and stored for each model in the model data. (One more reason for own model data format, see later...)

rcH4x0r wrote: Do we want a reversing forum? Somewhere to share what we learn about the original Walkera code. I'm keen to share as much as possible, no secret inner circles, no BS

I didn't want to make too much effort to refining the portal until it is certain that we will use it.
If it stays, than I will ask for some information what do you need here.
You both are administrators, so you can add or modify almost everything if you want, but I'm here to help, just let me know what to do...


About the model data:
I made some progress in discovering the model data. I know the meaning of 582 bytes of the total 912. This is all that needed for a heli config. (If I haven't missed something... )
I still have a feeling, that this format will be a limiting factor after some time. It's definitely not nice or universial, but it is at least small...
One possible way to keep some compatibility would be to use a side-config in the rest of the 4KB model data, but that would be ugly too.
Spectrum's model config is in plain text (at least the downloaded part), but it is about 11KB!

Another option would be full custom format, and make an own updater, which can convert them, but if we want to keep the wireless model data transfer feature, then the tx itself should be able to convert too.
I think it deserves a separate topic...


FDR

A 1-4 : I'm fine with this. I can see C++ is useful for GUI development but I don't plan to do a lot of that (FWIW my background is in GSM/GPRS/UMTS protocol stack development)

A clean code base is very important to me, I would be happy to see static code analysis tools being used too (Lint etc)

B 1-2 : The more abstract the interfaces the better. This will make porting to new platforms much easier

C1: I am in two minds about an RTOS. Being able to run the GUI and the protocol stacks as separate tasks is atractive but is it really necessary? FDR is correct the radio stack can be driven from a timer (TIM4 in the Walkera Devo8 code). I don't have an answer

C2: If we treat the SPI flash as a block device we could expose it as mass storage via USB. A host PC would then be able to use a file system and provide "drag n drop" functionality thru explorer. We would also need a file system in the firmware, preferably with a POSIX style API, I think there are plenty of them out there (UBoot might be a good place to get one)

C3: Generally I like 'word games' so Deviation is appealing but I'm fine with Whippet too. We definitely need a logo....

C4: I'm happy with FDR's setup. I had a fairly poor experience of the moderation on the 9xforums, I admit I got over excited and double posted but deleting both my posts and telling me to wait for the first to be approved before posting again was dumb. I wont be using that forum again

We should definitely be using GCC for all our code, we are an open source project and therefore we should use open source tools. GCC supports all the CPUs we are likely to want to work with

>>We should also define a clean API for different radio protocols so that we can easily add new ones as well.

Absolutely. PHY drivers and protocol engines should be "drop in" modules with generic interfaces top & bottom. One day it should be possible to swap old Walkera/new Walkera/DSM2 protocol modules with just a recompile (or even dynamically ie through a menu selection while the code is running). This will also help if other devs want to create modules.

Do we want a reversing forum? Somewhere to share what we learn about the original Walkera code. I'm keen to share as much as possible, no secret inner circles, no BS

FDR wrote: A/1) Do you mean rather C than C++, or it's about other possible languages? In what language the ST libraries are written C or C++?

Yes C is preferable to me over C++. We're using libopencm3 as it is GPL compatible (as opposed to the ST libs). Both are in 'C' though.

A/2-3-4) Yeah, programmers need some disciplines.
However the warnings can be tricky with different compilers.

I would say we should only support compiling with gcc, so it should be easy.

I would devide it even further: one hw layer, a device independent middle layer, and a high level one. For example in case of transmitting: the hw layer knows the actual init and handling of the CYRF6936, the middle layer knows the protocol, and the high level simple says: transmit xyz...

This is basically how the screen stuff I've implemented already works.

I have asked rcH4x0r if we want an universial fw for all the DEVOs, or compile one for each.

Well a universal binary doesn't make any sense, but I don't see why we can't support the entire range of models with the same code base. I already have an emulator target that runs on the PC to help develop the GUI.

Cool, thanks!

A/1) Do you mean rather C than C++, or it's about other possible languages? In what language the ST libraries are written C or C++?
A/2-3-4) Yeah, programmers need some disciplines.
However the warnings can be tricky with different compilers.

I would devide it even further: one hw layer, a device independent middle layer, and a high level one. For example in case of transmitting: the hw layer knows the actual init and handling of the CYRF6936, the middle layer knows the protocol, and the high level simple says: transmit xyz...
And yes, the devil 7 is quite different.
I have asked rcH4x0r if we want an universial fw for all the DEVOs, or compile one for each. I think if you want to use this code for transmitters other then the DEVOs, than only the second option is possible. In that case we should have a separate header for each DEVO defining the hw staff and possibly to include the different hw libraries. If we want to support the DEVO 7, I think we should totally separate the UI from the rest, and have a special one for it.

C/1) It leads to the question of RTOS. I have no real experience with it, but I think this protocols use fixed timespan messages, so a relatively high priority timer based interrupt can handle it independently of the UI, just needs some care about the consistency of the data sent.
C/2) As you wish... That would be the benefit of some object oriented style, that it coud treat them closed.
C/3) Important urgent question! At least for me, if we decide to keep this portal...
But I don't want to force it...
C/4) As you probably know I for the separate portal and forum (at the moment the forum is the more important I think). Do you know them? Can we benefit from their 9x projects?

Here is my proposal for code development. It roughly describes the current code database, and is defined in the DEVELOPERS file:

1) Code should be in 'C' whenever possible
2) Exported function names should be named as <module>_<function> (i.e. SPIFlash_Init() )
3) Indentation should be 4 spaces
4) Code should compile without warnings even with -Wall

I'm trying to define a clean API to talk to the hardware, such that other transmitters can be more easily supported. We may find this too cumbersome, or unfeasible as we move forward, but I've currently split it into 2 APIs:
1) Hardware interface. These are the bare-bones functions for accessing Flash, Radio, LCD, buttons, touch-screen, sticks, ...
2) Screen interface. These provide screen drawing functions for a given resolution. Possibly the entire GUI would end up here, though I'm not really sure. My goal would be to have support here for different resolutions and b/w vs color. I have no idea how we'd handle supporting the Devo-7 screen though, unless the entire GUI lives in this area

We should also define a clean API for different radio protocols so that we can easily add new ones as well.

Please don't take this as set in stone, it is just my opinion of how to get started.

Other things that we need to talk about:
1) Should we use an RTOS? Does it buy us anything
2) Should we treat the SPIFlash as a filestystem? It may be a lot more convenient to be able to use routines like 'open()' and 'read()' to get bitmaps and model info.
3) Are we happy with 'Whippet' as the project name, and using mercurial as a DVCS?
4) How do we want to manage the project? Should we keep forums here or ask the 9xforums folks for a section? Wiki?

You are welcome!

It is not ready, because it has a lot of features and settings I know little about...
For example I bearly see what I am typing now, because the font size of this editor is too small!

Thank you FDR for putting this together, now we need to fill it with "the good stuff"

Here we can discuss about the portal's and forum's content, design and other requirements...

So far I have to learn a lot about configuring them.
Please feel free to comment!