Code: Select all
struct {
uint16_t a,b,c,d,e,f;
uint32_t g;
uint16_t h;
uint8_t i,j,k,l;
} misc;
Alexinparis wrote:Ok, I will try to complete your doc and put it on the wiki.
timecop wrote:Having descriptive variable names will increase code size.
Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?
Crashpilot1000 wrote:No, copterrichie that is covered by MSP_IDENT alone. Transmitting serial numbers is a different story it is more in the direction of personalization and the beginning of what DJI does in (much, much) greater extend (and working..). And I remember that Kraut bitching something like that .. too bad that tc didn't write down the serial numbers of his sold cpus.. .
Crashpilot1000 wrote:@TC: I see, you are not responsible for stuff in your repo. And you have absolutely no clue what spirit is behind that. And of course you didn't say on IRC that you are planning to crash other hardware than yours.
fryefryefrye wrote:timecop wrote:Having descriptive variable names will increase code size.
Only source code size. Not onboard code size.
Self-descriptive code is very usefully then comments.
Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?
timecop wrote:Having descriptive variable names will increase code size.
brm wrote:Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?
ups - got a head Crash recently?
imagine you have a mesh Network.
how to address the correct node?
the unique id is extremely helpfull in doing so.
i have a few boards behind me to create a mesh Network.
the unique id is very helpfull to create the correct short address for communicating.
I think crashpilot1000 do his name exact like the number in his nick. // Chip Unique ID on F103
#define U_ID_0 (*(uint32_t*)0x1FFFF7E8)
#define U_ID_1 (*(uint32_t*)0x1FFFF7EC)
#define U_ID_2 (*(uint32_t*)0x1FFFF7F0)
Crashpilot1000 wrote:Oh, yes shure.
Thats why it reads here http://code.google.com/p/afrodevices/so ... board.h#37:// Chip Unique ID on F103
#define U_ID_0 (*(uint32_t*)0x1FFFF7E8)
#define U_ID_1 (*(uint32_t*)0x1FFFF7EC)
#define U_ID_2 (*(uint32_t*)0x1FFFF7F0)
Even the comment shows Its intend: Identify the CPU and not for some softwareversion. MSP_IDENT would have been sufficient for versioning.
I already removed that stuff for the next version, once I understood the real intend. Anyway I keep my source public at known places, others burn everything (docu&code) and wait for someone to ask for it.
ezio wrote:Hi
Could we have a file with protocol decryption which will be updated when there are the changes in MSP protocol ? (something like this https://www.dropbox.com/s/m1ssij26q61cp94/protocol.ods )
Or could we have a descryption in the Protocol.cpp ?
it is frustrating to find what the values means if they labeled like this:Code: Select all
struct {
uint16_t a,b,c,d,e,f;
uint32_t g;
uint16_t h;
uint8_t i,j,k,l;
} misc;
come on, can't you use normal names ?
Bart
ezio wrote:That is perfect!
Thank you very much Alex!
Could we, from this point, put the changes in the protocol in this thread with some decryption ?
timecop wrote:Things that come to mind:
conf.mag_declination (what is its value in processing? why is it /10 there? what?)
various vbat*scale/min/max related shit. they seem to be getting * 10 / 10 stuff in various places. why.
