OK
I believe I've found the answer, its the baud rate, FG can't handle
115200, I changed the baud rate to 9600 and now it appears that the values
I'm getting back for the altitude are correct. I'm going to run a more
extensive test on all of the other outputs I need and see what happens.
On Tue, Aug 16, 2011 at 8:50 PM, Derrick Washington <ddwas...@gmail.com>wrote:
>
> OK so this is my latest test.
>
> I took the word from the UART assuming that they were integers, I took
> the 32bit word converted it to a string and printed that string out to a
> terminal. Now in my generic protocol file I am only outputting one variable
> now and thats the altitude. The list of numbers that FG is passing back to
> me is shown below, looking at the altitude in the menu while FG is running I
> see the altitude at some where around 631.77231~ does anyone have a clue why
> I'm getting these numbers?
>
> FF3CFFFF
> FFFFFFC4
> FFFFFFC4
> FE4EFFC4
> FEC4FFC4
> FEFFFE4E
> FFC4FFC4
> FEFFFE27
> FFC4FEFF
> FFFF27BC
> FFFF4EBC
> FFBEFFC4
> FFC4FFBC
> FFFFBEFF
> C4FFBCFF
> C4FF67BC
> FF4DBCFF
> BCFFFFFF
> FFBCFFBC
> FFCDBCFF
> 67BCFFC4
> 78FF4DBC
> FFCDBCFF
> BCFFFF3C
> FFFDC43C
> FFFDFDFD
> 3CFF3CFF
> 3CFFC43C
> FF3CFFC4
> FDFDFD3C
> FF4D3CFF
> C4FD3CFF
> 3CFFC4FD
> FEFEFEFE
> FEC4FEFE
> 67FEFEFE
> 67FEFEFE
> FEC4F9FE
> FEFEC478
> FE4CFE27
> FEFEFCFE
> FE27FE27
> FEFCFCC4
> FCFCFCC4
> FFFC67FE
> C4FEFCFE
> On Tue, Aug 16, 2011 at 5:08 PM, Derrick Washington
> <ddwas...@gmail.com>wrote:
>
>> A little background would probably help here. The hardware I am using is
>> my hardware, I designed it from start to finish, so I'm pretty sure it
>> supports what I'm doing. Basically its like you said I just stored the
>> float variable at the address of the UART register, and yes when its gets
>> read its treated as a float, I looked at the disassemble list and no the
>> software does not try to convert the value in any way, because it was
>> declared as a float so it assumes float. And no there isn't any need to
>> wait after a read, the check I do before I read the UART checks to see if
>> the total number of bytes I am looking for is actually in the UART, so if it
>> returns positive, I know that the exact number of words/bytes (however I
>> configure the hardware) is waiting in the buffer.
>>
>>
>>
>> On Tue, Aug 16, 2011 at 3:27 PM, Anders Gidenstam <
>> anders-...@gidenstam.org> wrote:
>>
>>> On Tue, 16 Aug 2011, Derrick Washington wrote:
>>>
>>> > Anders
>>> >
>>> > I have included the following line in my generic xml file
>>> >
>>> > <output>
>>> > <binary_mode>true</binary_mode>
>>> > <byte_order>network</byte_order>
>>> >
>>> > My C++ code looks like this now.
>>> >
>>> > float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
>>> >
>>> > if ( (quik_silva_status_reg & 0x00001000) != 0 ) { //CHECK TO SEE IF
>>> > SIMULATOR DATA IS AVAIABLE
>>> >
>>> > gps_vdummy = rs232_uart1_fp;
>>> > gps_zdummy = rs232_uart1_fp;
>>> > gps_xdummy = rs232_uart1_fp;
>>> > gps_ydummy = rs232_uart1_fp;
>>> > etc ...
>>> >
>>> > My hardware is returning a 32bit floating point word, in hardware what
>>> is
>>> > happening is my UART is taking in the bytes one at a time of course and
>>> > shifting the into a 32bit register a byte at a time, and returning that
>>> > 32bit value. Soooo if FG is sending the data MSB(most significant byte
>>> > first), then I should be getting the correct value, right?
>>>
>>> So rs232_uart1_fp is a floating point variable located at the
>>> address of the UART output register/port or something similar?
>>> Are you sure it supports that (i.e. reading it as a float)? If not could
>>> you try reading the 32bit value into an int variable and reinterpret it
>>> as a float with something like
>>>
>>> unsigned int foo = rs232_uart1_u32;
>>> float bar = *(float *)&foo;
>>>
>>> Also, there is no need to wait before reading the next word from the
>>> UART?
>>>
>>>
>>> Cheers,
>>>
>>> Anders - who hasn't programmed an UART since the 68hc11 and late Amiga
>>> days.
>>> --
>>>
>>> ---------------------------------------------------------------------------
>>> Anders Gidenstam
>>> WWW: http://www.gidenstam.org/FlightGear/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>>> user administration capabilities and model configuration. Take
>>> the hassle out of deploying and managing Subversion and the
>>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>>> _______________________________________________
>>> Flightgear-devel mailing list
>>> Flightgear-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>>
>>
>>
>
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
