- Posts: 4402
General development guidelines
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.
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?
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?
Please Log in or Create an account to join the conversation.
22 Apr 2012 18:08 #8
by PhracturedBlue
Replied by PhracturedBlue on topic Re: General development guidelines
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.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++?
I would say we should only support compiling with gcc, so it should be easy.A/2-3-4) Yeah, programmers need some disciplines.
However the warnings can be tricky with different compilers.
This is basically how the screen stuff I've implemented already works.
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.I have asked rcH4x0r if we want an universial fw for all the DEVOs, or compile one for each.
Please Log in or Create an account to join the conversation.
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
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
Please Log in or Create an account to join the conversation.
24 Apr 2012 09:02 - 24 Apr 2012 11:35 #10
by FDR
It'not too important for me personally, but it should be decided before doing the design and go public.
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...
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...)
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
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.
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
Please Log in or Create an account to join the conversation.
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?
)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.
25 Apr 2012 18:54 #47
by FDR
Replied by FDR on topic Re: General development guidelines
Cool!
devopen is free except for .com
What primary domain we want it to be in? .com .org .net?
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.
Time to create page: 0.090 seconds
-
Home
-
Forum
-
Development
-
Development
- General development guidelines