<mameluc[m]>
I am having some trouble with defmt-serial. Only some of the stuff gets written. My program "ends" in a sys_reset and I think not everything gets written to the serial port before that. Is there any way to "wait" until all is written?
<JamesMunns[m]>
0.7 had a pretty big soundness hole that I think was fixed in 0.8. I think 0.8 allows you to get the serial port back, which you probably could flush from?
<JamesMunns[m]>
so, it just drops any bytes that happen to be 13. I think.
gauteh[m] has joined #rust-embedded
<gauteh[m]>
socat on Mac is buggy, better to use stty and cat, if you're on mac
linfax has joined #rust-embedded
Guest7282 has joined #rust-embedded
<jannic[m]>
<JamesMunns[m]> "0.7 had a pretty big soundness..." <- Shouldn't 0.7 be yanked in such a case?
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<jannic[m]> "Shouldn't 0.7 be yanked in..." <- I would say so. I'm unsure which other versions had a similar issue.
NazarSolomakha[m has joined #rust-embedded
<NazarSolomakha[m>
Hi everyone! I'm in search of a Middle or Senior Rust developer with a strong background in hardware applications. We're offering a fully remote, contract position working with drone technology for a U.S. company. If you know someone perfect for this role and they get hired, our company, upstaff.com, will happily offer a $1,000 USD bonus as a thank you.
<NazarSolomakha[m>
* Hi everyone! I'm in search of a Middle or Senior Rust developer with a strong background in hardware applications. We're offering a fully remote, contract position working with drone technology for a U.S. company. If you know someone perfect for this role and they get hired, our company, upstaff.com, will happily offer a $1,000 USD bonus as a thank you.
<mameluc[m]>
with pull ups I get "malformed frame skipped" but yes generally it should probably be pull up. This works well enough for me and I can confirm crnl is probably better not used
<mameluc[m]>
this is with "malformed frame" on the first message. Hard for me to tell what it is supposed to be but the waveforms look good enough. Probably just some glitching when I re-init the uart the way I do
<JamesMunns[m]>
you could add some delay before reset or after reset to make it more clear
<JamesMunns[m]>
I'm spoiled by saleae and the serial decoder :D
<mameluc[m]>
I have a serial decoder on this analog discovery too but I don't know what the bytes are supposed to be. Are the defmt messages deterministic, would the first messages always be 1 or something?
<JamesMunns[m]>
the first thing is making sure what you're getting out of socat matches what the logic analyzer says
<JamesMunns[m]>
(no changed/corrupted/missed bytes)
<JamesMunns[m]>
if they match, you probably don't have to worry about looking at the logic analyzer. (we're trying to bisect the problem).
<JamesMunns[m]>
If they DO match, you can first at least check if the rzcobs encoding is right, you can decode each frame as it ends with a `0x00` byte
<JamesMunns[m]>
if THAT all looks fine, then you have to figure out the payload of the message, but you can also probably guess a bit at that by the content. defmt prints are basically interned IDs, so they'll always be something like "1 means 'hello'", "2 means 'init'", etc.
<JamesMunns[m]>
you can see if there's something weird about the first message on the second loop
<JamesMunns[m]>
like 0x01 becomes 0x81 or something
<mameluc[m]>
with pullups the logic analyzer understands the serial but socat doesn't. tee:ing to a log file gives nothing. With pulldown it works. strange
<JamesMunns[m]>
I wonder if the reset happens "too soon", some chips only mark `flush` done once the last bits are in the shift register
<JamesMunns[m]>
pull down might hold the line low enough to complete a stop condition correctly?
<mameluc[m]>
good point, a little delay would not hurt
<JamesMunns[m]>
at 115200, I'd delay 100us or so to allow for a full character time
<JamesMunns[m]>
could use embassy time or just cortex_m delay/nop loop
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
<mameluc[m]>
still a delay would not help the first loop but good to have it there
<JamesMunns[m]>
What does the scope trace look like with the delay? do the chars before/after the gap look reasonable? which one is socat glitching on?
<JamesMunns[m]>
btw with tee, you need to open the resulting file with a hex editor, like xxd or hexyl, it's gunna be all control characters
<JamesMunns[m]>
dunno if you tried to look at it with a text editor or something
<mameluc[m]>
yup
<JamesMunns[m]>
(idk if tee is trying to do buffering and just never actually seeing a newline and never flushing)
<mameluc[m]>
when I get something in the file it matches perfectly with what the analyzer says
<mameluc[m]>
when it doesn't work I get nothing
<mameluc[m]>
but eh, this will have to do for now.
<mameluc[m]>
Seems like it sometimes works and sometimes not
<mameluc[m]>
thanks for the help debugging 👍️
<JamesMunns[m]>
I've never found pipe utils for binary serial data that I love. I almost always end up writing a small tool with `serialport-rs` or `tokio-serial`.
<JamesMunns[m]>
Anyway, good luck, maybe just add some sacrificial dummy logs on startup so you don't miss anything important :D
<JamesMunns[m]>
I would guess it's getting out of sync or corrupted on reboot, that's the whole point of rzcobs, it allows for resynchronization after one corrupted packet, which means that you can recover
<JamesMunns[m]>
On a reset you'll get two `0x00` back to back, I think this can cause the decoder to print the "malformed" message
<dirbaio[m]>
after you do that, the RPI-RP2 drive should no longer show up for the probe, and probe-rs should start working
<dirbaio[m]>
(korken89 Noah is it intended that they don't come with firmwaer?)
<dirbaio[m]>
s/firmwaer/firmware/
korken89[m] has joined #rust-embedded
<korken89[m]>
They will come with firmware
<korken89[m]>
I sent Adam Hott a prototype I build by hand
<dirbaio[m]>
ahh okay
<AdamHott[m]>
wow one step forward two steps back, I run: DEFMT_LOG=off cargo build --release --bin app
<AdamHott[m]>
from the root of the firmware, and I get: error: failed to install component: 'llvm-tools-preview-aarch64-apple-darwin', detected conflict: 'lib/rustlib/aarch64-apple-darwin/bin/llc'
<AdamHott[m]>
korken89[m]: thanks again!
<dirbaio[m]>
something in your rustup is broken, no idea what
<AdamHott[m]>
I updated rustup and removed the llvm-tools-preview, tried to build again with previous command: error: failed to install component: 'rust-std-thumbv7m-none-eabi', detected conflict: 'lib/rustlib/thumbv7m-none-eabi/lib/liballoc-ea6fba2d727bcf6d.rlib'
<sjm42[m]>
I have a sincere question. I already have a CMSIS-DAP probe and a BlackMagic debug probe, both are flashed on an STM32F411 "black pill" board.
<sjm42[m]>
Should I obtain a rusty probe too, and why? Yeah, I fully agree that just coolness is also a thing. 🙂
<korken89[m]>
sjm42[m]: > <@sjm42:matrix.org> I have a sincere question. I already have a CMSIS-DAP probe and a BlackMagic debug probe, both are flashed on an STM32F411 "black pill" board.
<korken89[m]>
> Should I obtain a rusty probe too, and why? Yeah, I fully agree that just coolness is also a thing. 🙂
<korken89[m]>
If you want a probe that supports high speed and 1.8-3.3v IO voltages it could be something consider :)
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<AdamHott[m]>
<dirbaio[m]> "these errors make no sense" <- I uninstalled everything and reinstalled everything and successfully flashed the probe! I have to run for now, but will test more later! Thanks for everything, as always dirbaio korken89 We will solve this!
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
linfax has quit [Ping timeout: 264 seconds]
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
<JamesMunns[m]>
postcard-rpc v0.4 released, now with optional serial deps (for y'all using it with TCP/UDP), and nicer macros :)
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]>
Nice!
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Hey speaking of postcard and [de]ser, do y'all have a favorite way of serializing structs and enums in a low-code way that uses a fixed format?
<firefrommoonligh>
I wonder if maybe Serde could help here
<firefrommoonligh>
* postcard and \[de, * [de\]ser, do, * a fixed/flexible format?
<dirbaio[m]>
but back to the "wrap the C driver" strat instead of "yolo RiiR"?
<diondokter[m]>
Yup
<dirbaio[m]>
last I checked these dma_map/dma_unmap were implemented as noops in their OSAL
<diondokter[m]>
Getting stuck on this DMA thing. At some point it just starts reading from the address I give it. I don't know how to turn that into SPI reads
<diondokter[m]>
Really?
<dirbaio[m]>
it seems to be some weird remnant from other wifi chips working over PCI, where you have to setup some IOMMU or something to do DMA
<diondokter[m]>
Hmmm
<dirbaio[m]>
or maybe they were noops and unused
<dirbaio[m]>
I don't remember
<diondokter[m]>
Well, it's used now... I can't actually find the zephyr implementation of this
<diondokter[m]>
They already implement the BAL ops!
<diondokter[m]>
I just need to pass that
<diondokter[m]>
Gotcha
<dirbaio[m]>
why nrf71? just curious
<diondokter[m]>
Why work on it?
<dirbaio[m]>
yea
<dirbaio[m]>
vs something else, like esp32
<diondokter[m]>
Mostly curiosity. And apparently I have a desire to go insane
<dirbaio[m]>
🤣🤣🤣🤣
<dirbaio[m]>
okay
<diondokter[m]>
I've gotten much further than the last try a year ago haha
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
I don't get what they're doing with the nrf71
<dirbaio[m]>
I wouldn't be surprised if sales flop due to it being impossible to use with other RTOSs/MCUs due to the driver being like this
<diondokter[m]>
I actually spoke with two Dutch people from nordic today. When I told them I was trying to use the nrf70 with no zephyr and the OSAL layer, they didn't say anything but their faces said I was mad for trying hahaha
<dirbaio[m]>
so they KNOW 🤣
<dirbaio[m]>
but why
<dirbaio[m]>
why do they do this
<diondokter[m]>
They're all in on Zephyr
<diondokter[m]>
They don't care about anything else
<dirbaio[m]>
for their MCUs sure
<dirbaio[m]>
but if you want to drive sales of a non-MCU wifi chip you want to make it easy for literally everyone to use it, no matter what MCU/RTOS they're using
<dirbaio[m]>
i'd believe it's a big brain play to boost sales of their MCUs if the nrf71 was exceptionally good. like in price or features
<dirbaio[m]>
but ... it's not the case:|
<dirbaio[m]>
* the case :|
<dirbaio[m]>
in a world that esp32 exists
<dirbaio[m]>
s/that/where/
<diondokter[m]>
Well, they think that the overlap of people wanting to use nordic chips and people wanting to use zephyr is 100% I think
<dirbaio[m]>
nordic MCUs sure
<diondokter[m]>
🤷♂️
<dirbaio[m]>
¯\_(ツ)_/¯ indeed
<JamesMunns[m]>
<firefrommoonligh> "Hey speaking of postcard and [de..." <- Do you mean "design your own", or "describe an existing/external binary format"
pbsds has quit [Ping timeout: 264 seconds]
pbsds has joined #rust-embedded
fuse117[m] has joined #rust-embedded
<fuse117[m]>
<diondokter[m]> "Well, they think that the..." <- My colleague and I have spoken with at least two Nordic people in the US over the last month or two. They did seem to assume we were using Zephyr and also inquired into to why we weren't working with them to deploy our products (prototypes). I am not sure how or why we would work with them to deploy devices. The questions were actually a tad confusing. However, they became really
<fuse117[m]>
interested when we said that w were running baremetal Rust. They have asked to have some follow-on meetings to learn more about what we are doing and how.
<fuse117[m]>
s/w//
<diondokter[m]>
Oh yeah, especially Nordics engineers are into Rust. Seems to me it's mostly higher (technical) management holding off the boat
<diondokter[m]>
But really, they care most about sales. If there's enough sales for Rust projects, it'll get important to them
<fuse117[m]>
"they care most about sales"... don't we all
<diondokter[m]>
Well, they want the chicken before they invest in an egg
<diondokter[m]>
* the chicken first before they
<dirbaio[m]>
> inquired into to why we weren't working with them to deploy our products (prototypes). I am not sure how or why we would work with them to deploy devices
<dirbaio[m]>
probably wanted to sell you their iot deployment fleet management cloud thingy https://nrfcloud.com
<fuse117[m]>
On of the individuals we spoke is an engineer, and he certainly showed the most interest in Rust. The other was sales manager. He seemed more interested in the market my colleague and I are trying to get into.
<diondokter[m]>
Yes, the casts are required because they keep casting everything to void pointers for some reason
<JamesMunns[m]>
🦋 is this object oriented programming?
dnm has quit [Ping timeout: 252 seconds]
therealprof[m] has joined #rust-embedded
<therealprof[m]>
The story I've been told is that Nordic got tired by the huge amount of work they have to spend on developing all custom BSPs and explaining it's use to people so they decided on picking up a modern embedded OS and put their efforts into that instead. Makes a ton of sense to me.
<therealprof[m]>
s/it's/its/
dnm has joined #rust-embedded
<diondokter[m]>
therealprof[m]: Makes sense because Zephyr is pretty popular. But it might be the wrong basket for them to have put all their eggs in if it turns out people are gonna move to something else. But the embedded space is very conservative, so... maybe that won't happen
<therealprof[m]>
Well, I do think it also became popular because of Nordics endorsement.
<therealprof[m]>
It's actually not too different from a lot of other companies (NXP, ST, Cypress/Infineon), who put a shitload of work into not only creating customising some OS but building a whole ecosystem with IDE and whatnot around it.
<therealprof[m]>
s/creating//
<diondokter[m]>
In my opinion that makes a ton of sense for C. You can't do abstraction well in C.
<diondokter[m]>
But with Rust with async and embedded-hal and the other common traits I feel we do it much better
<therealprof[m]>
Zephyr is actually quite nice if it is what one is looking for.
<therealprof[m]>
It is a whole operating system, so you get things like processes, networking stack, a shell with utilities. It's quite fun to play around with.
<therealprof[m]>
Not sure how or if I would use it for a real project though.
<therealprof[m]>
It has all the same diseases an old no-MMU suffers from: Crashes due to buggy drivers, stack overflows, out of memory situation, lack of determinism...
<therealprof[m]>
* old no-MMU OS suffers from:
<dirbaio[m]>
so all the good old C issues :D
<thejpster[m]>
To be fair Classic MacOS has those issues and it was written in Pascal
<therealprof[m]>
I don't think those are C issues.
<therealprof[m]>
Linux is also written in C and has none of those problems.
<dirbaio[m]>
Linux can also crash due to shit drivers
<dirbaio[m]>
as nvidia users will know 🥲
<dirbaio[m]>
Linux has much more users than zephyr so its drivers are usually better
<therealprof[m]>
Sure. I also wrote my fair share of bugs. But if a driver crashes, then it's in most cases only the driver that crashes, not the whole kernel. And if a user space application crashes, then well, the OS couldn't care less.
<dirbaio[m]>
yeah...
<dirbaio[m]>
so an MMU mitigates C problems, so Rust helps much more in no-mmu systems 🦀
<therealprof[m]>
I don't think a MMU mitigates C problems but I fully agree that Rust is a much better fit, especially without MMU.
<therealprof[m]>
But interacting with an OS running on an MCU is just so much fun and it doesn't exist in Rust.
SanchayanMaity has quit [Ping timeout: 252 seconds]
SanchayanMaity has joined #rust-embedded
AmanieudAntras[m has quit [Quit: Idle timeout reached: 172800s]
amaanq[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
what doesn't exist ... an OS for an MCU written in Rust?
<whitequark[cis]>
do you classify embassy as an OS?
<whitequark[cis]>
I wouldn't disagree with that, it's just a little surprising
<dirbaio[m]>
yes and no?
<dirbaio[m]>
yes because it gives you the things a typical C RTOS gives you (tasks, mutexes, IPC, scheduling, preemption)
<dirbaio[m]>
no because the mechanism it uses to do that is different: async, which is transformed into state machines by the compiler, instead of a real OS kernel doing context switching etc
<whitequark[cis]>
it could be classified as an exokernel
<whitequark[cis]>
but also, is tokio an OS?
<whitequark[cis]>
(I don't think I would disagree with that either! tokio as a semi-transparent virtualization layer)
<dirbaio[m]>
tokio isn't an OS because it's not self-contained, it calls into Linux
<dirbaio[m]>
OSs talk to the hardware
<M9names[m]>
OS's often talk through a hypervisor - is software indistinguishable from hardware not software any more?
<dirbaio[m]>
hypervisors pretend to be hardware
<M9names[m]>
if i wrote an program that hosted other programs and only talked the hardware exclusively through an API provided by BIOS/EFI, is that not an OS?
<dirbaio[m]>
no, that's an EFI application :)
<M9names[m]>
i think we're going to have to agree to disagree about this definition 😄
<dirbaio[m]>
I guess you'll say "and MS-DOS is a BIOS application then?" :P
<dirbaio[m]>
MS-DOS didn't just use the BIOS though?
<dirbaio[m]>
yeah
<dirbaio[m]>
I guess defining "OS" is hard 🤣
<JamesMunns[m]>
This goes back to my "Wanting an RTOS is often an X/Y problem"
<JamesMunns[m]>
like I wouldn't call embassy an rtos, and even after suggesting rtic call themselves a "hardware accelerated rtos", I feel like those are both "I can't believe it's not RTOS" lol
<JamesMunns[m]>
they certainly have RTOS aesthetics