<re_irc> <@d​irbaio:m​atrix.org> what does DefaultHandler with n = -16 mean?
<re_irc> <@d​irbaio:m​atrix.org> interrupt -16 doesn't exist
fabic has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: good idea. Although if I can turn it off when I need to, that would work too
<re_irc> <@d​irbaio:m​atrix.org> missing volatile, fixed in master but not released
<re_irc> <@a​damgreig:m​atrix.org> -16 means it read 0 and subtracted 16, and it reads 0 if it's in thread mode
<re_irc> <@d​irbaio:m​atrix.org> it's the DefaultHandler, it can't be in thread mode :D
<re_irc> <@a​damgreig:m​atrix.org> well quite
<re_irc> <@d​irbaio:m​atrix.org> just checked, the compiler is optimizing that read to return `0`
<re_irc> <@d​irbaio:m​atrix.org> with `read_volatile` it works correctly
<re_irc> <@a​damgreig:m​atrix.org> cool
<re_irc> <@a​damgreig:m​atrix.org> that explains why thejpster was getting that a couple weeks ago
<re_irc> <@a​damgreig:m​atrix.org> if you recall you noted at the time that -16 didn't make sense
<re_irc> <@d​irbaio:m​atrix.org> with volatile it reads `16` which is irq number 0 which is the one I'm actually missing a handler for
<re_irc> <@d​irbaio:m​atrix.org> yeah!
<re_irc> <@a​damgreig:m​atrix.org> really need to get a new c-m-rt out huh
<re_irc> <@d​irbaio:m​atrix.org> I guess.. hehe :)
<re_irc> <@d​irbaio:m​atrix.org> or cmrt-macros at least
<re_irc> <@a​damgreig:m​atrix.org> could backport that fix to a 0.6 release, macros master has breaking changes iirc
<re_irc> <@a​damgreig:m​atrix.org> wonder if anything else is worth backporting
<re_irc> <@d​irbaio:m​atrix.org> now to debug why embassy is screwing up my interrupts... fun
<re_irc> <@d​irbaio:m​atrix.org> lol, was missing `rt` feature.. classic...
<re_irc> <@a​damgreig:m​atrix.org> ah, exactly the same problem jpster had then too, lol
<re_irc> <@a​damgreig:m​atrix.org> it should really be enabled by default.....
<re_irc> <@d​irbaio:m​atrix.org> well usually hals enable them
<re_irc> <@d​irbaio:m​atrix.org> embassy-rp did... but I had replaced the dep with a path dep that didn't :D
<re_irc> <@d​irbaio:m​atrix.org> async timers working on the pico, wohooo
<re_irc> <@f​irefrommoonlight:m​atrix.org> Related: Has anyone used onboard op-amps? Any good for sensitive measurements? Eg STM32's
<re_irc> <@a​damgreig:m​atrix.org> i've used the f3's opamps for a basic gain block, they worked fine, really just gotta compare specs to whatever you're using now I guess
<re_irc> <@a​damgreig:m​atrix.org> they're not the lowest noise opamps in the world, but maybe still good enough. very convenient for sure.
<re_irc> <@f​irefrommoonlight:m​atrix.org> THank you
<re_irc> <@f​irefrommoonlight:m​atrix.org> The opamps I have now (AD8629)s are very nice, (maybe more expensive than I need), but can't be shut off directly
<re_irc> <@f​irefrommoonlight:m​atrix.org> Or put in a low-power mode
<re_irc> <@a​damgreig:m​atrix.org> might be possible to add an external power switch
<re_irc> <@a​damgreig:m​atrix.org> those are nice but also not super low noise due to being zero-offset self adjusting
<re_irc> <@a​damgreig:m​atrix.org> the stm32's will almost surely be worse zero offset, but perhaps you can calibrate that out and store cal offset in flash
<re_irc> <@a​damgreig:m​atrix.org> (or maybe it won't matter, depends a bit on how much gain you are applying too)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Unity gain!
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'd considered adding a second power supply that has a shutdown switch (The one I'm using for everythign would work), just to power the amps. But it seems like ICs have a nasty habit of pulling current from rando pins
<re_irc> <@f​irefrommoonlight:m​atrix.org> But worth a try. Could probably put something together with parts I have to do that with careful soldering. The amps are SOIC, so not too fine pitch
<re_irc> <@a​damgreig:m​atrix.org> what are you using them for if they're at unity gain?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Matching high-impedance probe leads to low impedance ADC
<re_irc> <@a​damgreig:m​atrix.org> huh, very high impedance probe huh? the onboard opamps seem like they should be ideal for that
<re_irc> <@a​damgreig:m​atrix.org> hmm
<re_irc> <@a​damgreig:m​atrix.org> the input bias current on the stm32f334 opamp is 0.2µA max, while on the ad8629 it's 300pA up to 1.5nA
<re_irc> <@a​damgreig:m​atrix.org> you can do the maths from your source impedance to see if that's an issue but it's definitely a lot worse
<re_irc> <@a​damgreig:m​atrix.org> (e.g. it would cause a 0.2V drop from a 1MR source...)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thanks for diving into taht!
<re_irc> <@f​irefrommoonlight:m​atrix.org> While the stats are worse, it's unclear if it would cause a significant problem with the measurement. I suppose would have to test
<re_irc> <@f​irefrommoonlight:m​atrix.org> Analog Devices seems to make devices with very nice specs, but at higher cost than other options, and onboard
<re_irc> <@f​irefrommoonlight:m​atrix.org> I wish this one had a shutdown/enable pin!
<re_irc> <@f​irefrommoonlight:m​atrix.org> Actually, would probably need to compensate for the voltage drop, since the voltages measured are generally -0.4V to +0.4V
<re_irc> <@f​irefrommoonlight:m​atrix.org> And we are dealing with MΩ impedance
<re_irc> <@f​irefrommoonlight:m​atrix.org> For now, I pulled the amps and will see if the batteries are alive in 2 days...
<re_irc> <@f​irefrommoonlight:m​atrix.org> They appeared to be the hottest item on the board, but my back-of-the-napkin math says they should still last 40 days
<re_irc> <@d​irbaio:m​atrix.org> debugging lowpower issues is the worst 😭
<re_irc> <@a​damgreig:m​atrix.org> AD stuff is definitely all extremely nice
<re_irc> <@a​damgreig:m​atrix.org> current project has a €300 single AD chip, love to solder that one
<re_irc> <@f​irefrommoonlight:m​atrix.org> HOLY CRAP
<re_irc> <@a​damgreig:m​atrix.org> not even close to the most expensive chips they sell though
<re_irc> <@a​damgreig:m​atrix.org> like this $12k opamp? https://www.digikey.com/en/products/detail/analog-devices-inc/HMC7748/6805271
<re_irc> <@a​damgreig:m​atrix.org> you might say that's a bit unfair, it's more of a packaged module, so scroll on down to like this $6k ADC https://www.digikey.com/en/products/detail/analog-devices-inc/AD9217BBPZ-10G
<re_irc> <@a​damgreig:m​atrix.org> and only 12 bits! the stm32 are also 12 bit
<re_irc> <@d​irbaio:m​atrix.org> $12k, wtf?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Well, it has an enable pin
<re_irc> <@t​halesfragoso:m​atrix.org> I get a 404 on the ADC, hmm, is that 10Gsps ?
<re_irc> <@a​damgreig:m​atrix.org> and yes, 10.25Gsps
<re_irc> <@a​damgreig:m​atrix.org> still, only one channel!
<re_irc> <@d​irbaio:m​atrix.org> 2 in stock! buy, quick
<re_irc> <@a​damgreig:m​atrix.org> two in stock though, could get one for tomorrow for the price of a used car
<re_irc> <@a​damgreig:m​atrix.org> at this rate they'll be worth $10k within a month
<re_irc> <@t​halesfragoso:m​atrix.org> I got a 100Msps for 3usd on ali, the jump is nice
jswagner has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> how many bits?
<re_irc> <@t​halesfragoso:m​atrix.org> Should be 8, I think
<re_irc> <@a​damgreig:m​atrix.org> this one is really a super-high-bandwidth RF ADC, you could directly sample the entire radio spectrum from DC to 5GHz, monstrous
<re_irc> <@a​damgreig:m​atrix.org> (or more likely you could sample 5GHz of some RADAR spectrum)
<re_irc> <@t​halesfragoso:m​atrix.org> I'm suppose to connect it to my ecp5 board once I learn analog design, it's gonna take some time, heh
<re_irc> <@a​damgreig:m​atrix.org> nice!
<re_irc> <@a​damgreig:m​atrix.org> is it a parallel interface to the ecp5?
<re_irc> <@a​damgreig:m​atrix.org> aaages ago i made a little board to plug a 10-bit 100MS/s ADC into a cyclone iv dev board and then spit the samples back out a 100MS/s DAC, it was pretty fun https://imgur.com/a/lLyca
<re_irc> <@t​halesfragoso:m​atrix.org> It's parallel, yes. AD9288
<re_irc> <@t​halesfragoso:m​atrix.org> The datasheet says that it has a 10bit pin-compatible upgrade, maybe it's the same as yours ?
<re_irc> <@a​damgreig:m​atrix.org> yea! mine was an AD9218
<re_irc> <@a​damgreig:m​atrix.org> for the DAC I made an NCO in migen (this was before nmigen existed), it's like <20 lines of python to get an oscillator with phase, frequency, and amplitude modulation: https://imgur.com/a/hXYbh
<re_irc> <@t​halesfragoso:m​atrix.org> Do you have the sch and PCB on your website ?
<re_irc> <@a​damgreig:m​atrix.org> then I could hook the ADC input into those modulating inputs, feed a 1kHz baseband signal in, output a 1MHz carrier with 1kHz FM modulation or whatever, it was cute
<re_irc> <@a​damgreig:m​atrix.org> hmm, yep! https://github.com/adamgreig/basebandboard/settings
<re_irc> <@a​damgreig:m​atrix.org> uh
<re_irc> <@a​damgreig:m​atrix.org> it was private until just now so it probably has a lot of embarrassing code and so on
<re_irc> <@t​halesfragoso:m​atrix.org> It will definitely help a lot, I have lots to learn, thanks
<re_irc> <@a​damgreig:m​atrix.org> i later added a touchscreen with a gui to make a little pulse+noise generator and scope thing https://photos.app.goo.gl/XRsxQcAiSXe2axkR7
<re_irc> <@a​damgreig:m​atrix.org> but the gateware for that is _horrific_ lol https://github.com/adamgreig/basebandboard/blob/master/gateware/bbb/ui.py#L128
<re_irc> <@a​damgreig:m​atrix.org> "immediate mode" or what
<re_irc> <@a​damgreig:m​atrix.org> anyway it ran at 100MHz somehow
<re_irc> <@t​halesfragoso:m​atrix.org> Nice, my idea was to play with something like a scope too
<re_irc> <@a​damgreig:m​atrix.org> yea! it was very fun and educational
<re_irc> <@a​damgreig:m​atrix.org> first meaningful fpga project i did i think
<re_irc> <@a​damgreig:m​atrix.org> nice because you just could not do 100MS/s processing on like an stm32
<re_irc> <@t​halesfragoso:m​atrix.org> Maybe pair it together with the Gigabit LAN on the led board heh
<re_irc> <@t​halesfragoso:m​atrix.org> But first I need to remove the level shifters
<re_irc> <@a​damgreig:m​atrix.org> oh, yea, that would be neat
<re_irc> <@a​damgreig:m​atrix.org> shout if you need any help with the gige on that, i've got some nmigen examples
<re_irc> <@d​irbaio:m​atrix.org> if a SPI chip says it can go at max 4mhz, is it OK for SPI to go faster when that chip is not selected?
<re_irc> <@a​damgreig:m​atrix.org> current work project is an ecp5 and gigE to dump a ton of adc data into the computer, so it came in handy eventually
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: yea, so long as CS is high the chip shouldn't pay any attention to the clk
<re_irc> <@a​damgreig:m​atrix.org> in general at least it should be totally fine and is commonly done
<re_irc> <@d​irbaio:m​atrix.org> I got a touch that can do max 4mhz and a display at 60+ mhz ⚡️
<re_irc> <@d​irbaio:m​atrix.org> cool
<re_irc> <@d​irbaio:m​atrix.org> was wondering if the fast clk would still glitch it somehow
<re_irc> <@a​damgreig:m​atrix.org> unlike i2c it shouldn't have any effect
<re_irc> <@d​irbaio:m​atrix.org> also, annoying that shared_bus can't switch spi freq automatically :P
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: I think I even saw that already, I will definitely talk to you once I get it going, but I will probably just spend a lot of time just reading, don't have much time to sink into it just now, already have some simpler side projects to finish
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Nice, share a video later of ferris bouncing around
<re_irc> <@t​halesfragoso:m​atrix.org> This is from therealprof iirc
<re_irc> <@d​irbaio:m​atrix.org> nice FPSs
<re_irc> <@t​halesfragoso:m​atrix.org> Parallel interface iirc
<re_irc> <@d​irbaio:m​atrix.org> ahhh that's cheating :P
<re_irc> <@d​irbaio:m​atrix.org> this SPI can theoretically do `64e6/320/240/2/8 = ~52 fps`
<re_irc> <@d​irbaio:m​atrix.org> except with the stupid pause between bytes, it'll do `64e6/320/240/2/8 = ~41 fps`
<re_irc> <@t​halesfragoso:m​atrix.org> And I'm here playing with my 400kHz i2c, and for some reason optimizing it to use write_vectored, to send all data in a single i2c transfer
<re_irc> <@d​irbaio:m​atrix.org> lol the st7789 can do max 62.5mhz
<re_irc> <@t​halesfragoso:m​atrix.org> It worked at least, still not very fast
<re_irc> <@d​irbaio:m​atrix.org> welp i'm already at the limit of both the pico and the st7789
jswagner has quit [Ping timeout: 272 seconds]
<re_irc> <@m​etajack:m​atrix.org> Hi, I'm trying to get some basic stuff working on the Daisy Field, which is based on stm32h7xx. I got the onboard LED blinking easily enough, but now I'm trying to blink some of the button leds (there are 24 of them). This requires I2C communication with a pair of PCA9685s. However, I can't seem to set up the...
<re_irc> ... clocks properly; it's basically halting during freeze(). The C++ library (libdaisy) sets all the multipliers and dividers for the different clocks, and by doing the math on what it wants, I can set those using stm32h7xx_hal, but I must be doing something wrong. Any help would be appreciated.
<re_irc> <@m​etajack:m​atrix.org> My code is here: https://gist.github.com/metajack/657fe7d9e243fa70988805ff391c74d7
mrkajetanp has quit [*.net *.split]
Rondom has quit [*.net *.split]
Rondom has joined #rust-embedded
mrkajetanp_ has joined #rust-embedded
Ekho has quit [*.net *.split]
Ekho has joined #rust-embedded
astroanax has quit [*.net *.split]
xnor has quit [*.net *.split]
nohit has quit [*.net *.split]
xnor has joined #rust-embedded
astroanax has joined #rust-embedded
nohit has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> Hmm... I would recommend trying to drop down the SYS_CK and PLL1_P to 400MHz metajack - the newer revs of H7 allow up to 480MHz, but I don't know if the HAL supports those configs? Also, why are you specifying every single PLL P/Q/R clock? It shouldn't be necessary in general terms if all you're doing is...
<re_irc> ... I2C
<re_irc> <@r​yan-summers:m​atrix.org> You should probably be able to get by with just specifying the HSE and the SYS_CK. Also, can you confirm that the daisy field has an external 16MHz oscillator installed on the board?
<re_irc> <@r​yan-summers:m​atrix.org> Just looking at the dev board layout photos, I don't see any obvious candidate for a 16MHz oscillator, so your dev board may not have one. Definitely something to verify. If you don't have an external oscillator, you can't specify `use_hse()`
<re_irc> <@r​yan-summers:m​atrix.org> After looking further, it looks like there is a 16MHz XTAL, so that shouldn't be the problem
fabic has quit [Ping timeout: 255 seconds]
fabic has joined #rust-embedded
neceve has joined #rust-embedded
aquijoule__ has quit [Ping timeout: 252 seconds]
richbridger has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <@j​hbruhn:j​hbruhn.de> Hi everyone! Has someone already made some experiences with writing and flashing a bootloader to a cortex-m device via Rust/Cargo? My current idea is to write the bootloader as a separate binary crate with a linker script specific to it (starting at the default boot location, limited in flash size) and then the...
<re_irc> ... application has another linker script starting after the bootloader. So far so good, but how do I get cargo to link these two binaries together into an .elf (is that even possible?) and the load that .elf to the microcontroller (e.g. using probe-run/cargo embed)? And in the long run, is there a way to let cargo/rustc linking produce a...
<re_irc> ... pure binary so i do not have to convert the .elf to a .bin. It seems that a post-build.rs could be handy for those types of tasks...
aquijoule_ has joined #rust-embedded
<Darius> I haven't done it in rust but iut's a PITA :)
richbridger has quit [Read error: Connection reset by peer]
<Darius> I would suggest keeping them separate, assuming your micro has a lockable boot loader area
<Darius> objcopy can create a bin from an elf
<re_irc> <@m​etajack:m​atrix.org> I’m specifying all the clocks because it didn’t work when I just used the simple clock setup and I thought maybe I had to initialize all the clocks for the I2C stuff to work. I may have had something else wrong. I can try to go back to the simple setup and see if I can make progress with I2C. Here’s the...
<re_irc> ... code in libdaisy that configures the clocks, which is what I painstakingly traced through to get those values: https://github.com/electro-smith/libDaisy/blob/master/src/sys/system.cpp#L181
<re_irc> <@a​damgreig:m​atrix.org> jhbruhn: I have, your approach sounds fine, you don't need to link the two together into a single elf (though it is possible if you really want)
<re_irc> <@a​damgreig:m​atrix.org> each elf only needs to be flashed to the part of memory it actually uses, and you'll need to put them in separate flash sectors anyway because you can only erase the flash sector-by-sector
<re_irc> <@a​damgreig:m​atrix.org> so it's fine to just flash the bootloader, then flash the application later (or program it using the bootloader!)
<re_irc> <@a​damgreig:m​atrix.org> rustc won't emit a pure binary but `cargo-binutils` provides `cargo objdump` which can easily generate a binary in one step
<Darius> you can even load both into gdb later BTW
<re_irc> <@j​hbruhn:j​hbruhn.de> Thanks for your answers Darius and adam! Yes, they will be in separate flash sectors, I was just hoping there was an easy way to integrate the bootloader/firmware partitioning into cargo to, in the end, have a workspace with both projects in which I can easily use cargo embed to flash both of them :)
<Darius> but I would recommend keeping them separate
<Darius> if you want to do an "all in one" for production then just write a script which flashes the boot loader then the application
<re_irc> <@j​hbruhn:j​hbruhn.de> You're right, that production process will be specialised anyways so it makes sense to keep it separate even there
<Darius> the other fun thing would be adding some sort of checksum to the application so the boot loader can verify it before it jumps
<re_irc> <@j​hbruhn:j​hbruhn.de> Yes, that is definitely going to happen :) I'll try to keep it as modular as possible so other people can benefit from it in the future as this will be part of my masters thesis. But no promises yet... ;)
fabic has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> jhbruhn: `cargo embed -p bootloader` followed by `cargo embed -p application`?
<re_irc> <@a​damgreig:m​atrix.org> it seems like it should be rare that you need to reflash both
<re_irc> <@a​damgreig:m​atrix.org> (anyway why not use the bootloader to flash the application? that way you get to test it's working :P)
<re_irc> <@j​hbruhn:j​hbruhn.de> that would require the bootloader to be doing that, the updates itself will happen from the application for various reasons, they bootloader only does image switching (in my case at least)... I'll do some experiments with cargo embed and the likes! :)
<re_irc> <@a​damgreig:m​atrix.org> aah got it
<re_irc> <@a​damgreig:m​atrix.org> sorry, in my head the bootloader was also doing the talking to whatever gave it a new image, but totally makes sense for the application to do that and write it to another bank and the bootloader just swaps or whatever
<re_irc> <@j​hbruhn:j​hbruhn.de> Yea right, this way the bootloader does not have to duplicate most of the applications code, which get's size-expensive when doing e.g. network communications! and it also allows to update the update process
<re_irc> <@a​damgreig:m​atrix.org> still, I'd probably keep them as two projects, even inside a shared workspace, and just flash them one at a time
<re_irc> <@a​damgreig:m​atrix.org> yea, makes good sense! and easier to recover from if there's some problem flashing too since the application can check it was OK before asking the bootloader to make the swap
<re_irc> <@h​uegene:m​atrix.org> adamgreig: would that not be wise anyway as to have the bootloader for more than just one project?
<re_irc> <@j​hbruhn:j​hbruhn.de> Yes, will definitely be separate projects in a shared workspace, although the latter is still a problem: they two projects need separate linker scripts which specify the entry location of the flash region, but currently the linker only looks for them in the workspace but not in the project directories, does...
<re_irc> ... someone have a hint here?
<re_irc> <@a​damgreig:m​atrix.org> yea, use a build.rs script to copy the memory.x from the relevant project
<re_irc> <@a​damgreig:m​atrix.org> that will take precedence over the workspace root
<re_irc> <@a​damgreig:m​atrix.org> (or anyway don't put memory.x in the workspace root)
<re_irc> <@j​hbruhn:j​hbruhn.de> huegene: depends. the hardware could be different enough for two projects to share some code but not all, especially partitioning information. I'll make a bootloader-library which has all the common functionality, so it will only need to be configured in the project-specific bootloader project
<re_irc> <@h​uegene:m​atrix.org> 🤔
<re_irc> <@h​uegene:m​atrix.org> Good Morning People 🙂
<re_irc> <@h​uegene:m​atrix.org> I am RTFS'ing my way through serial_port.rs (usbd_serial) and I am beeing stumped by the line
<re_irc> <@h​uegene:m​atrix.org> "use crate::buffer::{Buffer, DefaultBufferStore};"
<re_irc> <@h​uegene:m​atrix.org> I am stumped because I cant find what DefaultBufferStore is.
rjframe has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> Lumpio- might be able to explain better, it looks like it's just a struct that contains a 128-byte array for it to use as a buffer, and Buffer::new takes anything that implements the BorrowMut trait, which DefaultBufferStore does
<re_irc> <@h​uegene:m​atrix.org> Ahh! Oh my! regarding where to read is I guess the rust tutorial ;)
<re_irc> <@h​uegene:m​atrix.org> adamgreig: never mind I overlooked thar usbdls
<re_irc> <@a​damgreig:m​atrix.org> you've probably found it already but the DefaultBufferStore is here: https://github.com/mvirkkunen/usbd-serial/blob/master/src/buffer.rs#L120-L133
<re_irc> <@h​uegene:m​atrix.org> adamgreig: thank you I overlooked that usbd-serial implements its own buffer "A mediocre buffer that allows "
<re_irc> <@a​damgreig:m​atrix.org> you can see it's a plain struct containing a [u8; 128]
<re_irc> <@a​damgreig:m​atrix.org> but you could provide a different store if you wanted, so long as your store also impls `BorrowMut<[u8]>`
<re_irc> <@a​damgreig:m​atrix.org> but, you can probably just use the default as well
<re_irc> <@h​uegene:m​atrix.org> adamgreig: coming from C, I am stumped by so many things (nice really great features) in rust that for the most part, I read up on how other people have implemented solutions to problems and toying around with examples.
<re_irc> <@h​uegene:m​atrix.org> So for now I'll "study" buffer.rs from usbd-serial :)
<re_irc> <@a​damgreig:m​atrix.org> shout if anything still doesn't make sense :)
<re_irc> <@h​uegene:m​atrix.org> adamgreig: "doesn't make sense" is a really strong word *hahaha*
wose has quit [Ping timeout: 250 seconds]
wose has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
<re_irc> <@m​etajack:m​atrix.org> What does argument name `prec` mean in the stm32 hal crates?
<re_irc> <@r​yan-summers:m​atrix.org> peripheral reset enable control?
<re_irc> <@r​yan-summers:m​atrix.org> Or something similar. It's a concept introduced to allow drivers to enable their peripherals in the RCC
<re_irc> <@m​etajack:m​atrix.org> I'm trying to get i2c working and failing. The discovery book uses I2c::new which I guess doesn't exist anymore. It looks like there is just I2c::i2c1(...) now, and somehow it knows about the right pins (although it seems to know about two different sets of pins for scl and sda). Is this how I'm supposed to set...
<re_irc> ... it up?
<re_irc> <@m​etajack:m​atrix.org> `let i2c = I2c::i2c1(dp.I2C1, 1.mhz(), ccdr.peripheral.I2C1, &ccdr.clocks);`
<re_irc> <@a​damgreig:m​atrix.org> what stm32 are you using? prec is mostly on the stm32h7xx-hal i thought, but the discovery book targets the stm32f3 and the different stm32f3xx-hal
<re_irc> <@m​etajack:m​atrix.org> yes, i'm on a stm32h7xx
<re_irc> <@a​damgreig:m​atrix.org> have you seen the i2c example? https://github.com/stm32-rs/stm32h7xx-hal/blob/master/examples/i2c.rs
<re_irc> <@a​damgreig:m​atrix.org> it knows about different sets of pins because you can use many different pins as sda and scl for i2c, depending on what's convenient for your circuit and to help avoid conflicts with other functions available on each pin
<re_irc> <@a​damgreig:m​atrix.org> (the datasheet for your specific stm32h7 will have a 'alternate function mapping' table in the "pinouts and pin description" section, which details which pins can be used as i2c1 sda/scl)
<re_irc> <@m​etajack:m​atrix.org> Thanks, that was helpful, although I'm still unable to get it to do anything. When I try to do anything with the bus the code stops working, and even stranger, if i break the debugger when it's stopped, it is in the clock freeze which is well before I try to use the bus.
<re_irc> <@m​etajack:m​atrix.org> In https://gist.github.com/metajack/7191767b626c297a2f784c51346e59cf if I comment out line 51, I get blinking leds. If I uncomment that line the program hangs and the debugger says I'm on line 39.
<re_irc> <@r​yan-summers:m​atrix.org> You likely can't connect to your I2C device to to e.g. incorrect address or bus contention
<re_irc> <@r​yan-summers:m​atrix.org> The Pca9685::new() likely does some I2C commands internally, so those commands are likely hanging because of something in the I2C interface
<re_irc> <@m​etajack:m​atrix.org> Doesn't seem to do anything from what I can see, except to verify address: https://github.com/eldruin/pwm-pca9685-rs/blob/master/src/device_impl.rs#L13
<re_irc> <@r​yan-summers:m​atrix.org> Ah sorry
<re_irc> <@r​yan-summers:m​atrix.org> line 51 is right below, at `set_output_driver()
<re_irc> <@r​yan-summers:m​atrix.org> which definitely does do I2C transfers
<re_irc> <@m​etajack:m​atrix.org> Yes, and now that you mention that I realize I am calling those without enabling the thing.
<re_irc> <@m​etajack:m​atrix.org> Same issue, now I move the pwm.enable().unwrap() above the call to set_driver and with just enable uncommented I get the same hang.
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, so check your addresses, I2C line config, etc.
<re_irc> <@e​ldruin:m​atrix.org> exactly, I would check the address you have configured on the hardware
<re_irc> <@e​ldruin:m​atrix.org> otherwise, you may need to set the prescaler, for example
<re_irc> <@e​ldruin:m​atrix.org> here an example I know for a fact to work: https://github.com/eldruin/driver-examples/blob/master/stm32f1-bluepill/examples/pca9685-pwm-rgb-led-servos-bp.rs
rjframe has quit [Ping timeout: 256 seconds]
<re_irc> <@m​etajack:m​atrix.org> I'm not sure what I would have bus contention with, and afaict from looking at the C++ code and how this Pca9865 driver works, they are using the same addresses. Here's the led driver in C++ for this board: https://github.com/electro-smith/libDaisy/blob/master/src/dev/leddriver.h#L231 note that...
<re_irc> ... pwm_pca9865::Address::default() is 0x40 and that matches PCA9685_I2C_BASE_ADDRESS. It is oring with 0 there (the first PCA9865 is 0x00 and the second one is 0x02).
<re_irc> <@m​etajack:m​atrix.org> led config in C++ is here: https://github.com/electro-smith/libDaisy/blob/master/src/daisy_field.cpp#L66 which shows the same pins.
<re_irc> <@m​etajack:m​atrix.org> eldruin:
<re_irc> <@r​yan-summers:m​atrix.org> Do you see that expected address on the actual I2C line? Some drivers take it in 7-bit format and shift it. There was some ambiguity a while back
<re_irc> <@r​yan-summers:m​atrix.org> E.g. the address may be 0x40, but some drivers may take that and shift it left before setting the R/W bit
<re_irc> <@m​etajack:m​atrix.org> How would I check that?
<re_irc> <@r​yan-summers:m​atrix.org> This is generally a bug in implementation, but something to look for
<re_irc> <@e​ldruin:m​atrix.org> Can you lower the I2C speed?
<re_irc> <@m​etajack:m​atrix.org> I can, although I'm not sure what speed to use. 1MHz is what libdaisy was using for this, so that's why I used it.
<re_irc> <@r​yan-summers:m​atrix.org> 1MHz is really fast for a lot of I2C devices
<re_irc> <@e​ldruin:m​atrix.org> 400kHz should be good
<re_irc> <@r​yan-summers:m​atrix.org> Btw I don't see a mismatch in the I2C addresses used by the device and the HAL
<re_irc> <@e​ldruin:m​atrix.org> 100 kHz is the most compatible
<re_irc> <@m​etajack:m​atrix.org> Same issue at 100kHz.
<re_irc> <@r​yan-summers:m​atrix.org> Honestly I'd pull out a logic analyzer and look at the bus to save some time
<re_irc> <@r​yan-summers:m​atrix.org> If you have one available
<re_irc> <@a​damgreig:m​atrix.org> the other quick checks for i2c is to make sure the pins are open-drain and have pull-up resistors somewhere
<re_irc> <@r​yan-summers:m​atrix.org> Valid point. Daisy may be relying on internal pullup enables
<re_irc> <@a​damgreig:m​atrix.org> (`gpiob.pb8.into_alternate_af4().set_open_drain()` in the i2c example)
<re_irc> <@a​damgreig:m​atrix.org> i hope it's not relying on internal pullups at 1MHz!
<re_irc> <@a​damgreig:m​atrix.org> but definitely check
<re_irc> <@a​damgreig:m​atrix.org> adamgreig: ah, i just noticed your gist, i see you have got this ok
<re_irc> <@m​etajack:m​atrix.org> Not exactly sure what to look for, but that's the hardware ref i've been referring to for such questions.
<re_irc> <@a​damgreig:m​atrix.org> yep, it shows hardware 4k7 pull-up resistors on those lines
<re_irc> <@a​damgreig:m​atrix.org> sheet 3/5, cell C4
<re_irc> <@a​damgreig:m​atrix.org> so that should be OK...
<re_irc> <@e​ldruin:m​atrix.org> ok I see the A1 is pulled high
<re_irc> <@e​ldruin:m​atrix.org> So you will need something like: `Address::from((false, true, false, false, false, false))`
<re_irc> <@e​ldruin:m​atrix.org> or 0x50.into() or so
<re_irc> <@e​ldruin:m​atrix.org> assuming I got the order right. Otherwise 0x42.into()
<re_irc> <@m​etajack:m​atrix.org> Can you explain that a bit more?
<re_irc> <@e​ldruin:m​atrix.org> In sheet 3 of the schematics you can see the pca9685
<re_irc> <@e​ldruin:m​atrix.org> there you can see that the selectable address pins are all pulled low but A1, which is pulled high
<re_irc> <@e​ldruin:m​atrix.org> so the address is not the base address (`0x40`) but the address or'd with with that
<re_irc> <@r​yan-summers:m​atrix.org> I think that would be 0x42, A1 is defined as the 2nd LSB
<re_irc> <@e​ldruin:m​atrix.org> yeah I just checked as well and it would be `0x42`
<re_irc> <@m​etajack:m​atrix.org> Wait, there are two of them, and only one is shown. They are at 0x00 and 0x02 (although the schematics there show 0x00 and 0x01 in the label for some reason). The C++ code has it at 0x00 and 0x02 which gets ORed with the base address. The C++ code definitely works.
<re_irc> <@m​etajack:m​atrix.org> Regardless, 0x40 and 0x42 as address produce the same result.
<re_irc> <@e​ldruin:m​atrix.org> ah I see, then I do not know
<re_irc> <@m​etajack:m​atrix.org> So I'm uploading code via stlink and openocd. I previously used dfu-util to flash the c++ examples onto it, the last one of which still loads when I boot the thing and turns on all the LEDs.
GenTooMan has quit [Ping timeout: 240 seconds]
<re_irc> <@m​etajack:m​atrix.org> So each time I send new code via gdb, the device doesn't seem to reset at all at least not visually. Is that normal?
GenTooMan has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> What would you expect to see visually? When a CPU resets, often nothing actually changes on a hardware level (unless you have hardware PWMs running LEDs etc?)
<re_irc> <@r​yan-summers:m​atrix.org> In any case, you might want to look at using probe-rs instead of openocd
<re_irc> <@a​damgreig:m​atrix.org> are you saying if you power cycle it then it runs the old c++ code?
<re_irc> <@a​damgreig:m​atrix.org> as though your code wasn't being written to flash?
<re_irc> <@m​etajack:m​atrix.org> adamgreig: yes.
<re_irc> <@r​yan-summers:m​atrix.org> AFAIK the H7 doesn't support RAM execution, so something's not working right in the flashing process then?
<re_irc> <@a​damgreig:m​atrix.org> in your memory.x file, what do you have for FLASH (if you have one)?
<re_irc> <@a​damgreig:m​atrix.org> (it doesn't?)
<re_irc> <@r​yan-summers:m​atrix.org> That's probably a lie
<re_irc> <@a​damgreig:m​atrix.org> at least the cortex-m4 core on the dual core parts are suggested to execute from ram
<re_irc> <@a​damgreig:m​atrix.org> i mean, it's probably fair to say stm32h7xx-hal isn't designed for running from ram
<re_irc> <@a​damgreig:m​atrix.org> and like, your vector table probably isn't right at all in that case, so any interrupt would cause it to all go badly wrong
<re_irc> <@m​etajack:m​atrix.org> memory.x and .cargo/config.toml: https://gist.github.com/metajack/ca32024ae65c8a7dca5291eb851467a1
<re_irc> <@r​yan-summers:m​atrix.org> But you're right, it _can_. We run some functions from ITCM, which is SRAM (I think) on Stabilizer
<re_irc> <@r​yan-summers:m​atrix.org> Flash isn't at address 0
<re_irc> <@a​damgreig:m​atrix.org> huh, flash at 0x0 is unusual
<re_irc> <@a​damgreig:m​atrix.org> i mean, it probably _is_
<re_irc> <@r​yan-summers:m​atrix.org> https://github.com/quartiq/stabilizer/blob/master/memory.x#L11
<re_irc> <@r​yan-summers:m​atrix.org> Stabilizer also uses an H7
<re_irc> <@a​damgreig:m​atrix.org> i think boot0 will map the selected boot address down to 0x0
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, but don't point to address 0
<re_irc> <@a​damgreig:m​atrix.org> the cortex-m7 needs the vector table to live at 0x0 when the offset reg is 0, so the stm32 should be mapping boot flash to 0
<re_irc> <@a​damgreig:m​atrix.org> but yea
<re_irc> <@a​damgreig:m​atrix.org> not right for flashing for sure
<re_irc> <@r​yan-summers:m​atrix.org> or what you're writing to may change depending on internal config.
<re_irc> <@a​damgreig:m​atrix.org> I think the write just won't work
<re_irc> <@a​damgreig:m​atrix.org> which raises some very interesting questions about how anything is working at all
<re_irc> <@r​yan-summers:m​atrix.org> If it mirrors RAM there, it would work fine, wouldn't it?
<re_irc> <@a​damgreig:m​atrix.org> yea, you're right
<re_irc> <@a​damgreig:m​atrix.org> if the boot pins are set to map ram to 0, which they can be, or if the normal c++ firmware is doing that itself for any reason
<re_irc> <@a​damgreig:m​atrix.org> then this memory.x would lead to openocd writing all your code to ram, and it working, even the vector table
<re_irc> <@r​yan-summers:m​atrix.org> That wouldn't affect your actual I2C problems though
<re_irc> <@a​damgreig:m​atrix.org> metajack: if you `cargo install cargo-flash` and then run `cargo flash --release --chip stm32h750ZBTx` or whatever your specific chip is
<re_irc> <@a​damgreig:m​atrix.org> it should build and flash over the stlink for you
<re_irc> <@r​yan-summers:m​atrix.org> Atleast I don't think
<re_irc> <@a​damgreig:m​atrix.org> (or check out cargo-embed for a slightly more powerful version where you put the chip in Embed.toml and just run `cargo embed --release` to build and flash)
<re_irc> <@a​damgreig:m​atrix.org> yea, it's probably not the i2c issue
<re_irc> <@m​etajack:m​atrix.org> I tried probe-run, but it fails with `No flash memory contains the entire requested memory range 0x000000..0x000298.`
<re_irc> <@a​damgreig:m​atrix.org> you'll need to update your memory.x to put flash at 0x08000000
<re_irc> <@r​yan-summers:m​atrix.org> That's because youre memory.x file is wrong
<re_irc> <@a​damgreig:m​atrix.org> if you have access to an oscilloscope or logic analyser it does sound like it's time to measure the sda/scl lines and see if anything is happening
<re_irc> <@m​etajack:m​atrix.org> I copied the one from libdaisy c++ code, minus the weird segment names
<re_irc> <@r​yan-summers:m​atrix.org> That doesn't really change things. It's the wrong address for flash in the H7 devices in general, so probe-rs isn't going to accept it
<re_irc> <@m​etajack:m​atrix.org> oh weird. I thought I pasted that directly, but obviously I messed that up somehow.
<re_irc> <@a​damgreig:m​atrix.org> kinda curious how it was working with it at 0 but anyway maybe give it a try with that fixed
<re_irc> <@a​damgreig:m​atrix.org> does stm32h7xx-hal use interrupts for i2c?
<re_irc> <@a​damgreig:m​atrix.org> i wouldn't have guessed so
<re_irc> <@m​etajack:m​atrix.org> It does seem to work now ;)
<re_irc> <@a​damgreig:m​atrix.org> such is life with embedded devices, lol
<re_irc> <@m​etajack:m​atrix.org> I have blinking leds! You all rock!
<re_irc> <@a​damgreig:m​atrix.org> wow I didn't realise there was a very similar 🤟 emoji, lol
<re_irc> <@a​damgreig:m​atrix.org> probe-run and cargo-flash/cargo-embed should also work now I guess, i find them a lot more convenient than openocd
<re_irc> <@m​etajack:m​atrix.org> eldruin: The daisy_field.cpp stuff uses DMA to write to the led array since there are a lot of them. Does that mean I need to write my own driver or can I extend yours somehow?
<re_irc> <@e​ldruin:m​atrix.org> it depends
<re_irc> <@r​yan-summers:m​atrix.org> openocd is particularly bad for H7 - you have to custom-compile it and then install from git because the H7 isn't in any of the official releases
<re_irc> <@a​damgreig:m​atrix.org> even the very new 0.11?
<re_irc> <@e​ldruin:m​atrix.org> if it is a DMA-based I2C implementation, then you can use the driver as is
<re_irc> <@r​yan-summers:m​atrix.org> Maybe not with 0.11
<re_irc> <@r​yan-summers:m​atrix.org> Haven't used it in a year or so
<re_irc> <@a​damgreig:m​atrix.org> or, well, not that new any more, it came out in march apparently
<re_irc> <@a​damgreig:m​atrix.org> but it's their first release in like three years or longer
<re_irc> <@e​ldruin:m​atrix.org> if it uses DMA directly somehow, replicating the whole I2C shenannigans, then yes
<re_irc> <@a​damgreig:m​atrix.org> longer... 2017 for 0.10, lol
<re_irc> <@a​damgreig:m​atrix.org> there's a (slightly complicated) example of using DMA with stm32h7xx-hal for I2C here: https://github.com/stm32-rs/stm32h7xx-hal/blob/master/examples/i2c4_bdma.rs
<re_irc> <@a​damgreig:m​atrix.org> but it's more about using BDMA to allow the main power domains to all turn off while the D3 domain runs the I2C op, so it might be slightly overcomplicated for what you want
<re_irc> <@m​etajack:m​atrix.org> I appreciate the pointer, I'll take a look at this in a bit.
aquijoule_ has quit [Quit: Leaving]
<re_irc> <@x​norman:m​atrix.org> metajack: i may be a little late (was out of town).. i've worked with that chip and i2c on the h750 for daisy: https://github.com/x37v/libdaisy-rust/blob/xnor/field/src/field.rs
<re_irc> <@x​norman:m​atrix.org> ahh, looks like you've already got things going though, cool. i'm not doing DMA (yet)
<re_irc> <@e​ldruin:m​atrix.org> metajack: If you have a lot of LEDs, you might enjoy the [`set_all_on_off()` method](https://docs.rs/pwm-pca9685/0.3.0/pwm_pca9685/struct.Pca9685.html#method.set_all_on_off)
fabic has quit [Ping timeout: 255 seconds]
<re_irc> <@m​etajack:m​atrix.org> So what is the best workflow? I've been doing `cargo run` with gdb using openocd. Is cargo-embed the new hotness? The config toml for cargo-embed has a lot of options, so not sure what I should be using there.
<re_irc> <@y​atekii:m​atrix.org> metajack: you can just set the chip option and try with that :)
<re_irc> <@y​atekii:m​atrix.org> and then add more from there :)
<re_irc> <@r​yan-summers:m​atrix.org> probe-run is a nice option if you want to use RTT logging etc in an interactive console with the app
<re_irc> <@r​yan-summers:m​atrix.org> I generally use cargo-embed if I want to just flash and nothing else. Otherwise, I use probe-run for interactive logging
<re_irc> <@m​etajack:m​atrix.org> Is cargo-embed using probe-run behind the scenes? It sort of seemed that way from the github page
<re_irc> <@r​yan-summers:m​atrix.org> probe-rs is not probe-run, although the naming is confusing
<re_irc> <@r​yan-summers:m​atrix.org> probe-run and cargo-embed all use probe-rs behind the scenes
<re_irc> <@r​yan-summers:m​atrix.org> and probe-rs is basically a cargo crate for interfacing with hardware probes like the stlink
<re_irc> <@a​damgreig:m​atrix.org> ryan-summers: out of interest, why not rtt with cargo-embed?
<re_irc> <@m​etajack:m​atrix.org> Does the rtt stuff get compiled out for release builds or does it just noop if stlink isn't there?
<re_irc> <@r​yan-summers:m​atrix.org> Because our toolchain is setup and works and I don't touch it or think about it any more :)
<re_irc> <@r​yan-summers:m​atrix.org> Generally whenever i need an interactive terminal I'm dropping into gdb anyways using openocd. Haven't gotten our tooling set back up for revamped probe-rs yet
<re_irc> <@l​achlansneff:m​atrix.org> Anyone happen to know if any companies in aerospace or the space industry are using embedded rust?
<re_irc> <@a​damgreig:m​atrix.org> I definitely know that _some_ are because I work with rust in aerospace :P
<re_irc> <@a​damgreig:m​atrix.org> iirc it's been on various satellites too
<re_irc> <@l​achlansneff:m​atrix.org> Oh wow, that's super neat
<re_irc> <@y​atekii:m​atrix.org> adamgreig: living the dream :P
<re_irc> <@y​atekii:m​atrix.org> doing Rust AND Rocket Science
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, that's so cool
<re_irc> <@r​yan-summers:m​atrix.org> When I was at SpaceX, some of the firmware team were talking about using it, but that wasback in 2016 before Rust embedded really was going
<re_irc> <@a​damgreig:m​atrix.org> people will put a lot of things on satellites though, cubesats have like a 60% dead-on-arrival-to-orbit rate anyway so you can pretty well do whatever won't compromise the host mission
<re_irc> <@a​damgreig:m​atrix.org> definitely rpis running python have been on cubesats, android phones, the works
<re_irc> <@y​atekii:m​atrix.org> adamgreig: what, that's actually crazy lol
<re_irc> <@a​damgreig:m​atrix.org> (*precise statistic value made up)
<re_irc> <@y​atekii:m​atrix.org> deploying a cubesat got EVEN MORE expensive than I thought
<re_irc> <@a​damgreig:m​atrix.org> apparently in 2014, 18% were dead on arrival, from some study I just found
<re_irc> <@y​atekii:m​atrix.org> that's actually the real reason I need a decent salary: so I can finally deploy my cubesat :D
<re_irc> <@a​damgreig:m​atrix.org> another says 45% success rates
<re_irc> <@a​damgreig:m​atrix.org> anyway it's not great
<re_irc> <@y​atekii:m​atrix.org> sounds like it :D
<re_irc> <@r​yan-summers:m​atrix.org> The cost has dropped a _lot_ due to rideshare in recent years, so I wouldn't be surprised if that's resulted in a higher failure rate as the barrier to entry lowers
<re_irc> <@a​damgreig:m​atrix.org> yea, it sounds like it
<re_irc> <@y​atekii:m​atrix.org> yeah
<re_irc> <@a​damgreig:m​atrix.org> you can afford for it to not be perfect
<re_irc> <@y​atekii:m​atrix.org> but it's still 10-20k I think
<re_irc> <@a​damgreig:m​atrix.org> and chasing that reliability costs soooo much
<re_irc> <@r​yan-summers:m​atrix.org> That's nothing even to some university clubs
<re_irc> <@a​damgreig:m​atrix.org> quite a different scenario to launcher vehicles
<re_irc> <@r​yan-summers:m​atrix.org> Not nothing, but they can easily get donations for it
<re_irc> <@y​atekii:m​atrix.org> it's something to me XD
<re_irc> <@a​damgreig:m​atrix.org> where a 45% success rate would not be great lol
<re_irc> <@a​damgreig:m​atrix.org> (I mostly work on testing propulsion systems rather than flight vehicles, so have a lot more leeway in technology choices)
<re_irc> <@l​achlansneff:m​atrix.org> ryan-summers: I saw in the spacex ama a month or two ago that they're using rust, but they didn't mention anything about embedded.
<re_irc> <@r​yan-summers:m​atrix.org> The embedded team isn't super huge. When I was there it was only like 5-10 engineers. Flight software is _much_ more comprehensive for most of the rocket
<re_irc> <@r​yan-summers:m​atrix.org> And I wouldn't doubt flight software is using rust somewhere
<re_irc> <@a​damgreig:m​atrix.org> are most of the flight software developers not embedded?
<re_irc> <@a​damgreig:m​atrix.org> I feel like you could charitably still call it embedded development but maybe it's not a useful term at that point
<re_irc> <@r​yan-summers:m​atrix.org> It's a bit of a mix, but flight software tends to program on the flight computers, which I think were using some forked linux OS
<re_irc> <@r​yan-summers:m​atrix.org> embedded linux, but still very much in software land
<re_irc> <@a​damgreig:m​atrix.org> yea, fair
<re_irc> <@l​achlansneff:m​atrix.org> Ah, makes sense
<re_irc> <@a​damgreig:m​atrix.org> plus a ton of other software for people to interact with no doubt
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, flight software was only one of the many software teams
<re_irc> <@r​yan-summers:m​atrix.org> In any case, I know that Rust's safety is garnering a lot of attention in safety critical systems. A lot of the engineers I work with on medical devices are now getting very interested because of the memory safety
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, that's one reason why I'm so interested in using it for aerospace applications
<re_irc> <@a​damgreig:m​atrix.org> yea, it's definitely working its way up from the enthusiastic embedded engineers to also getting attention from everyone else
<re_irc> <@a​damgreig:m​atrix.org> i think mostly it just needs someone to pay for enough of a project using it that everyone else can point to them and say "look, it's flight-proven, let's go"
<re_irc> <@r​yan-summers:m​atrix.org> I think one of the bigger barriers as well is talent. A lot of embedded just use C because it's hard enough just to find embedded engineers
<re_irc> <@a​damgreig:m​atrix.org> there's a lot of hype for model-based design now, your engineers just work out model parameters in labview and it generates the fpga code to run on your flight hardware and then validates it for you too
<re_irc> <@a​damgreig:m​atrix.org> i am not a fan but it's for sure popular
<re_irc> <@r​yan-summers:m​atrix.org> But yeah, project risk definitely plays a role in being shy
<re_irc> <@a​damgreig:m​atrix.org> so people often end up buying in hardware and the low-level embedded software
<re_irc> <@a​damgreig:m​atrix.org> I'm sure we'll see more rust in the lower-risk sectors like cubesats first, and maybe all the new-space companies in the states will pick it up for their launchers and other software?
<re_irc> <@a​damgreig:m​atrix.org> they have more money and talent and enough trendiness to attract trendy rust devs :P
<re_irc> <@l​achlansneff:m​atrix.org> How do you guys suggest getting into the rusty part of the industry? It's very opaque from the outside, so difficult to target groups that use Rust or are rust adjacent
<re_irc> <@r​yan-summers:m​atrix.org> Honestly, look for rust adverts
<re_irc> <@r​yan-summers:m​atrix.org> Or get on a new company where you can direct the projects to start off in rust
<re_irc> <@a​damgreig:m​atrix.org> 👍️
<re_irc> <@r​yan-summers:m​atrix.org> Changing a culture that's already established is a _lot_ harder and I have a friend struggling with that right now
<re_irc> <@a​damgreig:m​atrix.org> the good thing is that most companies using rust are very vocal about it on their hiring pages
<re_irc> <@l​achlansneff:m​atrix.org> Okay, that makes sense
<re_irc> <@l​achlansneff:m​atrix.org> That's also true haha
<re_irc> <@a​damgreig:m​atrix.org> the bad thing is that a lot of companies not using rust are also very vocal about it on job adverts because it looks cool, lol
<re_irc> <@l​achlansneff:m​atrix.org> adamgreig: Really?
<re_irc> <@r​yan-summers:m​atrix.org> I know there's actually a few people in this chat that are looking for rust devs to hire
<re_irc> <@a​damgreig:m​atrix.org> "we use rust!!!
<re_irc> <@a​damgreig:m​atrix.org> *one of our interns wrote ten lines of rust last year, but hey, that counts? the rest is in java"
<re_irc> <@a​damgreig:m​atrix.org> the rust-embedded twitter account RTs people looking for jobs and looking to hire for embedded rust, and some of the recent RTs have a few replies with suggestions too, but I didn't notice any in aerospace in particular
<re_irc> <@l​achlansneff:m​atrix.org> I'm still in university, so really just trying to find internships that will help push me forward on my career goals (of working in the space industry and doing rust)
<re_irc> <@a​damgreig:m​atrix.org> depends a lot on where you are too. if you're a US citizen you can work for a lot of aerospace companies, if not it's trickier...
<re_irc> <@l​achlansneff:m​atrix.org> I'll definitely keep an eye out on adverts
<re_irc> <@l​achlansneff:m​atrix.org> I'm a US citizen, yeah
<re_irc> <@a​damgreig:m​atrix.org> that sure helps, heh
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, +1 on US citizenship. I'm pretty sure SpaceX is currently facing a lawsuit about discrimination against non-US citizens, but it's all due to ITAR regulations.
<re_irc> <@a​damgreig:m​atrix.org> that sounds like a wild lawsuit, lol
<re_irc> <@a​damgreig:m​atrix.org> but people are _constantly_ complaining that spacex won't hire them due to not being US citizens
<re_irc> <@a​damgreig:m​atrix.org> welcome to ITAR
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, and when I worked there, it was _very rare_ to see someone who wasn't a US citizen and you had to be careful about what information they then got access to
<re_irc> <@r​yan-summers:m​atrix.org> Different color badges and everything
<re_irc> <@l​achlansneff:m​atrix.org> Wow, that must have really sucked for those people :/
<re_irc> <@r​yan-summers:m​atrix.org> Likely hence the lawsuits
rjframe has joined #rust-embedded
<re_irc> <@m​etajack:m​atrix.org> @xnor Why is your (and libdaisy's) LED setting routine not just on=0 off=gamma[brightness]? Is it to stagger all the led phases? libdaisy seems to keep on the same and then set off as on+gamma[brightness], except for flipping full on bit sometimes.
<re_irc> <@m​etajack:m​atrix.org> But it seems like if the ons are inited to zero, then it will never stagger phase, so I'm not sure why it's so complicated.
<re_irc> <@x​norman:m​atrix.org> metajack: it has been a little while since i worked on that, and i used libdaisy as a reference, something about the controller indicated that phases should not be aligned IIRC
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
tokomak has quit [Read error: Connection reset by peer]
xnor has quit [Changing host]
xnor has joined #rust-embedded
<re_irc> <@m​etajack:m​atrix.org> Do DMAs always start with the register offset or is that just how libdaisy organizes its buffer? I notice the buffer is 16 * 4 + 1 in size, 1 byte is 0x06 (the register offset for setting all the led values) and then all the 16bit values for on/off for each of the 16 leds.
<re_irc> <@x​norman:m​atrix.org> metajack: IIRC that is simply the instruction byte?
<re_irc> <@r​yan-summers:m​atrix.org> It depends what you're DMAing and how you're DMAing it
<re_irc> <@r​yan-summers:m​atrix.org> And it depends on the DMA implementation as well
<re_irc> <@r​yan-summers:m​atrix.org> DMA fundamentally just sends data from point A to point B
<re_irc> <@m​etajack:m​atrix.org> I don't see anything in https://cdn-shop.adafruit.com/datasheets/PCA9685.pdf about DMA implementation. But I do see that 0x6 is the register offset where the led bytes start.
<re_irc> <@r​yan-summers:m​atrix.org> That's because "DMA" is only internal to the microcontroller. You're using DMA to copy data from your u8 buffer into the I2C transfer buffer I imagine
<re_irc> <@r​yan-summers:m​atrix.org> Unless the PCA9685 has some kind of bit-bang interface, in which case you DMA into the GPIO registers
<re_irc> <@r​yan-summers:m​atrix.org> DMA is only internal to the H7 and ends at the IO pads
<re_irc> <@m​etajack:m​atrix.org> Yes, that's the idea. I assume that's what the hal calls MemoryToPeripheral
<re_irc> <@m​etajack:m​atrix.org> In other words, sending DMA to I2C address would be the same as if I just sent a byte stream there manually?
<re_irc> <@r​yan-summers:m​atrix.org> DMA with I2C is likely different because I2C is transfer based. Transactions always have defined format (e.g. start byte, address, restart (in case of read), then bytes)
<re_irc> <@r​yan-summers:m​atrix.org> So it may be more complex. It depends on what exactly you want to do.
<re_irc> <@r​yan-summers:m​atrix.org> You could do a DMA implementation where you constantly write groups of 5 bytes, or you could do a DMA implementation that writes an infinite stream of bytes to a single I2C device
<re_irc> <@m​etajack:m​atrix.org> Does it matter which DMA and which stream gets used for particular transfers? I can see in libdaisy that it uses DMA1 and stream 6, but I have no idea if that's for a particular reason or just chosen arbitrarily.
<re_irc> <@r​yan-summers:m​atrix.org> The DMA _does_ matter, but the stream generally doesn't. DMA1/DMA2, BDMA, and MDMA all have different connections to different peripherals
<re_irc> <@r​yan-summers:m​atrix.org> But if you're just dealing with I2C, you can use either DMA1/DMA2 pretty interchangeably
<re_irc> <@r​yan-summers:m​atrix.org> Beware that DMA peripherals don't have access to all of the memory space of the device as well. You have to place your transmit buffers into specific linker sections so the DMA can access it
<re_irc> <@r​yan-summers:m​atrix.org> E.g. DMA1/DMA2 cannot access the DTCM memory, but MDMA can
<re_irc> <@m​etajack:m​atrix.org> Yes, I had noticed that in libdaisy and in the DMA example that was posted earlier.
<re_irc> <@m​etajack:m​atrix.org> Where would I find that info out? I'm reading ch 15 of RM0433 and it says "the entire 4GB can be addressed" and I've yet to see any mention of DTCM
<re_irc> <@r​yan-summers:m​atrix.org> Check out figure 1 under Section 2.1 - it shows the AXI bus matrix, and you can see that the DMA implementations don't have any connection through to the TCM
<re_irc> <@m​etajack:m​atrix.org> First pass hits this error: the trait `TargetAddress<_>` is not implemented for `I2c<stm32h7xx_hal::stm32::I2C1>
<re_irc> <@m​etajack:m​atrix.org> code snippet here: https://gist.github.com/metajack/5a0a427cc63053f66972e7f5034980e0
<re_irc> <@m​etajack:m​atrix.org> Also, apparently it can't deal with the buffer not being writable (even though it shouldn't be writing it here) or it being a struct. Looks like I'll have to make it byte array alias of it or something.
<re_irc> <@x​norman:m​atrix.org> metajack: you mean it requires `mut` ?
<re_irc> <@x​norman:m​atrix.org> I've changed my thinking about `mut` meaning mutable to it indicating exclusive access.. maybe that is part of this?
<re_irc> <@m​etajack:m​atrix.org> I'd agree with that generally, but `note: required because of the requirements on the impl of `embedded_dma::WriteBuffer` for `&[u8; 65]``
<re_irc> <@m​etajack:m​atrix.org> But perhaps it's just poorly named :)
<re_irc> <@m​etajack:m​atrix.org> There is indeed no TargetAddress impl for I2Cx other than 4, but it's not clear why that is. https://docs.rs/stm32h7xx-hal/0.9.0/stm32h7xx_hal/dma/traits/trait.TargetAddress.html
<re_irc> <@a​lmindor:m​atrix.org> why do we expose two separate traits for https://github.com/rust-embedded/embedded-hal/blob/master/src/blocking/delay.rs ? shouldn't it just be `DelayUs` with `ms` version defaults?
<re_irc> <@c​hemicstry:m​atrix.org> Has anyone tried writting logger (e.g. `log`) backend for UART? I'm having trouble providing uart instance to a static logger. Since uart is initialized in main, you cannot have it &'static. You also can't pass it by value, because you then need to store it in some global static, where generics are not allowed...
<re_irc> ... (all stm32 serial implementations use generics). So I'm either stuck with unsound code or have to write implementation for one specific uart peripheral using a predefined set of pins (to not have generics in a static)
<re_irc> <@d​irbaio:m​atrix.org> If main never returns you can safely transmute a main local var to &'static
<re_irc> <@d​irbaio:m​atrix.org> But the easiest is to put a concrete uart type in a static
<re_irc> <@c​hemicstry:m​atrix.org> the problem with transmuting is that user of uart logger is forced to do transmute themselves. Or is there a way to tell compiler that I'm borroing uart for eternity that approaches 'static, but is not static? :D
<re_irc> <@c​hemicstry:m​atrix.org> what I mean is to avoid unsafe outside library code
<re_irc> <@l​achlansneff:m​atrix.org> Does it make sense for a network stack to not be global?
<re_irc> <@l​achlansneff:m​atrix.org> Cause I can't think of an instance where a non-global netstack would make sense
neceve has quit [Ping timeout: 256 seconds]
<re_irc> <@m​etajack:m​atrix.org> eldruin: It doesn't appear that I can set the BitFlagMode1::AutoInc config at all. Am I missing something?
<re_irc> <@m​etajack:m​atrix.org> Happy to submit a PR if it's just missing, but thought I'd ask first.
<re_irc> <@t​herealprof:m​atrix.org> chemicstry: That has been around for a long time but it's kind of oldschool now.
<re_irc> <@c​hemicstry:m​atrix.org> therealprof: Do you mean logging through uart? I know, but I only used stm32 as an example, I'm actually trying to do that on cortex-a SoC
<re_irc> <@t​herealprof:m​atrix.org> Maybe I misunderstood what you're after.
rjframe has quit [Remote host closed the connection]
rjframe has joined #rust-embedded
<re_irc> <@a​lmindor:m​atrix.org> is re-use of device resource only possible through manually doing consumer.free() all the way back?
<re_irc> <@a​lmindor:m​atrix.org> e.g. say I use a pin for SPI but that pin is also an internal on-board LED, I do something with the SPI and want to use it as output pin now, do I need to spi.free() -> get back pin or is there a shorter way? Asking because in my case it's wrapped 3x by the time it's done :D
<re_irc> <@a​lmindor:m​atrix.org> s/free()/release()
<re_irc> <@a​lmindor:m​atrix.org> let (di, _) = display.release();
<re_irc> <@a​lmindor:m​atrix.org> let (spi,_) = di.release();
<re_irc> <@a​lmindor:m​atrix.org> let mut blue = pins.2.into_output();
<re_irc> <@a​lmindor:m​atrix.org> seems a bit excessive, and I can imagine this getting only worse. I wonder if there's a good solution tho...
<re_irc> <@a​lmindor:m​atrix.org> let (_, pins) = spi.free();
<re_irc> <@g​rantm11235:m​atrix.org> If you change the drivers to use references instead of owned structs, this will all work automatically
<re_irc> <@c​hemicstry:m​atrix.org> That's the only safe way. If you like to live dangerously, you can use Peripherals::steal(), but then you have to make sure that other instances no longer exist or that they won't interfere
<re_irc> <@c​hemicstry:m​atrix.org> or yeah references for more convenience
<re_irc> <@a​lmindor:m​atrix.org> it's not at the driver level tho, the SPI already takes it
<re_irc> <@g​rantm11235:m​atrix.org> ```rust
<re_irc> <@g​rantm11235:m​atrix.org> let pins = Pins::new();
<re_irc> <@g​rantm11235:m​atrix.org> let display = Display::new(&mut spi);
<re_irc> <@g​rantm11235:m​atrix.org> let spi = Spi::new(&mut pins);
<re_irc> <@a​lmindor:m​atrix.org> wasn't consuming the resources sort of the point to make sure only one user is active at a time?
<re_irc> <@a​lmindor:m​atrix.org> > ```rust
<re_irc> <@a​lmindor:m​atrix.org> > let pins = Pins::new();
<re_irc> <@a​lmindor:m​atrix.org> > let display = Display::new(&mut spi);
<re_irc> <@a​lmindor:m​atrix.org> > let spi = Spi::new(&mut pins);
<re_irc> <@g​rantm11235:m​atrix.org> That is an issue with dma buffers, but it shouldn't be a problem in this case
<re_irc> <@g​rantm11235:m​atrix.org> I believe dirbaio is working on a hal that uses references like that
<re_irc> <@a​lmindor:m​atrix.org> would be cool if there was a language way to do "drop & reclaim" on the device resources level, as in "once all the users drop their bits, reclaim the whole"
<re_irc> <@a​lmindor:m​atrix.org> shouldn't it be possible to do something like that with the Drop trait on the children?
<re_irc> <@a​lmindor:m​atrix.org> so e.g. you do `do_something_with_pin(dr.pins.some_pin.into_output()` and then you can just refresh the `dr` because it knows the pin that was taken out was dropped
<re_irc> <@c​hemicstry:m​atrix.org> you could achieve something like that with reference counting (e.g. Arc, but that needs alloc), where you would only return peripheral once there are no other references available. But then the peripheral type changes and it would be incompatible with existing libraries
<re_irc> <@a​lmindor:m​atrix.org> I think you could "refresh" pieces of DeviceResources if they're dropped properly upstream. It'd be unsafe but "safe"
<re_irc> <@a​lmindor:m​atrix.org> as in, once the section get's Drop::drop() inside you re-create it for re-use (since it's just a memory mapping)
<re_irc> <@a​lmindor:m​atrix.org> only for single threaded tho I suppose
<re_irc> <@g​rantm11235:m​atrix.org> What do you mean by "re-create"?
<re_irc> <@a​lmindor:m​atrix.org> "make a new instance of" which effectively is just repointing to the same memory region for a register or such
<re_irc> <@a​lmindor:m​atrix.org> basically a steal() for the section so it repopulates it on the existing instance of the struct
<re_irc> <@g​rantm11235:m​atrix.org> You might also need to set the pin mode to spi for example
<re_irc> <@a​lmindor:m​atrix.org> either use the Drop to do that or make an unknown state setup
<re_irc> <@a​lmindor:m​atrix.org> I guess an issue is that Drop is not transient in this case
<re_irc> <@a​lmindor:m​atrix.org> e.g. pin.into_output() already drops the pin
<re_irc> <@g​rantm11235:m​atrix.org> My point is that creating an `Spi` struct isn't just a matter of rearranging some memory, it involves running code to configure things
<re_irc> <@a​lmindor:m​atrix.org> sure but I think the model employed here is conflating the two problems, basically we can't just drop it all and re-do in a safe way and the main issue I see is that it takes a single crate to not have release()/free() to lock you into unsafe code usage
<re_irc> <@a​lmindor:m​atrix.org> also I think the consensus is already that DeviceResources should be in "unknown" state when created no?
<re_irc> <@a​lmindor:m​atrix.org> (there's nothing preventing a different program already setting a pin to input before your code runs for example, say bootloaders/rescue code)
<re_irc> <@g​rantm11235:m​atrix.org> The spi pins are in an unknown state before the `Spi` struct is created, but they are known to be in spi mode once it is created. The spi driver knows that the pins will stay in spi mode because it owns them, so it doesn't need to set the pin mode again every time you send some data
<re_irc> <@d​irbaio:m​atrix.org> almindor: embassy does exactly this
<re_irc> <@d​irbaio:m​atrix.org> you can create spi/i2c/etc with owned pins or borrowed pins
<re_irc> <@d​irbaio:m​atrix.org> so when you drop the spi, the pin is no longer borrowed and you can use it for something else
<re_irc> <@d​irbaio:m​atrix.org> it doesn't even have a .free()
<re_irc> <@a​lmindor:m​atrix.org> cool, do you know if embedded-rust is planning to standardize this? it seems a lot of -hal crates only have the consuming types
<re_irc> <@d​irbaio:m​atrix.org> asking the hard questions there :P
<re_irc> <@d​irbaio:m​atrix.org> for that to work well, gpio types must not have typestates
<re_irc> <@d​irbaio:m​atrix.org> because `.into_pullup_input()` and co must always consume the pin
<re_irc> <@d​irbaio:m​atrix.org> and people have *opinions* about removing typestates
<re_irc> <@a​lmindor:m​atrix.org> yes but they're there for safety
<re_irc> <@a​lmindor:m​atrix.org> those pesky opinions :D
<re_irc> <@d​irbaio:m​atrix.org> embassy is equally safe, it's just different
<re_irc> <@f​irefrommoonlight:m​atrix.org> Safety is subtle
<re_irc> <@f​irefrommoonlight:m​atrix.org> Typestates are a pain
<re_irc> <@d​irbaio:m​atrix.org> P0_01 = unconfigured pin, equivalent to `P0_01<Disconnected>` in nrf-hal
<re_irc> <@d​irbaio:m​atrix.org> Input<P0_01> = pin configured as input, equivalent to `P0_01<Input<XX>>` in nrf-hal
<re_irc> <@d​irbaio:m​atrix.org> Output<P0_01> = pin configured as input, equivalent to `P0_01<Output<XX>>` in nrf-hal
<re_irc> <@d​irbaio:m​atrix.org> instead of "changing" the pin into "output state"
<re_irc> <@d​irbaio:m​atrix.org> you "create an output driver" with the pin
<re_irc> <@d​irbaio:m​atrix.org> `Output::new(p.P0_04)`
<re_irc> <@d​irbaio:m​atrix.org> and you can *also* create an output with a borrowed pin
<re_irc> <@a​lmindor:m​atrix.org> ah with &mut on the pin so it's single borrower only
<re_irc> <@d​irbaio:m​atrix.org> `Output::new(&mut p.P0_04)`
<re_irc> <@d​irbaio:m​atrix.org> which is impossible with typestates
<re_irc> <@d​irbaio:m​atrix.org> this is why typestates work badly with borrowing pins
<re_irc> <@a​lmindor:m​atrix.org> that's a pretty good idea, embedded-hal v0.3? :D
<re_irc> <@g​rantm11235:m​atrix.org> We just need the e-h traits to be impl'd for `&mut T`
<re_irc> <@d​irbaio:m​atrix.org> embedded-hal has nothing to do with this, the embassy gpio types are compatible with embedded-hal 0.2 (or the upcoming 1.0)
<re_irc> <@d​irbaio:m​atrix.org> GrantM11235: not needed :P
<re_irc> <@d​irbaio:m​atrix.org> `Output<P0_01>` implements `embedded_hal::digital::OutputPin`
<re_irc> <@d​irbaio:m​atrix.org> it just works
<re_irc> <@d​irbaio:m​atrix.org> no changes needed in `embedded-hal`
<re_irc> <@a​lmindor:m​atrix.org> oh you're right
<re_irc> <@g​rantm11235:m​atrix.org> Sure, but that would require changing all the drivers to use `&mut SPI` instead of `SPI`
<re_irc> <@a​lmindor:m​atrix.org> it's all in the individual specific-hal crates
<re_irc> <@d​irbaio:m​atrix.org> no, you create an SPI with borrowed pins, then give that to the driver
<re_irc> <@a​lmindor:m​atrix.org> yeah the driver doesn't care about SPI internals of course
<re_irc> <@d​irbaio:m​atrix.org> drop the driver, the owned SPI is dropped, the borrow on the pins is cleared
<re_irc> <@g​rantm11235:m​atrix.org> Whereas if the traits where impl'd for `&mut T`, everything should just work
<re_irc> <@a​lmindor:m​atrix.org> but drop works with that part
<re_irc> <@d​irbaio:m​atrix.org> so you can go and create *another* SPI with the same pins
<re_irc> <@a​lmindor:m​atrix.org> drivers can consume the "middleware" parts
<re_irc> <@d​irbaio:m​atrix.org> for example
<re_irc> <@d​irbaio:m​atrix.org> a driver can require a `T: OutputPin`
<re_irc> <@a​lmindor:m​atrix.org> it's the low endpoints that need to be borrowed so basically all the -hal crates
<re_irc> <@a​lmindor:m​atrix.org> they all define GPIO with these subtypes
<re_irc> <@a​lmindor:m​atrix.org> e.g. https://github.com/riscv-rust/e310x-hal/blob/master/src/gpio.rs
<re_irc> <@d​irbaio:m​atrix.org> yeah, you simply can't have borrowed pins with the current design
<re_irc> <@a​lmindor:m​atrix.org> there doesn't actually seem to be an enforcing trait or anything, they all just kinda adopted this style
<re_irc> <@d​irbaio:m​atrix.org> this is why I made embassy different
<re_irc> <@d​irbaio:m​atrix.org> because I legit think it's better
<re_irc> <@d​irbaio:m​atrix.org> but other people don't
<re_irc> <@a​lmindor:m​atrix.org> i agree
<re_irc> <@a​lmindor:m​atrix.org> what are the counter arguments?
<re_irc> <@d​irbaio:m​atrix.org> if you were to PR this change to nrf-hal or stm32xxx-hal it'd be *controversial* :D
<re_irc> <@a​lmindor:m​atrix.org> i might just do it for the e310 then :P
<re_irc> <@d​irbaio:m​atrix.org> also allowing only borrowing is annoying too
<re_irc> <@d​irbaio:m​atrix.org> you want to allow both owned pins or borrowed pins
<re_irc> <@d​irbaio:m​atrix.org> embassy has some trait hackery to allow that, the `Unborrow` trait
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: This is 2 separate issues, if I understand correctly. At least on STM, pins aren't associated with the peripheral's software setup. Borrowing a bus (eg SPI) vs owning is set at the level of the struct or functions used to control the peripheral by performing reads and writes on the bus
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, if you're using a driver for a certain peripheral, and it's generic by using e-h traits, its that driver's call on owning vice borrowing
<re_irc> <@g​rantm11235:m​atrix.org> dirbaio: I think part of the problem was that everyone only heard you say "I got rid of typestates!" and got too scared to hear you out 🤣
<re_irc> <@f​irefrommoonlight:m​atrix.org> It sounds like dirbaio 's solution is to make it so the struct with control over the bus isn't exclusive
<re_irc> <@d​irbaio:m​atrix.org> I've explained the "borrowed pins" and such many times :P
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, you could have multiple structs with access to the SPI periph, which is a nice way of being flexible with drivers
<re_irc> <@d​irbaio:m​atrix.org> No, embassy's SPI represents exclusive access to the bus
<re_irc> <@d​irbaio:m​atrix.org> if you create it with borrowed pins, it's exclusive access *for the duration of the borrow*, but still exclusive
<re_irc> <@a​lmindor:m​atrix.org> it's &mut so single user, single execution environment, should be as safe
<re_irc> <@d​irbaio:m​atrix.org> sharing the same SPI instance between multiple drivers is something else, embassy doesn't do this. For that you need the `shared_bus` crate or roll your own with RefCell
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ah
<re_irc> <@d​irbaio:m​atrix.org> almindor: exactly, it takes all pins as &mut so while the borrow lasts the pins are exclusive for the current SPI instance
<re_irc> <@d​irbaio:m​atrix.org> and it's an owned SPI instance like all others
<re_irc> <@a​lmindor:m​atrix.org> yeah I get it, it's a really good take on how to approach this issue
<re_irc> <@d​irbaio:m​atrix.org> GrantM11235: 🤣
<re_irc> <@d​irbaio:m​atrix.org> can't blame them, the benefits are not immediately obvious
<re_irc> <@d​irbaio:m​atrix.org> but I've explained them many times already 🤷‍♂️
<re_irc> <@g​rantm11235:m​atrix.org> dirbaio: Is this just because a reference is infinity% bigger than a ZST, or are there other reasons too?
<re_irc> <@a​lmindor:m​atrix.org> the only issue I guess is you can't really define a "specific" pin in a specific state right? (as a type obv.)
<re_irc> <@a​lmindor:m​atrix.org> so e.g. you can't force SPI to only take PIN1 in iof1 state
<re_irc> <@d​irbaio:m​atrix.org> almindor: yea but why'd you want that? If you want to require input/output, you require Input<XX> or Output<XX>.
<re_irc> <@a​lmindor:m​atrix.org> it's really nice to prevent mistakes in some cases
<re_irc> <@d​irbaio:m​atrix.org> I guess `iof1` is the same as stm32's AFs?
<re_irc> <@d​irbaio:m​atrix.org> these states don't even exist in embassy
<re_irc> <@a​lmindor:m​atrix.org> e.g. I can only instantiate the e310 SPI from the correct pins (in the correct state but that part is enforceable in your world too)
<re_irc> <@d​irbaio:m​atrix.org> you give bare unconfigured pins to spi, i2c, uart
<re_irc> <@d​irbaio:m​atrix.org> and the spi, i2c, uart driver switches them to the right iof / af
<re_irc> <@a​lmindor:m​atrix.org> so the way they do it with public constructor constraints
<re_irc> <@d​irbaio:m​atrix.org> and switches them back to disconnected on drop
<re_irc> <@a​lmindor:m​atrix.org> you can do things like Input<PIN1>
<re_irc> <@a​lmindor:m​atrix.org> for say CS
<re_irc> <@a​lmindor:m​atrix.org> this forces pin sets
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@a​lmindor:m​atrix.org> it's not a huge loss but some could argue for it
<re_irc> <@d​irbaio:m​atrix.org> in embassy it's the SPI driver that does the mode setting internally
<re_irc> <@d​irbaio:m​atrix.org> makes the api way cleaner
<re_irc> <@d​irbaio:m​atrix.org> why ask the user to manually switch the pin to IOF4123 if the SPI driver can do it automatically
<re_irc> <@d​irbaio:m​atrix.org> easier to use, and you no longer need the "IOFx" typestates
<re_irc> <@d​irbaio:m​atrix.org> and it's equally safe
<re_irc> <@a​lmindor:m​atrix.org> it's not the state tho
<re_irc> <@a​lmindor:m​atrix.org> what you lose is the pin identification itself
<re_irc> <@a​lmindor:m​atrix.org> e.g. you can't force "pin5"
<re_irc> <@d​irbaio:m​atrix.org> yeah you can, there's still a type per pin
<re_irc> <@d​irbaio:m​atrix.org> P0_01, P0_02, P0_03 etc are individual pins
<re_irc> <@a​lmindor:m​atrix.org> ahh then &P0_02 would work still
<re_irc> <@d​irbaio:m​atrix.org> the only removed thing is typestates
<re_irc> <@a​lmindor:m​atrix.org> ok then no downside at all
<re_irc> <@a​lmindor:m​atrix.org> I thought you kind of foced the impl GpioPin thing
<re_irc> <@d​irbaio:m​atrix.org> so you can't have `P0_03<Input<PullUp>>`, just `P0_03`
<re_irc> <@a​lmindor:m​atrix.org> yeah but you can then have Input<P0_03>
<re_irc> <@a​lmindor:m​atrix.org> sorry &mut ...
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@d​irbaio:m​atrix.org> but for SPI you'd do something like
<re_irc> <@g​rantm11235:m​atrix.org> Stop telling people you got rid of typestates, just say that you turned them inside out 🤣
<re_irc> <@a​lmindor:m​atrix.org> yeah I think this should pass, we might be missing something else but it seems to be compatible
<re_irc> <@d​irbaio:m​atrix.org> GrantM11235: fair! but only "states" are then Input and Output, there's no AF, no PullUp/PullDown/OpenDrain etc
<re_irc> <@d​irbaio:m​atrix.org> very rough sketch
<re_irc> <@d​irbaio:m​atrix.org> trait MosiPin;
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> impl MosiPin for P0_01;
<re_irc> <@a​lmindor:m​atrix.org> how is function state handled then?
<re_irc> <@d​irbaio:m​atrix.org> this makes it so that `Spi::new` accepts `P0_01, P0_12, P0_13, &mut P0_01, &mut P0_12, &mut P0_13` for `mosi`
<re_irc> <@d​irbaio:m​atrix.org> so it still restricts only the right pins can be used
<re_irc> <@d​irbaio:m​atrix.org> and then `new` switches them internally to the right `iofX`
<re_irc> <@a​lmindor:m​atrix.org> but ioX is still just IOX<&mut Pin> no? or is that completely left out?
<re_irc> <@d​irbaio:m​atrix.org> there's no ioX type at all
<re_irc> <@h​uegene:m​atrix.org> hi currently I am reading the rtic documentation. I would like to try out software tasks, but the documentation points to IRQs that I never heared of.
<re_irc> <@h​uegene:m​atrix.org> " // RTIC requires that unused interrupts are declared in an extern block when
<re_irc> <@h​uegene:m​atrix.org> // using software tasks; these free interrupts will be used to dispatch the
<re_irc> <@h​uegene:m​atrix.org> // software tasks.
<re_irc> <@d​irbaio:m​atrix.org> huegene: you need to pick some unused interrupts for your chip that you want to "sacrifice" for RTIC to use, and put their names there
<re_irc> <@d​irbaio:m​atrix.org> `SSIO` and `QEIO` are interrupt names specific to that exmaple, you need to pick some unused ones from your particular chip
<re_irc> <@a​lmindor:m​atrix.org> > there's no ioX type at all
<re_irc> <@a​lmindor:m​atrix.org> So you only track input and output states, how do you keep the pin "locked" to a functional state then?
<re_irc> <@d​irbaio:m​atrix.org> with lifetime magic
<re_irc> <@d​irbaio:m​atrix.org> `pub fn new<'a>(..., mosi: impl Unborrow<Target=impl MosiPin>> + 'a) -> Spi<'a, T>`
<re_irc> <@d​irbaio:m​atrix.org> the `'a` there makes it so the borrow lasts for the entire time the Spi exists
<re_irc> <@d​irbaio:m​atrix.org> not just for the time `new` is running
<re_irc> <@d​irbaio:m​atrix.org> so while the `Spi` exists, the user can't touch the pin at all
<re_irc> <@d​irbaio:m​atrix.org> the user has to drop the Spi to be able to touch the pin again
<re_irc> <@a​lmindor:m​atrix.org> I think it might be easier to sell this to e-r if the functional state had "wrappers" too so they can be forced if needed, is there a reason to drop those from the "state wrap" ?
<re_irc> <@d​irbaio:m​atrix.org> the reason is IOFx states are useless on their own
<re_irc> <@d​irbaio:m​atrix.org> if "Pin 13 IOF3 mode" is SPI mode, there's no reason to have "Pin 13 in IOF3 mode" unless you want to use it for SPI
<re_irc> <@a​lmindor:m​atrix.org> you still need to expose a way of setting and keeping them in general, SPI is not the only function
<re_irc> <@d​irbaio:m​atrix.org> there is a reason to have "Pin 13 in Input mode", so you can use it as input directly
<re_irc> <@a​lmindor:m​atrix.org> ok but what about driver/bus writers
<re_irc> <@d​irbaio:m​atrix.org> but the only use case for "Pin 13 in IOF3 mode" is to give it to `Spi::new`
<re_irc> <@a​lmindor:m​atrix.org> ok, granted you can argue that encapsulation + using functional mode setting only internally works
<re_irc> <@a​lmindor:m​atrix.org> how do you set them?
<re_irc> <@d​irbaio:m​atrix.org> the only usecase I can think of is if you want to implement a custom out-of-hal SPI, but still want to use the in-hal GPIO
<re_irc> <@d​irbaio:m​atrix.org> is that what you were refering to?
<re_irc> <@a​lmindor:m​atrix.org> i'm more looking at it from a generic abstraction perspective. I agree that using functional states is ok to be "internalized only". What's the way they would be set then tho, would you do &mut P0_03.set_function() with no type info then?
<re_irc> <@d​irbaio:m​atrix.org> yea within the HAL there are lower-level private functions to set modes
<re_irc> <@a​lmindor:m​atrix.org> i'd argue it'd still be nice to have, perhaps a generic IOF<&mut impl Pin> wrapper to at least signal that it's in function mode (with const generics I guess we could use number identifiers too :D)
<re_irc> <@d​irbaio:m​atrix.org> or even do GPIO register writes in SPI::new, embassy simply does this https://github.com/embassy-rs/embassy/blob/master/embassy-nrf/src/twim.rs#L70-L87
<re_irc> <@g​rantm11235:m​atrix.org> Signal to who?
<re_irc> <@d​irbaio:m​atrix.org> you might argue it "violates encapsulation" because only HAL GPIO should do GPIO reg writes
<re_irc> <@d​irbaio:m​atrix.org> but in the end if SPI requires special GPIO modes, there has to be some "collaboration" between spi and gpio, somewhere
<re_irc> <@d​irbaio:m​atrix.org> it can be through public typestates
<re_irc> <@d​irbaio:m​atrix.org> it can be through SPI directly doing GPIO reg writes
<re_irc> <@d​irbaio:m​atrix.org> it can be through SPI calling private GPIO funcs
<re_irc> <@d​irbaio:m​atrix.org> you can never separate them 100%
<re_irc> <@d​irbaio:m​atrix.org> out of these 3, IMO public typestates make the public API ugly for no reason
<re_irc> <@d​irbaio:m​atrix.org> options 2 and 3 are better
<re_irc> <@d​irbaio:m​atrix.org> imo having a clean public API is top concern for a HAL
<re_irc> <@d​irbaio:m​atrix.org> "To use pin 13 as MOSI for SPI2, you need to set it to IOF7" is precisely one of the low-level details a HAL should abstract
<re_irc> <@d​irbaio:m​atrix.org> user should be able to ask "use pin 13 for MOSI", then SPI driver shoudl be able to figure out it needs to be IOF7 internally
<re_irc> <@d​irbaio:m​atrix.org> it's a Hardware *Abstraction* Layer after all
<re_irc> <@g​rantm11235:m​atrix.org> dirbaio: Don't be ridiculous, I love to construct my spi in three or four separate steps that involve passing `gpio.gpioa.crh` for some reason
<re_irc> <@d​irbaio:m​atrix.org> oh yeah the `&mut CRH` stuff, embassy also removed these
<re_irc> <@d​irbaio:m​atrix.org> same with &mut RCC and co
<re_irc> <@d​irbaio:m​atrix.org> User shouldn't care that setting a gpio as input needs to write to CRH
<re_irc> <@d​irbaio:m​atrix.org> the HAL should just do it
<re_irc> <@m​etajack:m​atrix.org> Ok, this code now compiles but doesn't quite work. I had to patch pwm-pca9685-rs to allow auto-increment mode, and then I added appropriate lines to dma/dma.rs in stm32h7xx-hal to enable I2C1,2,3 targets. https://gist.github.com/metajack/d9b2a0acd9e099d702dadee700c164fa
<re_irc> <@m​etajack:m​atrix.org> I'm not sure if more work in needed in stm32h7xx-hal besides
<re_irc> <@m​etajack:m​atrix.org> @@ -928,6 +929,12 @@ peripheral_target_address!(
<re_irc> <@m​etajack:m​atrix.org> (pac::SAI1, chb.dr, u32, P2M, DMAReq::SAI1B_DMA),
<re_irc> <@m​etajack:m​atrix.org> Anything obvious I'm missing now?
<re_irc> <@g​rantm11235:m​atrix.org> 🤏 "This is way too complicated, it should be much simpler"
<re_irc> <@g​rantm11235:m​atrix.org> 🧠 "Ah, I see, `device.GPIOA.split` takes `&mut rcc.apb2` because it needs to enable the gpio in the rcc"
<re_irc> <@g​rantm11235:m​atrix.org> ⭐️ "This is way too complicated, it should be much simpler"
<re_irc> <@d​irbaio:m​atrix.org> in embassy you don't even have to `.split()` 😛
<re_irc> <@f​irefrommoonlight:m​atrix.org> From that snippet.
<re_irc> <@f​irefrommoonlight:m​atrix.org> #1: `split` isn't a great name
<re_irc> <@f​irefrommoonlight:m​atrix.org> #2: I don't mind accepting RCC as an argument, to indicate you're doing RCC reg writes. I don't like the convention of using a thin wrapper around the PAC representation - this makes it incompatible with outside code
<re_irc> <@f​irefrommoonlight:m​atrix.org> I can also see the argument of "Don't pass RCC because it's boilerplate/clutter"
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think you could ommit RCC as an arg if documentation is clear that all peripheral initialization methods do writes to RCC enable and reset that periph
<re_irc> <@f​irefrommoonlight:m​atrix.org> And they don't do anything to RCC beyond that
<re_irc> <@g​rantm11235:m​atrix.org> I don't think that hals should be required to document what registers they use, that is the point of an abstraction
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> // =========== embassy
<re_irc> <@d​irbaio:m​atrix.org> let mut spi = Spi::new(
<re_irc> <@d​irbaio:m​atrix.org> let p = embassy_stm32::init(Default::default());
<re_irc> <@d​irbaio:m​atrix.org> 9 lines vs 24 lines :rofl
<re_irc> <@g​rantm11235:m​atrix.org> GrantM11235: (bump)
<re_irc> <@d​irbaio:m​atrix.org> It's not that, Input<X> is always ZST
<re_irc> <@d​irbaio:m​atrix.org> `Input::new(p.P0_03)` gives you a `Input<'static, P0_03>`
<re_irc> <@d​irbaio:m​atrix.org> `Input::new(&mut p.P0_03)` gives you a `Input<'a, P0_03>`
<re_irc> <@d​irbaio:m​atrix.org> `Input<'whatever, P0_03>` is always ZST, it never stores a &mut on the struct
<re_irc> <@d​irbaio:m​atrix.org> the reason to allow both owned and borrowed is
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmm. I'm considering it
<re_irc> <@f​irefrommoonlight:m​atrix.org> Tersening the API
<re_irc> <@d​irbaio:m​atrix.org> you want owned if you want to store the `Input<'static, P0_03>` in a struct. If only borrowed was permitted, you'd still have to store the P0_03 somewhere, and not on the same struct because that'd be self-referential
<re_irc> <@d​irbaio:m​atrix.org> you want borrowed because of the above discussion (tldr `free()` sucks)
<re_irc> <@d​irbaio:m​atrix.org> having only owned or only borrowed is meh
<re_irc> <@f​irefrommoonlight:m​atrix.org> I guess API design is an issue of letting the user clearly specify what he/she wants. And Dirbaio's setup example does that
<re_irc> <@f​irefrommoonlight:m​atrix.org> My design is closer to L4xx for that
<re_irc> <@f​irefrommoonlight:m​atrix.org> Might change it
<re_irc> <@d​irbaio:m​atrix.org> and the embassy API is not sacrificing safety vs stm32xxx-hals
<re_irc> <@f​irefrommoonlight:m​atrix.org> Are there any footguns that could realistically happen by handling stm32 RCC en/rst using raw pointers, vice mut RCC arg?
<re_irc> <@a​lmindor:m​atrix.org> me likey, I'll see if I can cook this up for the e310x-hal in a branch/pre-release after I'm done with some small things on my plate
<re_irc> <@d​irbaio:m​atrix.org> embassy-stm32 currently does it with critical sections to avoid races
<re_irc> <@d​irbaio:m​atrix.org> not zero cost, but almost-zero cost
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh.....
<re_irc> <@d​irbaio:m​atrix.org> the API simplicity gain is wayyyyyyyy worth it imo
<re_irc> <@d​irbaio:m​atrix.org> it's a very very short critical section doing RMW on registers, just a handful of clock cycles
<re_irc> <@d​irbaio:m​atrix.org> and there's plans to switch to bitbanding/atomics which should be even less cost (zero cost?)
<re_irc> <@d​irbaio:m​atrix.org> that's chip-spefcific though, as only some have bitbanding or atomics
<re_irc> <@f​irefrommoonlight:m​atrix.org> So you have something like this -
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> let mut rcc = &(*pac::RCC::ptr());
<re_irc> <@f​irefrommoonlight:m​atrix.org> free(|cs| {
<re_irc> <@d​irbaio:m​atrix.org> so it's using critical sections for now because that's what works on all chips
<re_irc> <@f​irefrommoonlight:m​atrix.org> Whereby race conditions don't need to be carefully avoided?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm considering it
<re_irc> <@d​irbaio:m​atrix.org> yeah if you do it inside CS no other code can execute during it
<re_irc> <@d​irbaio:m​atrix.org> so no other code can race your RMW
<re_irc> <@a​lmindor:m​atrix.org> wait, doesn't the current design need some form of locking too?
<re_irc> <@g​rantm11235:m​atrix.org> almindor: Yeah, that's what the `&mut rcc` does
<re_irc> <@t​halesfragoso:m​atrix.org> It's not really a lock though, it's zero cost
<re_irc> <@d​irbaio:m​atrix.org> zero runtime cost
<re_irc> <@t​halesfragoso:m​atrix.org> Sure
<re_irc> <@d​irbaio:m​atrix.org> nonzero api complexity cost :D
<re_irc> <@d​irbaio:m​atrix.org> nonzero user brain-juice cost
<re_irc> <@d​irbaio:m​atrix.org> user brain-juice is scarce 🙈
<re_irc> <@t​halesfragoso:m​atrix.org> Btw, the compiler doesn't know that critical section is a lock and avoids races, so be aware, it's fine on our case though
<re_irc> <@d​irbaio:m​atrix.org> is it not?
<re_irc> <@d​irbaio:m​atrix.org> cs enter/exit is asm with fences
<re_irc> <@d​irbaio:m​atrix.org> so it shouldn't reorder reads/writes in/out the cs
<re_irc> <@d​irbaio:m​atrix.org> or you mean something else?
<re_irc> <@t​halesfragoso:m​atrix.org> Yeah, it's fine because of the outline asn
<re_irc> <@t​halesfragoso:m​atrix.org> asm*
<re_irc> <@t​halesfragoso:m​atrix.org> Oh, yeah, we added the fences a while ago
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok, doing it
<re_irc> <@d​irbaio:m​atrix.org> welcome to the dark side
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: *cries in multicore*
<re_irc> <@t​halesfragoso:m​atrix.org> Be sure to know what you're doing when using unsafe though
<re_irc> <@d​irbaio:m​atrix.org> adamgreig: embassy uses `critical_section` crate allows replacing the impl with a multicore-safe one
<re_irc> <@d​irbaio:m​atrix.org> *without generics everywhere*
<re_irc> <@a​damgreig:m​atrix.org> do you have any implemented?
<re_irc> <@a​damgreig:m​atrix.org> i remember when we discussed it ages ago but haven't looked at the crate...
<re_irc> <@d​irbaio:m​atrix.org> or a softdevice-safe one for that matter
<re_irc> <@d​irbaio:m​atrix.org> that was my main motivation to write `critical_section`
<re_irc> <@d​irbaio:m​atrix.org> the `custom_impl!` macro makes that the global critical_section impl
<re_irc> <@d​irbaio:m​atrix.org> all crates in the tree magically switch to using that one instead of cpsid/cpsie
<re_irc> <@d​irbaio:m​atrix.org> I still have to document it though..
<re_irc> <@d​irbaio:m​atrix.org> the safety contract on the trait is ultra tricky
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm OK with the critical sections on the assumption this code is generally run once at program start
<re_irc> <@f​irefrommoonlight:m​atrix.org> At least in the programs I've written
<re_irc> <@f​irefrommoonlight:m​atrix.org> And... change made
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've only made it in the `new` fns; ie clock config that might happen during runtime still takes `&mut RCC`