<thejpster[m]>
Yes, itβs fine. And I can keep all my Pico 1 cables.
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<chrenderle[m]>
diondokter: I have another question regarding device driver: The ST25DV has a register of 256 bytes. This is for fast transfer mode. Messages are exchanged over this register. Sometimes all 256 bytes need to be read and sometimes not all 256 bytes. When I set it as a big register of 256 bytes it has the advantage that the 256 bytes are transferred faster in one big read. But I can't read only parts. When i set it as 256 single
<chrenderle[m]>
registers with repeat I can read parts but the read is slower since a new read is started for every register. What is the best way to do this? Is buffer the best way to do this?
<diondokter[m]>
chrenderle[m]: Right, well if it's like a buffer of bytes, the buffer type would be best to use
<diondokter[m]>
Which register is it? I'm curious to see in the datasheet myself
<chrenderle[m]>
Its mb_dyn. I'm looking at DS13519 - Rev 8
<chrenderle[m]>
How would I handle the EEPROM? It is a maximum of 64kBytes on some devices. I think that is too big to handle as one big register, because it would then need 64kBytes buffer on the mcu. And on the other hand it doesn't make sense as a buffer.
<diondokter[m]>
Yeah for eeprom there is nothing. So you'd need to write your own thing around that
<diondokter[m]>
For that d-d would really need commands with dynamic length data
<chrenderle[m]>
diondokter[m]: Maybe you could add an attribute like partial read or something. Where you can specify the length you want to read
<chrenderle[m]>
Or add something like memory. It would be like register but you can access it partially
<diondokter[m]>
chrenderle[m]: Yeah indeed
<chrenderle[m]>
diondokter[m]: How difficult would this be to implement? Maybe I could do it myself and open a PR
<diondokter[m]>
Mostly a design question really. Implementing it would be some work, but should not be very difficult
<diondokter[m]>
So before doing anything, there should be a design
<chrenderle[m]>
Do you have a design I can look at and add the memory feature?
<chrenderle[m]>
Do you want me to post this here or open a issue on the repo?
<diondokter[m]>
An issue is better
dinkelhacker_ has joined #rust-embedded
Makarov27 has quit [Quit: Client closed]
Makarov27 has joined #rust-embedded
<JamesMunns[m]>
<Lumpio[m]> "Micro USB in 2024 π€" <- I know it doesn't count but I'd laugh if they fell afoul of the European charger directive: https://en.wikipedia.org/wiki/Radio_Equipment_Directive_(2022)#:~:text=European%20Parliament%20adopted%20new%20rules,different%20chargers%20for%20their%20equipment.
<Lumpio[m]>
<thejpster[m]> "Yes, itβs fine. And I can keep..." <- There's a Pico specific cable..?
<diondokter[m]>
<chrenderle[m]> "I created the issue" <- Thanks, I don't really have time to respond now though so I'll need a bit of patience from you
<chrenderle[m]>
diondokter[m]: No problem
<thejpster[m]>
<JamesMunns[m]> "Yeah, like I said it probably..." <- If they had changed the Pico 2 to USB-C, a different set of people would have complained that it uses a different connector to the Pico 1 and isn't drop-in compatible.
<thejpster[m]>
My view is - if you want USB Type-C, buy a Feather, or buy a Β£1.50 Type C to micro-B adapter and leave it in your Pico. The USB micro-B connector is cheaper, cables are still readily available, and USB Type-C offers basically zero benefits (except maybe you can plug the cable in upside down).
<JamesMunns[m]>
thejpster[m]: I've heard their official PR statement on it, yes :D
<thejpster[m]>
if you're implying that I just come here to quote from their official PR material, then I have better things to do with my day
<JamesMunns[m]>
:/
<JamesMunns[m]>
Didn't mean to be an ass, sorry.
<Lumpio[m]>
More of a generic embedded question, but if you wanted to just erase and flash an SPI flash chip with an FTDI FT2232H adapter or similar _on Windows_ (due to work) what would you use?
<Lumpio[m]>
I had serious trouble finding a utility that actually works and doesn't require me to install like mingw to build it, and just ended up writing a Rust program for it...
sroemer has quit [Ping timeout: 252 seconds]
Makarov75 has joined #rust-embedded
Makarov27 has quit [Ping timeout: 256 seconds]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
mdietrich[m] has joined #rust-embedded
<mdietrich[m]>
Anyone here comfortable with Nix? I am not new to programming but new to embedded, Rust and (fairly) new to Nix, so I am a bit lost. Trying to use crane and rust-overlay in a flake-based setup and firstly not sure how to set up a usable and stable development environment and secondly having difficulties getting cargo and nix to behave similarly.
<thejpster[m]>
<Lumpio[m]> "More of a generic embedded..." <- In the past I wrote a c++ program that used the official DLL. Did the job.
<Lumpio[m]>
Yeah but I was thinking is there a tool out there already that just works and I couldn't find
<Lumpio[m]>
"Flashrom" doesn't have official Windows builds and I don't feel like downloading mingw or some sus binary on my work PC, I think openocd might support SPI flashing maybe but I couldn't figure out how, then I found some random tools from Adafruit and some .NET GUI contraption which didn't support FT2232H and I didn't feel like fixing them
dngrs[m] has joined #rust-embedded
<dngrs[m]>
<mdietrich[m]> "Anyone here comfortable with Nix..." <- The Rust room has a few nix users iirc. Can't link to it though because element on phone is inept
jakzale has quit [Remote host closed the connection]
jakzale has joined #rust-embedded
crabbedhaloablut has quit []
cinemaSundays has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
kenny has quit [Ping timeout: 252 seconds]
kenny has joined #rust-embedded
Makarov1 has joined #rust-embedded
Makarov75 has quit [Ping timeout: 256 seconds]
crabbedhaloablut has quit []
dinkelhacker_ has quit [Quit: Client closed]
Makarov1 has quit [Ping timeout: 256 seconds]
crabbedhaloablut has joined #rust-embedded
Makarov1 has joined #rust-embedded
cinemaSundays has quit [Quit: Connection closed for inactivity]
Makarov48 has joined #rust-embedded
Makarov1 has quit [Ping timeout: 256 seconds]
Makarov48 has quit [Quit: Client closed]
Makarov48 has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
Makarov48 has quit [Ping timeout: 256 seconds]
Makarov48 has joined #rust-embedded
almindor[m] has joined #rust-embedded
<almindor[m]>
hmm is it me or is the esp-hal/embedded-hal-bus SPI setup incompatible with sharing devices? There doesn't seem to be a way to have different SPI speeds per device?
cinemaSundays has joined #rust-embedded
Makarov48 has quit [Quit: Client closed]
Makarov48 has joined #rust-embedded
Makarov48 has quit [Client Quit]
Makarov48 has joined #rust-embedded
danielb[m] has joined #rust-embedded
<danielb[m]>
<almindor[m]> "hmm is it me or is the esp-hal/..." <- I'm not sure if embedded-hal-bus offers per-device configurability, but embassy-embedded-hal does and we support that.
<almindor[m]>
so embedded-hal doesn't use esp-hal under the hood?
<almindor[m]>
for esp boards I mean
<danielb[m]>
that's a very weird question considering embedded-hal is just a set of interfaces
<almindor[m]>
* so embassy-embedded-hal doesn't
<almindor[m]>
fixed :D
<almindor[m]>
I meant embassy-embedded-hal
<danielb[m]>
π€¨ esp-hal implements the traits necessary to use embassy-embedded-hal
<almindor[m]>
so how is the SPI reconfigured per device then, esp-hal enforces frequency be set when creating the SPI bus itself. Or do you pass in individual frequencies to devices as well and they just reconfigure on switch?
<danielb[m]>
yeah but even in that version you had set_frequency somewhere
<danielb[m]>
I know it exists because I cried loud enough last year to get that added :D
<almindor[m]>
ah so it's an unreleased change then I see. Yeah set-frequency would work with embedded-hal-bus supported it, but I don't think that is standardzied via the traits
<danielb[m]>
sorry but what is unreleased?
<almindor[m]>
nvm. it's the new_with_config vs new. Regardless though it seems that I'd have to reconfigure the bus manually between using different devices
<danielb[m]>
please don't blame that on esp-hal, we didn't write the shared bus π
<danielb[m]>
* shared bus/device, * traits π
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
blame me I guess? π€£
<danielb[m]>
dirbaio[m]: give us better libs, dirbaio-san
<almindor[m]>
I'm not blaming anyone :) I think the SpiDevice and SpiBus should have a type Config and the SpiBus should have a fn reconfigure(Self::Config) to be used whenever switching
<dirbaio[m]>
almindor[m]: that's exactly what embassy-embedded-hal SetConfig does
<dirbaio[m]>
it'd be nice to add it to embedded-hal
<dirbaio[m]>
but I expect it to be controversial
<almindor[m]>
that's how I did it with hifive1/e310x-hal as well
<danielb[m]>
dirbaio[m]: well, bus isn't stable yet π
<almindor[m]>
it allows HW level specifics to work out too (e.g. hw timing between spi bursts etc.)
<dirbaio[m]>
danielb[m]: unstable serial bus
<almindor[m]>
we already have a USB spec :P
<dirbaio[m]>
that's universal cereal bus
<dirbaio[m]>
idk
<dirbaio[m]>
so, about SetConfig
<dirbaio[m]>
the advantage is it's "abstracted away" from what the actual config is
<dirbaio[m]>
so we don't have to define its contents, the actual HAL impl does
<dirbaio[m]>
but the downside is it's only useful for setting config in shared buses
<dirbaio[m]>
while there's many people who want an actual "set baudrate", "set frequency", "set spi mode"
<dirbaio[m]>
for example if a driver knows the chip needs Mode 3 it might want to just go and set it
<dirbaio[m]>
instead of hoping the user read the docs and set it correctly when creating the bus
<dirbaio[m]>
or set_baudrate() for garbo AT command modems
<dirbaio[m]>
* or set_baudrate() for garbo AT command modems that boot with a slow-as-snail uart and the driver wants to speed them up
<danielb[m]>
especially when SetConfig does some involved looping clock calculation, it's not even trivial in runtime π
<almindor[m]>
Bus shouldn't be usable whatsover, it's a bad way of looking at it
<almindor[m]>
Bus should just be a placeholder for Device
<almindor[m]>
and then devices should take in CS (or NoPin if not needed) and configs
<danielb[m]>
that's not the point, the point is device drivers can't do anything with SetConfig
<almindor[m]>
this will also allow HW level control of CS per device
<almindor[m]>
they shouldn't need to do anything with SetConfig
<almindor[m]>
they shouldn't even see the config
<danielb[m]>
embedded-hal is an interface between hals and drivers, not hals and user code
<danielb[m]>
i know, strongly simplified
<almindor[m]>
user creates MCU specific SPI config (which is just an associated type as per trait) and passes it into creation of specific SpiDevice constructors.
<almindor[m]>
the spi devices will use their handle to the parent bus to reconfigure with their config each time they get into use
<almindor[m]>
that's it
<dirbaio[m]>
SetConfig works for drivers like RefCellDevice
<dirbaio[m]>
it doesn't work for drivers like SimcomUartModem
<almindor[m]>
this should include the CS pin btw.
<dirbaio[m]>
where SimcomUartModem wants to "set uart to 115200 baud, send "pls go faster" AT command, set uart to 921600 baud, send more commands"
<almindor[m]>
drivers shouldn't see any of this, drivers should just see SpiDevice with transfer etc.
<danielb[m]>
that's a bit limiting when the device has exactly two frequency options, and the user ends up configuring the SpiDevice to use a third
<almindor[m]>
so you're daying you have a driver requirement where the driver needs to set SPI speed for its device in the "middle"
<almindor[m]>
s/daying/saying/
<dirbaio[m]>
yeah
<dirbaio[m]>
for SPI/I2c it's rarer
<dirbaio[m]>
for uart the motivation is quite compelling
<danielb[m]>
dirbaio[m]: ads1292 π
<diondokter[m]>
dirbaio[m]: SD card iirc
<dirbaio[m]>
danielb[m]: I don't wanna hear about it π
<danielb[m]>
dirbaio[m]: why, it's good for the heart (it's an ecg frontend :D )
<almindor[m]>
Well, if we abstract the `type Config` into something more specific, you could open up something like `SpiDevice::reconfigure(&dyn SpiConfig)`
<dirbaio[m]>
sounds cursed
<dirbaio[m]>
spi device that requires changing speed??? π
<danielb[m]>
no, doesn't require it, you can do it if an oscillator is soldered
<diondokter[m]>
Hmmm ok, I've never seen requires
<diondokter[m]>
For spi
<almindor[m]>
it does get painful if that becomes a necessity. I always assumed spi would just set and go
<almindor[m]>
it can still be done for "common values" I suppose
<danielb[m]>
almindor[m]: so how exactly do you propose said trait to contain the CS pin?
<danielb[m]>
just to go by an example
<almindor[m]>
CS pin is tricky if you need HW support (e.g. SPI bus to handle the CS setting). In those cases you can't just have a generic SpiDevice::new(bus-whatever, cs: OutputPin) because the pin might need to actually be IOF or such
<danielb[m]>
but that means this idea breaks down somewhat quickly
<almindor[m]>
it works out of abstraction (e.g. if the hal actually implements it right)
<almindor[m]>
I'm not sure how to abstract it right to enforce it
<almindor[m]>
this approach should work on other MCUs if they have HW CS setups
<almindor[m]>
but I have no idea how the e-h traits/abstraction could be done to sort of "enforce" handling this right
<danielb[m]>
well you are in the e-h room where these get designed, so I guess you can see why the interface doesn't exist yet :D
Foxyloxy has joined #rust-embedded
<danielb[m]>
s/e-h//
<danielb[m]>
* well you are in the room where these get designed (or at least discussed), so I guess you can see why the interface doesn't exist yet :D
<almindor[m]>
I've been here when this was just an idea :) this was the 1st HAL implementation that did the SPI separation even before e-h had SpiDevice in at all. The main issue as I see it tho is there's no easy way to enforce that hal implementors do this "right"
<almindor[m]>
e.g. "don't enforce software CS" kind of right
<dirbaio[m]>
have you benchmarked how much faster is hardware CS? i'm very curious
<almindor[m]>
I never had a particularly peformant slave, my highest was a combination of 80Mhz and 60Mhz capable displays
<almindor[m]>
and then I managed to brick my red-v :D I just recently got esp-c6 hence my renewed interest heh
<danielb[m]>
I designed a revision of my ECG before I realized that the C6 only has a single SPI :(
<almindor[m]>
yeah, I tried to combine a display with the usb-host (max3421e) and that's when I realized "this won't work direct, the mode and speed are not set automatically" :D
<danielb[m]>
well I could bitbang my ADC, I don't recommend you try for either, but maybe the PARL_IO could work as an alternative
<almindor[m]>
I can still RefCell it
<almindor[m]>
I can just use RefcellDevice with refcell on the SPI and set the mode and speed manually between using the drivers
<almindor[m]>
it's sucky but it should work
<danielb[m]>
why don't you just use embassy-embedded-hal as I said like two hours ago?