Thanks for the reply Curt,
I took your comment onboard, Not much time today so I still have not
modified the process routine, but have instigated printf for testing. I wish
I knew it was so easy to so that earlier.My background in single chip
devices where there is no screen!.
Thus at the moment, the process routine calls the parse routine as in
yesterday, There I am picking up the number of chars in "buf" from
"length". In the parse routine then I am testing each char and at the same
time sending the char to a printf.
If I test each char, from "buf" I can find 0x5a "Z" but not 0xA5. Futher the
terminal shows only the printable characters from "buf". However it is a
steady cycle of the same pintable char data 10 times a sec with the non
printables missing.
>From these 2 observations I suspect the non printables are not in the "buf"
array.
If I understand your response correctly, every time parse is called, "buf"
will hold fresh serial data and the number of bytes is in "length", this may
not be the complete burst of data I send every tenth of a second to the
serial from my Pic. But if i gather these bytes and write them to an array
or file I will end up with a replica of the stream in. From that i could
find the sync bytes and recover the complete block of data.
However I realise once I have it working i need to refine the code a bit,
but if thats the case I seem to be missing the non printables.
You mention modifying the call to parse to call it only when its got the
full block of data. I would prefer very much not to be putting patches in
the other code outside of my sim file (cloned from the Altas one in
src/network), the only patch i have done is in fgio.c and that was to clone
the call for the atlas routine.
So questions
Firstly have i come to the correct conclusion above, and is it possible non
printables are not present in the "buf" data?
Could you tell me where in FG it calls the process routine for the various
io protocols? I seached today with out sucess, possibly from simgear?
Also the parse routine only seesm to run when i define serial "in" in the
comand line, where as I want the port bidirectional and would use "bi" in
the command line. eg, fgfs --sim=serial,in,10,/dev/ttyS0,38400 --httpd=5008
As i want to read in 8 bit hex data should i be looking at another method?
I apologize for dumb questions but I fully realize FG is quite a complex
piece of evolving code and I only want to hook in a small addon.
regards Harry
Below is modified to pick up char Z (ox5A) from buf and test as mentioned
above using lenth to read from buf.
It outs the 0x5A to screen and sets the gear property but cant finsd a 0xA5.
SGPropertyNode * node;
l =0;
while(l != length)
{
ch = buf[l];
printf("%c",ch);
switch (Msg_State)
{
case 0: // find the sync header byte 0
if(ch == 0x5A)
{
Msg_State++;
Msg_CS_OK = 0;
b5=false;
node = fgGetNode("/controls", true);
node->setBoolValue("gear/gear-down", b5);
}
On Tue, Mar 24, 2009 at 12:12 AM, Curtis Olson <[email protected]> wrote:
> Hi Harry,
>
> I've only skimmed your example code, but off the top of my head here are a
> couple things.
>
> The FlightGear serial IO defaults to non-blocking. That means characters
> will only be read if they are available, and you can't depend on the entire
> message string being there when you try to read it. If you back up to the
> routine that actually reads the data in, you may need to do some work there
> to accumulate the entire message before handing it off to your parsing
> routine.
>
> One thing I do quite often in these situations is to add printf()'s to the
> code that reads the data in. Seeing the actual data values or message
> lengths that are read each time can be quite instructive.
>
> Best regards,
>
> Curt.
>
>
> On Mon, Mar 23, 2009 at 3:44 AM, Harry Campigli wrote:
>
>> Could I ask for some help and advise on this issue.
>>
>> I am trying to interface my Microchip Pic based sim hardware to FG. I have
>> it working with a genetic string but the string is becoming to large for the
>> pics to handle, also I would like a crc or check sum on the data. Thus i
>> prefer a compressed hex format. Ie the pic sends 4 bytes sync,16 bytes each
>> bit being a switch boolean, 16 bytes each being an analog setting then 2
>> bytes with each bit being a sign on the 16 analogs.
>>
>> The format thus is A5 5A A5 5A hh hh hh hh hh hh .......for 40 bytes.
>>
>> For simplicity I opted to clone and adapt the Atlas driver, keeping in
>> line with all existing FG conventions. and use it as a frame. and intigrate
>> my driver into FG when i build.
>>
>> So far I have bumbled my way along, I not a good programmer but have
>> learnt my way around C with the microchip C18 to drive all the hardware. I
>> have managed to generate and output a binary compressed message from FG. But
>> cant seem to get it to decode on the inwards stream.
>>
>>
>> My approach is similar to the way i run the can bus between the hardware
>> Pics, pick up the char one at a time, check for the first A5, then 3 sync
>> chars from "buf" then if ok (synced up), copy the next 40 chars to "msgin".
>> If thats ok then it sets a flag to decode the data. for now i also have an
>> 0x0D on the end making it 41 chars. Later i intend to add the CRC routine.
>> Also I intend to use a network socket to the Pics once its all working. I
>> try to work in small steps.
>>
>> It seems I cant pick up the first A5, as I understand it, "buf" has the
>> data in.
>>
>> My question is how does the low level IO in Sg and FG work, am I wrong to
>> work on the premise that every time parse message is called buf contains
>> fresh data from the serial, Or does the the low level code require a CR? DO
>> i need to set up a static ring buffer os sorts and take the incoming from
>> that?
>>
>>
>> Below Is the code as it stands. i would expect to come out of this with
>> Msg_CS_OK=1, but maybe its not quite correct, for starters I need to pick up
>> the first sync char.
>>
>>
>> I hope i have provided enough info to enable an answer,
>> Regards Harry
>>
>> FYI the OS is suse11.1 but i am not having any problems from that point of
>> view.
>>
>>
>>
>>
>>
>> bool FGSim::parse_message() {
>> SG_LOG( SG_IO, SG_INFO, "parse atlas message" );
>> char msgin[256],dblin[6];
>> char
>> a,b,c,d,e,f,g,h,b0,b1,b2,b3,b4,b5,b6,b7,w,starter,Char_Count,ch,l;
>> static char Msg_State,Msg_pointer,Message_CS_H,Message_CS_L,Msg_CS_OK;
>> double min, max;
>> int intin;
>> char pbsw;
>>
>> // string msg = buf;
>> // msg = msg.substr( 0, length );
>> // SG_LOG( SG_IO, SG_INFO, "entire message = " << msg );
>>
>> SGPropertyNode * node;
>>
>>
>>
>>
>> Char_Count = 41; // length
>> l =0;
>> while(l != Char_Count)
>> {
>>
>> ch = buf[l];
>> switch (Msg_State)
>> {
>> case 0: // find the sync header byte 0
>> if(ch == 0xA5)
>> {
>> Msg_State++;
>> Msg_CS_OK = 0;
>> b5=false; // test
>> to see if value recieved.
>> node = fgGetNode("/controls", true);
>> node->setBoolValue("gear/gear-down", b5);
>> }
>>
>> break;
>>
>> case 1: // find the sync header byte 1
>> if(ch == 0x5A) {Msg_State++;}
>> else Msg_State= 0;
>>
>> break;
>>
>> case 2: // find the sync header byte2
>> if(ch == 0xA5) {Msg_State++;}
>> else Msg_State= 0;
>> break;
>> case 3: // find the sync header byte 3
>> if(ch == 0x5A) {Msg_State++;Msg_pointer=0;} // reset
>> counter point for msgin
>> else Msg_State= 0;
>> break;
>>
>> case 4:
>> msgin[Msg_pointer] =ch;
>> Msg_pointer++; // write ch to msgin till all done
>> if(Msg_pointer==40){Msg_State++;Msg_CS_OK=1;}
>> break;
>>
>> case 5: // get fist cs byte
>> Message_CS_H = ch;
>> Msg_State++;
>> break;
>>
>> case 6:
>> Message_CS_L =ch;
>> Msg_State = 0;
>> break;
>> default:
>> Msg_State=0;
>> break;
>>
>> } // switch
>>
>>
>> l++;
>> } // while
>>
>> .....
>>
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Flightgear-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>>
>
>
> --
> Curtis Olson:
> http://baron.flightgear.org/~curt/<http://baron.flightgear.org/%7Ecurt/>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
--
Regards Harry
19b Jln Danau Poso
Sanur, Bali
80228
H +62 361 285629
M +62 812 7016328
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
