majors_ has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
majors has joined #rust-embedded
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]>
hi i'm trying to debug a hal what's a good way to step through and look at hardware registers in debug
<Darius>
gdb?
<Darius>
what hardware?
konkers[m] has quit [Quit: Idle timeout reached: 172800s]
RockBoynton[m] has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
AtleoS has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
Hi! I am trying to write a 9 bit serial driver (using pio for Pico) in rust. After a feel as to how people would represent the 9 bit type in rust. I had wondered about feeding the driver a pair of U8 so I can utilise the existing embedded write() trait, and the driver takes the lower bit from the high byte and joins it with the low byte, to send. And the opposite for rx
<davidmpye[m]>
The other way was just to have a custom write function eg fn write_9bit(byte: u8, bit9:bool)
<davidmpye[m]>
Which do people reckon is less ick?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
u16
M9names[m] has joined #rust-embedded
<M9names[m]>
you could also give it a 16bit value?
<M9names[m]>
okay i guess we're all on the same page :P
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
yeah, u16 is most common here, both in hardware and in software
<davidmpye[m]>
Well, the embedded::write trait uses only u8 so if I want to use that I need to use two adjacent u8
<davidmpye[m]>
But I suppose I don't have to use that trait!
<davidmpye[m]>
Can just make a write16()
<davidmpye[m]>
Sorry, write9(u16)
<JamesMunns[m]>
.to_le_bytes() or .to_be_bytes() can be used, your wrapping code can do the mapping
<JamesMunns[m]>
you could also do unsafe casting here, to turn the `&[u16]` into a `&[u8]` (going from 16 -> 8 is generally fine, as the alignment requirements are less strict, going the other way you have to be more careful)
<JamesMunns[m]>
but yeah, note that this isn't always portable: different hardware could handle larger-than-u8 serial bytes differently
<JamesMunns[m]>
some you can write two u8s to, some hardware you need to explicitly do a 16-bit write to the "output address" to trigger a 9-bit write
<davidmpye[m]>
I'll have a look, thanks. TBF it's whatever I write the Pico pio driver to do
AtleoS has quit [Ping timeout: 252 seconds]
AtleoS has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]>
What's the general release sync story between embassy-net and smoltcp? Should I wait for embassy-net PRs to have something released in smoltcp, or is it on some always updated branch anywya?
<dirbaio[m]>
when a smoltcp release happens embassy-net updates to that
<dirbaio[m]>
when smoltcp has something unreleased I want in embassy-net, I temporarily change embassy-net to depend on smoltcp git
<dirbaio[m]>
so if you want to PR something to embassy-net that needs unreleased smoltcp it's fine
<dirbaio[m]>
that does mean embassy-net release is blocked by smoltcp release
<dirbaio[m]>
s/is/becomes/
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
Does anyone have any experience with implementing simple menus on small OLEDs?
<AlexandrosLiarok>
I can write the whole menu system myself from scratch, just thought I may be able to leverage an existing crate. `embedded-menu` seems ok although I am having some issues with remapping the input events after selection. There is also `cycle-menu` which seems more bare-bones.
<AlexandrosLiarok>
* Does anyone have any experience with implementing simple menus on small OLEDs?
<AlexandrosLiarok>
I can write the whole menu system myself from scratch, just thought I may be able to leverage an existing crate. `embedded-menu` seems ok although I am having some issues with remapping the input events after selection. ~~There is also `cycle-menu` which seems more bare-bones~~.
<AlexandrosLiarok>
* Does anyone have any experience with implementing simple menus on small OLEDs?
<AlexandrosLiarok>
I can write the whole menu system myself from scratch, just thought I may be able to leverage an existing crate. `embedded-menu` seems ok although I am having some issues with remapping the input events after selection. <del>There is also `cycle-menu` which seems more bare-bones</del>.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
<AlexandrosLiarok> "Does anyone have any experience..." <- > <@aliarokapis:matrix.org> Does anyone have any experience with implementing simple menus on small OLEDs?
<vollbrecht[m]>
> I can write the whole menu system myself from scratch, just thought I may be able to leverage an existing crate. `embedded-menu` seems ok although I am having some issues with remapping the input events after selection. <del>There is also `cycle-menu` which seems more bare-bones</del>.
<vollbrecht[m]>
maybe you can find something in the logs of https://matrix.to/#/#rust-embedded-graphics:matrix.org .
<AlexandrosLiarok>
thanks!
<vollbrecht[m]>
* maybe you can find something in the history of https://matrix.to/#/#rust-embedded-graphics:matrix.org .
Makarov has joined #rust-embedded
Ralph[m] has joined #rust-embedded
<Ralph[m]>
i will need to interact with three cameras (2x 1080p B/W, 1x 4K color) and trigger them at 10 Hz, take the pictures, possibly do some post-processing on them and send them to a host (via ethernet; i control the receiving end as well, so the data format/protocol can be freely chosen). do you think bare-metal rust (using embassy or RTICv2) would be a good match for this or would i be better served with a slightly bigger MCU which can
<Ralph[m]>
do you know a good protocol to send the images (+ some other sensor readouts, all with timing information)? i'm wondering if stuffing everything into a `struct` and using postcard might be an option? (though postcard-rpc currently doesn't support TCP/IP yet 🙁)
<Ralph[m]>
run linux? (the post-processing doesn't have to happen on this board, though if we can do it there it'd be nice)
<dirbaio[m]>
how're you going to interact with the camera sensors?
<dirbaio[m]>
embassy-stm32 supports DCMI, but that typically throws the data at you ultra fast, you have to DMA it all to somewhere in RAM so you can later send it via the network at your own pace
<dirbaio[m]>
so you'll need A LOT of RAM, which means messing with FMC or similar
<dirbaio[m]>
it'll be much eaiser to do with some random linux SBC
<JamesMunns[m]>
> postcard-rpc currently doesn't support TCP/IP yet
<JamesMunns[m]>
I'm open to an impl (or sponsorship to do it), btw. There are structures that you can reuse (it's written with different transports in mind), happy to point you at notes.
<JamesMunns[m]>
That being said, unless you are power or hard-real-time constrained, I would probably also suggest a linux sbc here
<JamesMunns[m]>
once you have "networking" and "something that would require/benefit more than a few MiB of RAM", you're pretty firmly in "better off Linux unless you're making >10k of them and have time + money for custom SW dev effort"
<JamesMunns[m]>
(in my opinion, at least)
<JamesMunns[m]>
The trick in linux is just finding an SBC that has the right interfaces (and enough of them) for talking to your camera. Also streaming 4K@10Hz data will either require gigabit eth for raw/bitmaps, or compression (waaaaay easier on Linux), unless your camera give you pre-compressed jpgs/mpegs or whatever
<JamesMunns[m]>
Anyway, let me know if you want more of my opinions on balancing NREs (Non-Recurring Expenses, e.g. custom hw/sw dev costs) and BOM (Bill of Material, per-unit costs) for small volume manufacturing. The deck is stacked heavily towards "put a linux on it, if you can get away with it, maybe with an MCU 'buddy' processor if you need that to patch up any real-time requirements"
<dirbaio[m]>
btw you can get IP cameras that support something like RTSP, so you can do zero engineering on the camera side :D
<drewbus[m]>
<Ralph[m]> "i will need to interact with..." <- > <@rursprung:matrix.org> i will need to interact with three cameras (2x 1080p B/W, 1x 4K color) and trigger them at 10 Hz, take the pictures, possibly do some post-processing on them... (full message at
<drewbus[m]>
Sure. I built something on that stack earlier this year. Gstreamer was kind of a trip to get my head around at first, but it is super comprehensive and battle tested. I have six cameras feeding over a vpn from a jetson agx to anybody with the binary to watch them. The inference is done on the edge device, requiring Deepstream, so I wrote that side in C. However if you don’t need inference you can write the whole thing in rust. My
<drewbus[m]>
client side is pure rust. Also dirbaio ‘s comment about rtsp and ip cameras is spot on as well, and it’s likely cheaper than a daughter board + cameras.
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
Ahhh... my only problem with GStreamer and Linux SBCs is that the cheapo ones (read: AllWinner/RockChip and AmLogic) all have a very shaky HW codec stories. So in case you need to transcode the RTSP camera stream (as I needed for my little private anything-to-Miracast project, as Miracast supports only 16:9 res, which is atypical for cameras), your mileage might vary. and you might need to use a "vendor" kernel ... = likely
<ivmarkov[m]>
unpatched, insecure, old kernel. NVidia (and RPI) are of course a different story, but the price tag on these is much bigger than what I can accept for my stuff to have an even remote chance of being profitable...
<ivmarkov[m]>
s/and/And/
<ivmarkov[m]>
Not to mention that stuff like Amlogic does not even have a hardware encoder story at all. Reason: these chipsets (or the older ones, that is) were primarily created for "tv boxes", where HW encoding is not a use case.
<ivmarkov[m]>
Otherwise, what I can say is that gstreamer-rs is mostly API complete, so it is a joy to use.
<ivmarkov[m]>
... if you don't need transcoding (by transcoding I mean unpacking the actual video stream, so as to e.g. change the res, or re-encode from e.g. h264 to h265) then Linux SBC with a recent kernel is kind of achievable.
<dirbaio[m]>
i'd suggest staying away from sbc's also if you can
<dirbaio[m]>
grab a x86 minipc, chuck some standard linux distro on it with your own code, image that.
<dirbaio[m]>
much more standard hardware = less issues
<dirbaio[m]>
don't fall into the trap of using an sbc because you need gpio/i2c/spi/whatever
<dirbaio[m]>
if you need it build a tiny embedded board that speaks usb, make your main linux binary rpc to it
<dirbaio[m]>
with postcard-rpc 🙃
<ivmarkov[m]>
What you are describing is ok for a one-shot hobby setup. But if you want to sell the device... you can't match the $15 - $30 price tag of a rockchip board with a x86 sbc
AtleoS has quit [Ping timeout: 276 seconds]
<dirbaio[m]>
if you do compete on price and will sell enough units to justify the NRE then sure
<dirbaio[m]>
a lot of this "x86 pc with camera / sensors attached" is more one-off very custom factory/industrial automation stuff where you don't sell that many
<JamesMunns[m]>
NRE costs absolultely destroy BOM costs until you get at least >100 units, and it's a tighter race than many think for 100-10k units.
<dirbaio[m]>
or is for your own use, you don't even seel
<dirbaio[m]>
s/seel/sell them/
<dirbaio[m]>
I made this mistake for Akiles factory tooling.
<JamesMunns[m]>
dirbaio[m]: for the record, I am actively working on this right now:
<JamesMunns[m]>
If you are a company that is using an SBC for realtime or IO reasons, but you would love if you could use a simpler (or x86) PC/SBC, please please send me a DM.
<dirbaio[m]>
"we need gpios and adcs and shit for factory testing the boards -> use a rpi in a custom pcb with the adcs and stuff"
<dirbaio[m]>
it was terrible :D
<JamesMunns[m]>
the goal is to make handling 1..N "sidekick MCUs" utterly painless, with a single API/crate that manages all the plumbing, config, and even historical data management.
<dirbaio[m]>
pain to maintain their weird arm linux
<dirbaio[m]>
slow
<dirbaio[m]>
fry a gpio? throw away the entire $80 rpi
<dirbaio[m]>
and boy the BCMwhatever gpios fry easily
<ivmarkov[m]>
JamesMunns[m]: 5K+ to 50K units was the target market segment I was aiming at, but I agree (even though I never did a proper business plan / analysis) - it is a tight race :-)
<dirbaio[m]>
2nd iteration will be just a jig with a rp2040 you plug in to usb. it'll do debug probe, gpio, adc, etc all RPC'd over usb
<JamesMunns[m]>
dirbaio[m]: please talk to me before you do this, btw :D
<dirbaio[m]>
as a bonus we'll be able to develop the linux tool much easier, just plug in the jig to your main dev workstation, no need to scp binaries to the rpi
<dirbaio[m]>
want to flash another product? just plug in another jig
<JamesMunns[m]>
yep, my plan is to make a 3U, 19" rack, with common modules (SWD, SPI, UART, I2C, Relay, power measurement), with a single USB cable you plug into your laptop or PC.
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Also the RPI has literally no ADCs
<dirbaio[m]>
rp2040s are cheap enough that you can hotglue them to the jig, no need to mess with wires when switching products
<JamesMunns[m]>
JamesMunns[m]: basically, "what if national instruments SerIO, but you don't have to use labview"
<JamesMunns[m]>
JamesMunns[m]: (and, it'll be feasible to make your own modules, if you want to build/contract some arcane interface you must talk to)
<vollbrecht[m]>
JamesMunns[m]: For professional HIL testing there are also companies out there in that space that do a lot for the big money. So you will have to carefully think what your actual target for this stuff would be. You can for example look here what is already out there from a somewhat bigger german player in this [space](https://www.dspace.com/en/pub/home/applicationfields/foo/hil-testing.cfm).
<JamesMunns[m]>
Okay, that's enough of me pitching: If anyone is doing a project they think fits what I just described, or "I want that but on my custom PCB and smaller and not in a rack", also hit me up.
<JamesMunns[m]>
vollbrecht[m]: yep. My market is "I do 2-4 gigs a year where the customer needs a little custom hardware, but could get away with less than they think, and they pay me to do all the plumbing anyway, so I can just build a toolkit I can reuse to do it faster and cheaper". If it's a big enough market to sell hardware/services, cool that's a bonus, but right now there's *enough* gigs like this (HIL but also one-offs or low volume hw
<JamesMunns[m]>
design) where I don't need volume to make it worth my efforts.
<i509vcb[m]>
I've been able to play with some semiconductor testing equipment and I might some day I might act in my thought: "How much of this could I replicate on a shoestring budget"
<i509vcb[m]>
Obviously I won't be doing RF stuff and anything beyond 30MHz due to the like sub $1k I'd probably set as a limit
<i509vcb[m]>
(The equipment I get to play with is $620k)
<JamesMunns[m]>
Nice!
<JamesMunns[m]>
Yeah, right now the plan is "how much damage can you do by throwing up to 16 RP2040s at a problem?"
<JamesMunns[m]>
and once the next RP2350 silicon revs come out, probably then upgrading to that where it makes sense.
<JamesMunns[m]>
Then if I really need something fancy after that, probably throwing an imxrt or stm32h7 at it
<JamesMunns[m]>
THEN after that, a CH569, or something else that speaks USB 3.0 :D
<i509vcb[m]>
Or a cheap FPGA I guess for more complicated stuff
<JamesMunns[m]>
different topic: CC adamgreig bartmassey - for the meeting tomorrow, do you need me to run it? Or is Bart also running it this week?
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
I'm still UTC+9 so not much good for running a meeting. IIRC Bart only volunteered for the first week (thank you for running that one! Looked like it went well)
<JamesMunns[m]>
happy to take a turn this week, unless Bart wants to keep the momentum going
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Would slightly prefer you do it, but am good either way
<JamesMunns[m]>
ah, then I'll plan to run it tomorrow :)
<bartmassey[m]>
Thanks!
Makarov has quit [Ping timeout: 256 seconds]
starblue1 has quit [Ping timeout: 260 seconds]
kentborg[m] has joined #rust-embedded
<kentborg[m]>
I think my "Adafruit Feather nRF52 Pro with myNewt Bootloader - nRF52832" died overnight. When I try to program flash with nrfjprog I get a verification error on address 0x5 or 0x8 or 0x9, depending on the exact elf I try to program.
<JamesMunns[m]>
it's usually pretty hard to do permanent damage to MCUs, unless you wire them up backwards, or give them too high of a voltage. That goes for the J-Link as well.
<JamesMunns[m]>
(gotta run for a bit, hopefully other folks can help diagnose tho!)
<kentborg[m]>
I suspect I erased the bootloader then. I have played with some Zephyr hello-world level code, some embassy hello-world code, and last night I pulled my toy embassy code out of their example directory into a fresh "cargo new" directory. It would program, I could light either LED, I was getting out of the mud!
<kentborg[m]>
This morning I tried to read the button but and it would not program. I tried programming an old binary from the embassy example directory, one that I think worked yesterday, and it fails, too. Plug-cycled the board, rebooted my Linux development machine…
<JamesMunns[m]>
Do you have probe-rs installed?
<JamesMunns[m]>
dirbaio do you remember the magic "wipe everything including UICR" invocation these days for probe-rs?
<dirbaio[m]>
probe-rs erase should do it on nrf52xx
<JamesMunns[m]>
you don't need a --allow-something flag anymore for the more stubborn rev3 chips anymore?
<JamesMunns[m]>
ah maybe that's just 840 anyways?
<kentborg[m]>
* the button SW2 but and
<dirbaio[m]>
ah yes that's if the chip has locked itself
<JamesMunns[m]>
(for reference, probe-rs is kind of like OpenOCD, or like the jlink tools, but works with many kinds of different debuggers, including jlinks, it's what most people in embedded Rust use)
<JamesMunns[m]>
Once you have that installed, let me know what happens when you run that probe-rs erase --chip nrf52832 --allow-erase-all command, and we'll see where to go next :)
<JamesMunns[m]>
(if you're in an embedded project folder, Rust will build for the embedded target, not your host)
<kentborg[m]>
I'm on Debian stable. Tried a fresh terminal, same error.
<kentborg[m]>
I hate piping curl output into sh.
<kentborg[m]>
At least they aren't insisting on sudo.
<JamesMunns[m]>
kentborg how did you install rust/cargo/rustup, by the way? Are you using debian's package, or did you install from rustup.rs?
<kentborg[m]>
My rustup was through a wget or curl or whichever they want.
<JamesMunns[m]>
cool, just wanted to check!
<JamesMunns[m]>
fwiw, it looks like your error might have come from forgetting to pass --locked, e.g. cargo install probe-rs-tools --locked, but installing via that curl script is the recommended way to install (to avoid issues like this!)
<JamesMunns[m]>
then in that folder, run cargo run --release --bin blinky
<kentborg[m]>
It looks like I can erase-all and download my old binary more than once. I can erase-all and down the new more than once. Moving between the two worlds messes up.
<JamesMunns[m]>
make sure the FLASH is 512KiB and the RAM is 64KiB
<JamesMunns[m]>
(in the memory.x)
<dirbaio[m]>
kentborg[m]: because you're missing `--sectorerase`
<dirbaio[m]>
the bitwise AND of the same binary two times is the binary
<dirbaio[m]>
* the bitwise AND of two different binaries is garbage
<dirbaio[m]>
--sectorerase is all you need
<kentborg[m]>
I have the right chip ID in my new Cargo.toml. I hadn't changed it in the the examples.
<kentborg[m]>
And now I can alternate between the two!
<dirbaio[m]>
👌🙃
<kentborg[m]>
Thanks to all. I won't have to wait for a replacement board to be delivered.
<kentborg[m]>
probe-rs: It looks useful, can run a gdb server, for example. Do I no longer need nrfjprog?
<JamesMunns[m]>
correct!
<JamesMunns[m]>
many people also use gdb less heavily, and use defmt, which can print logs efficiently using rtt/probe-rs
<kentborg[m]>
Is that like itm?
<JamesMunns[m]>
sort of, but it goes over the SWDIO/SWCLK wires, so you don't need an extra pin. It also doesn't do the printf stuff on the MCU, it just sends the raw data and has the PC do the formatting.
<kentborg[m]>
Looks like probe-rs has a good website (at least pretty one). I have some reading to so. But first I want to read SW2.
<kentborg[m]>
s/so/do/
<kentborg[m]>
One more regression from yesterday: Yesterday I realized that the reset push button didn't work because I had the Ozone debugger running and it was stopping the reset. Today, having pulled my trivial code out from the embassy example directory and into a new directory…the reset button is no longer working.
<kentborg[m]>
Suggestions?
<dirbaio[m]>
the reset pin only works if you configure it in uicr
<kentborg[m]>
Looks like PSELRESET[0] is wrong. Thanks.
<dirbaio[m]>
why isn't embassy-nrf isn't setting it correctly, though? 👀
<dirbaio[m]>
it should work out of the box
<kentborg[m]>
I'm going to try switching back to the 52840 chip and see whether the behavior moves with it…
<kentborg[m]>
…no, pretending I have a 52840 doesn't bring back the reset. Something about not running in the example environment, but knowing why helps.
<kentborg[m]>
I do like being in my own directory, rust-analyzer works, for example.
<kentborg[m]>
* …no, pretending I have a 52840 doesn't bring back the reset. Something about not running in the example environment, but knowing the chip is so flexible about the reset pin helps.
<kentborg[m]>
I do like being in my own directory, rust-analyzer works, for example.
<dirbaio[m]>
running a 52840 firmware in a 52832 won't work. the uicr is different.
Makarov has joined #rust-embedded
<kentborg[m]>
52840 or 52832, rest isn't working for me in the embassy example environment. So I changed something I didn't notice, or my erasure confusions were a problem. (Why my programming worked as well as it did is a puzzle.)
<kentborg[m]>
s/rest/reset/
Makarov has quit [Ping timeout: 256 seconds]
<Ralph[m]>
small info for anyone using H-bridge style motor controllers: i finally released v1.0 of this driver: https://crates.io/crates/tb6612fng (thanks eldruin for the reviews!) 🥳
<Ralph[m]>
the main difference to the previous 0.2 version is that it finally moves to e-h 1.0 (this was in git for a while, but the last polishing touches for a proper 1.0 were missing). this is my first 1.0 crate on crates.io 😃
<Ralph[m]>
also something which might be interesting for anyone who wants to ensure that checks are enforced on their PRs: so far i always had to configure every single check which should be mandatory, meaning that for matrix builds which e.g. include the rust version you have to update the settings on GH every time, which is super annoying. but there's an easier way: you can add a job which requires all the other jobs and fail that one if
<kentborg[m]>
Good to be aware that not only does the state of flash program memory matter, but there are non-volatile settings in these chips.
<kentborg[m]>
In my case it get set to a sensible reset behavior value once up a time, and stayed that way, until I broke it. I need to be aware these settings need to be managed and think about the best way to do that.
<drewbus[m]>
<dirbaio[m]> ""we need gpios and adcs and shit..." <- ivmarkov: dirbaio in a past life I was buying cash counting hardware for a bank and the vendor tried to convince me that their bone stock Debian Sarge >10 year EOL hardware was totally safe in my secured network even after I pointed out it had 138 known critical vulnerabilities. I have never forgotten the importance of upgrade paths since.
<dirbaio[m]>
lmao
<dirbaio[m]>
yeah that's a problem you don't have with a pure-rust nostd firmware 🦀
Makarov has quit [Ping timeout: 256 seconds]
rafael[m] has joined #rust-embedded
<rafael[m]>
<Ralph[m]> "small info for anyone using H-..." <- > <@rursprung:matrix.org> small info for anyone using H-bridge style motor controllers: i finally released v1.0 of this driver: https://crates.io/crates/tb6612fng (thanks eldruin for the reviews!) 🥳
<rafael[m]>
> the main difference to the previous 0.2 version is that it finally moves to e-h 1.0 (this was in git for a while, but the last polishing touches for a proper 1.0 were missing). this is my first 1.0 crate on crates.io 😃
<rafael[m]>
wow what a coincidence, I just recently bought one... and was slowly ambling towards making stuff work for a hobby project. How cool You provide that driver! 🙂 I was really just a pinch away from looking into how I will drive the motors when You posted. Life is funny 🙂
<rafael[m]>
Just finished my async driver for hc-sr04, so with the motor driver I am now ready to go 🙂 Amazing, thx.
<rafael[m]>
https://crates.io/crates/hcsr04_async BTW, my very first. Hobbyist-newbie quality, but it works and is cross checked with a scope, too. So may be useful to somebody 🙂
NiaLinaLunaStorm has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
<rafael[m]> "> <@rursprung:matrix.org..." <- good coincidence! 😄
<Ralph[m]>
good luck with your project! if you notice anything with the crate just raise an issue (and/or provide a PR 😉)
therealprof[m] has joined #rust-embedded
<therealprof[m]>
<adamgreig[m]> "I'm still UTC+9 so not much good..." <- Ooh, I'd love to be in UTC+8/9 right now.
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
What are folks out there using to support the various build commands that are needed for a moderately complex embedded systems project (including on-workstation support tools.)
<PhilMarkgraf[m]>
I've been using cargo xtask for some time to allow single command builds, but have become increasingly dissatisfied. One big issue is that (in my application) it kills incremental builds. Issue the same command twice in a row... rebuild every dependency and file twice in a row. (Doubtlessly an issue in my xtask setup, but I've yet to figure out why.)
<vollbrecht[m]>
if you look for a good command runner, not an extension to the build system maybe something like `just` is a [thing](https://github.com/casey/just) for you?
jonored[m] has joined #rust-embedded
<jonored[m]>
dav1d: just uploaded a 0.2.1 of esp-hal-rmt-onewire that builds against 0.20.1 and has a usage example. It's just grabbing Internal via transmute, there's more fuss to do to get the proper API to work for it (and there's waiting for a release of esp-hal as well).
<dav1d>
jo, awesome!
<jonored[m]>
I was having less success with the internal pullup and the particular sensor I'd hooked up this time around, so you might need a real external pull-up resistor to get it to work.
<jonored[m]>
Not quite, because peripherals still grab the pin and set it up in one particular configuration, and I'm not having as much success as I'd have expected changing that configuration back after the fact. Basically just need a "configure_minimal" that doesn't change the pin settings at all, just the peripheral setup.
<jonored[m]>
I'm going to loop back on that and submit an issue, I just haven't gotten to it and wanted to unblock with how it is right now.
<dav1d>
ah, that sucks
<jonored[m]>
eh, it's not much more to do and I wouldn't be surprised at that bit of fix catching this release cycle anyways. it's a comparatively trivial change to get done on top of 2128.