<re_irc>
<@firefrommoonlight:matrix.org> : Any prog on the GNSS? Of note, I'm getting no signs of life from my M10. On a diff board, I soldered the pins from a M8 module and was able to get it to communicate. Not sure if I made a subtle wiring error or what. It's hard to imagine there could be a solder fault due to how big and spaced out the pads are, but I also can't inspect them
<re_irc>
<@firefrommoonlight:matrix.org> When I send to the M8, I get a NACK back, which is probably fine since it looks like they use completely diff protocols!
<re_irc>
<@firefrommoonlight:matrix.org> I don't get anything with the actual M10 chip soldered on
<re_irc>
<@firefrommoonlight:matrix.org> : Any prog on the GNSS? Of note, I'm getting no signs of life from my M10. On a diff board, I soldered the pads to the leads on a an M8 module and was able to get it to communicate. Not sure if I made a subtle wiring on the design or what. It's hard to imagine there could be a solder fault due to how big and spaced out the pads are, but I also can't inspect them
<re_irc>
<@firefrommoonlight:matrix.org> Or maybe there's some voodoo I have to do to get it to start acking/nacking. I just sent it a CFG-SETVAL msg with a few settings in the payload
<re_irc>
<@firefrommoonlight:matrix.org> (And the M8 module would be ready to ACK/NACK because I ripped it off a quad that already was set up)
<re_irc>
<@firefrommoonlight:matrix.org> (Ie in addition to nacking it was also sending NMEA packets on the reg, which I didn't ask for, and am using the UBX protocol)
<re_irc>
<@korken89:matrix.org> : I'm still working on the 4G modem, getting some nice async interfaces on the AT commands :) but I'll start soon with the GNSS
<re_irc>
<@elpiel:matrix.org> Good morning everyone,
<re_irc>
rust-lld: warning: section type mismatch for .uninit.defmt-rtt.BUFFER
<re_irc>
rust-lld: warning: section type mismatch for .got
<re_irc>
On cortex-m0 I'm getting this strange error from "defmt" which I don't know how to debug:
<re_irc>
>>> <internal>:(.got): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: warning: section type mismatch for .got.plt
<re_irc>
>>> <internal>:(.got.plt): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: warning: section type mismatch for .got
<re_irc>
>>> <internal>:(.got): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 10848 bytes
<re_irc>
...
<re_irc>
<@elpiel:matrix.org> Good morning everyone,
<re_irc>
On cortex-m0 I'm getting this strange error from "defmt" which I don't know how to debug:
<re_irc>
rust-lld: warning: section type mismatch for .uninit.defmt-rtt.BUFFER
<re_irc>
>>> <internal>:(.got): SHT_PROGBITS
<re_irc>
rust-lld: warning: section type mismatch for .got
<re_irc>
rust-lld: warning: section type mismatch for .got.plt
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
>>> <internal>:(.got.plt): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 10848 bytes
<re_irc>
...
<re_irc>
<@elpiel:matrix.org> Good morning everyone,
<re_irc>
On cortex-m0 I'm getting this strange error from "defmt" which I don't know how to debug:
<re_irc>
rust-lld: warning: section type mismatch for .uninit.defmt-rtt.BUFFER
<re_irc>
>>> <internal>:(.got): SHT_PROGBITS
<re_irc>
rust-lld: warning: section type mismatch for .got
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: warning: section type mismatch for .got.plt
<re_irc>
>>> <internal>:(.got.plt): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 10848 bytes
<re_irc>
...
<re_irc>
<@elpiel:matrix.org> Good morning everyone,
<re_irc>
On cortex-m0 I'm getting this strange error from "defmt" which I don't know how to debug:
<re_irc>
rust-lld: warning: section type mismatch for .uninit.defmt-rtt.BUFFER
<re_irc>
>>> <internal>:(.got): SHT_PROGBITS
<re_irc>
rust-lld: warning: section type mismatch for .got
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: warning: section type mismatch for .got.plt
<re_irc>
>>> <internal>:(.got.plt): SHT_PROGBITS
<re_irc>
>>> output section .got: SHT_NOBITS
<re_irc>
rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 10848 bytes
<re_irc>
...
<re_irc>
<@elpiel:matrix.org> ahhh, it's again due to not enough stack size I believe
<re_irc>
<@elpiel:matrix.org> lowering the size of one of the channels was enough to remove the error
<re_irc>
<@elpiel:matrix.org> * for the error to disappear
<re_irc>
<@ryan-summers:matrix.org> The error message tells you what was happening. BSS (static variables) was too large for RAM memory. Not sure if there's good tools to show you ram size when not fitting, but binutils can show you what's using space once it compiles
dc740 has joined #rust-embedded
<re_irc>
<@boiethios:matrix.org> Hello, how common is it for a no-std library to ask for an allocator from the user? A variable on the stack could be used as an arena, for example. I'm not talking about a complex allocator, I only need a few bytes each call to my library, and the bytes would be freed during the call.
<re_irc>
I don't know which amount I need upfront, because it depends on a const generic parameter, and one cannot (for now) do any computation with it.
<re_irc>
<@elpiel:matrix.org> : great, thank you. I have to finally start tracking my application size 😅
<re_irc>
<@admin:orangemurker.com> : "cargo bloat" is an easy way to do that
<re_irc>
<@elpiel:matrix.org> oh great, that also goes into my toolbox
<re_irc>
<@ryan-summers:matrix.org> : Maybe helpless is a better solution for this if your memory size has a known compile time size, or an upper bound
<re_irc>
<@boiethios:matrix.org> : I'm already using a crate like that. I'm not sure that I need this kind of simple allocator, I'm asking more theoretically, after thinking about it for a bit.
<re_irc>
BTW, that makes me think about another question: I work on a STM32 and a RP2040, and sometimes, I have to choose between spending a bit more of memory, or a bit more of a CPU cycles. Working on a classical OS, I would 100% spend more memory, but I wonder if it's the same on such MCUs. Is the memory that tight? I understand it's an open-ended question, but I'm looking for guidelines mainly.
<re_irc>
<@boiethios:matrix.org> I'm supposed to have several hundreds of KiB, which is quite a lot for the small programs I write.
<re_irc>
<@boiethios:matrix.org> I don't know how to check that :/
<Darius>
although also modern MCUs are "pretty fast" so probably doesn't matter either way
<Darius>
you can only measure it statistically
<Darius>
like sample what the stack pointer is and what the heap allocator has free
<re_irc>
<@boiethios:matrix.org> It adds up quickly. If I go through several loops instead of caching the result each ms, it can makes quite a difference at the end.
<re_irc>
<@boiethios:matrix.org> Darius: I don't have a debugger on the MCU I work on, at the moment, but I'll do that on the RP2040 whose PCB I'm soldering myself at the moment
<re_irc>
<@boiethios:matrix.org> -at the moment
<Darius>
you don't need a debugger for it
<re_irc>
<@ithinuel:matrix.org> Even the core type matters when you need to make such a choice.
<re_irc>
Depending on the workload you can see huge differences between a Cortex-m0 and a cortex-m4 running at the same frequency.
<re_irc>
<@boiethios:matrix.org> Darius: Really? How do you get the value, then?
<Darius>
you can just read the stack pointer in an IRQ (if you setup a high priority IRQ to go off and then do the sample)
<Darius>
a debugger would be better but it would still give you useful information
<re_irc>
<@boiethios:matrix.org> I could indeed hack the HID to get the value after the IRQ
<re_irc>
<@boiethios:matrix.org> : I know that the frequency has nothing to do with the number of operations per second. The frequency of mainstream CPUs hasn't gone up for a while, and we still have faster and faster CPUs.
rardiol has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> : The three options are usually roughly:
<re_irc>
1. Use a specific stack container, like heapless
<re_irc>
2. Use a general bump/arena allocator, like bumpalo or similar
<re_irc>
3. Use global alloc
<re_irc>
In the future with custom allocators (instead of global allocators), there might be a "2.5" option instead.
<re_irc>
Options 1+2 seem like they could work for your case, but require the callee to "play along" and take the proper types. Option 3 (and 2.5) are a bit more work, but honestly are pretty reasonable unless you're tight on CPU cycles or RAM, though you will want to have some extra room available than you strictly need, to avoid fragmentation.
<re_irc>
<@jamesmunns:beeper.com> To answer "what is common", usually you either ask for an allocator by requiring the alloc crate (option 3), or you take a buffer at the call site (option 1). Or in embedded it's not uncommon for a library to keep its own storage, in a static or similar
<re_irc>
<@boiethios:matrix.org> : Thanks a lot for the detailed answer!
iprusov has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@chemicstry:matrix.org> does anyone know if there is any tooling to interface with stm32 arduino bootloader (aka maple)? I.e. to flash blue pill board via onboard USB port without an st-link
rardiol has quit [Remote host closed the connection]
rardiol has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Not sure about the arduino bootloader, but the stm32f103 supports usb dfu
<re_irc>
<@9names:matrix.org> IIRC the maple loader is just dfu
<re_irc>
<@9names:matrix.org> uhh. you sure about usb dfu builtin on the 103?
<re_irc>
<@boiethios:matrix.org> Is the dfu the thing allowing to just drag and drop the binary into the mounted volume, and then it's flashed and dismounted? That thing is dope, all the controllers should be like that.
<re_irc>
<@jamesmunns:beeper.com> I was pretty sure? but could be wrong
<re_irc>
<@9names:matrix.org> no, that's uf2
<re_irc>
<@jamesmunns:beeper.com> : That's a specifc uf2 bootloader thing
<re_irc>
<@boiethios:matrix.org> I have a custom controller with a RP2040, and I can flash it like that
<re_irc>
<@jamesmunns:beeper.com> > The embedded bootloader of the STM32F103 does not provide DFU functionality as you can find in AN2606, table 3.
<re_irc>
Oh jk im wrong
<re_irc>
<@jamesmunns:beeper.com> must have been confusing it with another board I've used
<re_irc>
anyway: should be able to use dfu-util. i'm sure there's a rust port, because of course there is
<re_irc>
<@9names:matrix.org> part of why i'm loath to touch stm32f103's is that bootloader :/
mattgirv has quit [Ping timeout: 255 seconds]
<re_irc>
<@jamesmunns:beeper.com> but if you already have a firmware bootloader that speaks dfu, you can use cargo-objcopy to make a bin, and then dfu-util (or a rust tool) to upload the firmware
<re_irc>
<@firefrommoonlight:matrix.org> Very nice API!
<re_irc>
<@firefrommoonlight:matrix.org> I am tempted to copy it, but worry with so many variants, any errors I make from omissions or transcription will will make users, including myself, not trust it, or want to QC the User Manual each time
<re_irc>
<@firefrommoonlight:matrix.org> I am tempted to copy it, but worry with so many variants, any errors I make from omissions or transcription will make users, including myself, not trust it, or want to QC the User Manual each time
<re_irc>
<@dirbaio:matrix.org> just grab the data from stm32-data :P
<re_irc>
<@dirbaio:matrix.org> guaranteed accurate, or your money back
<re_irc>
<@firefrommoonlight:matrix.org> not a bad idea!
<re_irc>
<@firefrommoonlight:matrix.org> RN I have it set so the user has to manually choose the correct alt, which seems like something a HAL could do
<re_irc>
<@dirbaio:matrix.org> also, you can do without the enum
<re_irc>
<@dirbaio:matrix.org> this is what embassy does;
<re_irc>
<@dirbaio:matrix.org> "new()" uses the trait to get the af number, then switches the pins to it
<re_irc>
<@dirbaio:matrix.org> * it, and stores degraded pins in "self"
<re_irc>
<@firefrommoonlight:matrix.org> What does the "new" call look like?
<re_irc>
<@dirbaio:matrix.org> storing degraded pins covers the same purpose as storing a specially-made enum for that AF in the end, but you don't have to write the enum
<re_irc>
<@firefrommoonlight:matrix.org> Looks like we're on the same page re cfg structs with defaults!
<re_irc>
<@dirbaio:matrix.org> non_exhaustive <3
<re_irc>
<@dirbaio:matrix.org> while we're with HAL design questions:
<re_irc>
<@dirbaio:matrix.org> what's the way to go for SPI word size other than u8/u16/u32?
<re_irc>
<@dirbaio:matrix.org> define newtypes like "pub struct U5(pub u8);" and take those as "Word"?
<re_irc>
<@dirbaio:matrix.org> or take "Word=u8" but with a config setting to set it as 5bit?
<re_irc>
<@dirbaio:matrix.org> or both? or something else..>?
<re_irc>
<@dirbaio:matrix.org> contrbute native "u5" to Rust? 🤪
<re_irc>
<@vollbrecht:matrix.org> if you crate non power of 2 things, wouldn't the aliening always be part of the concrete implementation inside the hals?
<re_irc>
<@vollbrecht:matrix.org> i think its more of a question how to present an range option as an enum or something? If you would allow an arbitrary sice for example between 4bit and 48bit with stepsize of 1bit this would be a huge enum?
<re_irc>
<@vollbrecht:matrix.org> * size, for example between 4bit and 48bit with stepsize of 1bit,
<re_irc>
<@dirbaio:matrix.org> the spi trait is generic over the worc sice
<re_irc>
<@dirbaio:matrix.org> * word size
<re_irc>
<@dirbaio:matrix.org> so if you tx a "&[u8]" it'll tx 8 bit words, if you tx "&[u16]" it'll tx 16bit words
<re_irc>
<@dirbaio:matrix.org> people out there want other word sizes, like 5bit, for several cursed use cases, like neopixel leds
<re_irc>
<@dirbaio:matrix.org> ranged_integers seems interesting but it's nightly only
<re_irc>
<@vollbrecht:matrix.org> right and to represent that you can have for example for things smaller than an u8 this cursed range thing :D
<re_irc>
<@dirbaio:matrix.org> i'm OK with the range not being enforced at compile time, like if you TX "0b0101_0101", it'll tx "0b1_0101" and discard the top 4 bits
<re_irc>
<@firefrommoonlight:matrix.org> : Question question. I wish rust had customizable size types!
<re_irc>
<@dirbaio:matrix.org> but given that, i'm not sure whether it's best to take "&[u8]" or a custom u8-wrapper like "&[U5]"
<re_irc>
<@dirbaio:matrix.org> i'm OK with the range not being enforced at compile time, like if you TX "0b0101_0101", it'll tx "0b1_0101" and discard the top 3 bits
<re_irc>
<@firefrommoonlight:matrix.org> One way would be to use the integer type a size up and have the user specify size using an enum (or integer if it's really flexible)
<re_irc>
<@firefrommoonlight:matrix.org> Or you could go the custom-size/tight-packing route
<re_irc>
<@vollbrecht:matrix.org> yeah but the how to slice is always part of the hal implementation right?
<re_irc>
<@jamesmunns:beeper.com> does bitvec have a "chunks" iterator? :p
<re_irc>
<@vollbrecht:matrix.org> +part,
<re_irc>
<@dirbaio:matrix.org> one thing is, if it takes "&[u8]", you could give a 5bit spi to a driver that expects 8bit spi
<re_irc>
<@vollbrecht:matrix.org> so question is - How a general purpose interface should look like, and not how the driver actually does it?
<re_irc>
<@dirbaio:matrix.org> both?
<re_irc>
<@dirbaio:matrix.org> I guess drivers have no hope of using embedded-hal traits with 5bit spi portably since e-h doesn't define these word types
<re_irc>
<@vollbrecht:matrix.org> we know that every platform that supports xbit transfer, works with ybit wide variable, where x*1bit <= y. So to simply and be a bit wasteful, it would be best to store each xbit transfer in an ybit variable. This would make the implementation for each hal simplest no?
<re_irc>
<@vollbrecht:matrix.org> so if we have enums that tell the driver what type of bit transfer we have. for example Bitlength:Len14 it would expect a &[u16] and for Bitlenght:Len5 it would be an &[u8]
<re_irc>
<@vollbrecht:matrix.org> if we dont encode the bitlength in the type rather have an seperate bitlength something in the e-hal traits
<re_irc>
<@vollbrecht:matrix.org> this would not allow for per transfer different bitlength rather have a fixed bitlenght for all transfers on a given driver instance.
<re_irc>
<@vollbrecht:matrix.org> but this is niche enough ?
<re_irc>
<@dirbaio:matrix.org> this seems some link order issue? "compiler_builtins" is trying to use stuff from "core", but "core" depends on "compiler_builtins". how does this even work?
<re_irc>
<@dirbaio:matrix.org> repro is literally "do a u32 division in a thumbv6 binary" lol
<re_irc>
<@dirbaio:matrix.org> oh no
<re_irc>
<@dirbaio:matrix.org> it needs thumbv6 AND build-std AND lto AND opt-level=s to reproduce
<re_irc>
<@dirbaio:matrix.org> oh it's fixed in latest nightly
<re_irc>
<@dirbaio:matrix.org> in the repro
<re_irc>
<@dirbaio:matrix.org> ...but latest nightly ICEs when compiling the full project :(
<re_irc>
<@thejpster:matrix.org> Now I always try and stick to stable, committing bootstrap crimes if strictly necessary. But it does mean I miss out on all the fun.
<re_irc>
<@dirbaio:matrix.org> stable branches only get fixes for stable features, so bootstrap crimes doesn't mean the nightly features are bug-free
<re_irc>
<@dirbaio:matrix.org> if anything they're more likely to have bugs because the code is older
<re_irc>
<@thejpster:matrix.org> This is true. But my crimes are usually only building libcore.
<re_irc>
<@dirbaio:matrix.org> build-std on stable?