<re_irc>
< (@dkhayes117:matrix.org)> How do I read these sizes correctly? Like hex to KiB. Probe Run says 76 KiB was flashed. How do I get that from cargo size?
<re_irc>
< (@dkhayes117:matrix.org)> I used "size --release --bin app -- -A -x"
<re_irc>
< (@jamesmunns:beeper.com)> "-B" is the simpler one you usually see
<re_irc>
< (@grantm11235:matrix.org)> : Doesn't it also include ".data"?
<re_irc>
< (@jamesmunns:beeper.com)> (instead of "-A")
<re_irc>
< (@jamesmunns:beeper.com)> ".data" is a RAM section. ".rodata" is the flash initializer data for that ram section
<re_irc>
< (@jamesmunns:beeper.com)> (and ".bss" is the zero-initialized RAM section)
<re_irc>
< (@jamesmunns:beeper.com)> and ".uninit" (and maybe ".defmt"?) are also pre-set RAM sections.
<re_irc>
< (@jamesmunns:beeper.com)> (RAM sections don't need to be flashed, they are handled by the initialization code before main, copied/initialized from the info from flash)
<re_irc>
< (@adamgreig:matrix.org)> .data takes up flash and ram, .rodata is for things that never get copied into ram
<re_irc>
< (@adamgreig:matrix.org)> (in cortex-m-rt's linker script anyway)
<re_irc>
< (@jamesmunns:beeper.com)> hard disagree, unless I'm very wrong?
<re_irc>
< (@jamesmunns:beeper.com)> those live in ".text"
<re_irc>
< (@jamesmunns:beeper.com)> hold on, lemme pull up the linker script lol
<re_irc>
< (@adamgreig:matrix.org)> .text is code and some constant pools that live near code
<re_irc>
< (@adamgreig:matrix.org)> a non-mut (and no interior mut) static would like "static X:u32=12;" would go in .rodata and be read directly from flash when accessed, a static mut goes in .data and gets copied into ram at startup by c-m-rt's reset vector and then has an address in ram
<re_irc>
< (@jamesmunns:beeper.com)> huh. did that change from the old days?
<re_irc>
< (@adamgreig:matrix.org)> I think this has always been the case long before embedded rust
<re_irc>
< (@adamgreig:matrix.org)> I mean, you're definitely making me doubt myself now, but I'm on mobile and can't easily pull up the linker script lol
<re_irc>
< (@jamesmunns:beeper.com)> im on my pc and using nm to dump a recent program lol
<re_irc>
< (@dkhayes117:matrix.org)> -B output for same binary
<re_irc>
0x12008 0x6c 0x3fb0 90148 16024 app
<re_irc>
text data bss dec hex filename
<re_irc>
< (@dirbaio:matrix.org)> that one is a lie, "text" is vector_table+text+rodata :D
<re_irc>
; 0x144+0xe564+0x3960
<re_irc>
0x12008
<re_irc>
< (@dkhayes117:matrix.org)> I checked the math, and that is correct
<re_irc>
< (@dirbaio:matrix.org)> tldr on how to interpret that is:
<re_irc>
flash usage is "text + data"
<re_irc>
ram usage is "data + bss"
<re_irc>
< (@jamesmunns:beeper.com)> hmm
<re_irc>
< (@dirbaio:matrix.org)> * the short "size" output
<re_irc>
< (@jamesmunns:beeper.com)> I've like, written articles and given talks about this, and been totally wrong, and like... no one ever called me on it?
<re_irc>
< (@dkhayes117:matrix.org)> I've read that by the way :)
<re_irc>
< (@jamesmunns:beeper.com)> I owe you a beer , sorry for any unintended heart attacks :p
<re_irc>
< (@adamgreig:matrix.org)> I've read that blog post and never noticed 🙈
<re_irc>
< (@jamesmunns:beeper.com)> Today (actually many years ago), _I_ was the one who was wrong on the internet.
<re_irc>
< (@adamgreig:matrix.org)> Well I spent two hours chasing down what seemed like horrific weird ub in libusb where some code was timing out or taking forever even though it was *identical* to the other working code... only to eventually finally discover I was just accidentally putting khz in the hz hole in the slow code and that's why the usb transfers were taking 1000 times too long to complete lol
<re_irc>
< (@adamgreig:matrix.org)> So, good Thursday lol
<re_irc>
< (@jamesmunns:beeper.com)> (I am no stranger to being dumb and wrong!)
<re_irc>
< (@adamgreig:matrix.org)> They do say it's good to have extra bits for green on account of the eye being more sensitive or whatever
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I was getting REAL confused why my leds were always a red or blue/green, but never blue
<re_irc>
< (@jamesmunns:beeper.com)> (saying it like that makes it obvious, but I was also sleep deprived, and that was after like 6 hours of writing all the other code)
<re_irc>
< (@dkhayes117:matrix.org)> I spent quite a while trying to figure out why my board was pulling some much current only to find the debugger was still attached and plugged in :P
<re_irc>
< (@jamesmunns:beeper.com)> I thought I had fried the leds or something lol
<re_irc>
< (@adamgreig:matrix.org)> It usually sounds obvious when you explain it afterwards lol
<re_irc>
< (@dkhayes117:matrix.org)> * so
<re_irc>
< (@adamgreig:matrix.org)> I was sure I was chasing down something where whether I moved the usb handle in memory or not was affecting whether the transfers worked or timed out..... no
<re_irc>
< (@grantm11235:matrix.org)> : That's why I like to do "let RGB{ r, g, b } = old_rgb; let new_rgb = RGB{ r, g, b }"
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I mean there are a ton of other ways I COULD have done it
<re_irc>
< (@jamesmunns:beeper.com)> or like, not been lazy and defined an extra RGB8 type that wasn't needed
<re_irc>
< (@jamesmunns:beeper.com)> but hey, that's what sleep deprivation will do to you
<re_irc>
< (@adamgreig:matrix.org)> Surprised rustc didn't catch it for you :p
<re_irc>
< (@jamesmunns:beeper.com)> it was coming in off the wire
<re_irc>
< (@xobs:matrix.org)> Hey all. I'm trying to build some stuff on "riscv32imac-unknown-xous-elf" with rust-1.65.0, and I'm getting linker errors in "rust-lld". Is anyone else using rust-1.65.0 yet? What about on "riscv32imac"? Alternately, has anyone encountered "offset is outside the section" errors?
<re_irc>
< (@xobs:matrix.org)> The entire error message from cargo is "rust-lld: error: E:\Code\Xous\Core\target\riscv32imac-unknown-xous-elf\release\deps\pddb-8aba67b084ba8fc1.pddb-b3f235aec8c95441.n927u1iqdxcieg4.rcgu.o.rcgu.o:(.rodata.cst32): offset is outside the section"
<re_irc>
< (@adamgreig:matrix.org)> 1.65 is the first with llvm15 so that's probably the immediate cause
<re_irc>
< (@xobs:matrix.org)> Hmm... That's slightly concerning. I really need to get these patches upstreamed so that it's easier to test things.
<re_irc>
< (@xobs:matrix.org)> What would be the best way to narrow this down?
<re_irc>
< (@adamgreig:matrix.org)> one option is to bisect nightlies to find the exact one that breaks, but my bet is you'll find it's "the one where it swaps to llvm15" which isn't very informative (though I guess you could double-check...)
<re_irc>
< (@adamgreig:matrix.org)> otherwise I'd probably start by poking around the linker script to see if you can tweak something to appease it, which might be informative as to what changed
<re_irc>
< (@adamgreig:matrix.org)> I don't know about bisecting actual llvm commits, that sounds much more annoying
<re_irc>
< (@xobs:matrix.org)> Hmm... From what I understand, "rust-lld" doesn't have a linker script. At least it doesn't appear to be able to generate one.
<re_irc>
< (@adamgreig:matrix.org)> ah, this is a std platform so it's just using the default linker script I guess?
<re_irc>
< (@xobs:matrix.org)> Yeah. I guess maybe at this point since I'm adding libstd support and have an MMU maybe it no longer counts as an "embedded" platform :-/
<re_irc>
< (@adamgreig:matrix.org)> interestingly the riscv-rt linker script seems to be broken on 1.65
<re_irc>
< (@xobs:matrix.org)> Would it be better to post a bug on the bugtracker? Or is there another forum I should go to? I suspect there are very few who use "riscv32imac" with "libstd". But I do wonder if anyone else is experiencing it, whether using riscv, arm, or other targets.
<re_irc>
< (@adamgreig:matrix.org)> yea, probably worth opening an issue on rust-lang/rust, especially if this is a stable-to-stable regression
<re_irc>
< (@adamgreig:matrix.org)> you could potentially try using a different linker, too? like riscv32-unknown-elf-gcc or -ld
<re_irc>
< (@adamgreig:matrix.org)> (assuming you have a working gcc toolchain for that target which I guess might not be the case...)
<re_irc>
< (@xobs:matrix.org)> I can try that, thanks. We don't do anything special, so "riscv64-unknown-elf-ld" should work just fine.
<re_irc>
< (@xobs:matrix.org)> Hmm... I'm missing something. How can I set the linker? I've set it in ".cargo/config" but it looks like cargo is passing "--eh-frame-hdr". Let me try and figure out how to make it not do that.
<re_irc>
< (@xobs:matrix.org)> Changing the linker flavor does not make that option go away.
<re_irc>
< (@adamgreig:matrix.org)> usually just ""-C", "linker=arm-none-eabi-gcc"" in ".cargo/config.toml" would do the trick for me on arm
<re_irc>
< (@xobs:matrix.org)> It looks like my gcc was 8.3.0 which doesn't support "--eh-frame-hdr". I'm using the esp32 riscv compiler which I also happened to have around, and that appears to have linked it. Though I think I just ran into the same "riscv-rt" bug you mentioned above, so thanks for mentioning that!
<re_irc>
< (@xobs:matrix.org)> Alright, I have no idea how to convince "ld" to accept this linker script for the loader. But I can link the loader just fine using "lld". And you're right, using gcc as a linker rather than "rustc-lld" does result in a working build.
<re_irc>
< (@xobs:matrix.org)> : The magic incantation that got it working was to use a newer gcc and add this to ".cargo/config":
<re_irc>
< (@dkhayes117:matrix.org)> Does it make more sense, when defining a crate's Error enum variants, to use the full path or just "use" the path? IE
<re_irc>
use serde_json::error::Error as JsonError;
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> i don't think it makes much difference, but I'd probably use the full path if it was the only time I prefer to that item in this file, and otherwise "use" it at the top if I'm going to refer to it multiple times?
<re_irc>
< (@orclev:matrix.org)> That's really kind of a style question, functionally I don't think it makes a difference. Personally I kind of like the simplicity/explicitness of the full paths, although if the wrapped Error types are deeply nested in modules I could see that getting a little annoying.
<re_irc>
< (@dkhayes117:matrix.org)> Yeah, I'm just being pedantic :)
<re_irc>
< (@dirbaio:matrix.org)> both are fine, do whatever you like the most :D
<re_irc>
< (@dkhayes117:matrix.org)> : Thats the problem, I can't decide lol
<re_irc>
< (@dirbaio:matrix.org)> then toss a coin :D
<re_irc>
< (@dkhayes117:matrix.org)> 2 out of 3, or 3 out of 5 ?
<re_irc>
< (@dirbaio:matrix.org)> lol
<re_irc>
< (@dirbaio:matrix.org)> dunno, in general I try to avoid renaming imports with "as"
<re_irc>
<eekle> Flip a coin, then in the moment of terror when its in the air
<re_irc>
<eekle> youll know what you truly want
<re_irc>
< (@dirbaio:matrix.org)> because it confuses me, having something around with a name different than the "original" one
<re_irc>
< (@dirbaio:matrix.org)> except if referring to that type lots of times
<re_irc>
< (@dirbaio:matrix.org)> +and the original path is too long
<re_irc>
< (@orclev:matrix.org)> It can be nice to rename modules but leave the actual type names intact.
<re_irc>
< (@dkhayes117:matrix.org)> I think the full path might be better. It's a little more verbose when reading, but no confusion on where they come from.
conplan has joined #rust-embedded
<re_irc>
<meckispaghetti> Hey folks. I just wondered: Are there virtual machines / emulators to run and debug your embedded programs, or do you always flash it onto device?
<re_irc>
I’m just curious if there is a way to comfortably test pins/leds/ports whatever. Have never done any embedded development before.
<re_irc>
< (@orclev:matrix.org)> qemu I think is the emulator that gets used most often, but for what it's worth I pretty much always just test it on the device
<re_irc>
< (@adamgreig:matrix.org)> generally the emulators can run your business logic code, but you may as well run that on your real computer, and they don't often emulate all the mmio/peripherals or anything off-board very well (though there are exceptions), so generally people test on hardware - you can set up hardware so that e.g. CI automatically runs code on it and gathers test results
<re_irc>
< (@adamgreig:matrix.org)> there are some emulators that are better, and of course you could also build such a thing (often on top of something like qemu that can emulate the cpu core), but it's usually a lot of work to set up
<re_irc>
<meckispaghetti> Interesting, thank you guys!
<re_irc>
Let’s say you are developing "bare metal" on a chip without operating system. How do you print out debug messages? Connecting a little screen and using it as stdout?
<re_irc>
Sorry for my newbie questions 😅
<re_irc>
< (@k900:0upti.me)> Most of the time it's a serial port connected to a computer
<re_irc>
< (@k900:0upti.me)> Or these days a serial port connected to a serial-to-USB converter connected to a compute
<re_irc>
< (@k900:0upti.me)> * computer
<re_irc>
< (@k900:0upti.me)> Many development boards even come with serial-to-USB on the board itself, so you can connect to them without extra hardware
<re_irc>
< (@k900:0upti.me)> (which is usually just a second microcontroller connected to the debug interface of the primary one)
<re_irc>
<meckispaghetti> That’s nice, good to know.
<re_irc>
< (@k900:0upti.me)> The debug interface usually also gives you a bunch of other ways to control the hardware
<re_irc>
< (@k900:0upti.me)> So you can do the same kind of things you would do when debugging a more traditional application on top of an OS
<conplan>
does debug_assertions only work if you use the standard library
<re_irc>
< (@k900:0upti.me)> Like stepping through code, seeing the values in memory and so on
<re_irc>
< (@ryan-summers:matrix.org)> Actually, nowadays debug printing often goes through your debug probe
<re_irc>
< (@ryan-summers:matrix.org)> Take a look at RTT and defmt-based approaches such as probe-run. It basically has a RAM ring buffer on the device that IO gets printed into and the probe reads data out of that buffer from the device directly (as far as I understand it)
<re_irc>
< (@ryan-summers:matrix.org)> Yeah serial ports work, but they're not always available and are usually pretty bandwidth limited. RTT is much nicer and easier to use imo
<re_irc>
< (@ryan-summers:matrix.org)> Plus they still have to get setup, so you can't debug early in your init process
<re_irc>
<meckispaghetti> Amazing stuff, I already love it 😂
<re_irc>
< (@maik93:matrix.org)> can it be possible that I have just bricked an STM32 with the call "cortex_m::asm::wfi();"? I'm not able to flash it again 😅
<re_irc>
< (@adamgreig:matrix.org)> by default wfi enters a sleep mode where debug access is disabled
<re_irc>
< (@adamgreig:matrix.org)> if you have reset connected up to your programming probe, enable connect-under-reset to get it going again
<re_irc>
< (@adamgreig:matrix.org)> if not, try using the boot0 pin to reboot into the built-in bootloader, from where you can also debug as usual
<re_irc>
< (@adamgreig:matrix.org)> you can set bits in the dbgmcu register to tell it to keep debug alive during sleep (remember to disable those once you're actually in production!), or just skip sleep while debugging
<re_irc>
< (@ryan-summers:matrix.org)> What STM32 is it? Probe-rs _should_ handle this for some families
<re_irc>
< (@ryan-summers:matrix.org)> But it's not on everything yet
<re_irc>
< (@maik93:matrix.org)> it's an STM32F767
<re_irc>
< (@maik93:matrix.org)> thanks ! I managed to connect and make a full chip erase with STM32 Cube Programmer
<re_irc>
< (@ryan-summers:matrix.org)> Are you using probe-rs-based tools for flashing or no?
<re_irc>
< (@ryan-summers:matrix.org)> Based on my review of the code, probe-rs should handle the dbgmcu registers for this
<re_irc>
< (@maik93:matrix.org)> : yep, both "cargo flash" and "cargo embed" throws errors while trying to flash
<re_irc>
< (@ryan-summers:matrix.org)> Ah no, I lied
<re_irc>
< (@ryan-summers:matrix.org)> It's not released
<re_irc>
< (@ryan-summers:matrix.org)> It's in "master" but hasn't landed in a release yet, sorry
<re_irc>
< (@adamgreig:matrix.org)> : in your Embed.toml for cargo-embed you can specify "[default.general] connect_under_reset=true"
<re_irc>
< (@adamgreig:matrix.org)> and for cargo-flash, "--connect-under-reset"
<re_irc>
< (@firefrommoonlight:matrix.org)> There's a workaround you may need to enable to prevent this
<re_irc>
< (@epbuennig:matrix.org)> guys if i run ":ts-subtree" can i save the output somewhere? because it's unreadable rn
<re_irc>
< (@epbuennig:matrix.org)> lord have mercy
<re_irc>
< (@epbuennig:matrix.org)> oh wait
<re_irc>
< (@epbuennig:matrix.org)> pardon me wrong matrix
<re_irc>
< (@firefrommoonlight:matrix.org)> Ie, enable dbg_sleep etc in dbgmcu cr reg, and enable dma1's clock, even if you don't use it
<re_irc>
< (@firefrommoonlight:matrix.org)> Once you get it un-broken
<re_irc>
< (@firefrommoonlight:matrix.org)> : Really? I wouldn't expect that to do any reg writes
<re_irc>
< (@firefrommoonlight:matrix.org)> * the DMA clock thing may just be for L4 and F4; check errata
<re_irc>
< (@chemicstry:matrix.org)> any ffi gurus here? how would you model a safe Rust wrapper for C++ signature of "const Properties& Object::properties()"? Normally I would create two wrapers "struct Object { ptr: *mut CxxObject }" and "struct Properties { ptr: *mut CxxProperties }", but I can't have rust function "Object::proterties(&self) -> &Properties", because it would be a reference to a temporary value and if I return...
<re_irc>
... "Properties" by value I can't enforce immutability. I could have "ConstProperties" and "MutProperties", but that is a bit ugly. Any other options?
<re_irc>
< (@chemicstry:matrix.org)> I guess I will have to make concessions 😅 so far interfacing Rust with C was a breeze, but C++ is just hell. Although this particular problem is not exclusive to C++
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
<re_irc>
< (@firefrommoonlight:matrix.org)> : Yea - good observation
<re_irc>
< (@firefrommoonlight:matrix.org)> I concur
<re_irc>
< (@firefrommoonlight:matrix.org)> With C FFI, I like to use a thin rust wrapper over bindgen to get rid of the pointers in favor of arrays, and a few related things
<re_irc>
< (@firefrommoonlight:matrix.org)> Other than that, bindgen is great. I haven't tried it with C++, but have heard that can be hit/miss
<re_irc>
< (@firefrommoonlight:matrix.org)> C's pointer-based API isn't something I want to expose in firmware code
<re_irc>
< (@firefrommoonlight:matrix.org)> And use "usize" instead of "u32" or w/e when apt
<re_irc>
< (@chemicstry:matrix.org)> most of the C++ tools I tried break as soon as they encounter C++ templates. So far writting a C api over C++ and then using bindgen worked the best for me
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
conplan has quit [Client Quit]
conplan has joined #rust-embedded
conplan has quit [Client Quit]
conplan has joined #rust-embedded
conplan1 has joined #rust-embedded
conplan has quit [Ping timeout: 255 seconds]
conplan1 has quit [Ping timeout: 255 seconds]
conplan has joined #rust-embedded
conplan has quit [Ping timeout: 255 seconds]
<re_irc>
<ilpalazzo-ojiisan> What exactly is it about C++ that makes interop with "bindgen" difficult?
<re_irc>
<ilpalazzo-ojiisan> My use-case is about Arduino libraries, and I'm a bit apprehensive because they're not plain C.
<re_irc>
<ilpalazzo-ojiisan> (Then again… they're not full-fledged C++ either; sort of in-between.)
<re_irc>
< (@orclev:matrix.org)> I don't know a lot about C++, but I think part of the problem is that as far as I'm aware there's no standard ABI for C++. Each compiler is free to mangle names as it sees fit. C is super easy to interop with because it's very standardized and doesn't have the wrinkle of name mangling (technically calling conventions vary, but those are standardized by the OS, not sure what that means for bare metal C...
<re_irc>
... though). Additionally C++ has essentially every language feature anyone has ever thought up crammed into it and even though no (sane) person would use anywhere close to a majority of those features at the same time any tool needs to be prepared for them.
<re_irc>
< (@almindor:matrix.org)> in a way Rust is the same as C++ it just doesn't have that many compilers yet :) there's no ABI at all
<re_irc>
< (@almindor:matrix.org)> on the other hand ABI kinda loses meaning once you have things like generics
conplan has joined #rust-embedded
emerent has quit [Ping timeout: 255 seconds]
emerent has joined #rust-embedded
<re_irc>
<ilpalazzo-ojiisan> I take it no-one here has attempted to use the Arduino libraries with "bindgen", then?
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 248 seconds]
<Lumpio->
Isn't Arduino just C++ with some weird preprocessor because function prototypes are hard
<Lumpio->
But other than that just plain C++
<Lumpio->
I'm curious what the usecase for Arduino libraries is? Is it some specific library implemented on top of the Arduino APIs that does not exist in Rust?
<re_irc>
< (@orclev:matrix.org)> I actually thought Arduino was C not C++, but I've not really used it before so I don't actually know.
<re_irc>
< (@9names:matrix.org)> : there is an ABI, it's just not a stable ABI.
<re_irc>
and there is an active proposal to stabilise a version of this ABI
<re_irc>
< (@9names:matrix.org)> arduino is c++ with a preprocessor to avoid having to declare variables and import headers
<re_irc>
< (@9names:matrix.org)> most arduino libraries _are_ just c++ though, because it's easier to maintain that way
<re_irc>
< (@9names:matrix.org)> oh and with macros that transform init and loop into parts of main, but i guess that's pretty obvious
<re_irc>
< (@9names:matrix.org)> TLDR: FFI is no fun. the API you expose doesn't work how you expect Rust to work.
<re_irc>
unless there's a lot of functionality behind relatively few functions, it's more enjoyable and has better outcomes if you rewrite it in Rust. hence the meme.
<re_irc>
<ilpalazzo-ojiisan> Lumpio-: EEPROM usage has yet to be implemented in Rust, for instance. The raw pointers needed for it are exposed, but no ready-made functions.
<re_irc>
< (@9names:matrix.org)> that's literally a couple of register writes. FFI for that makes no sense
<re_irc>
<ilpalazzo-ojiisan> There's also "SoftwareSerial"; from what I've heard and seen it's basically a joke to implement, but yet remains unimplemented.
<re_irc>
<ilpalazzo-ojiisan> …a couple of register writes and a couple myriad of clock cycles waiting.
<re_irc>
<ilpalazzo-ojiisan> But w/e.
<re_irc>
< (@orclev:matrix.org)> : Most of the advantages of Rust come from its ownership model, which kind of breaks down any time you cross the FFI barrier. Doing that a bunch results in essentially C with extra steps.
<re_irc>
< (@9names:matrix.org)> software serial is implemented by bitbang_hal.
<re_irc>
i'm assuming you want to target AVR, so you probably want to fork that to handle timing in a way that makes sense for that target
<re_irc>
<ilpalazzo-ojiisan> I'm aware of that crate, but I hadn't used it yet because I had no idea how portable it is.
<re_irc>
< (@9names:matrix.org)> i'd recommend the same way that SoftwareSerial works (disable interrupts and ASM delays).
<re_irc>
it won't be great for realtime, but neither is SoftwareSerial
<re_irc>
<ilpalazzo-ojiisan> You said “fork”, so I'm assuming “not portable, but porting it is easier than it sounds”.
<re_irc>
< (@9names:matrix.org)> it is portable, but it relies on a timing abstraction that probably won't make sense for AVR (and doesn't work for a bunch of other targets either)
<re_irc>
< (@9names:matrix.org)> i think removing the abstraction would make your life easier
<re_irc>
< (@9names:matrix.org)> of course, if you try the original code and it just works you should just use the crate as-is
<re_irc>
< (@sajattack:matrix.org)> lol the fact that url contains my username somehow triggered a ping
<re_irc>
<ilpalazzo-ojiisan> …"nop"s? Why not "arduino_hal::delay_ms"?
<re_irc>
< (@9names:matrix.org)> : yeah matrix just matches on strings for usernames
<re_irc>
< (@9names:matrix.org)> because you're going to be delaying for microseconds, not milliseconds
<re_irc>
< (@9names:matrix.org)> and the delay_us/delay_ms functions delay for _at least_ that long, and you're going to want the closest delay
<re_irc>
<ilpalazzo-ojiisan> _OH!_ TIL.
GenTooMan has quit [Ping timeout: 255 seconds]
<re_irc>
<ilpalazzo-ojiisan> Hmmmmm. None of the documentation mentions this “at least that long” thing.
<re_irc>
<ilpalazzo-ojiisan> As far as the AVR is concerned, at least.
<re_irc>
< (@orclev:matrix.org)> pretty much every delay function in every system/OS/whatever only guarantees it will delay _at least_ the amount of time requested. Usually it's fairly close as long as you don't go below some arbitrary limit, but below that you're at the mercy of scheduling
<re_irc>
< (@chemicstry:matrix.org)> why would you want to run Rust on AVR? It's almost 2023, just leave 8bits behind already 😅 also AVRs are so simple that it would be faster to write a HAL in rust (which probably exists?) than to create C++ bindings
<re_irc>
<ilpalazzo-ojiisan> …because I know of no 32-bit microcontrollers that cost 1.8€ each.
<re_irc>
<ilpalazzo-ojiisan> If you do know of any, I'd be delighted to know.
GenTooMan has joined #rust-embedded
<re_irc>
<ilpalazzo-ojiisan> Also… to my astonishment, while a HAL does exist, it's still missing a lot of functionality.
<re_irc>
<ilpalazzo-ojiisan> All the things I mentioned are things that the current HAL doesn't implement.
<re_irc>
<ilpalazzo-ojiisan> In the medium-term (say, 6 months or so) I'd like to remedy that.
<re_irc>
<ilpalazzo-ojiisan> But in the short term… I have a dead-line to meet.
<re_irc>
<ilpalazzo-ojiisan> Basically all I really need is _one_ serial protocol that helps two Nanos communicate.
<re_irc>
< (@9names:matrix.org)> there should be plenty of cortex-m0 microcontrollers under that price
<re_irc>
< (@9names:matrix.org)> rp2040 should meet that requirement (though with spi flash as well, maybe not)
<re_irc>
< (@orclev:matrix.org)> I have often thought it might be interesting to program an ATtiny with Rust, but that is a bit like swatting a fly with a rocket launcher.
<re_irc>
< (@chemicstry:matrix.org)> STM32s start at 1$ in digikey, or at 50 cents in LCSC, you can get weirder brands even cheaper
<re_irc>
< (@9names:matrix.org)> i think the low-end atsamd's are also in that range
<re_irc>
< (@grantm11235:matrix.org)> ilpalazzo-ojiisan: It looks like "arduino_hal" already supports hardware uart (unless you are already using that for something else?)
<re_irc>
<ilpalazzo-ojiisan> The main problem is that each microcontroller will need to communicate with 6 others.
<re_irc>
<ilpalazzo-ojiisan> So one hardware UART is sadly not enough.
<re_irc>
< (@grantm11235:matrix.org)> Could you hook them all up in a ring?
<re_irc>
<ilpalazzo-ojiisan> : _In-stock_ STM32s start at 2€ in digikey, if bought individually.
<re_irc>
<ilpalazzo-ojiisan> Which is admittedly much lower than I thought.
<re_irc>
<ilpalazzo-ojiisan> Also where do those web-sites actually deliver?
<re_irc>
<ilpalazzo-ojiisan> : I fail to see why you wouldn't just take me at my word when I say that the hardware UART is not enough…
<re_irc>
…but, if you insist: I'm building smart building blocks. Each block is cubical, and hence has 6 sides; each side needs a different communication channel.
<re_irc>
<ilpalazzo-ojiisan> Unless I add more chips into the design, which increases cost.
<Lumpio->
So what happens if a UART transmission comes in while your thing is in a tight loop sending something with interrupts off
<Lumpio->
Have you considered just having a global bus where each block just has a numeric address?
<Lumpio->
Another albeit slow way I can think of is having a global serial clock, and using an interrupt handler to clock bits in/out all directions
<Lumpio->
But a global bus with a single hardware UART could end up being more efficient. As long as you can figure out enumeration and either decide on a bus-master or do multi-master which is always fun. Depends on your usecase of course.
<re_irc>
< (@orclev:matrix.org)> Lumpio-: ... isn't that just I2C?
<Lumpio->
Pretty much
<re_irc>
<ilpalazzo-ojiisan> I'd actually be delighted to discuss different ways of communication, but… it's kinda 01:20 where I live and my clock-cycles are rapidly diminishing.
<re_irc>
< (@sajattack:matrix.org)> : there's like a 25c riscv micro I saw that was announced recently
<Lumpio->
Although most chips won't have 6 I2C peripherals so you'd have to do it manually like I described
<re_irc>
<ilpalazzo-ojiisan> Lumpio-: Honestly, if there was a way to do that automatically without microcontrollers that'd basically solve my main problem automatically.
<re_irc>
<ilpalazzo-ojiisan> The first solutions I considered involved a global bus, and the construction's “foundation” communicating with each block.
<re_irc>
<ilpalazzo-ojiisan> : …I'll believes it when I sees it. I have no trouble believing that it might cost 0.1$ in four- or five-figure quantities, but I really don't have that kind of money.
<Lumpio->
Do what automatically btw?
<Lumpio->
And why without microcontrollers
<re_irc>
<ilpalazzo-ojiisan> Assign a numeric address to each block.
<Lumpio->
ah
<Lumpio->
I implemented that once using the fact that the STM32's I was using had a unique address burned in ROM from the manufacturer
<Lumpio->
It was 96 bits but I used that as a basis to differentiate the modules and assign shorter addresses
<re_irc>
<ilpalazzo-ojiisan> If each block had one assigned automatically, then the foundation could broad-cast commands to each block; decoding them would merely take a few shift-registers and comparators.
<re_irc>
<ilpalazzo-ojiisan> But if the address of each block is set, ie depends on neither its position nor on the order with which it was assembled, then the foundation could never know which block to address.
<re_irc>
<ilpalazzo-ojiisan> Lumpio-: The enumeration is merely each block's "[x, y, z]" coordinates.
<re_irc>
<ilpalazzo-ojiisan> The bus-master is the foundation—if there's a bus at all, that is.
<re_irc>
<ilpalazzo-ojiisan> But the really hard part is figuring out how each block is positioned.
<re_irc>
< (@orclev:matrix.org)> Hmm... makes me think, if each block only communicated with its neighbor you could have a fairly simple algorithm where if the address of the incoming message is anything but 0,0,0 it would just pass it so a neighbor while decrementing the address. So address 1,0,1, pass to the X face as 0,0,1 which then gets passed to the Z face as 0,0,0, which is the destination.
<re_irc>
< (@orclev:matrix.org)> although if you had non-contiguous layout you could end up at a dead end
<re_irc>
<ilpalazzo-ojiisan> Gnnnnnnnnnnnnn
<re_irc>
<ilpalazzo-ojiisan> I hate to have to leave just as the conversation is getting exciting, but I need sleep.
<re_irc>
<ilpalazzo-ojiisan> Thank you all; I'll be back after I wake.
causal has joined #rust-embedded
<re_irc>
<ilpalazzo-ojiisan> : That… is actually a fantastic idea.
<re_irc>
<ilpalazzo-ojiisan> I was thinking that each block could remember which block it was first connected to, but your idea is more intriguing.
<re_irc>
< (@halfbit:matrix.org)> have you considered CAN?
<re_irc>
<ilpalazzo-ojiisan> The lay-out is contiguous; any non-contiguous parts have no power to work with.
causal has quit [Ping timeout: 246 seconds]
<re_irc>
< (@9names:matrix.org)> I think CAN would be overkill here? Having an extra ic per chip would be more effort + cost
<re_irc>
<ilpalazzo-ojiisan> First criterion is, no more chips. The μC is already plenty.
<re_irc>
<ilpalazzo-ojiisan> Second criterion, ease of implementation.
<re_irc>
<ilpalazzo-ojiisan> Third criterion is speed.
<re_irc>
< (@9names:matrix.org)> I thought you were going to bed 😂
<re_irc>
< (@orclev:matrix.org)> There's definitely some problems that I can see cropping up with that approach, but maybe something worth noodling on. You should get some sleep and maybe when you wake up your sleeping mind will have come up with some things.
<re_irc>
<ilpalazzo-ojiisan> …so did I.
* re_irc
ilpalazzo-ojiisan waves
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
< (@halfbit:matrix.org)> there's micros with built in can transceivers?
<re_irc>
< (@halfbit:matrix.org)> I'm coming in late so... ignore if you already selected a part :-)
<re_irc>
< (@halfbit:matrix.org)> : well you can actually buy 8 bit micros so that's a plus