General development guidelines

More
22 Apr 2012 15:03 #6 by PhracturedBlue
General development guidelines was created by PhracturedBlue
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?

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

More
22 Apr 2012 17:13 #7 by FDR
Replied by FDR on topic Re: General development guidelines
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.

B) 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?

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

More
22 Apr 2012 18:08 #8 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines

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.

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

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

More
23 Apr 2012 21:44 - 23 Apr 2012 21:53 #9 by rcH4x0r
Replied by rcH4x0r on topic Re: General development guidelines
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
Last edit: 23 Apr 2012 21:53 by rcH4x0r.

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

More
24 Apr 2012 09:02 - 24 Apr 2012 11:35 #10 by FDR
Replied by FDR on topic Re: General development guidelines

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

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
Last edit: 24 Apr 2012 11:35 by FDR.

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

More
24 Apr 2012 13:34 - 24 Apr 2012 15:10 #11 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
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.
Last edit: 24 Apr 2012 15:10 by PhracturedBlue.

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

More
24 Apr 2012 14:24 - 24 Apr 2012 14:25 #15 by FDR
Replied by FDR on topic Re: General development guidelines
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.
Last edit: 24 Apr 2012 14:25 by FDR.

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

More
24 Apr 2012 18:48 - 24 Apr 2012 18:53 #17 by rcH4x0r
Replied by rcH4x0r on topic Re: General development guidelines

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


We should split this into two parts, the filesystem & a block/disk layer. This has several advantages:
-Other Filesystems can be easily supported (see below)
-Other flash/disk hardware can be easily supported
-We can hook the block layer upto USB mass storage. Updating models, bitmaps, string resources will be very easy using Windoze Explorer*

* It's a sad fact of life that 90%+ of our end users will be Windoze victims.

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


FAT12 or maybe FAT16 is all we need, the 4KB erase block size of our flash maps quite nicely onto a 4KB cluster in both. It is quite wasteful of flash space and any file (no matter how small) will occupy 4KB (slack space). So a 1 byte file = 4KB of flash & a 4097 byte file will occupy 8KB etc etc.

PhracturedBlue wrote: My searching seems to indicate a heavy bias towards FAT for embedded applications.


FAT is a _terrible_ filesystem for embedded devices. If the power is removed during a write the filesystem will be badly damaged. The only reason to use FAT is if we export the block layer over USB Mass Storage. If we aren't going to do this then we should look at an FS specifically designed for embedded systems (JFFS, YAFFS, UBIFS etc etc). These also have efficiency advantages ie no wasted slack space

Chan doesn't seem to specify a license (maybe we should shoot him a mail and confirm he is happy for it to be used in a GPLv3 code base). Alternatively UBoot is a great source of GPL v2 code and supports a number of FS aimed at embedded systems as well as FAT
Last edit: 24 Apr 2012 18:53 by rcH4x0r. Reason: Added note on efficiency

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

More
24 Apr 2012 20:28 #22 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
I believe Chan's stuff is effectively BSD licensed. He specifically says PetiteFAT is GPL compatible here:
elm-chan.org/fsw/ff/pf/appnote.html

We'll continue the rest of the discussion in the other thread.

I wanted to respond to something FDR mentioned. I have no interest in trying to build a firmware by hacking the Walkera feature with new features. While I don't care what others do, my interest is in developing an open-source general-purpose firmware, and my efforts will all be in that direction.

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

More
24 Apr 2012 20:32 #23 by rcH4x0r
Replied by rcH4x0r on topic Re: General development guidelines
I completely agree, hacking Walkera FW is a waste of time. Every new release you have to do the work again & you still only have a modded Walkera FW

FOSS replacement gets my vote!

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

More
25 Apr 2012 05:38 #30 by FDR
Replied by FDR on topic Re: General development guidelines

PhracturedBlue wrote: .....
I wanted to respond to something FDR mentioned. I have no interest in trying to build a firmware by hacking the Walkera feature with new features. While I don't care what others do, my interest is in developing an open-source general-purpose firmware, and my efforts will all be in that direction.


It's all right. I don't want it either, just mentioned that keeping the original model data intact with additional side configs make sense only for that purpose...

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

More
25 Apr 2012 15:02 #36 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
I just renamed the repo from 'whippet' to 'deviation' either pull a new copy from:
bitbucket.org/PhracturedBlue/deviation
or change .hg/hgrc appropriately

I uploaded a test-build dfu to the download area that will show a status-screen and demonstrates most of the hardware interfaces we've got so far.

I think we should change the 'devo' to 'deviation' in the URL and/or register an appropriate domain

Are we satisfied with the logo as is? I think it is probably fine.

Anything else we need to do on the administrative front?

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

More
25 Apr 2012 15:35 #37 by FDR
Replied by FDR on topic Re: General development guidelines
OK, I have created a new 'deviation' subdomain, but it needs some time to become alive. Then I will move this to there.

Later we can create an own domain, but it takes time and money...
BREAKING BAD NEWS: deviation.org, .net, .com is used or at least can not register!

Thanks for correcting your link to the bitbucket!
Should it be visible for guests, or just for the members (as it is now)?

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

More
25 Apr 2012 16:00 #38 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
I'll be happy to register it once we decide on a name if you like.

These seem to be available:
deviation.eu
deviation.me
de-viation.*
deviationtx.*

Both the download and the link to my repo should be public. When I look at the configuration, they seem to be, but feel free to fix whatever I messed up to make them so.

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

More
25 Apr 2012 17:06 #39 by FDR
Replied by FDR on topic Re: General development guidelines
OK, I've just moved to deviation.fdr.hu (as you probably noticed ;) )

The domain registration is no problem, just takes at least two weeks...
Do you have a DNS server?

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

More
25 Apr 2012 18:40 #43 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
Why would it take two weeks? I generally can get a domain active in less than 24hours. I've used my registrar's DNS servers without issue.

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

More
25 Apr 2012 18:45 #45 by FDR
Replied by FDR on topic Re: General development guidelines
Maybe elsewhere goes otherwise, but at least with our .hu domains it is announced, and there is a two weeks period while somebody can except against. If nobody did, the domain goes alive.
I've never registered other than a .hu domain...

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

More
25 Apr 2012 18:49 #46 by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
well, it has been a few years, but last time I registered a domain (edu/com/org) it was immediate. Someone can challenge it if it violates trademark, but that shouldn't be an issue for us. Just need to choose a name

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

More
25 Apr 2012 18:54 #47 by FDR
Replied by FDR on topic Re: General development guidelines
Cool! B)

devopen is free except for .com
What primary domain we want it to be in? .com .org .net?

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

More
25 Apr 2012 19:08 #48 by rcH4x0r
Replied by rcH4x0r on topic Re: General development guidelines
Hmmm, something funny going on with 'memcpy'. PB can you pull my code and try building/running the code (but enable the memcpy in the SignOn() fn)? It crashes on my setup

I think the module name should be 3-4 chars - UART_ and CYRF_

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

Time to create page: 0.056 seconds
Powered by Kunena Forum