<re_irc>
<@nihal.pasham:matrix.org> reaching out to the broader community in case anyone has come across a similar issue - https://matrix.to/#/!ilYBHdZNkWoALhBMSx:matrix.org/$cLKZB-Fkmlc-GbxcPyHI0xHtTjDRFBGy1KrpaYwTHcs?via=matrix.org&via=afofo.com&via=conduit.electromatic.us
<re_irc>
any inputs would be great..
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc>
<@hyahoos:matrix.org> I know this has been asked many times
<re_irc>
<@hyahoos:matrix.org> but im still wondering are we really not gnna add non-blocking traits to our IO? for example non-blocking I2c communication?
<re_irc>
<@jannic:matrix.org> There is embedded-hal-async. But I guess you are looking for non-blocking non-async traits?
<re_irc>
<@hyahoos:matrix.org> ya
<re_irc>
<@hyahoos:matrix.org> that
<re_irc>
<@jannic:matrix.org> I'm not completely sure but my impression is that most people working on embedded-hal are preferring async when they need non-blocking. So there's just nobody left caring much about embedded-hal-nb.
<re_irc>
<@jannic:matrix.org> It's unfortunate that many interesting async features still need nightly rust.
<re_irc>
<@hyahoos:matrix.org> yeah I just realized I could instead try to do embassy-hals and do async and stuff like that to get no-blocking behaviour
lehmrob has joined #rust-embedded
<re_irc>
<@9names:matrix.org> : could you summarise the issue here first? it's quite the ask to get folks to join a new channel and read a paragraph of prose to find out what your issue is and if they have relevant experience that could help you.
<re_irc>
<@9names:matrix.org> it's especially opaque since matrix doesn't even tell you which room you're linking to, so there's zero context for your request
markov_twain has joined #rust-embedded
<re_irc>
<@nihal.pasham:matrix.org> ah ok
<re_irc>
<@nihal.pasham:matrix.org> I've been working on adding Rust support for the i.MX 8M nano and managed to get the board up and running along with a working uart driver - code here (https://github.com/nihalpasham/rustBoot/tree/main/boards/bootloaders). The next step in my plan is to add a uSDHC driver for the nano. Here's a link to the initial implementation...
<re_irc>
The sequence of steps I used are as follows
<re_irc>
- enable the usdhc2 clocks via the ccm peripheral,
<re_irc>
- set mux state for the uSDHC2 peripheral via the iomuxc peripheral
<re_irc>
So far, steps 1 and 2 seem to work (I think)
<re_irc>
- initialize uSDHC driver and send a couple of commands to verify we have a working driver
<re_irc>
Here's the debug log output. From what I gather by looking at the contents of the uSDHC's _interrupt status_ field (i.e. a value of 0x00048001), the command (i.e. SEND_IF_CMD) was successfully sent and a response was received, however the response returned contains an error - *command end bit error*. Not entirely sure why this is happening.
<re_irc>
Also the _present status_ register has the SDOFF bit set (SD clock gated off internally). Again not sure why this is happening. The reference manual doesn't provide more information about these bits or the errors.
<re_irc>
Any inputs would be greatly appreciated. Please let me know if more information is required.
<re_irc>
<@nihal.pasham:matrix.org> ah ok, didn't know that. assumed matrix just works if its an internal channel, guess not
<re_irc>
<@nihal.pasham:matrix.org> ah ok, didn't know that. assumed matrix just works if its another matrix channel, guess not
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
lehmrob has quit [Ping timeout: 248 seconds]
lehmrob has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
<re_irc>
<@thejpster:matrix.org> Do you have a working C example to crib from? I'm not sure many folks here have done much Cortex-A, never mind iMX8
<re_irc>
<@ryan-summers:matrix.org> Is there a crate for mocking embedded-hal devices for purposes of demonstrating usage of a driver in rust-doc?
<re_irc>
<@ryan-summers:matrix.org> embedded-hal-mock exists, but it looks like it's more geared towards unit testing of drivers (i.e. you have to provide expected SPI transactions etc.)
<re_irc>
<@jamesmunns:beeper.com> Not that I'm aware, but you totally could just do a quick impl that returns Ok() for everything
<re_irc>
<@ryan-summers:matrix.org> I just want a dummy module that doesn't do anything, but impls the traits
<re_irc>
<@ryan-summers:matrix.org> Yeah was hoping to avoid the boilerplate, but it's not too bad tbh
<re_irc>
<@ryan-summers:matrix.org> I only need SPI and CS
<re_irc>
<@jamesmunns:beeper.com> with R-A you can write "impl Trait for FakeType { }" then do an "implement missing members" autofill
<re_irc>
<@jamesmunns:beeper.com> which will give you "todo!()"s in everything
<re_irc>
<@ryan-summers:matrix.org> Oh nice, I'll get that a shot then
<re_irc>
<@jamesmunns:beeper.com> : Do they have an SDCard example? I think that was what JP was getting at
<re_irc>
<@jamesmunns:beeper.com> like, "look at what the C code does to make sure you haven't missed any setup steps"
<re_irc>
<@nihal.pasham:matrix.org> yeah, I've cross-checked my impl with that of uboot and others. Their impls are similar if not exactly the same (at least as far the sd-card initialisation routine).
<re_irc>
to cross-check, I compiled uboot (and the corresponding device-tree) for the i.mx8 board. It works as expected but somehow fails when I use my impl and apply the same settings
<re_irc>
<@nihal.pasham:matrix.org> For more context from the other thread:
<re_irc>
I used the (exact) same "pad ctrl" settings as the ones from the linux device tree in "imx8mn.dtsi" and I am now able to detect and report if an sd-card is inserted. But I still cant figure out what's causing the command error (i.e. CEBE bit error).
<re_irc>
[ 71.987092] imx8mn-rs version 0.1.0
<re_irc>
[ 71.994481] Current privilege level: EL3
<re_irc>
[ 71.990506] Booting on: i.MX 8M Nano EVK
<re_irc>
On a side note, I noticed that one of the pins in the device tree is referenced as uSDHC2's voltage regulator (i.e. pad "iomuxc_sw_mux_ctl_pad_sd2_reset_b") but its pinmux configuration uses a mux mode that doesn't make sense. The device-tree contains a mux mode of 0x5 for this pin instead of a 0. Would anyone know why?
<re_irc>
When I set the pin’s mux-mode to 0x5 the "usdh controller" simply times out i.e. it doesn’t even detect the card.
<re_irc>
*Device tree source for the usdhc2’s voltage regular:*
<re_irc>
<@nihal.pasham:matrix.org> * _For more context from the other thread:_
<re_irc>
<@thejpster:matrix.org> Sorry, I don't know anything about the iMX8.
bjc has joined #rust-embedded
bjc has quit [Read error: Connection reset by peer]
bjc has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
jr-oss has quit [Ping timeout: 265 seconds]
jr-oss has joined #rust-embedded
markov_twain has quit [Read error: Connection reset by peer]
DepthDeluxe has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
markov_twain has joined #rust-embedded
dc740 has joined #rust-embedded
rardiol has joined #rust-embedded
bjc has quit [Quit: ¡?!]
lehmrob has quit [Ping timeout: 260 seconds]
DepthDeluxe has quit [Ping timeout: 260 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> Hi! What is y'alls take on maintaining a system time uptime count / timestamp? From what I've seen in C, a cortex-m interrupt tick is common. This seems to be a bit awk as it's bothering the CPU frequently. Alternatives include a dedicated RTC peripheral, and hardware timers. Obviously if you want accurate time and dates over long periods, RTC w/dedicated Xtal is the way to go. For generating CAN network timestamps...
<re_irc>
... etc, this is what I've set up. I'm posting to see what y'all think vice alternatives, and why the Systick approach is so common in OSS c code bases:
<re_irc>
// We use a hardware counter to measure relative system time. This is the number of times
<re_irc>
// it has overflowed. (timer expired)
<re_irc>
/// Example use, to get seconds since start: `tick_count_fm_overflows_s() +
<re_irc>
TICK_OVERFLOW_COUNT.load(Ordering::Acquire) as f32 * TICK_TIMER_PERIOD
<re_irc>
}
<re_irc>
<@firefrommoonlight:matrix.org> Basically, at a low frequency (in this case, 2 Hz), the overflow count interrupt fires, incrementing a counter; then it's just a matter of reading the counter, and reading the timer current value. Interrupt, which runs much slower than a systick would:
<re_irc>
<@firefrommoonlight:matrix.org> Basically, at a low frequency (in this case, 2 Hz), the overflow count interrupt fires, incrementing a counter; then it's just a matter of reading the counter, and reading the timer current value. Interrupt, which runs much slower than a systick would: