<re_irc>
<@willeml:matrix.org> that seems to cause it to fail
<re_irc>
<@mriise:matrix.org> After some more digging I came across the new LPC552x that seems to have a good balance of processing power efficiency along with integrated USB-HS PHY
<re_irc>
<@mriise:matrix.org> haven't come across a HAL crate for it yet though...
<re_irc>
<@willeml:matrix.org> willeml: Nevermind, it seems to fail at `let mut peripherals = Peripherals::take().unwrap();`
<re_irc>
<@willeml:matrix.org> Which is annoying because I kind of need the peripherals to do anything with QSPI...
tokomak has quit [Ping timeout: 255 seconds]
<Lumpio->
willeml: Does this initialize RAM at any point..? The take call uses a global variable for one
<Lumpio->
I.e. data and bss
<re_irc>
<@willeml:matrix.org> It does not initialize ram, how would I do that?
<re_irc>
<@willeml:matrix.org> And would I need to initialize the mpu as well?
<re_irc>
<@willeml:matrix.org> (at least, it does not initialize ram that I know of)
<Lumpio->
It's intricate to do it safely in Rust. Maybe check out the r0 crate. I think they did it in assembly.
dcz has joined #rust-embedded
<re_irc>
<@willeml:matrix.org> Also, why would I need to initialize ram when writing a flash algo but not when writing normal apps?
<Lumpio->
Because you're probably using a crate that does it for you normally like cortex-m-rt
<Lumpio->
But this isn't a normal application, it doesn't start from the reset vector for one
<Lumpio->
Hmm data might get uploaded when this is uploaded to RAM but I wonder if you still have to zero bss
<re_irc>
<@willeml:matrix.org> How do I write to BSS?
<re_irc>
<@disasm-ewg:matrix.org> @irc_libera_dcz_:psion.agg.io: Unfortunately, I don't have enough time at the moment and it seems that no one else maintains this crate... But if your changes are quite simple I'll try to review if you ping me
<re_irc>
<@disasm-ewg:matrix.org> Also feel free to join #gd32v-rust:matrix.org
<re_irc>
<@9names:matrix.org> mriise: lpc55 series looks nice. I liked the lpc43 family too, but the price + lack of community was an obstacle.
<re_irc>
<@9names:matrix.org> Lpc55 gets bonus points for not being unobtanium.
<re_irc>
<@ryan-summers:matrix.org> Note that there are some unsoundness / UB concerns about initializing data regions in Rust
<re_irc>
<@willeml:matrix.org> What kind of UB could I expect/what are the risks? And how would I fix this without doing this?
<re_irc>
<@ryan-summers:matrix.org> Risks are _most likely_ none
<re_irc>
<@ryan-summers:matrix.org> Let me find the issue
<re_irc>
<@ryan-summers:matrix.org> jamesmunns: Do you remember which issue was talking about the UB for zeroing BSS/data init in Rust? I can't seem to find it
<re_irc>
<@tiwalun:matrix.org> willeml: probe-rs will perform the necessary initialisation for the flash loader, so you shouldn't have to manually manage bss or similar. It will copy the flash loader functions to RAM, and initialize the other memory as well.
<re_irc>
<@tiwalun:matrix.org> It's different from normal code in that sense, because the flash loader functions are called directly using the debugger.
<re_irc>
<@tiwalun:matrix.org> And I think you cannot use `Peripherals::take`, because no static variables are initialized.
<re_irc>
<@willeml:matrix.org> So how would I go about accessing peripherals?
<re_irc>
<@willeml:matrix.org> Is there another way to access them? Or a way of initializing static variables?
<re_irc>
<@ryan-summers:matrix.org> I would imagine direct pointer instantiation, or isntantiating peripherals manually on the stack?
<re_irc>
<@tiwalun:matrix.org> I used this in my flash loader: `let spi = unsafe { &(*QSPI0::ptr()) };`
<re_irc>
<@ryan-summers:matrix.org> I don't think there's any reason that Peripherals has to be static honestly? Or is it a sealed struct type in the HAL
<re_irc>
<@willeml:matrix.org> ryan-summers: Right now its a struct in the hal afaik
<re_irc>
<@willeml:matrix.org> tiwalun: I will try that
<re_irc>
<@willeml:matrix.org> (it does not want a reference)
<re_irc>
<@willeml:matrix.org> Oh, I don't need to constrain it seems?
<re_irc>
<@willeml:matrix.org> How do I use the hal traits on the ptr?
<re_irc>
<@willeml:matrix.org> * how do I turn the register block type into the peripheral type
<re_irc>
<@willeml:matrix.org> (if thats even possible)
<re_irc>
<@ryan-summers:matrix.org> The HAL traits typically can't be used on the raw register blocks
<re_irc>
<@ryan-summers:matrix.org> They're from the PAC layer
<re_irc>
<@willeml:matrix.org> Should have posted, but I decided to just reimplement the entire QSPI driver
<re_irc>
<@willeml:matrix.org> (well, only the needed parts)
<re_irc>
<@ryan-summers:matrix.org> Yeah, that's what I'd imagine you'd need to do as well
<re_irc>
<@willeml:matrix.org> Well, it no longer gives an error, it says "success" but it does not actually write anything...
<re_irc>
<@9names:matrix.org> There's not much in the API for communicating errors. I got mine going by implementing it as a standalone app so I could attach the debugger, and making calls to the flash API funcs from main, use RTT, etc
<re_irc>
<@willeml:matrix.org> Do you have any examples of that?
<re_irc>
<@9names:matrix.org> I don't have anything I can share at the moment, I never put that part on GitHub :(
<re_irc>
<@willeml:matrix.org> :( guess I will try to figure it out tomorrow, at least the flash algo functions are only 480 bytes total...
neceve has joined #rust-embedded
fabic has quit [Ping timeout: 255 seconds]
fabic has joined #rust-embedded
neceve has quit [Ping timeout: 246 seconds]
fabic has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
tokomak has joined #rust-embedded
zBeeble42 has joined #rust-embedded
zBeeble has quit [Ping timeout: 255 seconds]
zBeeble42 has quit [Remote host closed the connection]
zBeeble42 has joined #rust-embedded
zBeeble42 has quit [Read error: Connection reset by peer]
zBeeble42 has joined #rust-embedded
richard has joined #rust-embedded
tafama has joined #rust-embedded
tafa has quit [*.net *.split]
richardeoin has quit [*.net *.split]
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
<re_irc>
<@metajack:matrix.org> Is there a way to delay for a single tick? I'm only seeing specific ms/us delay functions.
<agg>
cortex_m::asm::nop()
<agg>
is "at least a single tick"
<agg>
if you want to delay for like, 1000 ticks, check out cortex_m::asm::delay(1000), but that's "at least 1000 ticks" and might be more due to being interrupted or because your CPU is worse at branch prediction and/or multiple issue than the cortex-m it's benchmarked for
<re_irc>
<@metajack:matrix.org> it looks like hte C++ code I'm looking at for reference does
<re_irc>
<@metajack:matrix.org> {
<re_irc>
<@metajack:matrix.org> uint32_t now = GetTick();
<re_irc>
<@adamgreig:matrix.org> you can basically just call `cortex_m::asm::delay()`, then
<re_irc>
<@adamgreig:matrix.org> oh, hmm, it depends what GetTick does actually
<re_irc>
<@adamgreig:matrix.org> sorry, didn't read it properly
<re_irc>
<@adamgreig:matrix.org> is it reading SysTick?
<re_irc>
<@adamgreig:matrix.org> or CYCCNT or something?
<re_irc>
<@metajack:matrix.org> i assume SysTick CNT
<re_irc>
<@metajack:matrix.org> Maybe I should back up. I have two shift registers I'm trying to read. So the code basically sets clock high, latch low, delays 1 tick, then starts pumping the clock to read the data line.
<re_irc>
<@adamgreig:matrix.org> if it's delaying literally 1 tick then I'd just use cortex_m::asm::delay(5) or something rough like that
<re_irc>
<@adamgreig:matrix.org> well, it depends on how fast your systick is running
rjframe has joined #rust-embedded
<re_irc>
<@metajack:matrix.org> it looks like it delays whenever it touches the clock pin. is that specified by the shift register data sheet how long the delay must be?
<re_irc>
<@adamgreig:matrix.org> yea, I'd expect so
<re_irc>
<@adamgreig:matrix.org> you can implement a very similar thing directly if you want, using systick, like `let mut syst = cp.SYST; syst.set_reload(0xff_ffff); syst.clear_current(); syst.enable_counter(); while syst.get_current() < del {}`
<re_irc>
<@adamgreig:matrix.org> but it doesn't look like you really need to use systick at all here so it's probably easier not to
<re_irc>
<@adamgreig:matrix.org> check what the delay you actually need is, if it's already >=1µs then you could use delay_us(), if it's smaller then cortex_m::asm::delay() and calculate roughly how many core clock cycles you need to delay
<re_irc>
<@adamgreig:matrix.org> (e.g. if your core clock is 84MHz and you need to delay 30ns, each tick is 1/84MHz=12ns, so 3 ticks is enough, cortex_m::asm::delay(3))
<re_irc>
<@adamgreig:matrix.org> unhelpfully that datasheet doesn't even give timing numbers at 3v3 but presumably they're similar or worse than at 5v
<re_irc>
<@adamgreig:matrix.org> to get started try just using cortex_m::asm::delay(250) between each gpio operation, and see if it works, then start reducing them
<re_irc>
<@metajack:matrix.org> THe C++ talks about PClk. Which clock is that?
connorw has joined #rust-embedded
<re_irc>
<@metajack:matrix.org> I suppose it means the peripheral clock. Now I wonder what pclk1 gets set to if not expliticly initialized
<re_irc>
<@adamgreig:matrix.org> you can specify .pclk1() when building the clocks (rcc.....freeze()), the default is the fastest it's allowed up to hclk/2 iirc
mikehcox has joined #rust-embedded
<zBeeble42>
OK. Frustrating. In my continuing quest to get rust to bootstrap on a new type of system, I have installed the nightly build on my cross compile platform. When I run "rustc +nightly" ... it kicks back "error: couldn't read +nightly: No such file or directory (os error 2)"
<Lumpio->
Isn't the +channel thing for cargo
<Lumpio->
rustc is built separately for each channel
<agg>
yea, you either want "cargo +nightly ..." or use the specific nightly rustc you installed, wherever you installed it
fabic has quit [Ping timeout: 268 seconds]
<re_irc>
<@rahix:matrix.org> the +nightly part is added by the rustup wrapper, the actual rustc binary does not know such argument syntax
<re_irc>
<@rahix:matrix.org> so unless you're using rustup, you do not need to add it. If you want to use rustup, you can add your custom toolchain with `rustup toolchain link` iirc
tokomak has quit [Ping timeout: 255 seconds]
<zBeeble42>
OK. Getting through these instructions, I think you're not understanding what I'm trying to do. There is a board called the "HiFive Unmatched" ... riscv64 processor, 16 gig of ram, not necessarily embedded. I've got FreeBSD on it now and I'm trying to get a bootstrap copy of rust so that the "rust" port in freebsd will eventually build all by itself.
<zBeeble42>
there are instructions, vaguely, for doing this in several places, but they break down and don't work... seemingly not maintained.
<zBeeble42>
I need to bring up a rust toolchain on a new platform. To this end, I have a fully capable cross compile platform and a fully capable platform itself. The board is even self hosted at this point with clang and FreeBSD.
<zBeeble42>
can someone point me to the manner of creating and ... it would be really nice ... packaging a rust booststrap.
mikehcox has quit [Quit: Client closed]
<re_irc>
<@xnorman:matrix.org> metajack: I used 166ns delay between each clock, seems to be working well:
<re_irc>
<@jpc:ejpcmac.net> Hello! How would you do to expose time units in an embedded library interface in a way it can be ported accross HALs?
<re_irc>
<@jpc:ejpcmac.net> I need to express `Hertz`, `Second` and `Millisecond` the same way `stm32l4xx-hal` does for instance, but I don’t want to depend on its types to be portable.
<re_irc>
<@jpc:ejpcmac.net> So currently I am re-defining those myself, but I cannot have the U32Ext for both in the same scope.
<cyrozap>
zBeeble42: This channel, "rust-embedded", primarily concerns itself with embedded systems (e.g., microcontrollers running an RTOS or no OS at all). What it sounds like you're looking to do is bootstrap Rust on a platform with a normal OS, so that's somewhat outside of what this channel focuses on, I think. That said, have you tried the mrustc->rustc build route? i.e., build
<cyrozap>
https://github.com/thepowersgang/mrustc with a C compiler, then use mrustc to compile some old version of Rust, then use that older Rust to build a newer rust, and then repeat that process, building newer and newer versions of Rust until you get to the latest version.
<re_irc>
<@jpc:ejpcmac.net> burrbull: Oh, excellent! I think I’ll go for this one to at least build on something that could be a common point between libs.
creich has quit [Client Quit]
richard is now known as richardeoin
<zBeeble42>
the people in ##rust told me to ask in #rust-embedded ... I assume because the expertise was not present there...
<re_irc>
<@ubik:matrix.org> has anyone ever ventured into LoRa with Rust?
<re_irc>
<@dirbaio:matrix.org> the drogue iot project has done lots of lora stuff
<re_irc>
<@ubik:matrix.org> i got a LoRa-E5 devboard from Seeed to play with and was wondering if I can avoid writing C
<re_irc>
<@ubik:matrix.org> but drogue doesn't use embedded-hal, right?
<dcz_>
meta-question: who's in charge of the Matrix bridge? the messages come all from a single account on IRC, and it's rather hard to see who's speaking. Why not use the same bridge as on ##rust?
<re_irc>
<@ryan-summers:matrix.org> That's a question for adamgreig I believe
<re_irc>
<@therealprof:matrix.org> ub|k: LoRa pretty much still means Semtech. There's a number of crates around supporting those chips, check crates.io for "sx12".
<re_irc>
<@therealprof:matrix.org> Can't vouch for any of them though, most of my LoRa stuff is rotting at the bottom of my shame bin.
<agg>
dcz_: basically a) can't add ircservices bridge when matrix room is >100 users without matrix.org admin doing it and they never got back to me about it b) need to be an op on irc side but irc side isn't registered because it's in the #rust namespace and someone from the rust core team and/or foundation needs to register with libera and delegate that channel to us and they also haven't got back to me
<agg>
and c) the ircservices bridge kicks idle matrix users from the matrix room which was very annoying and rude for our majority-matrix userbase (and that can't be disabled) while this type of bridge doesn't
<agg>
my appetite for chasing matrix.org and rust core team members has dropped significantly since getting this version of the bridge working it has to be said
<dcz_>
sounds reasonable, yet sad at the same time
<agg>
indeed
<agg>
another victim of freenode exploding, we did previously use the ircservices bridge from freenode
<agg>
at that time (2018?) both matrix and rust were smaller so it was somewhat easier to sort out..
<re_irc>
<@ubik:matrix.org> therealprof: Thanks! It's actually an STM32WL, so I don't think those apply. I found [this](https://github.com/newAM/stm32wl-hal) but it's still quite incomplete, it seems.
<re_irc>
<@ubik:matrix.org> eldruin: Thanks! I guess he's using separate radio modules. I'd like to program the LoRa-E5 directly
dcz_ has quit [Ping timeout: 245 seconds]
rjframe has quit [Remote host closed the connection]
rjframe has joined #rust-embedded
rjframe has quit [Ping timeout: 258 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> newam is working on LoRa
<re_irc>
<@firefrommoonlight:matrix.org> Via stm32WL
rjframe has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> ub|k: "STM32WL microcontrollers feature a sub-GHz radio based-on Semtech SX126x..."
zBeeble42 has quit [Remote host closed the connection]
zBeeble has joined #rust-embedded
rjframe has quit [Remote host closed the connection]