<re_irc>
<@jamesmunns:beeper.com> and 1.0.6, which when the docs-rs queue finally clears, now shows fancy feature annotations on the docs
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
crabbedhaloablut has quit []
starblue3 has quit [Ping timeout: 245 seconds]
starblue3 has joined #rust-embedded
duderonomy has joined #rust-embedded
_whitelogger has joined #rust-embedded
<re_irc>
<@lavanya10010010:matrix.org> : Just out of curiosity, if I were to keep this as it is, how should I go about writing the 'else' block?
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@guenther_rostig:matrix.org> Sorry for not joyning yesterdays weekly. I hope having time next Tuesday.
<re_irc>
<@guenther_rostig:matrix.org> Project with the MSP432E401Y: There is no ethernet stuff in the TM4C HAL. I've dowloaded the svd-file and created a PAC with svd2rust. In combination with the cortex-m HAL I could create the missing parts. But before that I should take a look at the STM32 smoltcp example and at the crate for the XMC4500 (https://docs.rs/xmc4500/0.1.0/xmc4500/eth0_con/). I found a XMC4500 launchpad at home.
<re_irc>
<@diondokter:matrix.org> : Pretty much the same as what I wrote in the new else block
Dr_Who has quit [Read error: Connection reset by peer]
<re_irc>
<@guenther_rostig:matrix.org> Project with the MSP432E401Y: There is no ethernet stuff in the TM4C HAL. I've dowloaded the svd-file and created a PAC with svd2rust. In combination with the cortex-m HAL I could create the missing parts. But before that I should take a look at the STM32 smoltcp example and at the crate for the [XMC4500](https://docs.rs/xmc4500/0.1.0/xmc4500/eth0_con/). I found a XMC4500 launchpad at home.
<re_irc>
<@dirbaio:matrix.org> even though it's HAL team's
<re_irc>
<@sourcebox:matrix.org> Does Rust requires some special calls in the startup code? I'm talking about something like "__libc_init_array" for C.
<re_irc>
<@sourcebox:matrix.org> * require
<re_irc>
<@dirbaio:matrix.org> no, Rust has no static initializers unlike c/c++
<re_irc>
<@dirbaio:matrix.org> it just needs initializing .data and zerofilling .bss
<re_irc>
<@sourcebox:matrix.org> Ok, I just wanted to prove it ;-)
<re_irc>
<@sourcebox:matrix.org> Is there something that speaks against using startup code and linker script from C/C++ projects? The intention behind this is to be able to mix in C/C++ code and that requires some additional stuff.
<re_irc>
<@dirbaio:matrix.org> yeah, linking Rust code into a C/C++ project using C/C++ startup scripts should Just Work
<re_irc>
<@dirbaio:matrix.org> while linking C/C++ code into a Rust project that uses the cortex-m-rt startup scripts can break if the C/C++ code relies on static initializers
<re_irc>
<@sourcebox:matrix.org> Yes, that's exactly the reason why I want to use custom startup code.
<re_irc>
<@sourcebox:matrix.org> Also on the STM32MP1, I have to deal with fragmented memory. No flash, but the M4 starts into a 64k RETRAM.
<re_irc>
<@sourcebox:matrix.org> I think, the "__libc_init_array" call has to be in the linker script, but as weak call when no C code is linked.
<re_irc>
<@sourcebox:matrix.org> * startup code
<re_irc>
<@thejpster:matrix.org> I fixed my PSoC6
<re_irc>
<@thejpster:matrix.org> interrupts and RTIC working happily now on the Cortex-M4 core.
<re_irc>
<@thejpster:matrix.org> fun fact - just because a ROM bootloader jumps to your code in flash, doesn't mean it remembered to update VTOR to point at Flash.
<re_irc>
<@diondokter:matrix.org> : You remember that bootloader that you reviewed with me?
<re_irc>
Yeah, it missed setting the VTOR too :P
<re_irc>
<@thejpster:matrix.org> and the vector table in the ROM appears to be garbage, so you bounce off into the wilderness, which is a HardFault. Which has an invalid address. Cue second bounce.
<re_irc>
<@diondokter:matrix.org> Very easy to miss
<re_irc>
<@thejpster:matrix.org> : oh no
<re_irc>
<@thejpster:matrix.org> I hope you didn't put yours in mask ROM
<re_irc>
<@thejpster:matrix.org> Raspberry Pi also didn't do it, but they were able to update their 256 byte boot block to set it before the application proper ran.
<re_irc>
<@thejpster:matrix.org> (at my suggestion, iirc)
<re_irc>
<@diondokter:matrix.org> No, it's updatable. But things work because it boots to the SPM which doesn't use interrupts. And the SPM boots to our firmware and does set the VTOR
<re_irc>
<@diondokter:matrix.org> Very sneaky
<re_irc>
<@9names:matrix.org> why waste ROM space on a VTOR when you aren't going to use interrupts in your boot loader?
<re_irc>
<@thejpster:matrix.org> and maybe that's what Cypress were thinking here. You shouldn't be using interrupts in the boot code, so why not let the boot code set VTOR.
<re_irc>
<@9names:matrix.org> * vector table
<re_irc>
<@diondokter:matrix.org> You need the reset vector and initial stack pointer at least
<re_irc>
<@diondokter:matrix.org> I guess you could skip over all other vectors yeah haha
<re_irc>
<@9names:matrix.org> i mean, the infineon folks do on their M0 chips, but they have no VTOR so their hands are tied
<re_irc>
<@thejpster:matrix.org> I suspect that's what they did, hence why I bounced off to random addresses.
<re_irc>
<@thejpster:matrix.org> I was worried about that, but this is thankfully an M0+.
<re_irc>
<@thejpster:matrix.org> Really it deserves a whole number to itself. Shorter pipeline, better interrupt latency, VTOR support.
<re_irc>
<@9names:matrix.org> maybe they should have renamed m1 to m-1
<re_irc>
<@thejpster:matrix.org> The TI beagleboard x15 stuff had me stumped for a fortnight because I couldn't find the vector table in any of their code. It was two ".global" lines hidden at the top of a source file - one for reset and one for stack. They didn't specify any of the exception vectors and used that space for more code.
<re_irc>
<@thejpster:matrix.org> There is no Cortex-M2!
<re_irc>
<@jamesmunns:beeper.com> It's a shame M1 was already taken
<re_irc>
<@jamesmunns:beeper.com> yeah, I was going to ask :D
<re_irc>
<@jamesmunns:beeper.com> M1 is still hella rare, I think it's an IP/soft core only iirc?
<re_irc>
<@thejpster:matrix.org> yeah it's a soft core
<re_irc>
<@9names:matrix.org> it was the first. it does make sense, in a way
<re_irc>
<@jamesmunns:beeper.com> I know Arm usually does soft cores first, like all the -M2x and -M3x were available on fpga dev boards a while before the actual m23 and m33s came out
<re_irc>
<@jamesmunns:beeper.com> (I think I tried to request one once? but we ended up not moving forward with that customer so we let the request hang)
<re_irc>
<@9names:matrix.org> maybe i'm wrong about that. sick at the moment, brain is firing sideways. going to do some research.
<re_irc>
<@like2wise:matrix.org> Well ARM doesn't do hard cores, or do they?
<re_irc>
<@thejpster:matrix.org> Yes, that's the MPS2 board. I wrote neotron-qemu-bios to run on it. It has a big FPGA you load signed blobs into.
<re_irc>
<@like2wise:matrix.org> I mean, they provide the IP.
<re_irc>
<@jamesmunns:beeper.com> : not in volume. They do some test chips sometimes, but they are meant for validation/reference not production
<re_irc>
<@9names:matrix.org> yeah no, m3 came first. now i need to know why they started at 3...
<re_irc>
<@jamesmunns:beeper.com> but yeah, I dunno what the delta between their typical IP cores and "no really this ones just for fpgas"
<re_irc>
<@jamesmunns:beeper.com> probably M1 is optimized to be cheap to synthesize in fpga fabric, vs M0/+ which could be done on FPGA, but might need weird combos of SRAM/LUTs/gates/whatever that makes it take up more space on fabric, despite being small on silicon
<re_irc>
<@jamesmunns:beeper.com> I say "probably", I have no idea, that's just my best guess.
<re_irc>
<@blurred1984:matrix.org> Hi everyone, I`m trying to connect a gprs module to an arduino uno. It requires a serial connection for sending commands. My code works well in the usual arduino IDE but I can`t seem to find a way to do the same thing with rust. 😅
<re_irc>
<@jamesmunns:beeper.com> : I wanna say it had a different name, this one was only to be borrowed, not sold
<re_irc>
<@9names:matrix.org> : arduino-hal should be able to provide you with a UART driver that you can use.
<re_irc>
have you found a driver crate for your GPRS module or are you writing everything from scratch?
<re_irc>
<@jamesmunns:beeper.com> Musca board is what I was thinking of:
<re_irc>
> Register below if you’d like to be considered to receive a loaner board from Arm.
<re_irc>
:D
<re_irc>
<@blurred1984:matrix.org> : From scratch... could`nt find any crate
<re_irc>
<@2:0x2c.org> how do you debug embedded arm firmware? i'm trying "cargo embed" and "arm-none-eabi-gdb", but i have problems resetting the firmware
<re_irc>
<@thejpster:matrix.org> you debug embedded arm rust in the same way you debug embedded arm C.
<re_irc>
<@ryan-summers:matrix.org> What's providing your GDB stub? You may need something like "monitor reset" or something
<re_irc>
<@thejpster:matrix.org> (which is to say, often painfully, using poorly documented tools. Or you buy a fancy debugger like SEGGER's Oxide)
<re_irc>
<@ryan-summers:matrix.org> If it's JLink, the JLink probe is what exposes the ability to reset firmware
<re_irc>
<@thejpster:matrix.org> s/oxide/ozone. Close enough.
<re_irc>
<@ryan-summers:matrix.org> But also yeah, what thejpster said above. It's not any different than C. You can use probe-rs if your chip supports it to make it a lot easier
<re_irc>
<@ryan-summers:matrix.org> But I think you're using the MSP432, right?
<re_irc>
<@2:0x2c.org> as i wrote, i'm trying cargo embed, which provides a gdb server. it's just that it flakes out occasionally, and i don't know why
<re_irc>
<@ryan-summers:matrix.org> Or was that someone else
<re_irc>
<@thejpster:matrix.org> "monitor reset halt" is usually the magic for openocd. Then a single "stepi" to get the process started but not running.
<re_irc>
The cortex-m-quickstart repo has openocd scripts in it.
<re_irc>
<@2:0x2c.org> i know how to use openocd and gdb, but i figured maybe people are using cargo embed now
<re_irc>
<@ryan-summers:matrix.org> I find myself very rarely ever using gdb for Rust code nowadays
<re_irc>
<@ryan-summers:matrix.org> But I do use cargo-embed whenever I do need it
<re_irc>
<@thejpster:matrix.org> probe-rs is good at flashing. But I don't know if I'd use it for debugging because I don't know if I could tell if was I debugging probe-rs or my application. You need very very solid debug tools to not be second guessing yourself all the time.
<re_irc>
<@thejpster:matrix.org> (apologies if probe-rs people think their tool is very very solid at debugging - it's just a lack of experience on my part)
<re_irc>
<@ryan-summers:matrix.org> Tbh probe-rs is more stable than openocd in my opinion, but they're both very janky
<re_irc>
<@2:0x2c.org> During the execution of GDB an error was encountered:
<re_irc>
A timeout occured.
<re_irc>
<@thejpster:matrix.org> when I was paid to do embedded I happily paid money for a J-Link and I used the SEGGER tools.
<re_irc>
<@2:0x2c.org> :( probe-rs
<re_irc>
<@thejpster:matrix.org> A J-Link costs like one or two billable hours.
<re_irc>
<@ryan-summers:matrix.org> Yeah, I've used a JLink in the past and it was pretty smooth sailing. Never had to think much about it
<re_irc>
<@2:0x2c.org> no idea what is going on, no guidance in cargo embed --help
<re_irc>
<@ryan-summers:matrix.org> what debug probe are you using corecode?
<re_irc>
<@2:0x2c.org> i never got reliable results with jlink, because they do some shenanigans with caching. openocd works better for me
<re_irc>
<@ryan-summers:matrix.org> A timeout is usually caused by timeout in communications with the probe, and is often seen with things like the crappy STlink probes
<re_irc>
<@guenther_rostig:matrix.org> : That was me. I try to work with the probe-rs, but there only the MAP432P401R chip is supported at this time. BTW, this chip is not produced any more.
<re_irc>
<@2:0x2c.org> : it's an embedded jlink on a silabs devboard
<re_irc>
<@mabez:matrix.org> Most of the jank comes from jank probe drivers. jlink (unless your using segger tooling) is not a good probe for either openocd or probe-rs
<re_irc>
<@mabez:matrix.org> At least you can run cmsisdap fw on jlinks now, which should help with the jank factor
<re_irc>
<@9names:matrix.org> : the next release will has support for your chip. if you install the git version, you can use it right now.
<re_irc>
<@9names:matrix.org> also, AFAIK the chip is still being produced. TI has (unofficially) stated that there would be no _new_ members of this family, which is a very different situation
<re_irc>
<@guenther_rostig:matrix.org> The relax kit (from Infineon) also has an embedded J-link. But with zadig you can change your driver to an Win-USB.
<re_irc>
<@9names:matrix.org> changing the windows driver doesn't stop it from being a jlink firmware, and the firmware is the part that makes it hard to support for anyone who isn't segger or licensing their driver
<re_irc>
<@guenther_rostig:matrix.org> * Open JLinkConfig.xe, there zou can change the driver from Segger to WisUSB
<re_irc>
<@guenther_rostig:matrix.org> * JLinkConfig.exe, there you can change the driver from Segger to WinUSB
<re_irc>
<@steelph0enix:matrix.org> Hi, gotta question about storing PAC peripherals and "Sync" trait. We're writing an RTOS with BSP for SAMV71 MCU, and one of our design goals is to make the RTOS the main source of peripherals for the user - on paper, we want to have a Peripherals struct that would contain both Cortex-M and MCU peripherals (from PAC), and user should be able to take the peripherals from that struct on per-peripheral basis (with a guard,...
<re_irc>
... preventing him from taking a peripheral twice).
<re_irc>
<@steelph0enix:matrix.org> However, we can't just store the PAC peripherals as-is, because they contain raw pointers which are not technically thread-safe. So, the question is - if we can guarantee that our Peripherals implementation will be thread-safe (peripheral access will be done via mutex), can i just mark our struct with "Sync" and should it be enough to guarantee safety?
<re_irc>
<@steelph0enix:matrix.org> Or is there other way to implement that?
<re_irc>
<@steelph0enix:matrix.org> (also; do i assume correctly that taking a peripheral from PAC-generated Peripherals struct would move it, automatically marking it as "taken" so it should not be possible to take a single peripheral twice, or am i going to land in boilerplate hell by having to guard each peripheral manually, until "svd2rust" supports per-peripheral "take"?
<re_irc>
<@steelph0enix:matrix.org> as for the code, currently it looks like that, and "Peripherals" cannot auto-derive "Sync" as PAC peripherals don't do that. In every HAL implementation i could find, there's no examples that show how to actually store the peripherals anywhere, just how to use them in main, so i don't really know how to bite that issue
<re_irc>
<@steelph0enix:matrix.org> maybe there's a completely different way of solving that issue that i don't see yet?
<re_irc>
<@marmrt:matrix.org> The PAC already contains the core peripherals
<re_irc>
<@marmrt:matrix.org> I guess, there is no reason to not aqcuire the core peripherals from the cortex-m crate, but pretty much all code I've seen gets core peripherals from the pac
<re_irc>
<@steelph0enix:matrix.org> hm, i don't see all Cortex peripherals in PAC crate - for example, NVIC is missing there
<re_irc>
<@steelph0enix:matrix.org> and FPU
<re_irc>
<@steelph0enix:matrix.org> i think that's SAMV71 specific, probably SVD file ignores Cortex-M peripherals (they are not described in datasheet either, so that's not really suprising)
<re_irc>
<@steelph0enix:matrix.org> huh, they do exist in SVD, strange
<re_irc>
<@steelph0enix:matrix.org> aaaaaaah, that way, all rigth
<re_irc>
<@steelph0enix:matrix.org> i see now
<re_irc>
<@marmrt:matrix.org> should do the same as the cortex-m take you\re doing
<re_irc>
<@marmrt:matrix.org> * you're
<re_irc>
<@steelph0enix:matrix.org> ye, but that's just one import less, so it doesn't really matter much in context of my issue
<re_irc>
<@steelph0enix:matrix.org> but thanks for pointing that ou!
<re_irc>
<@steelph0enix:matrix.org> * out!
<re_irc>
<@thejpster:matrix.org> > taking a peripheral from PAC-generated Peripherals struct would move it
<re_irc>
Yes but it leaves a partial-struct, which can't itself be moved. So people usually do that in main, move out all the things they want into individual driver objects, and discard what remains. If you want to be able to move the Peripherals struct after taking something from it, you'll need to make a new one where each field is an Option<T>.
<re_irc>
<@steelph0enix:matrix.org> Moving the "Peripherals" struct itself is not required, single instance of this struct will be stored in "static" instance of our RTOS kernel
<re_irc>
<@steelph0enix:matrix.org> i just need to be able to move the peripherals out of it when needed
<re_irc>
<@steelph0enix:matrix.org> via our "Hal" structure, if that matters
<re_irc>
<@steelph0enix:matrix.org> +- most likely we'll have two "Peripherals" struct definitions, one for user-accessible peripherals, and second for those that are used by our kernel (like timers, or watchdog)
<re_irc>
<@steelph0enix:matrix.org> * internally (like timers, or watchdog), and inaccessible to the user
<re_irc>
<@steelph0enix:matrix.org> so the idea is that during initialization, well make the "general" "Peripherals" struct, take the peripherals that we'll internally use and put into "KernelPeripherals" structure of some kind, and the rest of peripherals should be accessible via the first structure
<re_irc>
<@steelph0enix:matrix.org> and then the user can take, for example "UART" from "Peripherals" and make a HAL instance of UART using that PAC peripheral
<re_irc>
<@steelph0enix:matrix.org> so, long story short - i guess that as long as our code can guarantee that access to "Peripherals" will be somehow guarded (we're currently supporting only single-core MCUs, so the guard will most likely be a simple critical section), i can implement "Sync" trait for it and it should all be valid, safe Rust code?
<re_irc>
<@thejpster:matrix.org> if it's a static, you have to use option as you can't have a partial-struct stored in a static. And you'll have to use UnsafeCell or some other cell for each field as static variables are immutable.
<re_irc>
<@steelph0enix:matrix.org> option for each peripheral, that is?
<re_irc>
<@thejpster:matrix.org> but if you're already controlling access, why store an Option<UART2> when you can store a boolean and unsafely construct a UART2 reference on-the-fly as required.
<re_irc>
<@thejpster:matrix.org> yes
<re_irc>
<@steelph0enix:matrix.org> : well, yeah, that's also a way - what i'm worrying about is that both "Option" and bool flag approach would require me to write this boilerplate for every peripheral in PAC crate, is that correct?
<re_irc>
<@steelph0enix:matrix.org> i know i can probably use a macro to generate that code for me, my primary issue is that i'd like to be able to switch PAC crates in the future, and if i understand it correctly, this approach would require me (or someone who'll support that in the future) to write boilerplate like that for every supported PAC crate/
<re_irc>
<@steelph0enix:matrix.org> * crate?
Dr_Who has joined #rust-embedded
<re_irc>
<@steelph0enix:matrix.org> TBH since we'll have to implement HAL libs for each peripheral, we won't really avoid that boilerplate, so maybe it's not a bad option after all...
<re_irc>
<@steelph0enix:matrix.org> (pun not intended)
<re_irc>
<@marmrt:matrix.org> I don't really understand what you're doing here. It is already not possible to (safely) generate more than one copy of each peripheral in a pac.
<re_irc>
<@marmrt:matrix.org> It sounds like you're reinventing the wheel here
<re_irc>
<@steelph0enix:matrix.org> that's a possibility, yes
<re_irc>
<@lambdafriend:matrix.org> My POC for ADC reads using DMA and circular mode is working! The last bit ended up being "preselecting" the ADC channel, which was being done in the single channel case, but that line wasn't moved over to the new circular mode function.
<re_irc>
Now it's time to reset git and work on a cleaner implementation. Onwards and upwards! 🙌
<re_irc>
<@ryan-summers:matrix.org> Stabilizer actually has a sample of autonomously collecting N ADC samples using DMA before interrupt, using an external ADC controlled via SPI if that's something you're interested in
<re_irc>
<@ryan-summers:matrix.org> : What module are you using? You never listed a part number that I can see - also, definitely use the arduino-hal as mentioned to avoid implementing another UART :)
<re_irc>
<@lambdafriend:matrix.org> * issue
<re_irc>
<@blurred1984:matrix.org> : It's SIM800c ,basically my question is if there is an equivalent for SoftwareSerial lib in rust. which takes in two digital pins (tx,rx) and uses them to send and recive bytes (AT command, and response).
<re_irc>
<@dirbaio:matrix.org> : the HAL for your chip should have an UART implementation
<re_irc>
<@dirbaio:matrix.org> which chip are you using?
<re_irc>
<@dirbaio:matrix.org> +microcontroller
<re_irc>
<@dirbaio:matrix.org> or which arduino board?
<re_irc>
<@blurred1984:matrix.org> Arduino uno r3
<re_irc>
<@dirbaio:matrix.org> > Arduino UNO is a microcontroller board based on the ATmega328P
<re_irc>
<@dirbaio:matrix.org> +for how to do serial
<re_irc>
<@dirbaio:matrix.org> or you want the Rust equivlaent of SoftwareSerial specifically? like, using uart on pins where the hardware can't normally do uart?
<re_irc>
<@blurred1984:matrix.org> : Yeah I been using this crateq but the example only shows how to use the default usart not another pins
<re_irc>
<@blurred1984:matrix.org> : Yep
<re_irc>
<@dirbaio:matrix.org> ahh
<re_irc>
<@blurred1984:matrix.org> : Thank you I'll check it out
<re_irc>
<@dirbaio:matrix.org> it uses bitbanging with raw GPIO and a timer
<re_irc>
<@dirbaio:matrix.org> that example is for the stm32f1, but since it uses the "embedded-hal" traits for gpio and timers you should be able to use it with "avr-hal" too
<re_irc>
<@blurred1984:matrix.org> I've looked at it too, just had a bit of a hard time implementing the timer in arduino.
<re_irc>
<@dirbaio:matrix.org> for the timer, it needs something implementing "CountDown + Periodic"
<re_irc>
<@vollbrecht:matrix.org> the typical atmega328p programmer is one that loves to only work directly on the register level, so best to open the datasheet and flip that bits accordingly ;)
<re_irc>
<@blurred1984:matrix.org> : 🥲
<re_irc>
<@blurred1984:matrix.org> : Ok I'll look at it thank you😇
<re_irc>
<@thejpster:matrix.org> question - why does build.rs copy memory.x from "." to "${OUT_DIR}" when the linker just finds it in "." anyway?
<re_irc>
<@thejpster:matrix.org> Was very confused for 10 minutes copying a file called memory2.x over to ${OUT_DIR}/memory.x in my build.rs, but none of the changes having any effect. Because the linker found ./memory.x and used that.
<re_irc>
<@dirbaio:matrix.org> I think that doesn't always work, maybe in cargo workspaces or if you run the build from another working directory with --manifest-path
<re_irc>
<@dirbaio:matrix.org> strange that "." gets more precedence, that seems like a fun footgun
<re_irc>
<@thejpster:matrix.org> it certainly threw me for a loop
<re_irc>
<@sourcebox:matrix.org> Since I now have 2 different build targets in my workspace, I'm running also into some issues where RA gets confused.
<re_irc>
<@sourcebox:matrix.org> What's currently missing is a way to set different build targets for workspace members because their "cargo/config.toml" isn't evaluated from the workspace root.
<re_irc>
<@thejpster:matrix.org> i avoid this by not putting them in the same workspace
<re_irc>
<@thejpster:matrix.org> lots of things are harmonised in a workspace that you might not want harmonised when targeting different systems
emerent has quit [Ping timeout: 246 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<re_irc>
<@robgal519:matrix.org> Hi, I have a quick question.
<re_irc>
I want to create two applications, one for embedded device, and second for PC that will be talking with the embedded device.
<re_irc>
How should I organize the code? I should make two separate repositories, or create two cargo workspaces, one for embedded part, and one for PC part ?
<re_irc>
Those two applications will not have a lot of code in common, maybe a few structures for communicating, but overall they will be independent.
<re_irc>
On the other hand, the PC part does not make sense on its own without the embedded device (PC part is just a user interface for the device I want to make)
<re_irc>
So should I keep those applications together, or treat them as two separate projects ?
<re_irc>
<@ryan-summers:matrix.org> I'd treat them as two separate projects
<re_irc>
<@ryan-summers:matrix.org> Since you'd have two different target platforms in this case
<re_irc>
<@ryan-summers:matrix.org> And I avoid workspaces like the plague for embedded
<re_irc>
<@ryan-summers:matrix.org> As above noted - it harmonizes things you generally don't want harmonized
<re_irc>
<@robgal519:matrix.org> Thank you for the help
<re_irc>
<@thejpster:matrix.org> > So should I keep those applications together, or treat them as two separate projects ?
<re_irc>
I have three repos: neotron-pico-bios (a binary), neotron-os (a second binary booted by the BIOS) and neotron-common-bios (a library they share containing types and functions so they can talk to each other)
<re_irc>
<@thejpster:matrix.org> You could equally have three folders in one repo if you like, but I prefer to upversion and tag each one separately. It's easy enough to point cargo at either a folder (like "../neotron-common-bios") or a git repo, or a version, depending on how far along you are with any given set of changes.
joaj has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> Honestly, the workspace issues have to be solved at some point. It's not that they are really that complicated.
<re_irc>
<@sourcebox:matrix.org> They different targets already go into separate sub directories in the build, so no interference here.
<re_irc>
<@sourcebox:matrix.org> And in many cases, you have to deal with at least 2 targets anyway: the embedded one and the tests running on the host.
<re_irc>
<@dirbaio:matrix.org> my recommendation is separate Cargo projects (no workspace), but single repo
<re_irc>
<@dirbaio:matrix.org> you can share crates with path deps, no need for git dep spaghetti
<re_irc>
<@dirbaio:matrix.org> a single commit can make changes across several crates, no need to coordinate commits/merges across repos
<re_irc>
<@dirbaio:matrix.org> you can write multiple ".code-workspace" files, one for each "area"
<re_irc>
<@dirbaio:matrix.org> with the right rust-analyzer settings (target, linkedProjects, etc)
<re_irc>
<@dirbaio:matrix.org> and open them in separate vscode windows at the same time, even
<re_irc>
<@dirbaio:matrix.org> you can write multiple ".code-workspace" files, one for each "area" of the repo
<re_irc>
<@sourcebox:matrix.org> Whats basically needed is some section like "[workspace.members.<crate_name>]" where you can specify some properties.
WSalmon_ has quit [Remote host closed the connection]
WSalmon has joined #rust-embedded
<re_irc>
<@azzentys:matrix.org> Curious. STM32 seems to have a HAL and PAC offered by stm32-rs. We also have https://github.com/David-OConnor/stm32-hal. I was wondering what was the motivation behind both of them. If someone has to use either, why would they choose one and not choose the other? Embassy also has embassy-stm32 which builds from stm32-metapac. What was their motivation on doing such?
<re_irc>
Just curious, not questioning choices but trying to understand.
<re_irc>
<@adamgreig:matrix.org> different people doing different things, mostly. the stm32-rs hals generally support one family of chips per hal, so started stm32-hal2 to try and support multiple families in one hal for his products, and separately embassy needs async HALs, so embassy-stm32 adds async support, and to try and build that over multiple families with fewer differences between them they have stm32-metapac that makes it easier to write...
<re_irc>
... embassy-stm32 to support lots of families in one crate
<re_irc>
<@adamgreig:matrix.org> if you're using embassy or rtic2 with async, embassy-stm32 is probably a good shout, if you're not using async then I think the stm32-rs hals are popular but you can also use embassy-stm32 by itself (though it's not published on crates.io yet, you'd have to use a git dependency)
<re_irc>
<@adamgreig:matrix.org> (I help maintain the stm32-rs pacs but don't really get involved in the hals)
<re_irc>
<@azzentys:matrix.org> Thanks a lot for this summary!
<re_irc>
<@dirbaio:matrix.org> : can you check the permissions for the "nb" repo? I can't change the branch settings
<re_irc>
<@adamgreig:matrix.org> Ah yep sorry will do
<re_irc>
<@adamgreig:matrix.org> Just suspended my pc for dinner time though, gimme a min :p
<re_irc>
<@adamgreig:matrix.org> : done
pbsds has quit [Ping timeout: 252 seconds]
pbsds has joined #rust-embedded
kenny1 has quit [Quit: WeeChat 4.0.2]
kenny has joined #rust-embedded
<re_irc>
<@shakencodes:matrix.org> I updated my rust toolchain to a new version of nightly (rustup toolchain install nightly-2023-06-01), and have previously installed a target for cross-compilation (rustup target add thumbv7em-none-eabi). Now when I build, I am getting an error "note: the "thumbv7em-none-eabi" target may not be installed"
<re_irc>
It appears that only the native compiler has been pulled up to the requested nightly compiler, but the cross-compiler has not. What am I missing?
joaj has quit [Quit: WeeChat 4.0.2]
<re_irc>
<@shakencodes:matrix.org> Wait... if I do "cargo build" in one of the cross-compiled directories, it updates the cross compiler. My build attempts have been using xtask to do the whole project build.
<re_irc>
So... is there a way to trigger the complete compiler update, other than "do one build in the cross compiled directory"... which seems like a weak sauce workaround.
<re_irc>
<@dngrs:matrix.org> so, a few things
<re_irc>
<@dngrs:matrix.org> when you did "rustup toolchain install nightly-XXXXX" you did not update your "nightly", you installed an _additional_ toolchain
<re_irc>
<@dngrs:matrix.org> if you install "nightly" without a date, this will install the latest nightly available, and get updated whenever you do "rustup update".
<re_irc>
<@dngrs:matrix.org> next - as you observed, installing a new toolchain will only download the native target, and additional ones have to be installed manually, with
<re_irc>
if you don't specify the toolchain, it will use your default, which can be switched with "rustup default <name>". Personally I think the default is best left as "stable" and otherwise configured per project via "rust-toolchain.toml" in the project root.
<re_irc>
<@dngrs:matrix.org> additionally (and I'm fuzzy on the details here) if you _do_ have a "rust-toolchain.toml", "cargo" will install the specified toolchain and (potentially, not sure) the required target(s)
<re_irc>
<@dngrs:matrix.org> +when building
<re_irc>
<@shakencodes:matrix.org> Thank you!
dc740 has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> : It'll only install the targets if you list them in the Toolchain file, same for components
<re_irc>
<@dngrs:matrix.org> : Ah! I tried to find docs for this but couldn't. Are there any?
<re_irc>
<@jamesmunns:beeper.com> : Somewhere, yes, if you look for rust Toolchain manifest format or something
crabbedhaloablut has quit []
<re_irc>
<@firefrommoonlight:matrix.org> : Hi. I wrote the lib you linked. I built that because I wasn't happy with the APIs used by existing HALs, and didn't want to change syntax and capabilities when changing MCU. I made some effort with PRs and issues, but didn't get anywhere.
<re_irc>
<@firefrommoonlight:matrix.org> +I think the perspectives are different too: My goal is more towards writing device firmware, while those HALs were built with infrastructure in mind.
<re_irc>
<@firefrommoonlight:matrix.org> * design requirements were IRT
<re_irc>
<@azzentys:matrix.org> : What do you mean by infrastructure?
<re_irc>
<@firefrommoonlight:matrix.org> Btw, the work Adam does on the PAC is what allows both the per-family STM32 HALs, and the one I wrote to work. He also wrote a cleaner, macro-based register-level API called stm32-RAL
<re_irc>
<@firefrommoonlight:matrix.org> Dirbaio, for use in Embassy consolidated STM32 MCUs at the PAC level, which is also a very nice choice
<re_irc>
<@firefrommoonlight:matrix.org> : I can't confirm it, but my working theory is a lot of the individual STM32 HALs were built with a primary design goal of "Add Rust support for these MCUs"
<re_irc>
<@firefrommoonlight:matrix.org> * MCUs, and built the Rust embedded ecosystem"
<re_irc>
<@azzentys:matrix.org> : I absolutely loved how stm32-RAL is implemented in the pac.
<re_irc>
<@azzentys:matrix.org> : Embassy seems very attractive to me as well. I plan to dig into what/how soon for Embassy.
<re_irc>
<@firefrommoonlight:matrix.org> If you like Async, that's the way to go
<re_irc>
<@azzentys:matrix.org> : Makes sense!
<re_irc>
<@azzentys:matrix.org> : I love the idea, need to study through how they're achieving in embassy
<re_irc>
<@azzentys:matrix.org> Appreciate your comments on things. Thanks a lot!
dc740 has quit [Remote host closed the connection]
<re_irc>
<@firefrommoonlight:matrix.org> I would IMO experiment with all the available things and see which you like. What are you looking to build?
Foxyloxy has quit [Read error: Connection reset by peer]