<re_irc> <@w​illeml:m​atrix.org> Hmm, LCSC and Digikey don't seem to have any of the riscv mcu like the k210 or the k510
fabic has joined #rust-embedded
<re_irc> <@9​names:m​atrix.org> Yeah, you can only really get them via sipeed in module form, on AliExpress/Banggood or from the manufacturer directly (if you're ordering sufficient quantities).
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: it's like a thing with wifi...
<re_irc> <@d​irbaio:m​atrix.org> yea but requiring threads!??!
<re_irc> <@t​halesfragoso:m​atrix.org> yep, always FreeRTOS under the hood or something
<re_irc> <@t​halesfragoso:m​atrix.org> really sad
<re_irc> <@t​halesfragoso:m​atrix.org> Lachlan Sneff: See https://github.com/bjoernQ/bl602-wifi-rs
<re_irc> <@d​irbaio:m​atrix.org> Nordic's blobs are freestanding, they just require you to hook up interrupts to it
<re_irc> <@t​halesfragoso:m​atrix.org> it has some task switching, but very PoC
<re_irc> <@t​halesfragoso:m​atrix.org> I hope nordic did wifi, wifi is so close, very very sad
<re_irc> <@d​irbaio:m​atrix.org> wow they give you 2 versions of the blob, one for nuttx and one for freertos? so the .a imports the nuttx/freertos symbols directly? ewwwwwww
<re_irc> <@l​achlansneff:m​atrix.org> Wow
<re_irc> <@t​halesfragoso:m​atrix.org> I think for nuttx is has a compat layer, and you have to implement some stuff
<re_irc> <@t​halesfragoso:m​atrix.org> freertos should be straight freertos
<re_irc> <@t​halesfragoso:m​atrix.org> but it includes malloc, task switching and other sad stuff
<re_irc> <@t​halesfragoso:m​atrix.org> they even force malloc into you, I thing it's the same with espressif
<re_irc> <@t​halesfragoso:m​atrix.org> you wonder why they did 4MB of external RAM...
<re_irc> <@d​irbaio:m​atrix.org> even malloc? wtffff
<re_irc> <@d​irbaio:m​atrix.org> wo so that repo implements a "stub" nuttx with task switching and everything to make the blob happy 🤯
<re_irc> <@l​achlansneff:m​atrix.org> Malloc sort of seems reasonable for networking I think
<re_irc> <@d​irbaio:m​atrix.org> it's not!
<re_irc> <@d​irbaio:m​atrix.org> embassy-net + smoltcp doesn't require a heap! 😎
<re_irc> <@t​halesfragoso:m​atrix.org> Could just ask for buffer pointers
<re_irc> <@t​halesfragoso:m​atrix.org> and let the user handle the allocation, or have some sort of pool
<re_irc> <@d​irbaio:m​atrix.org> fuck heaps
<re_irc> <@l​achlansneff:m​atrix.org> I wonder if an async executor could be written that can run an external thread when tasks are pending
<re_irc> <@l​achlansneff:m​atrix.org> I think you could probably make a small pool specifically for the driver's heap.
<re_irc> <@d​irbaio:m​atrix.org> Lachlan Sneff: you can do that with embassy InterruptExecutor
<re_irc> <@d​irbaio:m​atrix.org> run whatever sync code in thread mode, and async tasks in irq mode. when an async task needs to run, it preempts thread mode
<re_irc> <@l​achlansneff:m​atrix.org> Hmm
<re_irc> <@d​irbaio:m​atrix.org> but it still doesn't help with this blob issue..
<re_irc> <@d​irbaio:m​atrix.org> if the blob creates multiple threads they all need to be able to suspend to switch to another
<re_irc> <@d​irbaio:m​atrix.org> 💩
<re_irc> <@l​achlansneff:m​atrix.org> There's gotta be a way to do this transparently
<re_irc> <@d​irbaio:m​atrix.org> yup..reimplementing a mini-rtos 🤷‍♂️
<re_irc> <@l​achlansneff:m​atrix.org> nartos - not an rtos
<re_irc> <@b​urrbull:m​atrix.org> therealprof, thalesfragoso See f4xx-hal #340, #341, #342, #343
<re_irc> <@d​irbaio:m​atrix.org> burrbull: people already have github notifications set up so they get notified when you open a PR
<re_irc> <@l​achlansneff:m​atrix.org> Making a reusable thread library for embedded rust that's explicitly just for working around badly designed binary blobs seems reasonable to me.
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio you might disagree, but it's a necessity until vendors get their shit together
<re_irc> <@d​irbaio:m​atrix.org> I don't disagree, I think it sucks to have to do that, but I agree that it's needed 🤷‍♂️
<re_irc> <@l​achlansneff:m​atrix.org> Thankfully the particular blog I was referring to originally doesn't require malloc.
<re_irc> <@w​illeml:m​atrix.org> dirbaio: Not always true lol, I didn't realize I had PR email notifications turned off until I reviewed two PRs 4 days after they were made...
<re_irc> <@w​illeml:m​atrix.org> Would implementing https://docs.rs/usbd-dfu/0.1.1/usbd_dfu/ work for programming external flash via dfu-util?
<re_irc> <@w​illeml:m​atrix.org> (I am pretty sure thats what it is for, but not 100%) and then of course there is the question of can I make cargo embed understand that and maybe use it for flashing
<re_irc> <@d​irbaio:m​atrix.org> with dfu-util maybe, dunno
<re_irc> <@d​irbaio:m​atrix.org> with cargo-flash/cargo-embed/probe-run no
<re_irc> <@d​irbaio:m​atrix.org> with cargo-flash you'll need a "flash algorithm"
<re_irc> <@d​irbaio:m​atrix.org> you were on a F7 right? probe-rs already has a few flash algos for QSPI flashes, they aren't hooked up
<re_irc> <@d​irbaio:m​atrix.org> maybe one of them Just Works for you
<re_irc> <@d​irbaio:m​atrix.org> - copy that yaml
<re_irc> <@d​irbaio:m​atrix.org> - remove all chips except yours
<re_irc> <@d​irbaio:m​atrix.org> - in your chip, remove all qspi algos except the one you want
<re_irc> <@d​irbaio:m​atrix.org> - add a `Nvm` to the `memory_map` that matches the `address_range` of the algo
<re_irc> <@d​irbaio:m​atrix.org> - try using cargo-flash passing the path to the yaml with `--chip-description-path`
<re_irc> <@d​irbaio:m​atrix.org> copy it from the `v0.11` tag, there's been breaking changes to the format in master https://github.com/probe-rs/probe-rs/blob/v0.11.0/probe-rs/targets/STM32H7_Series.yaml
<re_irc> <@w​illeml:m​atrix.org> Oh, I didn't even know that existed!
<re_irc> <@w​illeml:m​atrix.org> Thanks, I'll check it out
<re_irc> <@d​irbaio:m​atrix.org> if they don't work you can write your own algo... but that's no fun
<re_irc> <@w​illeml:m​atrix.org> pretty sure thats it
<re_irc> <@w​illeml:m​atrix.org> ouch, thats longer than expected...
<re_irc> <@w​illeml:m​atrix.org> ```yaml
<re_irc> <@w​illeml:m​atrix.org> so I need to choose one of these?
<re_irc> <@w​illeml:m​atrix.org> flash_algorithms:
<re_irc> <@d​irbaio:m​atrix.org> probe-rs matches flash algos to Nvm regions based on the address range
<re_irc> <@w​illeml:m​atrix.org> nvm, its the `STM32F730V8Tx` (which is also there) so I just remove all entries except that one? and then choose one flash algo?
<re_irc> <@d​irbaio:m​atrix.org> if you leave all the algos in, multiple will match
<re_irc> <@w​illeml:m​atrix.org> And I guess I have to compile probe-rs from source?
<re_irc> <@d​irbaio:m​atrix.org> you can use a custom yaml with `--chip-description-path`
<re_irc> <@d​irbaio:m​atrix.org> no recompile needed
<re_irc> <@w​illeml:m​atrix.org> Wouldn't I need to flash something to the chip?
<re_irc> <@w​illeml:m​atrix.org> Or does it handle that
<re_irc> <@d​irbaio:m​atrix.org> the "flash algorithms" are tiny bits of code that are loaded into the chip's ram and executed
<re_irc> <@w​illeml:m​atrix.org> Ohh, thats what the instructions field is for
<re_irc> <@w​illeml:m​atrix.org> Never understood that until now
<re_irc> <@d​irbaio:m​atrix.org> so the qspi algos use the stm32 qspi peripheral to write to the external qspi flash
<re_irc> <@d​irbaio:m​atrix.org> so they should work independently of what firmware is in the internal flash :D
<re_irc> <@w​illeml:m​atrix.org> I guess I need to also find an algorithm that matches the size of the flash chip?
<re_irc> <@d​irbaio:m​atrix.org> not sure
<re_irc> <@d​irbaio:m​atrix.org> probably the algo doesn't care about the flash size, it just explodes if you try to flash to too high addresses
<re_irc> <@w​illeml:m​atrix.org> I hope so, because it looks like these are all for 64K flash chips
<re_irc> <@d​irbaio:m​atrix.org> if you set the address_range to match your particular flash, probe-rs will print a nice error message if you try to do that instead of everything exploding
<re_irc> <@d​irbaio:m​atrix.org> the algo doesn't know what address_range you've set though, so it should work with and without
<re_irc> <@w​illeml:m​atrix.org> `0x800000` is 8MB right?
<re_irc> <@w​illeml:m​atrix.org> oh, now I have to figure out sectors and sizes...
<re_irc> <@w​illeml:m​atrix.org> Just a couple sectors lol
<re_irc> <@d​irbaio:m​atrix.org> sector size 65536 probably will work
<re_irc> <@w​illeml:m​atrix.org> I still have to do it 128 times
<re_irc> <@d​irbaio:m​atrix.org> no :D
<re_irc> <@d​irbaio:m​atrix.org> ```yaml
<re_irc> <@d​irbaio:m​atrix.org> sectors:
<re_irc> <@d​irbaio:m​atrix.org> - size: 65536
<re_irc> <@d​irbaio:m​atrix.org> address: 0
<re_irc> <@d​irbaio:m​atrix.org> this means "from address 0 onwards, sectors are 64k"
<re_irc> <@w​illeml:m​atrix.org> ahhh, thanks!
<re_irc> <@w​illeml:m​atrix.org> Nearly hurt myself there lol
<re_irc> <@w​illeml:m​atrix.org> writing tools to write yaml
<re_irc> <@d​irbaio:m​atrix.org> you only need multiple entries there if the flash has differently-sized sectors
<re_irc> <@w​illeml:m​atrix.org> Which command is it?
<re_irc> <@d​irbaio:m​atrix.org> ahh I don't think probe-run has that
<re_irc> <@d​irbaio:m​atrix.org> I saw that in `cargo-flash --help`
<re_irc> <@w​illeml:m​atrix.org> cargo embed and run help don't have it listed either
<re_irc> <@w​illeml:m​atrix.org> ihh
<re_irc> <@d​irbaio:m​atrix.org> you can get custom yaml working with probe-run, if you build custom probe-rs...
<re_irc> <@w​illeml:m​atrix.org> Caused by:
<re_irc> <@w​illeml:m​atrix.org> variants[0].memory_map: unknown variant `Nvm`, expected one of `Ram`, `Generic`, `Flash` at line 6 column 7
<re_irc> <@w​illeml:m​atrix.org> recompile needed?
<re_irc> <@d​irbaio:m​atrix.org> or file an issue to get them to add support for custom yamls...
<re_irc> <@d​irbaio:m​atrix.org> update cargo-flash
<re_irc> <@d​irbaio:m​atrix.org> `Flash` was renamed to `Nvm` a while ago
<re_irc> <@w​illeml:m​atrix.org> Ah ok, good to know
<re_irc> <@w​illeml:m​atrix.org> I always forget that the STLink connection does not charge the battery on my calculator...
<re_irc> <@a​lmindor:m​atrix.org> wrt. sifive there's a hifive1 clone called redv from sparkfun (using e310 almost identical clone on the board side as well) that I just got
<re_irc> <@w​illeml:m​atrix.org> which one?
<re_irc> <@a​lmindor:m​atrix.org> redboard
<re_irc> <@a​lmindor:m​atrix.org> it's a 99% hifive1-revb clone, even the pinout is same except for the internal LED
<re_irc> <@a​lmindor:m​atrix.org> i didn't check if they use the same "bootloader" but the memory layout is also same including that "bootloader skip"
<re_irc> <@w​illeml:m​atrix.org> That looks awesome
<re_irc> <@a​lmindor:m​atrix.org> i made a WIP PR for the board in https://github.com/riscv-rust/hifive1/pull/22
<re_irc> <@a​lmindor:m​atrix.org> AFAIK the only difference is the LED, but their documentation is super scarce
<re_irc> <@w​illeml:m​atrix.org> Do you know of canadian sparkfun resellers? I would like to avoid the insane shipping that there will be if I order direct from sparkfun
<re_irc> <@a​lmindor:m​atrix.org> yeah I got it from them, it cost me +30 CAD just for the privilege on the border
<re_irc> <@w​illeml:m​atrix.org> Digikey has them for 53 CAD... Probably the cheapest I will get
<re_irc> <@a​lmindor:m​atrix.org> yeah seems like about right
<re_irc> <@a​lmindor:m​atrix.org> I thought how nice and cheap I got it the shipping charge was low and then bam, customs
<re_irc> <@a​lmindor:m​atrix.org> also took more than a month to arrive
<re_irc> <@w​illeml:m​atrix.org> Hmm, while I am making a digikey order, anything else I should add? 😁
<re_irc> <@a​lmindor:m​atrix.org> what's the endgame? :D
<re_irc> <@w​illeml:m​atrix.org> free shipping lol
<re_irc> <@a​lmindor:m​atrix.org> oh hah, get something to use with it? display or such
<re_irc> <@w​illeml:m​atrix.org> Oh, thats another 46$ away, already ordered an eink display
<re_irc> <@w​illeml:m​atrix.org> maybe Ill get an lcd as well
<re_irc> <@a​lmindor:m​atrix.org> I heard ST7789 is well supported :P
<re_irc> <@w​illeml:m​atrix.org> Hehe, already have one in my calculator, btw thanks for the driver :D
<re_irc> <@a​lmindor:m​atrix.org> if you use an external one, use SPI mode_3 (a bit of a gotcha i just stumbled upon)
<re_irc> <@a​lmindor:m​atrix.org> (that is to say the "no cs" version)
<re_irc> <@w​illeml:m​atrix.org> hmm, hopefully that will be easier than the FMC one, that was very frustrating
<re_irc> <@d​irbaio:m​atrix.org> yup the driver's great, thanks! messed with it on the rpi pico a while ago
<re_irc> <@a​lmindor:m​atrix.org> funny thing is I optimized it so much because I forgot to crank up the SPI speeds back then :D I was running on 1Mhz all the time thinking "there must be a way to make this better"
<re_irc> <@d​irbaio:m​atrix.org> oh noo :D
<re_irc> <@d​irbaio:m​atrix.org> on the pico it goes up to 64mhz.. that's faaaaaaaaast
<re_irc> <@a​lmindor:m​atrix.org> found a lot of good pre-existing stuff too of course, the buffering of pixels etc.
<re_irc> <@a​lmindor:m​atrix.org> yeah, I was blown away when I used it at ~60Mhz first time hehe
<re_irc> <@w​illeml:m​atrix.org> Lol, rfuest made a PR to my repo that uses it, according to them it's faster with batch mode off, (seems to be right, at least, for entire screen refresh)
<re_irc> <@a​lmindor:m​atrix.org> that's possible
<re_irc> <@w​illeml:m​atrix.org> What does batch mode actually do? merge the operations into one?
<re_irc> <@a​lmindor:m​atrix.org> batching is pretty obviously beneficial in some cases tho
<re_irc> <@a​lmindor:m​atrix.org> yeah so this thing uses "windowed data"
<re_irc> <@a​lmindor:m​atrix.org> you basically do "window of this rect" cmd followed by data of pixels
<re_irc> <@a​lmindor:m​atrix.org> left to right, top to bottom
<re_irc> <@a​lmindor:m​atrix.org> that's the best performance you can do
<re_irc> <@a​lmindor:m​atrix.org> batching makes things into small windows basically as little as possibler
<re_irc> <@a​lmindor:m​atrix.org> without that you'd do per-pixels on say a circle stroke
<re_irc> <@a​lmindor:m​atrix.org> which means cmd, data, cmd, data
<re_irc> <@w​illeml:m​atrix.org> Ohh, thats why the speed advantage is odd, when drawing into a small text box at the "bottom" of the screen, batch mode is amazing, when doing the whole screen, or stuff at the top, its not noticeable or even slower
<re_irc> <@a​lmindor:m​atrix.org> yeah it'd be slower if you have the full buffer
<re_irc> <@a​lmindor:m​atrix.org> on pinetime, you can't fit it in RAM
<re_irc> <@a​lmindor:m​atrix.org> the framebuffer is bigger than the memory of the MCU haha
<re_irc> <@a​lmindor:m​atrix.org> i guess the buffering could be turned off for some specific cases, fills should already not buffer tho
<re_irc> <@a​lmindor:m​atrix.org> actually if you still have this issue open it up in github, I'd love to investigate now that I have it hooked to an MCU that can do full frames :D
<re_irc> <@w​illeml:m​atrix.org> Lol, sure, I will have to do more digging myself first into actual speed benefits, I did not do a huge amount of testing...
<re_irc> <@w​illeml:m​atrix.org> Also whats the best supported stm32 board/mcu for rust embedded?
<re_irc> <@w​illeml:m​atrix.org> (not necessarily stm32 actually)
<re_irc> <@a​lmindor:m​atrix.org> no idea, I never used one
<re_irc> <@d​irbaio:m​atrix.org> F4, H7, L4 probably
<re_irc> <@w​illeml:m​atrix.org> guess ill pick up an f3disco board then
dcz_ has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> How would I tell the linker to put a certain file at a certain address?
<re_irc> <@w​illeml:m​atrix.org> /* For STM32F750 devices */
<re_irc> <@w​illeml:m​atrix.org> MEMORY
<re_irc> <@w​illeml:m​atrix.org> /* NOTE K = KiBi = 1024 bytes */
<re_irc> <@w​illeml:m​atrix.org> {
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> #[link_section = ".qspi"]
<re_irc> <@d​irbaio:m​atrix.org> #[used]
<re_irc> <@d​irbaio:m​atrix.org> static STUFF: [u8; include_bytes!("stuff.bin").len()] = *include_bytes!("stuff.bin");
<re_irc> <@d​irbaio:m​atrix.org> and then something like this in memory.x to make everything in section `.qspi` to go into `QSPI`
<re_irc> <@d​irbaio:m​atrix.org> SECTIONS {
<re_irc> <@d​irbaio:m​atrix.org> .qspi ORIGIN(QSPI) : {
<re_irc> <@d​irbaio:m​atrix.org> KEEP(*(.qspi));
<re_irc> <@d​irbaio:m​atrix.org> }
<re_irc> <@d​irbaio:m​atrix.org> } > QSPI
<re_irc> <@d​irbaio:m​atrix.org> you can verify with `cargo objdump -- -x`
<re_irc> <@w​illeml:m​atrix.org> ohh, cool, thanks
<re_irc> <@w​illeml:m​atrix.org> `Error No flash memory contains the entire requested memory range 0x90000000..0x900005d0.`
<re_irc> <@w​illeml:m​atrix.org> Is that a problem with memory.x or something else?
<re_irc> <@d​irbaio:m​atrix.org> problem with the yaml, can you paste it?
<re_irc> <@d​irbaio:m​atrix.org> add a Nvm to the memory_map that matches the address_range of the algo
<re_irc> <@w​illeml:m​atrix.org> oh, ok
<re_irc> <@d​irbaio:m​atrix.org> you have one Nvm for the internal flash, you need another for the external one
<re_irc> <@w​illeml:m​atrix.org> `0: Trying to write flash, but no suitable flash loader algorithm is linked to the given target information.` ok, so now I just need to actually choose the algo I guess
<re_irc> <@d​irbaio:m​atrix.org> hmm
<re_irc> <@d​irbaio:m​atrix.org> maybe that error happens because multiple algos match
<re_irc> <@d​irbaio:m​atrix.org> in the `flash_algorithms` list of names make sure you only have one
<re_irc> <@d​irbaio:m​atrix.org> no need to remove the entire algo, just the name in variants[].flash_algorithms
<re_irc> <@d​irbaio:m​atrix.org> only the listed ones are considered
<re_irc> <@w​illeml:m​atrix.org> this works to flash internal, but it fails as soon as external tries, because it cant erase
<re_irc> <@w​illeml:m​atrix.org> so i guess I just have to try each one
<re_irc> <@w​illeml:m​atrix.org> `Error Failed to erase flash sector at address 0x90000000.`
<re_irc> <@w​illeml:m​atrix.org> `Hint Perhaps your chip has write protected sectors that need to be cleared?` they all give this, except the micron ones, which just fail init
<re_irc> <@d​irbaio:m​atrix.org> and you can erase and write fine from your custom firmware right?
<re_irc> <@w​illeml:m​atrix.org> Yeah
<re_irc> <@d​irbaio:m​atrix.org> aw :S
<re_irc> <@w​illeml:m​atrix.org> Need to make my own flash algorigthm?
<re_irc> <@d​irbaio:m​atrix.org> maybe your flash isn't fully compatible, which chip is it?
<re_irc> <@d​irbaio:m​atrix.org> that's strange though, qspi flashes are quite stnadardized
<re_irc> <@w​illeml:m​atrix.org> AT25SF641 adesto
<re_irc> <@w​illeml:m​atrix.org> (Its very hard to find online
<re_irc> <@w​illeml:m​atrix.org> )
<re_irc> <@d​irbaio:m​atrix.org> oh it's a weird one
<re_irc> <@d​irbaio:m​atrix.org> also I have no idea where these algos come from, maybe from here https://github.com/STMicroelectronics/stm32-external-loader
<re_irc> <@d​irbaio:m​atrix.org> if you want to write your own in rust, there's these as examples https://github.com/Tiwalun/hifive-flashloader https://github.com/rp-rs/flash-algo
<re_irc> <@w​illeml:m​atrix.org> So I would just put in the code needed for indirect read/write?
<re_irc> <@w​illeml:m​atrix.org> Not memory mapped init stuff?
<re_irc> <@d​irbaio:m​atrix.org> probe-rs will call the Init, EraseSector, ProgramPage, Uninit fns for you
<re_irc> <@d​irbaio:m​atrix.org> you have to implement them
<re_irc> <@w​illeml:m​atrix.org> Awesome, thanks
<re_irc> <@w​illeml:m​atrix.org> Shouldn't be tooo hard, not easy, but not as bad as I was thinking
<re_irc> <@w​illeml:m​atrix.org> Will I need to flash it to the mcu?
<re_irc> <@d​irbaio:m​atrix.org> you convert it to yaml using target-gen
<re_irc> <@w​illeml:m​atrix.org> Also, whats the best way of doing this in a redistributable way? Adding that repo as a cargo git dependency and implementing the trait?
<re_irc> <@d​irbaio:m​atrix.org> or the rp-rs one has a custom sscript... I did it before learning target-gen could do it 🤣
<re_irc> <@w​illeml:m​atrix.org> lol
<re_irc> <@d​irbaio:m​atrix.org> i'd just copypaste it..
<re_irc> <@w​illeml:m​atrix.org> The whole algo.rs file?
<re_irc> <@w​illeml:m​atrix.org> Ill just clone and reupload, and then rewrite, that way commit history is not broken, but the repo is visibly unrelated besides sharing some code
<re_irc> <@d​irbaio:m​atrix.org> algo.rs is the glue, main.rs is the chip-specific rpi pico impl
<re_irc> <@d​irbaio:m​atrix.org> yea
<re_irc> <@d​irbaio:m​atrix.org> there's some docs on the functions here https://www.keil.com/pack/doc/CMSIS/Pack/html/algorithmFunc.html
<re_irc> <@w​illeml:m​atrix.org> my mini doc issue
<re_irc> <@d​irbaio:m​atrix.org> :D
<re_irc> <@w​illeml:m​atrix.org> I did not understand any of it then, now I understand much more thanks to you :D
<re_irc> <@d​irbaio:m​atrix.org> I have to go
<re_irc> <@d​irbaio:m​atrix.org> good luck! :D
<re_irc> <@w​illeml:m​atrix.org> Thanks!
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
SomeWeirdAnon has joined #rust-embedded
fabic has joined #rust-embedded
neceve has joined #rust-embedded
fabic has quit [Ping timeout: 255 seconds]
<re_irc> <@t​herealprof:m​atrix.org> dirbaio: I receive literally hundreds (sometimes thousands) notifications from GH per day and don't have time to look into all of them. I appreciate people tagging me over a different channel when something is ready for review.
<re_irc> <@r​yan-summers:m​atrix.org> I personally have mine tailored so that _most_ of my notifications are something I care about (as I use Github for work as well), but I imagine everyone has a different workflow :)
fabic has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> ryan-summers: That's not really possible for me. I'm part of so many organisations and involved in so much stuff that I really can't finetune notifications to only contain a reasonable amount of noise. It's really a all or zero (code related) notification choice for me. When receiving all notification at...
<re_irc> ... least there's a small chance I'll see it flying by...
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, I get that. That's why I imagine it's a personal workflow thing for a lot of people
<re_irc> <@r​yan-summers:m​atrix.org> Does anyone know why `cargo doc` may raise an error for not being able to find `std` for an embedded build, while `cargo build` does fine? One of our dependencies has a feature flag that enables std support, but we disable the default feature for our build
<re_irc> <@r​yan-summers:m​atrix.org> My best guess is that cargo-doc is using the wrong features?
<re_irc> <@a​damgreig:m​atrix.org> I wish GitHub would train an ai on "notifications I want to get emailed" and not "how to autogenerate boilerplate"
<re_irc> <@r​yan-summers:m​atrix.org> More specific: `cargo doc` works, but `cargo doc --workspace` fails
<re_irc> <@r​yan-summers:m​atrix.org> Does cargo-doc also build docs for dev-dependencies?
<re_irc> <@a​damgreig:m​atrix.org> Does --no-deps help?
<re_irc> <@r​yan-summers:m​atrix.org> Aha!
<re_irc> <@r​yan-summers:m​atrix.org> Cargo doc _does_ do dev-dependencies
<re_irc> <@r​yan-summers:m​atrix.org> Which can cause a version conflict, since dev-dependencies can have std enabled just fine
<re_irc> <@t​herealprof:m​atrix.org> Speaking of which... korken89 can I get a feel what you think about https://github.com/japaric/heapless/pull/220?
<re_irc> <@t​herealprof:m​atrix.org> There's another PR in the queue for which no reviewer is assigned... 😉
neceve has quit [Ping timeout: 268 seconds]
tokomak has joined #rust-embedded
<re_irc> <@k​orken89:m​atrix.org> therealprof: Unfortunately not, I got s baby two days ago so so my open source work is currently on pause
<re_irc> <@k​orken89:m​atrix.org> I'll be back in a few weeks
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@j​amesmunns:m​atrix.org> Congrats korken89!
neceve has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> korken89: Congrats from me as well. No worries then.
astroanax has quit [Quit: WeeChat 3.1]
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 255 seconds]
<zBeeble> is there anyone here who has resources to explain bootstraping rust on a new platform?
<re_irc> <@a​damgreig:m​atrix.org> have you seen https://docs.rust-embedded.org/embedonomicon/ ?
<re_irc> <@a​damgreig:m​atrix.org> especially https://docs.rust-embedded.org/embedonomicon/custom-target.html
fabic has joined #rust-embedded
<zBeeble> so I need cargo for this.
<zBeeble> I had not found that, no
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
agg has quit [Quit: brb]
fabic has quit [Ping timeout: 268 seconds]
adamgreig has joined #rust-embedded
adamgreig is now known as agg
<zBeeble> OK. Proceeding reading these instructions. How do I get the nightly build or build the nightly build ... obviously ready for cross compiling. Would be nice if those instructions were for FreeBSD, too.
<agg> zBeeble: `rustup install nightly` if you're using rustup, should be the easiest way
<agg> building rust for a new platform is quite rare and using freebsd is unfortunately also quite rare so taken together there's not a wealth of docs for what you want
<cr1901> That's because... ya know what I'm gonna shut up
<agg> :X
<re_irc> <@d​khayes117:m​atrix.org> zBeeble: You can also set different project directories with different compilers. IE cd to your desired folder then `rustup override set nightly`
<cr1901> I've been meaning to do a Rust cross compile to see how bad it is. Unfortunately, I've had to create a set of bash scripts just for compiling LLVM and Rust. Wheee...
<cr1901> and it's prob complicated enough (i.e. fully understandable in like 30 mins) to spin into its own repo
<re_irc> <@m​riise:m​atrix.org> Hello! first off a big thanks to everyone working on rtic! it has been a pleasure reading through documentation and code (especially the upcoming 0.6)
<re_irc> <@m​riise:m​atrix.org> while doing some debugging I noticed that it would halt at the start of the program right at ```call_asm!(__cpsid());``` I figured it was alright, and kept working, just jumping over the halt every time.
<re_irc> <@m​riise:m​atrix.org> When I tried to flash to have an independently running system, my poor blinky program didnt go anywhere! is this related?
<re_irc> <@m​riise:m​atrix.org> some more info:
<re_irc> <@m​riise:m​atrix.org> - stm32f2xx_hal is incomplete
<re_irc> <@m​riise:m​atrix.org> - target stm32f2
<re_irc> <@m​riise:m​atrix.org> - ```target halted due to debug-request, current mode: Thread
<re_irc> <@a​damgreig:m​atrix.org> wow, stm32f2 is a very rare sight indeed, what HAL are you using exactly?
<re_irc> <@a​damgreig:m​atrix.org> you might find more specific support in #rtic:matrix.org channel
<re_irc> <@m​riise:m​atrix.org> https://github.com/mike7b4/stm32f2xx-hal
<re_irc> <@a​damgreig:m​atrix.org> I wouldn't expect gdb to halt on that cpsid line, not sure why it's getting a debug-request
<re_irc> <@a​damgreig:m​atrix.org> out of interest why are you using an stm32f2?
<re_irc> <@m​riise:m​atrix.org> lowest power consumption chip that still has a USB High Speed port
<re_irc> <@m​riise:m​atrix.org> (from what ive found)
<re_irc> <@a​damgreig:m​atrix.org> and what probe are you using to program? you could try using `cargo flash` and see if the result is any different
<re_irc> <@a​damgreig:m​atrix.org> (`cargo flash --release --chip stm32f2...` instead of openocd)
<re_irc> <@m​riise:m​atrix.org> that was one of the options I tried!
<re_irc> <@m​riise:m​atrix.org> sadly no dice...
<re_irc> <@m​riise:m​atrix.org> so far i have tried: gdb, probe-run(debugging), cargo-flash, and cargo-embed
<re_irc> <@a​damgreig:m​atrix.org> hm, very odd, is your code online anywhere?
<re_irc> <@m​riise:m​atrix.org> it is not, i can do a quick pastebin if you would like
<re_irc> <@a​damgreig:m​atrix.org> might be worth a quick look in case it's something easily apparent
<re_irc> <@m​riise:m​atrix.org> https://pastebin.com/wJNFsVkz
<re_irc> <@a​damgreig:m​atrix.org> the stm32f2 is a super old and very uncommon family, i've only seen one in real life when it was bought by mistake instead of an f4, lol
<re_irc> <@a​damgreig:m​atrix.org> I think an h7 would have lower power and has USB HS
<re_irc> <@m​riise:m​atrix.org> hahaha
<re_irc> <@m​riise:m​atrix.org> oh really?
<re_irc> <@a​damgreig:m​atrix.org> mostly they're a much newer silicon node, so the power consumption is inherently lower, but also they have higher core clocks so you can often also sleep more
<re_irc> <@d​irbaio:m​atrix.org> at the very least, h7 is better supported :P
<re_irc> <@m​riise:m​atrix.org> i saw the 480mHz clock and ignored it, but if the power consumption per clock is better then that might be a better option
<re_irc> <@a​damgreig:m​atrix.org> do you have the `rt` feature of stm32f2xx-hal enabled?
<re_irc> <@a​damgreig:m​atrix.org> in cargo.toml, stm32f2xx-hal = { git = "...", features = ["rt"] }
<re_irc> <@m​riise:m​atrix.org> features = ["rt", "stm32f205", "usb_hs"]
<re_irc> <@a​damgreig:m​atrix.org> dang, that would have been too easy
<re_irc> <@a​damgreig:m​atrix.org> the power consumption per MHz is 57µA for like H7A3 compared to 188µA for F205
<re_irc> <@m​riise:m​atrix.org> >_>
<re_irc> <@a​damgreig:m​atrix.org> what if you remove the hprintln calls?
<re_irc> <@d​irbaio:m​atrix.org> plus M7 has better IPC than M3 (?)
<re_irc> <@a​damgreig:m​atrix.org> that too
<re_irc> <@a​damgreig:m​atrix.org> if you're lucky 2 instructions retired per cycle on a cortex-m7 iirc?
<re_irc> <@m​riise:m​atrix.org> still halts in gdb
<re_irc> <@a​damgreig:m​atrix.org> hm, even with all the hprintln removed?
<re_irc> <@a​damgreig:m​atrix.org> where is it getting a default request from :/
<re_irc> <@m​riise:m​atrix.org> oh hey!
<re_irc> <@m​riise:m​atrix.org> cargo-flash works!
<re_irc> <@a​damgreig:m​atrix.org> o/
<re_irc> <@a​damgreig:m​atrix.org> so with semihosting enabled, the program will halt on the first hprintln until a debugger is attached to read the message
<re_irc> <@a​damgreig:m​atrix.org> these days it's quite rarely used because it's also extremely slow
<re_irc> <@a​damgreig:m​atrix.org> you might have better luck trying out rtt, which you can use with cargo-embed or probe-run, and is much faster (and can not block when no debugger)
<re_irc> <@m​riise:m​atrix.org> thanks for the advice!
<re_irc> <@m​riise:m​atrix.org> i will see about using that instead
<re_irc> <@a​damgreig:m​atrix.org> https://probe.rs/docs/tools/cargo-embed/ has some tips on RTT
<re_irc> <@m​riise:m​atrix.org> (also h7)
<re_irc> <@a​damgreig:m​atrix.org> I think the probe-run docs do too
<re_irc> <@a​damgreig:m​atrix.org> there are some good h7 dev boards around, either the ST Nucleo ones or WeAct in china have some cheap ones that also work well (but don't come with an onboard stlink like the nucleos)
<re_irc> <@m​riise:m​atrix.org> i will have to wait a few more days as i think they still havent included the new probe-rs that includes stm32f2
<re_irc> <@a​damgreig:m​atrix.org> they're >10 years more modern so there's a lot different but it's mostly better
<re_irc> <@a​damgreig:m​atrix.org> you can probably install from git in the meantime
<re_irc> <@a​damgreig:m​atrix.org> (for cargo-embed at least)
<re_irc> <@a​damgreig:m​atrix.org> hm, though if your cargo flash works then cargo embed should too
<re_irc> <@m​riise:m​atrix.org> 🤷‍♂️
<re_irc> <@m​riise:m​atrix.org> stm32f2 was added last week in probe-rs if i remember correctly
<re_irc> <@m​riise:m​atrix.org> nope it was 22 days
<re_irc> <@m​riise:m​atrix.org> 0.11.0
<re_irc> <@a​damgreig:m​atrix.org> ah ok, it was added 3rd june and 0.11 is the most recent release with it
<re_irc> <@a​damgreig:m​atrix.org> so cargo-embed will work, it's already been updated to use 0.11
<re_irc> <@a​damgreig:m​atrix.org> and probe-run (not maintained by probe-rs, so release cadence is different) has merged it on git I believe, so you could cargo install from git
<re_irc> <@t​halesfragoso:m​atrix.org> A lot of stm32 have high speed USB, they just don't have the high speed phy on chip
<re_irc> <@t​halesfragoso:m​atrix.org> I think the F2 also doesnt have it
<re_irc> <@a​damgreig:m​atrix.org> I think only the "high performance" ones (f2, f4, f7, h7) have it?
<re_irc> <@a​damgreig:m​atrix.org> having the phy on-chip is super rare, only a few f7s have that maybe?
<re_irc> <@t​halesfragoso:m​atrix.org> No G4 ?
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: Yes, afaik
<re_irc> <@a​damgreig:m​atrix.org> G4 is like an F3 replacement, it's "mainstream" rather than "high performance"
<re_irc> <@a​damgreig:m​atrix.org> (and is USB FS)
<re_irc> <@a​damgreig:m​atrix.org> idk why it's not called G3
<re_irc> <@t​halesfragoso:m​atrix.org> Don't the F107 has a USB high speed ?
<re_irc> <@t​halesfragoso:m​atrix.org> It has OTG at least
<re_irc> <@a​damgreig:m​atrix.org> F1 is OTG FS and mainstream
<re_irc> <@t​halesfragoso:m​atrix.org> Not that is that low power anyway
<zBeeble> ok. I don't appear to have "rustup" ... and I'm not running linux if I can help it. Can I do a bootstrap of a new system without nightly?
<re_irc> <@a​damgreig:m​atrix.org> try setting the RUSTC_BOOTSTRAP environment variable to 1, heh
<re_irc> <@a​damgreig:m​atrix.org> but I think you can install rustup on freebsd?
<zBeeble> what does that do. Remember... new platform --- no bootstrap compiler. I'm cross compiling the bootstrap.
<re_irc> <@a​damgreig:m​atrix.org> https://rust-lang.github.io/rustup/installation/other.html has a freebsd installer
<re_irc> <@a​damgreig:m​atrix.org> I don't know about the bootstrap compiler at all, but you should be able to install a nightly compiler on your host platform if you can install anything, and rustup is probably the easiest way to do it
<zBeeble> OK. but why do I need the nightly? This certainly is pushing me down the path of disliking rust. There's nothing in what I need to do that is benefitted, in general, by being pushed into a nightly build.
<re_irc> <@f​irefrommoonlight:m​atrix.org> G4 uses the old school USB. Ie you can use the USBD lib with it. I was surprised too
<re_irc> <@f​irefrommoonlight:m​atrix.org> Its USB periph is (almost?) identical to F3, L4x2-4, WB etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> It is not like the one on H7, L4x5/6 etc
<re_irc> <@a​damgreig:m​atrix.org> does L4 have HS?
<re_irc> <@a​damgreig:m​atrix.org> zBeeble: sorry, I thought you were the one saying you needed the nightly, I don't know what would specifically require it
<re_irc> <@a​damgreig:m​atrix.org> I could believe something needs it in the process of getting to a new platform though.
<re_irc> <@f​irefrommoonlight:m​atrix.org> L4 USB depends on variant. x1 doesn't have USB. x2 and x3 have old-school. x5 and x6 has the one that can host
<zBeeble> the only proceedure I havn't proven broken for what I need to do involes using -Z which appears to be gated to nightly builds.
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: looks like none of them have HS though, which fits with them being "low power" and not "high performance", seemingly only the high perf parts have HS
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm not sure how the hs/fs thing works. I noticed H7 has both
<re_irc> <@a​damgreig:m​atrix.org> zBeeble: right, using unstable flags does require a nightly, though you could try setting RUSTC_BOOTSTRAP=1 and using a stable compiler... but if you do have a stable compiler installed, installing a nightly shouldn't be too hard.
<zBeeble> I have a new desktop platform --- freebsd on a RISC-V processor ... and there is no rust for it. I simply want to make the rust bootstrap so I can move on.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think L5 has the old one too bte
<zBeeble> there seems to be a port for the nightly --- it's just that this sort of nonsense drives people like me to run for the hills.
<re_irc> <@f​irefrommoonlight:m​atrix.org> So yeah like you said it's about high performance line, not release date
<cr1901> zBeeble: You have to do development on nightly before stable. Let's see if I can find the relevant doc
<cr1901> You add the FreeBSD/RISCV code to master/nightly. The beta compiler from the previous release must be able to build it.
neceve has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #rust-embedded
synack has joined #rust-embedded
dcz has quit [Ping timeout: 272 seconds]