dc_740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
rardiol has quit [Ping timeout: 248 seconds]
<re_irc>
<@wassasin:matrix.org> My experience with the uBlox SARA-R422-M10S is that ot'
<re_irc>
<@wassasin:matrix.org> * it's glitchy, so you might want to make the driver _very_ fail-safe
<re_irc>
<@wassasin:matrix.org> Examples include garbage bytes on the bus, hanging on operations, and UDP listen only working when you send a packet first (firmware update on their end is in progress)
<re_irc>
<@korken89:matrix.org> : Thanks for the heads-up!
<re_irc>
<@korken89:matrix.org> So far it seems to work, but I'll try to exercise the points you have to see if we get issues
<re_irc>
<@wassasin:matrix.org> Customers PCB didn't have the reset-trace routed to the microcontroller, so need to reset the modem by 'pressing' the pwrctrl pin for 16 seconds
<re_irc>
<@wassasin:matrix.org> * reset pin
<re_irc>
<@korken89:matrix.org> Ops 😅
<re_irc>
<@korken89:matrix.org> At least i connected that pin
<re_irc>
<@wassasin:matrix.org> Yeah I checked :')
<re_irc>
<@korken89:matrix.org> ^¥
<re_irc>
<@korken89:matrix.org> * ^^
<re_irc>
<@korken89:matrix.org> I've only been using TCP so far, so i guess it's time to test UDP
<re_irc>
<@korken89:matrix.org> Do you have a reproduction for how to get it to hang?
<re_irc>
<@korken89:matrix.org> I'd like to try it :)
<re_irc>
<@ondono:matrix.org> : A classic. I still don’t understand why so many people think this is an option
<re_irc>
<@wassasin:matrix.org> So the UDP-issue has to do with that the modem throws away UDP packets until you first send one out, similar to UDP hole punching
<re_irc>
<@wassasin:matrix.org> U-Blox has confirmed that this is a bug, and they will release a new firmware version for the modem Soon (TM)
<re_irc>
<@wassasin:matrix.org> What really is a bummer, is that it only works for a single IP address
<Darius>
interesting the modem is dodgy, IME their GPS stuff is pretty rock solid
<re_irc>
<@wassasin:matrix.org> So you need a fixed IPv4 address
<re_irc>
<@wassasin:matrix.org> +to send UDP packets from
<re_irc>
<@korken89:matrix.org> Right, makes sense
<re_irc>
<@korken89:matrix.org> Or continuously punch through i guess?
<re_irc>
<@wassasin:matrix.org> For the broken USART bus, I see garbage appearing sometimes on a logic analyzer, coming from the modem, and then it is unresponsive
<re_irc>
<@wassasin:matrix.org> : Not really a workable solution. Plus you need to know the IP address of the sender before actually getting the UDP packet sent
<re_irc>
<@korken89:matrix.org> : Alright, sounds like an adapter that looks for parsing errors to notify the MCU is issues will be needed in the end
<re_irc>
<@korken89:matrix.org> * of
<re_irc>
<@wassasin:matrix.org> Reproducing this behaviour is really difficult. It seems to happen when we do a lot of things in parallel
<re_irc>
<@ryan-summers:matrix.org> Can cargo workspace members have different build targets? I.e. can I have a binary crate and then lib crates in the same workspace?
<re_irc>
<@ryan-summers:matrix.org> Right now, I'm hitting an error when running "cargo test" on the target-unspecific "lib" crates with:
<re_irc>
error[E0463]: can't find crate for `test`
<re_irc>
For more information about this error, try `rustc --explain E0463`.
<re_irc>
error: `#[panic_handler]` function required, but not found
<re_irc>
error: could not compile `ads7924` due to 2 previous errors
<re_irc>
<@ryan-summers:matrix.org> Ugh I wish I could just tell it to avoid the .cargo/config in the repo root
<re_irc>
<@jamesmunns:beeper.com> : Tbh I avoid workspaces most of the time because of weird edge cases like this, ESPECIALLY when I have mixed host/target crates
<re_irc>
<@9names:matrix.org> the whole situation kinda sucks, especially because the book says this is what you should do
<re_irc>
<@ryan-summers:matrix.org> I might just move this to a separate repo honestly, just wanted to see if there was a minimal pain way to get this working
<re_irc>
<@ryan-summers:matrix.org> Because I don't want to maintain more CI workflows if unnecessary
<re_irc>
<@ryan-summers:matrix.org> Going to see if moving the "bin" up a level (so that it's not the root) resolves this. Technically, then .cargo/config wouldn't be in the search path and cargo shouldn't pick it up from the libs
markov_twain has quit [Ping timeout: 268 seconds]
markov_twain has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> So it works, but even more stupidly, cortex-m-rt then expects the memory.x at the repo root for some reason
<re_irc>
<@korken89:matrix.org> : Alright, I'll keep an eye open for weirdness!
<re_irc>
<@korken89:matrix.org> I hope I can port a lot of "nrf-modem" to just be "3gpp-modem" so one has all the "standardized" AT commands in a crate and only implement the extra
<re_irc>
<@korken89:matrix.org> +ones that are uBlox specific
<re_irc>
<@korken89:matrix.org> Quite nice that there is a standardized portion (at least on paper, I have not dug that deep yet)
<re_irc>
<@diondokter:matrix.org> : What would you port though?
<re_irc>
<@korken89:matrix.org> I like the interface of it, I'd really like to have a similar but a bit more generic
<re_irc>
<@korken89:matrix.org> So you can have the commuication (IPC vs UART vs ...) be a trait for example
<re_irc>
<@diondokter:matrix.org> Ah ok, yeah. The underlying code is very specific, that's why I wondered
<re_irc>
<@korken89:matrix.org> Not sure if it is a good idea yet though, just a direction for now :)
<re_irc>
<@korken89:matrix.org> It also gives me a chance to have a look at "embedded-io" traits
<re_irc>
<@korken89:matrix.org> They seem to be made for this usecase well and now I have a reason to try :D
<re_irc>
<@ryan-summers:matrix.org> Absolutely no clue on affordability though
<re_irc>
<@xiretza:xiretza.xyz> : PCBWay might be an option
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> : I'm a bit curious on that's going on then, has ublox said anything?
<re_irc>
<@korken89:matrix.org> When i run into the same issue i can talk to my ublox contact and see what they say as well :)
<re_irc>
<@ondono:matrix.org> : It depends a lot on what you want to make. A lot of these kinds of services can do some stuff themselves for cheap but externalize more complex parts.
<re_irc>
It also depends on where you are based. AFAIK, there’s more competitive options in the US vs Europe, and if you don’t mind taking for forever for delivery, there’s some cheaper providers in China.
<re_irc>
<@yatekii:matrix.org> : they want a phone number for an "instant quote" lol
<re_irc>
<@yatekii:matrix.org> : oh didn't know they machine too! it's not automatic quoting but it looks fine :) will try
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
markov_twain has quit [Quit: markov_twain]
jcroisant has joined #rust-embedded
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> I hope what I'm about to ask is not a super bad idea, but here goes…
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> I'm thinking of writing a panic handler, so that any panic information gets printed on my computer screen through the microprocessor's hardware USART.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> I've written a proof-of-concept, but calling it only mentions one file and one line, not the full unwind I'm used to.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Possibly of importance, I can't figure out what the "payload()" of the "PanicInfo" struct is supposed to contain. Whatever it is, it can't be downcast to a "&str".
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Am I doing something wrong, or is it more complex than I thought, or something different?
<re_irc>
<@dirbaio:matrix.org> : it's not really possible to do in embedded. To do that you need code that knows how to unwind, on std targets this is typically done by "libunwind"
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Do tell.
<re_irc>
<@dirbaio:matrix.org> and I think it needs (some) symbol/debug info flashed to the target, which you typically don't in embedded binaries
<re_irc>
<@dirbaio:matrix.org> not sure if it's possible or not, but I don't know of any project who has that working
<re_irc>
<@dirbaio:matrix.org> as an alternative, if you're developing, probe-run prints a nice stacktrace on panic
<re_irc>
<@dirbaio:matrix.org> it does the unwind on the computer side, not on the firmware
<re_irc>
<@dirbaio:matrix.org> or, if you want for debugging crashes of devices in the field
<re_irc>
<@diondokter:matrix.org> I've created a library specifically for this! Lemme get you a link
<re_irc>
take a raw registers+stack snapshot, somehow transfer it to the computer, and stackdump will do the unwind for you on the computer side too
<re_irc>
<@diondokter:matrix.org> I'd love to have more people use it and submit issues or ask for clarifications so I can improve it more 😁
<re_irc>
<@diondokter:matrix.org> Basically I want an excuse to work on it again
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Yes, I want this for development purposes.
<re_irc>
<@diondokter:matrix.org> If you have a debugger connected you can use probe-run if you're running your program through that. With that you get a nice function stacktrace.
<re_irc>
If you want a quick and dirty snapshot you could use stackdump-cli with the probe argument. It pauses the core and creates the snapshot through the debugging probe and give you a nice stack trace with functions and (best effort) variables.
<re_irc>
But if you want it to go through the uart, then stackdump is your best bet. Capture the memory and push it through the uart. If you can write the uart directly to a file, then stackdump-cli can open the dump and give you the trace. Alternatively you could create a little program based on stackdump-trace to automate this process
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Debugger, as in JTAG? Arduinos have no support for that, I think.
<re_irc>
<@xiretza:xiretza.xyz> the ARM ones almost certainly do
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Well yes, but it's not ARMs I'm using so the point is moot.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Oh wait
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> You mean the ARM Arduinos
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Here's the thing: AVRs absolutely support JTAG.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> But *I think* that Arduinos don't expose the relevant pins.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> “I think” being the operative words.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> > Currently only Cortex M is supported, but PR's are welcome!
<re_irc>
> Thank you, but…
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> ->
<cr1901>
it does the unwind on the computer side, not on the firmware <-- pedantic q: what does it mean to "do the unwind on the computer side"? I thought unwinding happened at runtime. But if you have a stackdump, then the runtime of the MCU is over :P
<re_irc>
<@diondokter:matrix.org> In theory the microcontroller could do its own unwinding, but it has too little memory to do that. You'd as a minimum have to include the debug info of the elf file in the flash. But for our 300kb program we get a 3mb elf file. Super inefficiënt
<re_irc>
<@diondokter:matrix.org> : Didn't know you were using AVR. But might be a nice project to work on 🙂
<re_irc>
You'll have to implement interrupt stack unwinding and the rest _should_ work
<re_irc>
<@diondokter:matrix.org> Could actually be a cool thing to do for me on Friday
<cr1901>
Does this crate rely on probe-rs to function? Might be interesting to add msp430 support, but me adding msp430 to probe-rs right now is unlikely
<re_irc>
<@diondokter:matrix.org> No, it's not dependent. Only the cli can use probe-rs to get to the info, but that's entirely optional
<cr1901>
As an alternative, I have an mspdebug-embedded driver crate to get info from msp430 micros
<re_irc>
<@diondokter:matrix.org> Ah, that one is 16 bit. I have to say that I wrote everything to assume everything is 32 bit just to make it work quickly. If all is well all those assumptions should be gone now, but it's possible I missed a place
<cr1901>
Well, AVR is 8-bit :P
<re_irc>
<@diondokter:matrix.org> Yep, same there
<re_irc>
<@diondokter:matrix.org> And probably you need to do something there as well because it's not all one address space. Don't know how DWARF debug info handles that
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> AVR is… sort of 8-bit, sort of 16-bit.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> The *ALU* has a width of 8 bits. The *memory bus* has a width of 16 bits.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Which is the deciding factor?
<cr1901>
Most 8-bit micros I know of support 16-bit addr bus
<cr1901>
8051, 6502, z80, AVR, probably 6809
<re_irc>
<@diondokter:matrix.org> Memory space, so probably 16-bit
lehmrob has quit [Ping timeout: 260 seconds]
<re_irc>
<@thejpster:matrix.org> A BlueCore is 16 bit but has 24 bit instruction addresses (and 16 bit data addresses).
<re_irc>
<@thejpster:matrix.org> Just in case you thought you’d get away with glib generalisations 😜🤣
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> I'm pretty sure that “glib” in this context is pronounced with one syllable, but just in case I'd like for you to clarify.
<re_irc>
<@thejpster:matrix.org> Yeah, no, I’m not talking gobjects
<cr1901>
g_main_loop_new() was just fine for async programming :P
<re_irc>
<@jamesmunns:beeper.com> cr1901 do you know of any 8-bit micros that DON'T have a 16-bit address space?
<re_irc>
<@jamesmunns:beeper.com> : Oh man that makes me think of the MSP430X, which has 16-bit address, except when it has 24-bit ones
<cr1901>
jamesmunns: Not offhand
<cr1901>
It's 20-bit address space, but yes I get the sentiment :'D