On Fri, Feb 18, 2022 at 7:59 PM Gary E. Miller <
gem@rellim.com> wrote:
>
> Yo All!
>
> I looked at tests/test_nmea2000 again.
>
> The good news: adding the -t flag to canplay runs the regression test in
> 4 seconds instead of almost 4 minutes.
>
> The bad news: results from test_nmea2000 are not repeatable...
>
> Worse news: When I run the two badly named examples from #176 using
> test_nmea2000, there is no output at all from either one. Naming
> canbus data capture files as nmea*.log was very confusing.
>
> The NMEA 2000 code in gposd has been broken a long time. Unlikely this
> gets fixed before the next release.
I think there should be some changes to gpsd to somewhat better
help NMEA200, CAN bus, CAN over ethernet, etc.
1. Some {,re}{c,m}allocs, I would suggest that allocating memory to
device structures at run time rather than build time would allow
greater flexibility. Initially, I would suggest a single
scalable allocation at startup.
2. CAN-centric protocols are packet-oriented and have at least
the possibility of packet fragmentation. In this case, you could
either add to a backing store or throw things away, and I know
not what is discarded.
3. The current NMEA2000://{,v}can* CAN address only maps to a
single device on the bus, which is only a good thing if there
are only two devices on the bus. I would suggest dropping the
first device to having a sub device number, and either having
the common act as either a promiscuous or NetLink type listener
(preference for the latter), possibly both.
4. Alow for smaller fragmentary reports for the things
supported.
5. Using machine-generated parsers tagged as experimental.
6. Get access to Hardware (or at least captures) and/or people
who can help.