M9names[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 276 seconds]
notgull has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
notgull has quit [Ping timeout: 252 seconds]
emerent has quit [Ping timeout: 246 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<thejpster[m]>
I do wish I could cfg on a target wildcard. It works in the cargo config after all.
samkent has joined #rust-embedded
m3vict[m] has joined #rust-embedded
<m3vict[m]>
Could someone share some tips on how to implement a generic device driver over Spi word size? Let's say I have 2 impls for low level operations SpiDevice<u8> and SpiDevice<u16> and I would like to create higher level generic functions that use one of those 2 impls.
<m3vict[m]>
m3vict[m]: I tried creating a newtype + trait called "MyDeviceSpi", but then I got "conflicting implementations of trait `spi::QcaSpiDevice` for type `spi::QcaSpi<_>`"
<m3vict[m]>
* type `spi::QcaSpi<_>`",, * when creating 2 impls blocks (one for SpiDevice<u8> other for SpiDevice<u16>)
<AdamHott[m]>
Does anyone know of any job boards for embedded Rust jobs or internships?
<AdamHott[m]>
I'm pretty green still, so I'd be happy to go the internship route.
samkent has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
samkent has joined #rust-embedded
Guest7282 has joined #rust-embedded
Guest7282 has quit [Changing host]
Guest7282 has joined #rust-embedded
<tr09[m]>
<tr09[m]> "Has anyone tried getting..." <- NVIC’s IABR register bit for SWI0 stays lit on, I think that confirms chip boots up new firmware thinking it’s still handling an interrupt.
<tr09[m]>
When is IABR cleared? On ret instruction?
<K900>
Honestly if you have existing non-embedded Rust experience, just apply for the embedded jobs
<K900>
Most embedded teams would love to have a person who has touched grass in the past five years
<K900>
And the good ones recognize that
<tr09[m]>
unsafe { Is there any way to fake a return from ISR? }
<diondokter[m]>
tr09[m]: What do you mean?
<AdamHott[m]>
<K900> "Honestly if you have existing..." <- Thanks for the encouragement!
<AdamHott[m]>
I do have non-embedded Rust experience!
<tr09[m]>
diondokter[m]: I have a thread from yesterday: using rtic means tasks are inside ISR and if I call bootload new software is still “inside” of it and rtic is effectively broken.
<diondokter[m]>
tr09[m]: Right, yeah you can't do that. In RTIC I think you can have a software task at the lowest priority and let it call the bootload function. From your interrupt you then spawn that task and return from the interrupt as normal.
<tr09[m]>
diondokter[m]: From the generated intermediate .rs it appears that all tasks are interrupts, using SWIx
<tr09[m]>
* tasks are in interrupts, using
<diondokter[m]>
In RTIC 2 the lowest prio tasks should be on the normal thread (non-interrupt) level AFAIK
<diondokter[m]>
In RTIC 1 you've got the idle task that runs in thread mode
<tr09[m]>
Oh idle, gonna have to use that probability
<JamesMunns[m]>
I've seen that blog post, but I haven't seen anyone here actually using that
<ruan[m]>
I was assuming that this isn't specifically an issue with their code, but more that embedded rust development under windows doesn't work as well as under linux
<JamesMunns[m]>
> embedded rust development under windows doesn't work as well as under linux
<JamesMunns[m]>
I'm not sure why that doesn't fail on linux, but it's possible it's due to the linker used, which might happen to work on linux, if that's where the author was writing it from?
<JamesMunns[m]>
In general, those crates are only really intended to run on the actual intended targets - cortex-m devices
<JamesMunns[m]>
In general, the more common/recommended approach is:
<JamesMunns[m]>
* have one library crate, that is not target/hardware specific, and uses embedded-hal traits, and holds as much "business logic" as possible
<JamesMunns[m]>
* have one binary crate, that is specific to your hardware
<JamesMunns[m]>
that will allow you to test the library crate on your host, without linking in any cortex-m/stm32 specific hardware libraries, and used mocked embedded-hall impls
<JamesMunns[m]>
then, usually "don't test" the binary crate, or test it specifically on the hardware, using integration or system tests.
<ruan[m]>
yeah, that seems like a more sensible approach
<ruan[m]>
thanks for your advice!
<Ralph[m]>
the only thing to note there is that you can't put it into a cargo workspace as you can't have per-crate targets defined. thus your IDE might not be 100% happy.
<Ralph[m]>
regarding mocking: i don't understand why this example implements it on its own. [`embedded-hal-mock`](https://github.com/dbrgn/embedded-hal-mock/) is doing a nice job, IMHO
<tr09[m]>
diondokter: thank you very much for the suggestion, bootloading from idle works!
<diondokter[m]>
Cool! Great :)
<tr09[m]>
<tr09[m]> "NVIC’s IABR register bit for SWI..." <- Solution: invoke moonboot from `fn idle`
notgull has joined #rust-embedded
Guest63 has joined #rust-embedded
notgull has quit [Ping timeout: 245 seconds]
<Lakier15[m]>
<Ralph[m]> "the only thing to note there..." <- Actually, I think as long as you are using nightly, you can use the [per-package-target](https://doc.rust-lang.org/cargo/reference/unstable.html#per-package-target) unstable feature where you can have mixed targets in the same cargo workspace. That's what I use to have `cargo test` being happy with a workspace that targets both x86_64 and bare metal
<adamgreig[m]>
I think that still merges features for all dependencies though, which often means you still can't combine everything into one workspace (?)
<dirbaio[m]>
yeah it still merges
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 252 seconds]
hmw has quit [Quit: Bye.]
hmw has joined #rust-embedded
kpcyrd[m] has joined #rust-embedded
<kpcyrd[m]>
I'm now considering trying bitbang_hal instead, but I noticed I need to implement both OutputPin **and** InputPin for SDA. Implementing OutputPin for Pin<Output, _> and InputPin for Pin<Input, _> is trivial, but I don't understand how I would implement both traits at once. Can somebody help?
<kpcyrd[m]>
I'm trying to get i2c to work on a digispark attiny85, a friend who's an electrical engineer helped me implement the embedded_hal::blocking::i2c traits using the hardware's USI thingy, we've used a logic analyser and it seems to be somewhat working, but the i2c screen I'm using for testing does not respond.
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Brief question on embedded-storage{,-async}, merely to verify that I'm not missing something stupid:
<chrysn[m]>
Is there anything in the ReadNorFlash and NorFlash that is really about NOR flash, and not just about being small-block-writable and large-block-erasable?
<chrysn[m]>
Only with MultiwriteNorFlash the write restriction gets relaxed and then the NOR flash behavior of erase-to-1-write-to-0-overwrite-to-0 comes through -- and even that behavior is shared with NAND flashes.
<dirbaio[m]>
chrysn: yeah, other than the multiwrite NorFlash could be usable as-is for NAND
<dirbaio[m]>
but aren't there other differences for NOR vs NAND? like, you need to handle bad blocks on NAND but not on NOR
<dirbaio[m]>
so if you impl NorFlash for a NAND flash and give it to a fs/db driver that doesn't handle bad blocks because it's intended for NOR, it'd break down
<diondokter[m]>
huh, yeah reading about NAND that sure seems to be an issue. Also no random reads apparently
<diondokter[m]>
I guess you could implement the NOR traits on top of a software error correction layer instead of directly on top of the NAND hardware
<dirbaio[m]>
yeah.. though at that point you might be better off emulating a block device instead of a nor flash
<dirbaio[m]>
"block device" as in "you can read an entire block or write an entire block"
<dirbaio[m]>
no partial or multi writes
<AdamHott[m]>
Hi All, I did a walkthrough that I can turn into a blog post https://github.com/CodingInGreen/microbit_v2_rgb_led but I actually have a problem getting a part of it to work. I've got GPIO Pin 9 working properly on the Kitronik Edge Connector Breakout Board in the example, but I can't find any other GPIO Pins that are correctly sending voltage through. Here's the pinout chart for the micro:bit V2, I've tried P08, P16, P14, P6, P7,
<AdamHott[m]>
P4, P3. None of them are sending voltage through. I feel like it might be a coding issue, all the cables and RGB LED lights up with the correct color when connecting the cables to Pin 9. https://tech.microbit.org/hardware/edgeconnector/#pins-and-signals
<AdamHott[m]>
Its a RGB LED Common Cathode, it has 4 terminals
<AdamHott[m]>
3 terminals for RGB, respectively
<K900>
So only red works, the other ones just don't?
<AdamHott[m]>
Right
<AdamHott[m]>
No voltage on the Pin
<K900>
Have you tried it without the breakout?
<K900>
Like, if you just poke the board itself with a voltmeter
<AdamHott[m]>
I haven't tried that no!
<AdamHott[m]>
That's a great idea!
<AdamHott[m]>
I've tried with 2 different micro:bits and 2 different breakouts
<AdamHott[m]>
I'll try that!
<AdamHott[m]>
Thanks!
<chrysn[m]>
I wasn't so much thinking of NAND even, but of (probably NOR based) more elaborate flashes, which often are checksummed to some granularity, and more exotic ones (FRAM).
<chrysn[m]>
The NorFlash type is already parametrized so that it can also express what @dirbaio called "block devices" (when WRITE_SIZE == ERASE_SIZE).
<dirbaio[m]>
"NorFlash with WRITE_SIZE == ERASE_SIZE" is still not a great trait for block devices, because you have to erase first
<dirbaio[m]>
vs on a block device you don't "erase", you just overwrite
<chrysn[m]>
The error handling guarantees might be better served spelled out explicitly -- of a NorFlash you may not expect bad blocks, but is that a trait that could or should be added in the tree? And the guarantees on power failure during writes are even more complex (to the point I don't think it's reasonable to express them in types)
<chrysn[m]>
dirbaio[m]: That depends on the block device; the APIs may make it look that way, but for example SD cards do need explicit erase IIRC
<dirbaio[m]>
they don't
<AdamHott[m]>
<K900> "Like, if you just poke the board..." <- I poked the red lead on the gold pin on the microbit for Pins 03 and 04 and am not getting a reading with either of the 2 micro:bit V2s I have.
<AdamHott[m]>
But I am getting the 3.3 V from Pin 09
<K900>
But is it blinking
<K900>
Or is it just a constant voltage
<K900>
Because your code should make it blink
<K900>
And if it doesn't it has probably crashed
<AdamHott[m]>
Is there a way to recover it?
<K900>
Recover what?
<AdamHott[m]>
Like are my micro:bit's fried?
<K900>
Probably not
<AdamHott[m]>
It's rotating the current every 250 ms like specified in my code
<K900>
You can attach a debugger and look
<K900>
Oh
<K900>
So it is blinking
<K900>
Just only the red pin?
<AdamHott[m]>
Yeah, but just on Pin 9
<AdamHott[m]>
It's blinking on Pin 9
<K900>
Oh wait
<K900>
Are you sure you're using the right pins?
<JamesMunns[m]>
"it's blinking" => where is the LED?
<JamesMunns[m]>
on the breakout, or on the microbit itself?
<K900>
I'm guessing you're looking at the labels on the board
<K900>
Which match their software abstraction, not the actual GPIO numbers on the chip
<K900>
The one that exists specifically to confuse yout
<K900>
s/yout/you/
<K900>
Does every board have to have one
<JamesMunns[m]>
lmao
<JamesMunns[m]>
K900: Pin: LED Red (herring)
<K900>
My personal favorite is still one of the old Intel Quark breakout boards that had a pin that switched a multiplexer that just happened to be connected to 0 on one side and 1 on the other by default
<AdamHott[m]>
So Pin 3 would be p0.21?
<K900>
So it looked like it worked until you changed something completely unrelated and then it stopped
<JamesMunns[m]>
AdamHott[m]: What do you mean Pin 3
<AdamHott[m]>
should I be looking at the mod column or the MCU column?
<AdamHott[m]>
That's the MCU column
<K900>
The mod column is what's silkscreened on the board
<K900>
The MCU column is what you want to use in your code
<AdamHott[m]>
ok, thanks so much, that fixed it!
<AdamHott[m]>
I'm getting voltage on the board now
<AdamHott[m]>
on the P3, P4, and P9
<barnabyw[m]>
<dirbaio[m]> "beginner-friendly board 👍️" <- it’s warm-up training, to prepare people for all the bizarre diagrams, inscrutable acronyms and multiple thousand-page PDFs they’re going to need to wade through to do any useful embedded programming 🙃
<AdamHott[m]>
There's a lot of matching things up I've noticed, this equals that on the other diagram, etc.
<JamesMunns[m]>
It doesn't HAVE to be like that, but sadly it is in practice fairly often.
<AdamHott[m]>
This voltmeter that arrived today and all your help saved the day!
SzczepanCielik[m has quit [Quit: Idle timeout reached: 172800s]
samkent has quit [Ping timeout: 264 seconds]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
WSalmon has quit [Read error: Connection reset by peer]
WSalmon_ has joined #rust-embedded
StephenD[m] has quit [Quit: Idle timeout reached: 172800s]
<K900>
Update to Rust 1.75, it should allow async fn in traits by default
<holo[m]>
hello K900 ⚡️ i was talking yesterday with you (among others) when i was setting up NixOS and you told me on NixOS channel that Nix is not supproting newest version any other workaround for this problem? Or maybe is some option to use newest rust on NixOS?
<K900>
Maybe give it a few days then
<K900>
We should have 1.75 in maybe a week or so
<K900>
Probably earlier if all goes right
<dirbaio[m]>
you can't use rustup on nixos?
<K900>
You can but it's a little wonky
<K900>
NixOS-packaged Rust is generally a safer bet especially for newcomers
<dirbaio[m]>
not if you can't use it at all because it's not yet available 🤣
<dirbaio[m]>
and if you want to use nightly how do you do it?
<holo[m]>
K900: Oh no, i was so happy i finally successfully created flake with direnv and it started to work, will try to switch to this fenix in that case
<K900>
You could include Fenix in your current flake
<K900>
But the setup for that is a little more involved
eZioPan[m] has joined #rust-embedded
<eZioPan[m]>
"Fe-nix, fresh iron without rust on it" right?🤣
<K900>
And is probably better discussed in #nix:nixos.org or #rust:nixos.org
<K900>
So we don't accidentally curse this channel
esden[cis] has quit [Quit: Idle timeout reached: 172800s]
Guest63 has quit [Quit: Client closed]
notgull has joined #rust-embedded
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 268 seconds]
notgull has joined #rust-embedded
fooker has quit [Quit: WeeChat 3.8]
fooker has joined #rust-embedded
<holo[m]>
ok i finally have newest version of rust and i started to test examples from embasy-rs project for pico W wifi and blinking is compiling and working. I wanted to start with I2C bus (becasue i have SCD41 sensor to play with) but im getting such runtime error after compiling this example:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/imAViHLvUyQkJZjrrVMnyeyw>)
<holo[m]>
* ok i finally have newest version of rust and i started to test examples from embasy-rs project for pico W. Wifi and blinking example are compiling and working. I wanted to start with I2C bus (becasue i have SCD41 sensor to play with) but im getting such runtime error after compiling this example:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LADSIyIpnWbvIkwOvFYlPCvG>)