GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
justacec[m] has joined #rust-embedded
<justacec[m]>
I have a situation where I am thinking of keeping an internal log of data taken at some rate. Maybe something like 0.1Hz. If I wanted to store up to 7 days of data for 4 variables, it seems that would take up a fair amount of space. I am using a Pi Pico 2W which has 4MB of flash and 512 KB of RAM. At full precision, that seems like it would take 4 * 236KB (my estimate of each variable's space requirements) = 944KB of storage
<justacec[m]>
space. Are there any good recommendations on how to approach this issue?
<justacec[m]>
My current unstripped firmware is compiling to ~4.7MB (but it is still fitting on the Pico somehow?)
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
QSPI flash chip
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
Unstripped means it has various non-executable and non-data sections. You can use 'cargo size' to look at the section details.
_whitelogger has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
PicklePoacher[m] has quit [Quit: Idle timeout reached: 172800s]
<okhsunrog[m]>
you can create a python or bash script to calculate this if you need to do it often
<thejpster[m]>
<justacec[m]> I have a situation where I am thinking of keeping an internal log of data taken at some rate. Maybe something like 0.1Hz. If I wanted to store up to 7 days of data for 4 variables, it seems that would take up a fair amount of space. I am using a Pi Pico 2W which has 4MB of flash and 512 KB of RAM...
<thejpster[m]>
If you are very very cost constrained you can write data to the flash chip you already have. But it’s complicated because you can’t run code from it whilst you write to it, so you have to copy little routines to RAM and use them to program the chip.
<thejpster[m]>
If you can afford it, add a second flash chip - either SPI or I2C.
<thejpster[m]>
If you run size without -A I think it adds up the sections correctly for you.
<okhsunrog[m]>
<thejpster[m]> If you run size without -A I think it adds up the sections correctly for you.
<okhsunrog[m]>
yes, it does, didn't know about that :)
<okhsunrog[m]>
good to know
<okhsunrog[m]>
<thejpster[m]> If you are very very cost constrained you can write data to the flash chip you already have. But it’s complicated because you can’t run code from it whilst you write to it, so you have to copy little routines to RAM and use them to program the chip....
<okhsunrog[m]>
I think he can use Dion's crate `sequential-storage`
EthanGardner[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
<okhsunrog[m]>
Could you please give your thoughts on this matter, how would ergot handle it?
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
Just sat down for lunch, but the short answer is:
<JamesMunns[m]>
Ergot has a socket oriented model that is less bound to a single interface, it has a specific place for "how we speak to the outside world" (formerly InterfaceManager, just renamed to Profiles today), and I plan to explicitly support profiles for "bridging" multiple interfaces together
<dngrs[m]>
<thejpster[m]> If you are very very cost constrained you can write data to the flash chip you already have. But it’s complicated because you can’t run code from it whilst you write to it, so you have to copy little routines to RAM and use them to program the chip....
<dngrs[m]>
or even an SPI SD card interface. 16GB should be enough for anybody.
<JamesMunns[m]>
okhsunrog postcard-rpc is built around a single dispatcher loop that works well for a single "forever" interface, but doesn't really compose well for multiple interfaces or ones that can come or go.
<JamesMunns[m]>
Ergots design is different to better handle these cases, and to require way fewer gnarly macros
<okhsunrog[m]>
JamesMunns[m]: enjoy your lunch, sorry for bothering😅
<okhsunrog[m]>
sounds cool! I'll take a closer look at ergot this weekend
<JamesMunns[m]>
It also allows embedded devices to be "clients" as well, which was much harder in postcard-rpc.
<okhsunrog[m]>
<JamesMunns[m]> It also allows embedded devices to be "clients" as well, which was much harder in postcard-rpc.
<okhsunrog[m]>
it should already be possible to use ergot to communicate between devices connected via BLE or esp-now, right?
<JamesMunns[m]>
okhsunrog[m]: Yes, if you write profile for it. There's an rp2040 example already for two rp2040s connected via user
<JamesMunns[m]>
okhsunrog[m]: I plan to expand that to allow one of them to also have an optional usb connection, so it can bridge both nodes to the pc when connected, but still work when the pc isn't connected
<JamesMunns[m]>
* you write a profile for
<JamesMunns[m]>
JamesMunns[m]: To be clear, "multi hop routing" isn't well supported in ergot yet, it's still a work in progress :D, but I am working towards that now.
<JamesMunns[m]>
* Yes, if you write a profile for it. There's an rp2040 example already for two rp2040s connected via uart
<okhsunrog[m]>
JamesMunns[m]: yeah, reading it right now. looks very nice!
<JamesMunns[m]>
FWIW: Ergot is now at the point where I'd say ergot is ready for "early adopters": it's definitely usable for quite a few things already, especially for point-to-point or local-only comms. IMO if you have a bunch of channels in your code, ergot sockets are probably going to be much nicer.
<JamesMunns[m]>
There's definitely more breaking changes to be had, and design to sort out for for things, but I'd love to get feedback from folks, or questions about what needs better explanation/docs.
<okhsunrog[m]>
JamesMunns[m]: will it eventually replace postcart-rpc? does it also use postcard and cobs?
<JamesMunns[m]>
Not totally sure what the long term plan is with postcard-rpc, whether it's a hard replacement, or whether postcard-rpc just becomes "powered by" ergot. They definitely overlap, but ergot is sort of aiming to be a superset of what postcard-rpc can do
<JamesMunns[m]>
ergot uses a lot of the same tricks from postcard-rpc (wrt type schemas, comms model), uses postcard for serialization, etc.
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
<okhsunrog[m]>
JamesMunns[m]: and what about framing, does it always do it's own framing, or uses tcp framing, for example, when using ergot over tcp?
<JamesMunns[m]>
it has it's own frames, it's the job of the `interface` to define how you send/receive frames. For example over TCP, right now I use COBS to separate frames, over USB, I use the bulk packet framing (a non-max size packet denotes the end of a frame). It's flexible enough you can do whatever you'd like.
<JamesMunns[m]>
For example over UART, you could either do read-to-break/read-to-idle for framing, or do a normal stream with cobs (which works better with usb-uarts which can't always do idle detection/line breaks)
<JamesMunns[m]>
(this is very similar to how postcard-rpc's `WireTx` and `WireRx` traits, if you're familiar with that!)
<JamesMunns[m]>
Right now, I really only have "direct edge" profiles for embedded: they hold a single interface. I have embassy-usb interfaces built in, and a uart interface/profile in the rp2040 as well (you can define your own profiles/interfaces outside the ergot crate, they are just trait impls)
<JamesMunns[m]>
* the rp2040 demo project as well
<JamesMunns[m]>
Right now with "direct edge" profiles, you can basically do any comms you could with postcard-rpc, though I don't have the full "service discovery" capabilities implemented yet. But we have endpoints + topics over USB, so most of the functional behavior.
<okhsunrog[m]>
<JamesMunns[m]> Basically:...
<okhsunrog[m]>
and if I'd need 2 different sets of endpoints for 2 different interfaces, I'd create 2 netstacks?
<JamesMunns[m]>
<JamesMunns[m]> Basically:...
<JamesMunns[m]>
Not sure if I understand, if you have two interfaces, you can just have a single set of sockets, and they can accept messages from either interface
<JamesMunns[m]>
<JamesMunns[m]> Basically:...
<JamesMunns[m]>
like, you just run sockets on your device, the netstack will route messages from either interface to the same socket.
<JamesMunns[m]>
you COULD run two netstacks, each with one interface, if you really wanted to "firewall" the two of them, but I hadn't really considered that :D
<okhsunrog[m]>
JamesMunns[m]: I mean restricting which sockets to interfaces that can use them
<okhsunrog[m]>
* I mean restricting which sockets can be used by which interfaces.
<okhsunrog[m]>
JamesMunns[m]: okay, yeah, that's a rare usecase
<JamesMunns[m]>
Sockets can also see the source addr of a packet, that doesn't tell you exactly which interface it comes in on, but you could decide to reject packets that aren't from the local machine, for example
<i509vcb[m]>
From a skim, the `Driver` trait feels more like a `Bus` trait?
<i509vcb[m]>
Although the daisy chained SPI does seem like fun
<Emkanea[m]>
Hm yeah will think about it but my first feeling is you are right :)
<i509vcb[m]>
I of course might be wrong from not understanding the rest of the code
<Emkanea[m]>
The whole crate is a driver so it seems right that this is the "bus part"
ouilemur has joined #rust-embedded
<firefrommoonligh>
Yo! What is the state of BLE on Nordic chips in rust, as of 2025? Just need an exposed HCI interface. I'm currently doing that with ESP-Hosted, and it's working well. I'm interested in Nordic for a future project, as I don't need Wi-Fi for it.
<firefrommoonligh>
* working well for that. I'm
<firefrommoonligh>
* Yo! What is the state of BLE on Nordic chips in rust, as of 2025? Just need an exposed HCI interface. I'm currently doing that with ESP-Hosted, and it's working well for that. I'm interested in Nordic for a future project, as I don't need Wi-Fi for it.
<firefrommoonligh>
Is there an example of a "hello-world" that allows you to read and write arbitrary HCI?