Vertigo #$FF
I'm quickly coming to the opinion that, if you're doing deep-embedded development in anything except assembly language (or some other language with assembly's level of abstraction), you're just doing it wrong. Full fucking stop.
Sigh.
Two weeks and counting debugging this fucking live-lock bug with this UART, and Rust's utter inability to cooperate with me when debugging is just straight up infuriating.
Wolf480pl
@vertigo don't have much experience with microcontrollers, but ended up debugging low-level stuff multiple times and usually I was looking at disassembly and single-stepping instructions regardless of what language the software was written it.
The only way Rust could make it more difficult that I can think of is by spitting out horrible instructions that make the disassembly unreadable. But unreadable assembly is also usually suboptimal so I think they'd try to not do that...
Vertigo #$FF
@wolf480pl If you use a normal debug build, that is indeed the case. However, because we are optimizing for size, a lot of size optimization takes place before generating the final assembly result. As a result, the resulting assembly language listing bears relatively little relationship to the original source code listing.
Josias
@vertigo Does Forth fit?
Vertigo #$FF
@josias Yes. Very, very, very yes.
Nearly all Forth systems have source code which maps 1:1 with the produced object code. Even those systems which do not have exact 1:1 correspondance, the relationship between the generated assembly language and the original Forth code is usually obvious upon visual inspection.
In either case, Forth code is significantly easier to debug both interactively and in batch.
Csepp π©Έ
@vertigo @josias Asking as a Forth noob: How do you debug Forth? Do you run it in an emulator and step through it? Or add asserts and prints?
Vertigo #$FF
@csepp @josias This depends heavily on which forth environment you're working with. I cannot give specifics. However with swift-X, you can compile and run individual words and interrogate and altar variables, and so forth, exactly as if it were a host compiled program. So even though you're working on the target, the user interface is exactly the same as if you were programming on the host.
Santa Claes πΈπͺππ°π
Vertigo #$FF
@yrabbit Working with Rust would be OK if I had a target environment that fully supported a debug-mode build of the binary. But, since this is a small microcontroller with very limited flash, that is just not possible for our current environment.
I'd argue, based on this, that Rust is excellent for application development, or maybe large-scale kernel development. But, it's not ready for deep embedded work yet. It's just doesn't support debugging under such tight constraints.
Uglyhack
@vertigo @yrabbit I thought for embedded profiles the debug information was split into a separate file (and not included in the binary). Otherwise this should be fixable with https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo
YRabbit
@vertigo I recall that the architecture of the PDP-11 was such that it made it fairly easy to write directly in machine codes and without assembly language.
12724 123 -> MOV #123,(R4)+
That was because the codes strictly obeyed a very few rules:)
Yeah, I know, it's old way, it's considered almost indecent nowπ
ajft
@vertigo 30yrs since I did any embedded systems stuff and ye gods I'm enjoying reading what you write. Wishing you all strength to your debugging hammer
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.