Stuck on reworking GPS demo w/ buffer reads

[danjwait]

Trying to recreate the GpsTutorial on F' v3 w/ Fpp ; by way of a mix of together the cross-compile (for getting on the RPi) and math demos (for the Fpp approach) with the old GpsApp in xml.

Presently stuck where it looks like the Gps component function to parse the serial data coming across the UART (serialRecv_handler ) isn't receiving enough data to work with. I have repurposed the Gps component Tlm ports to route out debug info; it looks like serialRecv_handler is only ever seeing one buffer filled from the gpsSerial.serialRecv port (the Drv.LinuxSerialDriver instance connected to the UART), so it skips out at the else if (buffsize < 24 ) ... return

I would think that was the same issue addressed in this discussion, but I thought the preamble function fulfilled the purpose of giving the UART multiple buffers to write to in order to create a complete message. So I think somehow my code isn't letting the UART fill those buffers or the serialRecv_handler is reading the buffers on every write rather than waiting for multiple buffers to fill.

I'd appreciate any suggestions on where to look next.

FWIW I'm running the GpsApp on the target RPi 4 (Raspbian 11) w/ the Adafruit Ultimate GPS FeatherWing attached via Pi Wedge; I can see the GPS strings w/ cat /dev/serial0 on the RPi, so I know that works. With other debug Fw::Logger messages to console I can see that the driver opened the port and that the preamble assigns the buffers.

P.S. In retrospect I should have gone math demo, cross-compile, then RPi demo, then merged in Gps. So the code is a bit of a mashed up mess as I've pulled in RPi demo code to try debugging. I could back up and start again from scratch, but think that I just one one setting wrong somewhere.

[LeStarch]

I think the GPS tutorial has made a bad assumption that it would receive a complete GPS frame per serial transaction. However, on newer PIs like the PI 4 the processing may out-pace the ability of the serial port to deliver.

You'd should have some local storage in the Gps component that aggregates data. Then process the aggregated data once its size has passed 24.

[danjwait]

Thanks; after debugging this a bit it's working now. There was a maybe-confounding issue with the "miniUART" (software UART) on the RPi 4 that has been worked around w/ a device tree overlay.

Now that it's working; is there utility in cleaning up the work and doing a pull request (or complete update?) to the GPS tutorial? If so, do you have a suggested approach or template for tutorials and/or contributed components?

[danjwait]

@LeStarch I think I've wrapped this up for now; it's posted here if that's at all of use https://github.com/danjwait/fprime/tree/GpsApp/GpsApp

[capsulecorplab]

@danjwait FYI, I just attempted to generate the build cache, using fprime-util generate, for your fork of the GpsApp from danjwait@c5a8529, but encountered an fpp-tools version incompatible issue (virtually identical to #1478)

Also, if of interest to anyone, I'm running the aforementioned setup in an immutable virtual kasm development environment specifically for fprime development, which you can build and run locally from https://github.com/capsulecorplab/kasm-fprime-workspace/tree/install-cross-compile-toolchain-for-teensy

[danjwait]

@capsulecorplab I have also struggled with getting the versions to line up. There's another discussion thread along those lines #1235 . I follow the logic with the versions not being compatible, and it looks like that's getting worked on (per pull #1491 ). If it helps at all, here's what I used to get this to work:

fprime$ more versions.json 
{
    "FPRIME_TOOLS_VERSION": "v3.0.1",
    "FPRIME_GDS_VERSION": "v3.0.2",
    "FPP_TOOLS_VERSION": "v1.0.1-84-g7271178b"
}

[capsulecorplab]

@danjwait I'm not familiar with the versions.json file. Is this a file that would reside in the GpsApp/ directory?

[LeStarch]

Yeah, we added it to track versions of packages (tip of devel). However, we will likely remove that in favor of a requirements.txt as that will be:

1. automatically generated
2. lock down a complete "working set" of dependencies as opposed to just our packages.

[capsulecorplab]

Just updated my environment to use the locked python packages as per #1491 and reran the build using https://github.com/danjwait/fprime/tree/GpsApp/GpsApp. Have yet to test it with hardware, but GpsApp seems to at least be building without issues!

[danjwait]

Sorry, first I'd typoed that pull request, it should be #1491 which is w/ the requirements.txt per M Starch. Second I was runover by work and just got back here; and also as per M Starch the versions.json is in my /fprime directory:

:~/02_Projects/fprime$ ls *json
versions.json

Hope that helps a bit