<cr1901>
dirbaio: FWIW, I have an application that cannot reliably be msp430 due to RAM requirements, so I'm prob gonna jump to the dark side and try embassy :P
<cr1901>
in the coming weeks
<cr1901>
YuhanLiin: If you're on the Matrix side, I'm on the IRC side
<re_irc>
<@yuhanliin:matrix.org> cr1901: I'm using element. Should we talk here?
<cr1901>
yuhanliin: Yes, talking here is fine. If anyone else is around tomorrow, I can get feedback too.
<cr1901>
Sometime in 2020, the other two msp430 maintainers went into hibernation. They still help me when needed, but I'm the only active member making sure msp430 Rust doesn't break at the moment.
<re_irc>
<@yuhanliin:matrix.org> So about joining the MSP430 team, I actually haven't been on the embedded side of things for quite a while. I can help with maintaining stuff and possibly additional development.
<re_irc>
<@yuhanliin:matrix.org> When are the WG meetings?
<cr1901>
Meetings are Tuesday at 3:00PM EST. That doesn't help you I think :P
<cr1901>
That's fine re: maintenance. I have a laundry list of things I need to do to get MSP430 stabilized. I just find your extra pair of eyes helpful.
<cr1901>
I'm not going to _delegate_ tasks to you or anything like that. If someone needs help w/ msp430, I'd like there to be someone else who can help me.
<cr1901>
If someone didn't point out the unsoundness w/ CriticalSection in 1.0.0, I would've gone and made a release not knowing it was unsound/would've missed it.
<cr1901>
yuhanliin: What's your time zone?
<re_irc>
<@yuhanliin:matrix.org> I should be able to lurk during the meetings (and lurk here at other times as well). I'm EST so I'll probably at work during the meetings.
<re_irc>
<@yuhanliin:matrix.org> Can probably participate in the meetings to an extent on some days.
<cr1901>
That's perfectly fine. I'm at the meetings usually anyway
<cr1901>
and if I'm not, I tell agg ahead of time
<cr1901>
Usually lurking as well. The one cool thing about Rust's ARM bias is that I can let the ARM ppl battle out what's best and then I steal what's appropriate ;)
<cr1901>
Anyways, this all works for me, thanks. I uhhh, forget the repo where I'm supposed to add you as maintainer. I'll ask agg in the morning/when he's around.
<re_irc>
<@yuhanliin:matrix.org> Interestingly enough `cortex-m` hasn't bumped `bare-metal` to 1.0.0 yet, to my knowledge
<re_irc>
<@yuhanliin:matrix.org> makes sense since it's a big change
<cr1901>
Really? Hmmm, that's fair. Well, there's less msp430 code to break, and less expectations of stability, for better or worse
<cr1901>
I still maintain AT2XT as a proof that each breaking change made still results in a working small firmware
<cr1901>
Meaning, _I_ don't care about breaking the API in bursts :P
<cr1901>
(We're stuck on nightly anyway until I at least do the asm!() port. I need to go on Zulip and get help w/ that)
<re_irc>
<@yuhanliin:matrix.org> I haven't been maintaining my HAL or PAC crates so things are probably broken. Haven't heard anyone raise issues with it tho so I've been working on other non-embedded stuff.
<cr1901>
Sure, and that's totally fair. But when I do need help w/ something, you've been pointing out stuff that I miss pretty consistently
<cr1901>
What is the advantages of using `export_name` vs `no_mangle`? Both seem to work AFIACT?
<cr1901>
yuhanliin: But perhaps I don't see the reason for the change other than "it's what you wanted to do"
<re_irc>
<@yuhanliin:matrix.org> using `no_mangle` allows me to not use a hash as the function name, since I can use the exported name instead, but we still use the hash name anyways
<re_irc>
<@yuhanliin:matrix.org> I guess we can still use `export_name`
<cr1901>
If `export_name` still works, I'd rather maybe introduce the `no_mangle` change in a separate PR that I can test separately. Is that okay?
<cr1901>
It probably is a user-invis change
<cr1901>
Just me wanting to test the new changes slowly :P
<re_irc>
<@yuhanliin:matrix.org> I can just revert back to `export_name` since it makes zero difference anyways
<cr1901>
Ack, thanks
rardiol has quit [Ping timeout: 256 seconds]
cr1901 has quit [Remote host closed the connection]
<re_irc>
<@luojia65:matrix.org> Loongarch support for rustc 1.57
<re_irc>
<@luojia65:matrix.org> I'd note their group to help them get upstream'd into rustc main branch, if that's possible we'd have a new target for rustc compiler at that time.
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc>
<@TimSmall:matrix.org> Aliexpress search has gone completely batshit - searching `cmsis dap atmel` gets me refractometers, some type of herbal medicine, and hemorrhoid cream. Perhaps their AI is entering a rebellious teenage phase.
<re_irc>
<@therealprof:matrix.org> TimSmall: That search was always horrible and pretty much useless. It wouldn't even find a product if you entered the full title and would produce random other articles instead...
<re_irc>
<@TimSmall:matrix.org> yeah, it got some sort of machine learning "upgrade" about 2 years ago which made it pretty bad, but since I last used it (~2 months ago), it's got way worse.
starblue has joined #rust-embedded
radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@therealprof:matrix.org> Possible. Ever since they upgraded their customer support to be non-human and I had a problem with a scammer the machine failed to resolve I've shut down my account and will never do any business with them again.
rardiol has joined #rust-embedded
<re_irc>
<@josfemova:matrix.org> TimSmall: Btw, Seeeduino Xiao m0's can be used just like those debug probes and sometimes end up being cheaper/more reusable
<re_irc>
<@TimSmall:matrix.org> josfemova: On that page, I was looking at the (ATSAM3U2C based) models which do USB high-speed, since I've already got a couple of CMSIS-DAP and Daplink probes (plus the WeACT mini-f4 has a CMSIS-DAP firmware too). HW/FW here: https://github.com/wuxx/nanoDAP-HS/blob/master/README_en.md - and also for comparison when debugging probe-rs vs. hardware probe issues.
<cr1901>
it has a 20-bit program counter
<cr1901>
everything else is 16-bit
<cr1901>
and not even C code can easily use more than 16 bits of the program counter
<re_irc>
<@ryan-summers:matrix.org> Yeah, so things like jump instructions, or data segments beyond the 64K boundary are awful
<re_irc>
<@ryan-summers:matrix.org> Doch. I use all 128K I have
<re_irc>
<@ryan-summers:matrix.org> Although that leverages IAR to handle the compilation / assembly generation. Don't know how well rust or msp-gcc work
<cr1901>
Never used IAR
<re_irc>
<@ryan-summers:matrix.org> Would not recommend
<re_irc>
<@ryan-summers:matrix.org> Very expensive for the exact same thing imo
<cr1901>
I've been meaning to experiment with > 64kB in Rust, but it's not a high priority right now.
<re_irc>
<@ryan-summers:matrix.org> Although to be honest, if you use msp-gcc at high optimization levels, there's some serious bugs that arise, like multiplication no longer working
<cr1901>
github.com/cr1901/AT2XT Fits in 2kB of Rust
<cr1901>
and 128 bytes of RAM
<cr1901>
(more like 70 bytes)
<cr1901>
Anyways, I resent ARM for taking out the 16-bits and making your microcontroller choices "ARM" and "RISCV". This is an emotional opinion rather than one objective, and I'm not likely to change it.
<re_irc>
<@ryan-summers:matrix.org> Not trying to argue with you :) MSP430 has been around a really long time and has proven itself as a useful tool
<re_irc>
<@ryan-summers:matrix.org> Was just curious about people using it in industry with Rust, since I would imagine memory constraints are problematic for real projects
<re_irc>
<@ryan-summers:matrix.org> And when I say "real", I mean "complex" (e.g. multiple peripherals, ICs, sensors, etc.)
<cr1901>
fat LTO seems to do alright
<re_irc>
<@ryan-summers:matrix.org> I'd be curious to compare similar C/Rust apps in terms of space. I'm at the phase where I'm hunting for bytes even in C
<cr1901>
I have those somewhere, but... there's absolutely no question, right now, that hand-written asm is smaller than Rust. This seems to be true for cortex-m r0 as well though
<cr1901>
My AT2XT firmware in C is about 1500 bytes w/ msp430-gcc, 1600-1700 w/ Clang, and 1940 w/ Rust
<re_irc>
<@ryan-summers:matrix.org> I've seen a lot of comparisons that have quoted about 10-20% code size increase for Rust, which imo is quite manageable
<cr1901>
Yea, not great. There's things I can do to get that down a bit tho
<cr1901>
and opts that Clang doesn't properly take (like dead code elimination of the prolog from noreturn main, somehow)
<cr1901>
Of course if I do unsafe opts I get even better savings :P
<cr1901>
I would say the inherent size diff is about 10%. None of the C version uses e.g. a bare-metal Mutex to sync vars
<cr1901>
In addition, I take advantage of multiple match patterns per arm, not possible in C. Also brings up code size (and not _quite_ equiv to C code)
<cr1901>
not quite semantically equivalent*.
<re_irc>
<@ryan-summers:matrix.org> How do you manage flashing? Dump a bin on there using msp-fet?
<re_irc>
<@ryan-summers:matrix.org> E.g. no comprehensive debug?
<cr1901>
Debug info works
<cr1901>
via mspdebug's gcc server
<cr1901>
err gdb*
<re_irc>
<@ryan-summers:matrix.org> Ah gotcha, yeah I've used mspdebug, just had forgotten about it
<cr1901>
I'm not porting the entirety of mspdebug to cargo flash tho
<re_irc>
<@ryan-summers:matrix.org> I actually looked into it and I think it's reasible
<re_irc>
<@ryan-summers:matrix.org> The msp tilib source code _is_ distributed by TI as open sourced
<cr1901>
I have some flash tools that use the old rf2500 protocol
<cr1901>
EEM is not documented in datasheets, and I don't have the willpower to figure out how it works via tilib
<re_irc>
<@ryan-summers:matrix.org> That's the same wall I hit a while back
<cr1901>
i.e. "get around the GPL problem using IPC"
<re_irc>
<@ryan-summers:matrix.org> Also, I get billions of random EEM errors from the Msp430Flasher utility that are indecipherable
<re_irc>
<@ryan-summers:matrix.org> If you've ever used micropython, you may get minorly triggered by the description of embedded-mode from mspdebug...
<cr1901>
?
<re_irc>
<@ryan-summers:matrix.org> The whole unprompted command interface is a hellscape for the pyboards
<re_irc>
<@ryan-summers:matrix.org> and is incredibly unreliable IME
<cr1901>
Well, I asked if dlbeer would relicense it/give an exception for Rust, and the answer was "no" (not b/c of anything he can control, tbf)
<re_irc>
<@9names:matrix.org> ooh, i didn't know there were DIP PIC32's.
<cr1901>
Oh so embedded MIPS PIC32 works finally... cool
<cr1901>
ryan-summers: I'll put it this way... choices are mspdebug, cargo flash using the embedded-mode of mspdebug, or someone besides me contributes a tilib/rf2500 binding to cargo flash. I'm not taking on that burden right now.
<re_irc>
<@ryan-summers:matrix.org> Again, not asking you to, just commenting :P
<cr1901>
(... is there any precedent for a cargo binary crate compiling and _installing_ a non-Rust binary as part of compiling the crate?)
<re_irc>
<@dirbaio:matrix.org> compiling sure
<re_irc>
<@dirbaio:matrix.org> installing it (touching files outside target/) would be extremely rude :D
<re_irc>
<@ryan-summers:matrix.org> I mean, unless someone typed a `cargo install <X>` command
<re_irc>
<@ryan-summers:matrix.org> E.g. rewrapping your utility as a crate
<re_irc>
<@dirbaio:matrix.org> hm, but "install" is "build" and then copy the output binary
<re_irc>
<@ryan-summers:matrix.org> You can use a cargo build script to build non-rust components
<re_irc>
<@dirbaio:matrix.org> from build.rs you can't distinguish between "build" and "install", so you don't know whether to install the second bin
<re_irc>
<@ryan-summers:matrix.org> I use it to build some javascript for a server+frontend project
<cr1901>
Well, what if I want to make it easy for someone to compile mspdebug as part of installing cargo flash?
<cr1901>
I guess I can say "grab the binary somewhere", but sadly it's a source release
<re_irc>
<@dirbaio:matrix.org> linking is forbidden due to gpi, right? m
<cr1901>
yes
<re_irc>
<@dirbaio:matrix.org> maybe embed the bin, and at runtime extract it to /tmp then run it
<re_irc>
<@dirbaio:matrix.org> and watch all windows antivirus flag you
<re_irc>
<@dirbaio:matrix.org> :S
<cr1901>
let's not.
<re_irc>
<@ryan-summers:matrix.org> And today, in things not to do as a developer...
<re_irc>
<@ryan-summers:matrix.org> ;)
<re_irc>
<@dirbaio:matrix.org> 🤣
<cr1901>
mspdebug is _not_ a difficult program to compile IMHO. I just don't like having to make Windoze users of Rust install make
<re_irc>
<@dirbaio:matrix.org> just link it conditionally on a Cargo feature, and tell the user "if you enable this then the resulting binary is GPL"
<re_irc>
<@adamgreig:matrix.org> Would it actually use anything from probe-rs to do its job or should it just be a new binary cargo-mspflash or whatever?
<cr1901>
agg: It might be acceptable as a new binary, but the idea was to eventually start replacing all the needs with calling out to mspdebug with Rust code in cargo-flash
<cr1901>
in an incremental approach that allows me not to disrupt the ecosystem, since I don't have enough energy to write the flashers myself (or enough other ppl to delegate work to)
<re_irc>
<@adamgreig:matrix.org> cargo-flash is a very thin wrapper around probe-rs library which is what understands the cmsis-dap/stlink/jlink/ftdi debug probes and currently cortex-m and risc-v architectures, so I guess that's where such work would need to go
<re_irc>
<@adamgreig:matrix.org> Not sure how piecemeal it could be done though
<re_irc>
<@adamgreig:matrix.org> In principle it would give you support in probe-run and cargo-embed and for rtt and stuff too though
<cr1901>
yea sorry, I've been using probe-rs and cargo-flash interchangeably
<cr1901>
I apologize
<cr1901>
I want to put the msp430 code into probe-rs*
<re_irc>
<@adamgreig:matrix.org> got it, makes sense then!
<re_irc>
<@ubik:matrix.org> `cargo-embed` question: what should I set as "name" of an RTT channel? Is it just for UI purposes?
<re_irc>
<@ubik:matrix.org> I'm getting no output, although I do get it if I just call `probe-run`.
<re_irc>
<@ubik:matrix.org> hm... I think somehow cargo-embed is not decoding the defmt format OK
<re_irc>
<@yatekii:matrix.org> ubik:matrix.org: master should work. crates.io does not have the newest decoder
<re_irc>
<@ubik:matrix.org> Oh, I see
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc>
<@ubik:matrix.org> Noah: yeah, that works. Thanks!
rardiol has quit [Ping timeout: 256 seconds]
rardiol has joined #rust-embedded
radens has joined #rust-embedded
<re_irc>
<@unrelentingtech:mozilla.org> man `.write()` on pac registers is such a footgun.. was debugging why the PLL isn't coming up on STM32L1, turns out the HAL was disabling the PLL's source in the same call it was enabling the PLL because it's a `.write()` instead of `.modify()`
kehvo has quit [Ping timeout: 268 seconds]
<re_irc>
<@unrelentingtech:mozilla.org> it should've been called `clear_write` or something
<re_irc>
<@dngrs:matrix.org> `steamroll`
<re_irc>
<@unrelentingtech:mozilla.org> btw, https://github.com/stm32-rs/stm32l1xx-hal/pull/14 is where this was. sadly the L1 hal doesn't seem to be actively maintained, the previous update PR is also not merged
<re_irc>
<@firefrommoonlight:matrix.org> unrelentingtech:mozilla.org: This reaction is understandable, but I think "footgun" isn't the right term. This comes down to how register access works. You can only write whole registers at a time. `modify` reads the register, and writes a new values that includes the previous value composed with the values you're modifying. `write` replaces the register content
<re_irc>
<@firefrommoonlight:matrix.org> So, once you undrestand that, the behavior makes sense, and I think you'll agree it's fine as is
<re_irc>
<@unrelentingtech:mozilla.org> I know how memory works of course :) still, `write` is not the most descriptive name. replacing and modifying are both "writes"
<re_irc>
<@9names:matrix.org> I strongly disagree firefrommoonlight as so many (maybe all?) E-H newbies blow their foot off using it while learning.
<re_irc>
<@9names:matrix.org> For a function that lets you specify the field values you wish to change, the intuitive understanding is that the value of other fields would be preserved, and that is not the case.