<Assatadajamante[>
<M9names[m]> just putting this out there in case it is interesting for you Aïssata:...
<Assatadajamante[>
well it settles it for the esp board!
<Assatadajamante[>
<diondokter[m]> I need to ask, what does embedded mean to you? What does your project look like?
<Assatadajamante[>
And then I have an old SPI screen that I think still works.
<diondokter[m]>
Right, so proper embedded. Good to know
<diondokter[m]>
Take a look at the embedded-graphics crate
<Assatadajamante[>
<diondokter[m]> Right, so proper embedded. Good to know
<Assatadajamante[>
Yes, proper 😆, but with some level of abstraction, especially for graphics.
<Assatadajamante[>
I don't know the terms for games but I know they use a sheet where some letters are replaced by items. And they render through this.
<Assatadajamante[>
(wow Slint has become cutting edge neat https://slint.dev/)
<wassasin[m]>
embedded-graphics as a simulator allowing you to develop the graphics on a normal host without needing to flash on an embedded device. I highly recommend developing using this
<diondokter[m]>
But be aware of codesize. The smallest of these pngs is 40kb
<diondokter[m]>
Embedded graphics also has support for text. So maybe you can use that system.
<diondokter[m]>
(They use an atlas too IIRC)
<Assatadajamante[>
Thank you everyone!
<Assatadajamante[>
I guess MVP with letters is a start :D
<Assatadajamante[>
* with letters moving around is a
<Lumpio->
ESP32 boards have like 2MB of memory on average so memory size isn't going to be an issue for having a few colorful sprites
<Lumpio->
And palettized images are small
<davidmpye[m]>
dirbaio: Sorry to ask directly, but a list of supported flash types for ekv, or do you need to implement the Flash trait for whatever you pick?
<dirbaio[m]>
You need to impl it yes
<dirbaio[m]>
Or you can send a PR to change it to use the NorFlash trait 🙃😋
<davidmpye[m]>
hehe, suggstion noted - thank you :-)
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
<Lumpio-> ESP32 boards have like 2MB of memory on average so memory size isn't going to be an issue for having a few colorful sprites
<KevinPFleming[m]>
That's fairly high... the original ESP32 has 320KB, and most of the newer flavors have as much as 512KB. They can all support additional RAM over SPI (PSRAM), but none of them include 2MB of RAM in the chip itself. 320KB is still quite a lot more than most STM32 and NRF devices, of course.
<Lumpio->
KevinPFleming[m]: I was talking about flash - but yes you might need to load some of the stuff to RAM as well, not all of it necessarily though.
<KevinPFleming[m]>
Lumpio-: Ahh, right! The common modules have 4MB of Flash or more, sure.
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
andar1an[m]1 has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
Is the order important? If you're copying from the ringbuffer that could just be 2 memcpy's (worst case). The order in your new buffer will be `old -> new` instead of `new -> old`, but that might be ok?
<diondokter[m]>
If the order is always `new -> old` maybe you could let the ring buffer go in reverse. So any time you add a new element to it, you do a push_front instead of push_back
<JamesMunns[m]>
I think the second example it can tell you are always using 0 as the input and it's just loading zero instead of actually doing any array ops
<diondokter[m]>
Good point, yeah in godbolt it's best to take these kinds of input as function parameters
<JamesMunns[m]>
It's a little closer, but still ~double
richardeoin has quit [Read error: Connection reset by peer]
andar1an has quit [Quit: andar1an]
andar1an has joined #rust-embedded
richardeoin has joined #rust-embedded
<jason-kairos[m]>
<diondokter[m]> Is the order important? If you're copying from the ringbuffer that could just be 2 memcpy's (worst case). The order in your new buffer will be `old -> new` instead of `new -> old`, but that might be ok?
<jason-kairos[m]>
It's to run averaging and other statistics on the elements in place. It might not matter.
<jason-kairos[m]>
At one time it was computing min/max/average for multiple windows, 60 seconds, 120 seconds, etc.
<jason-kairos[m]>
* multiple windows, lat 60 seconds,, * 60 seconds, last 120 seconds,
<jason-kairos[m]>
* At one time this section of code in the real application was computing min/max/average for multiple windows, lat 60 seconds, last 120 seconds, etc.
<diondokter[m]>
<jason-kairos[m]> It's to run averaging and other statistics on the elements in place. It might not matter.
<diondokter[m]>
Unless it involves floats, I don't think the order matters. With floats it can matter a little bit, but likely not enough for it to matter
andar1an has quit [Remote host closed the connection]
andar1an has joined #rust-embedded
andar1an has quit [Remote host closed the connection]
andar1an has joined #rust-embedded
andar1an has quit [Remote host closed the connection]
andar1an has joined #rust-embedded
andar1an has quit [Remote host closed the connection]
andar1an has joined #rust-embedded
andar1an has quit [Remote host closed the connection]
andar1an has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
tiwalun[m] has quit [Quit: Idle timeout reached: 172800s]
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
postcard-rpc v0.11.12 released, now with support for embedded-io-async based serial ports :)
<phycrax[m]>
If one core panics or hits a fault does the other core also stops execution on dual core mcus? Sorry if it's a bit out of topic.
<phycrax[m]>
It probably depends on panic impl, but I am not sure about faults.
<JamesMunns[m]>
yeah, depends on the mcu/panic impl. it's definitely not guaranteed that the other core will stop too.
<JamesMunns[m]>
AFAIK rp2xxx chips totally keep going if one core panics/resets, you have to do extra tricky things to force both cores to reboot, like use the watchdog IIRC
<phycrax[m]>
I'm thinking of a design where I would use the other core as a monitoring killswitch so if main core somehow panics or has a software bug, the other core would engage the safety switch. The second core would be monitoring hardware.
<JamesMunns[m]>
It's possible, though the question is always: what makes the second core less susceptible to faults/errors than the first core, and does the complexity of using two cores (that need to coordinate, directly or indirectly), actually improve or worsen the total chance of failure
<JamesMunns[m]>
What you're describing is common on many areas! Though it's often a cortex-m/cortex-r core babysitting a cortex-a core
<JamesMunns[m]>
where the hope is "a small firmware is statistically easier to audit than a large application processor running linux", for example
<JamesMunns[m]>
(this is an area where there's no "objectively right" answers, just a lot of questions that help you answer "is this the right choice for what I'm doing")
<JamesMunns[m]>
That being said, even just writing down all of the "things that can go wrong", and then "what you are doing to avoid those things", and "why is what you're doing actually helping, and how could the things you're doing ALSO go wrong", is a fun thought exercise.
<JamesMunns[m]>
Fault Trees are useful for trying to game out "am I making things better or worse", for thinking about "is my 'fix' actually independent from the thing it is trying to fix?": https://en.wikipedia.org/wiki/Fault_tree_analysis
<phycrax[m]>
Very helpful, thanks James!
<JamesMunns[m]>
It's fresh in my mind, I JUST did a podcast episode about this :D
<Ralph[m]>
we don't seem to have a discussion for next week's meeting yet - is this intentional? (could be a summer vacation break, for all i know?)
<thejpster[m]>
I think it just hasn’t been created yet
mrpashapg[m] has joined #rust-embedded
<mrpashapg[m]>
Could you please recommend a good, reliable library for working with W25 SPI memories and AT24 I2C memories? The only important requirement is that I don't want the library to automatically erase entire sectors on every write operation - I need manual control to handle wear-leveling myself. It should also be async-compatible.
<mrpashapg[m]>
Has anyone researched this before?
<mrpashapg[m]>
So far I've found spi-memory-async - would this be a suitable choice for commercial project use?
<JamesMunns[m]>
@diondokter is reworking his w25 library, lemme find it
<mrpashapg[m]>
diondokter[m]: I see, so the async functionality is implemented specifically through SPI's async operations? Would this be considered a particular implementation of async protocol?
<diondokter[m]>
Not sure what you mean with 'implementation of async protocol'
<diondokter[m]>
The w25 crate has async fns and it awaits the SPI transactions
<mrpashapg[m]>
diondokter[m]: What I mean is that since it only uses async SPI, the SPI protocol itself handles everything - unlike typical async logic that works with registers and status bits!
<mrpashapg[m]>
Or am I misunderstanding this?
<diondokter[m]>
My brain is not working 100% today, so it may just be me... I don't know what you mean.
<diondokter[m]>
Async usually doesn't do logic. It just waits for IO
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]>
<mrpashapg[m]> Could you please recommend a good, reliable library for working with W25 SPI memories and AT24 I2C memories? The only important requirement is that I don't want the library to automatically erase entire sectors on every write operation - I need manual control to handle wear-leveling myself. It...
<GuineaWheek[m]>
tbh i generally prefer to write these sorts of drivers myself
<GuineaWheek[m]>
that said
<GuineaWheek[m]>
if it implements the embedded-storage traits it generally won't erase on write
<dirbaio[m]>
polling for the status bits is "async busy-waiting", I think @mrpashapg:matrix.org might be hoping for a "really" async implementation where the chip sends an interrupt back when done so there's no busy-waiting at all?
<dirbaio[m]>
if that's the case, such a thing is not possible because the protocol has no "interrupt" pin, you have to busy-wait
<GuineaWheek[m]>
there are some chips with peripherals that automatically do this busypolling for you
<diondokter[m]>
Ah, yeah. These flash chips don't have interrupts
<dirbaio[m]>
but at least the busy-waiting will let other tasks run because it's async :P
<GuineaWheek[m]>
stm32h7 xspi can poll the status register for you iirc
<GuineaWheek[m]>
but then you gotta write your own driver for that lol
<mrpashapg[m]>
Is there really no way to use it asynchronously? Since it's one of the most frequently used modules in my project, this could potentially cause major issues.
<diondokter[m]>
mrpashapg[m]: I mean, you could probably contribute to it or fork it and make an async variant of the crate
<JamesMunns[m]>
turning "not async" crates into "async" crates is usually like a 10 minute job lol
<JamesMunns[m]>
replace embedded-hal with embedded-hal-async, turn every spi/i2c op into an async op, propagate the async fn changes until everything compiles
<JamesMunns[m]>
(I have a lot of "make crate x async" forks in my gh for one-offs, I usually open a PR, not everyone takes them)
<JamesMunns[m]>
this is less true for some more complex chips, but for a lot of basic drivers, it's that straightforward.
<mrpashapg[m]>
dirbaio[m]: Thanks for your helpful and valuable explanations.
<mrpashapg[m]>
dirbaio[m]: Good to know, I'm happy about this XD
<mrpashapg[m]>
GuineaWheek[m]: Oh boy, I really don't like dealing with it XD
<GuineaWheek[m]>
the more interesting things you want to do with your hardware the more you will have to write yourself because the original HAL authors did not imagine that usecase
<GuineaWheek[m]>
and block you off from it with sealed traits or limited visibility
<mrpashapg[m]>
<diondokter[m]> I mean, you could probably contribute to it or fork it and make an async variant of the crate
<mrpashapg[m]>
I haven't checked if someone has forked it and converted it to async or not XD
<mrpashapg[m]>
<diondokter[m]> I mean, you could probably contribute to it or fork it and make an async variant of the crate
<mrpashapg[m]>
Thanks for your time
<mrpashapg[m]>
<JamesMunns[m]> this is less true for some more complex chips, but for a lot of basic drivers, it's that straightforward.
<mrpashapg[m]>
Thanks for your great explanations and the time you've spent
<mrpashapg[m]>
<GuineaWheek[m]> and block you off from it with sealed traits or limited visibility
<mrpashapg[m]>
No, I absolutely don't intend to do anything illogical or that's intentionally restricted. I'm already risky enough with normal stuff as it is XD
sroemer has quit [Quit: WeeChat 4.5.2]
<firefrommoonligh>
<mrpashapg[m]> Could you please recommend a good, reliable library for working with W25 SPI memories and AT24 I2C memories? The only important requirement is that I don't want the library to automatically erase entire sectors on every write operation - I need manual control to handle wear-leveling myself. It...
<firefrommoonligh>
A thought: If your MCU supports it, you should probably memory map this using the QSPI peripheral. Normal IC operation is fine too, but the memory map operation will depend on your MCU's QSPI periph
<firefrommoonligh>
Also note that these chips' APIs are straightforward to work with in either mode
<diondokter[m]>
firefrommoonligh: If you want erase/write capability, that doesn't always work
<mrpashapg[m]>
firefrommoonligh: I've studied the module but couldn't find anything about QSPI
<firefrommoonligh>
For W25?
<mrpashapg[m]>
firefrommoonligh: yep
<firefrommoonligh>
Hmm
<firefrommoonligh>
It's all over the DS I'm looking for. Text search for "quad"
<diondokter[m]>
W25 definitely works with qspi
<firefrommoonligh>
It comes up 78 times
<diondokter[m]>
It's not in my driver though, if that's what you were looking at
<firefrommoonligh>
And normal SPI may be good enough and it's easy to use
<firefrommoonligh>
But this is teh canonical case for QSPI
<mrpashapg[m]>
firefrommoonligh: The libraries I've searched and reviewed didn't mention this in their examples or implementations.
<firefrommoonligh>
Libraries won't save you here; this is rust embedded
<firefrommoonligh>
Some day, we will be at a point where you can expect to use a lib as default; not yet
<firefrommoonligh>
I'm about to order a board that has these chips wired up this way; maybe I will post a lib then
<mrpashapg[m]>
firefrommoonligh: Perhaps you misunderstood my question - I'm not trying to implement a separate library. I just wanted a library that doesn't perform pre-erase operations like higher-level libraries do, since it significantly increases write costs
danielb[m] has joined #rust-embedded
<danielb[m]>
without QSPI traits, you'll not get QSPI-compatible libraries. but sticking with 1-wide SPI isn't terrible
<danielb[m]>
ok slight caveat is that a library can be made transport-agnostic with just taking closures I guess
<wassasin[m]>
It will be very difficult to come up with useful QSPI traits
<firefrommoonligh>
The same principle applies here: You will find a lib that nominally supports the chip, but it is not flexible enough to support your case
<firefrommoonligh>
This is the norm for now
<diondokter[m]>
wassasin[m]: Yeah, discovered that a bit ago too. Most qspi peripherals suck
<diondokter[m]>
Same with I2C slave
<firefrommoonligh>
The other way of phrasing this is: What you are seeking does not exist at this time.
<mrpashapg[m]>
firefrommoonligh: Oh, I hope everything goes well and you succeed! You can also use SMD to DIP8 adapter boards - they're especially easy to solder for W25 chips
<diondokter[m]>
firefrommoonligh: It does. He doesn't need qspi.
<diondokter[m]>
The W25 crate will be fine
<firefrommoonligh>
mrpashapg[m]: Using WSON-8 in this case
<firefrommoonligh>
diondokter[m]: For write without erase?
<diondokter[m]>
Yeah
<firefrommoonligh>
I stand corrected!
<diondokter[m]>
It implements the embedded-storage traits
<firefrommoonligh>
Nice. I'm not familiar with those traits, but it sounds relevant for my project.
RockBoynton[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Users of embedded-io: Is there anything incompatible you'd like changed before going 1.0?
<chrysn[m]>
(I'm not on that crate's team, but have enough dependencies on embedded-io that I'm interested in advancing it to the point where a 1.0 can be called)