#![no_std] compatibility

[squidpickles]

Some thought will need to go into optimal buffer sizes given multi-part messages, and I would want to look at a better way of building up character data, but this seems doable given demand.

[elpiel]

Hello @squidpickles ,
In order to allow for no_std, I suppose you should:

• remove the thiserror dependency (or replace the impl for the no_std environment)
• disable default features for nom
• remove any allocations (you can check the heapless crate) the only issue I see currently, is that in nmea we have a hard limit on message size of 102 characters. So we should see how to handle this for AIS messages.

[squidpickles]

Hi @elpiel,

Yes, I have started some work on this.

The message size limits do help, but AIS messages can be multipart; people have observed up to 10 parts combined into a single message. I've been thinking about the best way to do this, mainly because there are tradeoffs between covering most use cases efficiently and still having room for the extremes. heapless is a possibility, but still has the problem of needing to allocate larger blocks of memory than needed for the 95% case.

Likely, I'll do an alloc version that retains the Vec, and then see about what to do for no_std.

[elpiel]

people have observed up to 10 parts combined into a single message

Yes, we do have some combinations for GNSS message types in nmea too. Maybe we can incorporate the AIS message combination there too?!

I don't really know what messages we should combine though and what information can be collected from multiple messages.

I'm also open to suggestions for features in nmea to allow e.g. usage of ais messages only or gnss messages only.