lehmrob has quit [Remote host closed the connection]
<Ralph[m]>
is there a good way (or any way) to have a cargo workspace where not all members have the same target? i have the (common?) use-case that i have a `no_std` library built against embedded-hal and a usage example built against a specific microcontroller (and thus specific target). the moment i have a workspace cargo... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/CUNWWVMnAQTyexqwVhoYwvDU>)
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Ralph[m]: > <@rursprung:matrix.org> is there a good way (or any way) to have a cargo workspace where not all members have the same target? i have the (common?) use-case that i have a `no_std` library built against embedded-hal and a usage example built against a specific microcontroller (and thus specific target). the moment i have a... (full message at
<Ralph[m]>
diondokter[m]: too bad! do you think it would make sense to raise an issue with rust/cargo to ask for support for this setup? i presume i'm far from the only one who'd want to use this?
<Ralph[m]>
i could also imagine this making sense outside of the embedded world (e.g. with webassembly; i've never used it but my understanding is that you then also have a crate which has to target webassembly while you might well have part of the logic in another crate which is agnostic of this?)
<JamesMunns[m]>
I'm not sure if there is an open issue, but I have prepared a simple repro case that illustrates at least some of the problems: https://github.com/jamesmunns/bad-workspace
<JamesMunns[m]>
Feel free to use it if you do open an issue.
<JamesMunns[m]>
(I've had to explain this issue to a couple people, and then later clients, when I suggest they don't use workspaces, or at least one workspace)
<JamesMunns[m]>
Eliza put a bunch of work into getting workspaces going, but it does require unstable cargo features, and is still not without pain
<diondokter[m]>
Yeah I tried it like 2 years ago and didn't seem to be worth the hassle
<JamesMunns[m]>
It's gone from "not possible" to "work in progress", IMO.
<JamesMunns[m]>
My suggested alternative would be to use a tool like `just` to give you top level "build/check/test all" commands if you have a pretty simple set, and then maybe upgrading to writing a set of xtask rules
<Ralph[m]>
thanks for the feedback! so it actually looks good(-ish) as there are nightly features which should hopefully get stabilised eventually (links found through mnemos linked by James Munns):
<JamesMunns[m]>
and yeah, we lean on just to handle the other platform-specific targets
<JamesMunns[m]>
You can have them in a workspace, but you can't build them all at the same time, because they get unified
<dirbaio[m]>
default-members doesn't fix it, the creates you're excludign are still "broken" because feature unification, you're just not building them
<JamesMunns[m]>
I believe you can still use cargo xxx --package whatever ... correctly, as that is what our justfile does.
<JamesMunns[m]>
I think resolver=2+per package targets allows that behavior, when you are specifically building a package
<JamesMunns[m]>
but I'm not certain, off the top of my head. We use just commands in our CI, so it works somehow at least.
<JamesMunns[m]>
I wouldn't recommend doing it this way, honestly. But it's not impossible, even if unpleasant.
<dirbaio[m]>
does per-package-target make the "wrong target" crates get completely excluded? so the features they enable are not enabled?
<dirbaio[m]>
maybe that's why it works? 🤔
<JamesMunns[m]>
Not sure!
<JamesMunns[m]>
Eliza did that work, you could ping her in Anachro about it
<dirbaio[m]>
anyway
<dirbaio[m]>
it'll still break if you've got "application, bootloader, shared" where application enables shared/foo and booloader enables shared/bar, and foo+bar is incompatible
<dirbaio[m]>
because both application and bootloader will have target set to thumbv7em
<dirbaio[m]>
so they'll get features unified between themselves..??
<JamesMunns[m]>
I mean, I don't use workspaces on any of my own projects, other than mnemos, because Eliza did the work lol
<JamesMunns[m]>
I'd probably recommend "don't use workspaces" for now.
<dirbaio[m]>
yeah, 100%
<diondokter[m]>
There should probably be like two types of workspaces. Strong and weak where the current one is strong where it tries to combine builds and such. The weak one would have the same interface for easy cli commands, but build everything separately
<dirbaio[m]>
i'd prefer some cli syntax for "build all these unrelated crates at once"
<diondokter[m]>
Well... Maybe. Like the weak workspace would pretty much just be a config for just that
<dirbaio[m]>
that's faster because it can parallelize and share the target dir, but exactly equivalent to separate cargo build foo; cargo build bar; cargo build baz...
<dirbaio[m]>
it's stupidly faster than doing 180 cargo builds separately because it can keep all cores at 100%, while separate cargo builds often have bottlenecks where it uses 1 core only
<diondokter[m]>
Yeah, I can imagine
<dirbaio[m]>
which is the main benefit of being able to do a single big cargo build or cargo test on a workspace
<dirbaio[m]>
but without the downsides of feature merging
<JorgeDOrtizFuent>
The code is unedited. Any pointer to what I might be doing wrong?
SergioGasquez[m] has joined #rust-embedded
<SergioGasquez[m]>
<JorgeDOrtizFuent> "Hi all!..." <- Hi Jorge! For esp questions I'd suggest using https://matrix.to/#/#esp-rs:matrix.org. That being said, you dont need to install esp-idf, the build process takes care of that (there is also an option for reusing a local esp-idf installation but you need to make sure your Rust dependencies and ESP-IDF version are aligned)
<JorgeDOrtizFuent>
SergioGasquez[m]: Hi Sergio. I was looking for that one. I remembered you mentioned it. Glad to ask there too!
<SergioGasquez[m]>
JorgeDOrtizFuent: Which cli tools did you install? You would require:
<JorgeDOrtizFuent>
SergioGasquez[m]: ldproxy is installed. I didn't install espflash (neither version). I understood they were optional for risc-v arch
<SergioGasquez[m]>
JorgeDOrtizFuent: `espflash`/`cargo-espflash` is the tool that uploads your app to the device
<SergioGasquez[m]>
SergioGasquez[m]: So you'll need it once you can build your project
<JorgeDOrtizFuent>
SergioGasquez[m]: In any case, I am running `cargo build`, so I understand that I am not doing that yet.
<SergioGasquez[m]>
JorgeDOrtizFuent: `espup` is what install the Xtensa Rust, and since you are using RISC-V, which is officially supported in upstream Rust, you dont need it
<JorgeDOrtizFuent>
SergioGasquez[m]: 👍
<SergioGasquez[m]>
JorgeDOrtizFuent: > I have installed esp-idf and the cli tools and then:
<SergioGasquez[m]>
Mind sharing how did you install esp-idf?
<SergioGasquez[m]>
SergioGasquez[m]: I tried building a template with the same prompts and I was able to build it suscesfully
<SergioGasquez[m]>
SergioGasquez[m]: Using `rustc 1.76.0-nightly (d86d65bbc 2023-12-10)`
<SergioGasquez[m]>
JorgeDOrtizFuent: This is the installation guide for EPS-IDF
<vollbrecht[m]>
SergioGasquez[m]: its only necessary for the prerequest
<vollbrecht[m]>
vollbrecht[m]: to follow the instruction you mention Jorge D. Ortiz Fuentes
<SergioGasquez[m]>
vollbrecht[m]: You can reuse a local ESP-IDF installed version, but you need to make sure its using the same tag/branch that your esp-idf-template project its using. In your case, you installed ESP-IDF master branch and in the template project, you were using the `v5.1.2` tag
<JorgeDOrtizFuent>
SergioGasquez[m]: Yep that was the document I used that page and followed the link that is called "ESP-IDF prerequisites"
<JorgeDOrtizFuent>
JorgeDOrtizFuent: Ok, I understand. It makes a lot of sense.
<vollbrecht[m]>
JorgeDOrtizFuent: also since you are now run the . export from the downloaded git repo you may need to restart your terminal to get rid of the old env vars
<vollbrecht[m]>
* env vars if you like to get rid of the local install
<SergioGasquez[m]>
JorgeDOrtizFuent: Ahh! Maybe we warn the user better that only prerequisites are needed
Guest7282 has joined #rust-embedded
<JorgeDOrtizFuent>
SergioGasquez[m]: Totally my mistake. But I was confused because (most?) of the prerequisites were already mentioned in the initial page (before the link)
<SergioGasquez[m]>
JorgeDOrtizFuent: Sorry, which initial page?
<JorgeDOrtizFuent>
python, git and ldproxy (which are mentioned in the requisites later) are also enumerated here.
<SergioGasquez[m]>
JorgeDOrtizFuent: Uh, thanks for the feedback! I'll open and issue and try to improve this
<SergioGasquez[m]>
SergioGasquez[m]: I didnt notice that git and python were duplicated
<JorgeDOrtizFuent>
SergioGasquez[m]: Not really. It is more my bad than the document's.
<SergioGasquez[m]>
JorgeDOrtizFuent: The thing about listing pyton and git there is that Windows users only need to install those two things. But Unix users migth need to install the full package list shown in the ESP-IDF docs
<SergioGasquez[m]>
SergioGasquez[m]: So I'll try to make that more clear
<vollbrecht[m]>
SergioGasquez[m]: Maybe reword it in such a way that prerequest comes first in the sentence and not in the link. Like "Linux/MacOS users are required to have the prerequest installed mention in this ESP-iDF documentation. ( Only section about prerequest is needed)" or something simmilar
<SergioGasquez[m]>
vollbrecht[m]: Anyway, how is the build going? Expect the first time you build your project to take a while because of the download/installationo
<vollbrecht[m]>
SergioGasquez[m]: anyway besides imporving the documentation, Jorge D. Ortiz Fuentes the goal is to get running ;) did you make progess or are stuck elsewhere?
<vollbrecht[m]>
SergioGasquez[m]: :D
<vollbrecht[m]>
SergioGasquez[m]: you are to fast :p
<JorgeDOrtizFuent>
vollbrecht[m]: You guys rock!
<JorgeDOrtizFuent>
I have deleted esp-idf and ~/.espressif (as mentioned in the uninstall procedure). I have started with a brand new terminal and it is compiling at the moment.
huszty[m] has quit [Quit: Idle timeout reached: 172800s]
<JorgeDOrtizFuent>
<JorgeDOrtizFuent> "You guys rock!..." <- It is still in progress. I have some issues with GitHub and TLS at home that I have been occasionally chasing for months. But I have been unsuccessful so far. So I got a `LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443` and I have had to retry.
<vollbrecht[m]>
JorgeDOrtizFuent: github 🔥 only the first compile should be this painfull normally. as it sets the complete install for you up etc. After that it should be miles better
<dirbaio[m]>
I guess it's because the "it only reads so it can't race" thing
<dirbaio[m]>
but it rules out implementations that
<dirbaio[m]>
- have mutable state (like that issue), or
<dirbaio[m]>
- require exclusive access to something, for example an spi/i2c bus for a gpio expander.
<vollbrecht[m]>
vollbrecht[m]: if you ever think something fishy was going on in the mid,s of the install of esp-idf into your .embuild dir. At anytime in your project you can just delete the directory and on a new `cargo b` run detects that its missing and will install it again
<dirbaio[m]>
so there's disadvantages
<dirbaio[m]>
but is there any *advantage* in requiring only `&self`?
<dirbaio[m]>
why would a driver want that
<JorgeDOrtizFuent>
vollbrecht[m]: Doing that now, because I had some problem with one of the submodules that was resulting in cmake errors.
<vollbrecht[m]>
if the underlying pin is save to be accessed via a &self i think its pretty painfull for the user to always require a &mut self for such operation
<dirbaio[m]>
can you show an example of driver code that becomes uglier if InputPin requires `&mut`?
<vollbrecht[m]>
<dirbaio[m]> "can you show an example of..." <- what i am saying is if the driver/ logical functionality is not bound to have exclusive access to that pin, than i think its a unnecessary burden for sharing one pin with multiple places. If it is dictated that this can always only be a &mut than its a limiting factor.
<vollbrecht[m]>
But don't get me wrong if the functionality of the Driver depends on that its another case.
<dirbaio[m]>
HAL crates can still provide a HAL-specific `fn is_high(&self)` method.
<dirbaio[m]>
if the chip's internal pins can be read with just `&self`, which all MCUs can
<dirbaio[m]>
the issue is not all pins can be read with just `&self`. Pins on an I2C/SPI expander require `&mut` access to the I2C/SPI bus
<dirbaio[m]>
many HALs already provide a HAL-specific is_high so they can make it infallible, while the InputPin method is fallible
<dirbaio[m]>
so HAL-specific code can still use `&self` fine
<dirbaio[m]>
the question is HAL-independent drivers using the embedded-hal traits
<dirbaio[m]>
are there any HAL-independent drivers out there that rely on using input pins with `&self` and are not trivially fixable?
<JamesMunns[m]>
<dirbaio[m]> "can you show an example of..." <- Honestly if we claim to support failable pins to allow for port expanders, we should take &mut too
<dirbaio[m]>
lol yeah it's very incoherent if you look at it that way
<dirbaio[m]>
this proves nobody is using embedded-hal gpio traits with port expanders 🤣
<dirbaio[m]>
which was the only reason to make gpio fallible 🥲
<JamesMunns[m]>
The historical answer is probably "inputs are read only, therefore can be shared safely, therefore &"
<JamesMunns[m]>
I'd probably agree &mut makes more sense. I bet that's needed for async and wait_for methods anyway, and I've personally never shared an input pin
<dirbaio[m]>
yeah wait_for requires &mut
<vollbrecht[m]>
dirbaio[m]: sorry i maybe not have enough coffee today :D but aren't the failable on embedded-linux cause cdev etc?
<vollbrecht[m]>
and on esp-idf we also get them in a totaly abstracted save way :D we could use "&self everywhere for everything "
<vollbrecht[m]>
war between OS and bare_metal ⚔️
<dirbaio[m]>
the esp-idf api can still provide an `is_high` method with `&self` instead of `&mut self`, independently of what the trait does
<vollbrecht[m]>
dirbaio[m]: yeah its absolutly fine for us, we do that already
<vollbrecht[m]>
what i am just saying from a high perspective it breaks down to limiting it to the smallest common divisor to support a brought set of spaces where it can be used, but its a trade off between functionality and where it can be used - if i get it right?
<dirbaio[m]>
yea
<vollbrecht[m]>
maybe we need a good definition what is "common" for embedded-hal in that sense :D
<dirbaio[m]>
for embedded-hal it makes sense to favor the "where it can be used" side of the tradeoff
<dirbaio[m]>
make the trait usable with as many kinds of inputpins as possible
<dirbaio[m]>
this is why it's fallible
<dirbaio[m]>
and this is why it should take `&mut self` instead of `&self`
<dirbaio[m]>
even if it makes it a bit less nice to use
<dirbaio[m]>
(I think the usability hit of `&mut self` is little, for example it's less than the usability hit of making it fallible)
<JorgeDOrtizFuent>
<JorgeDOrtizFuent> "Still trying:..." <- I have had to use `networksetup -setv6off Wi-Fi` in my macOS that has solved my problems downloading the git submodules.
<JorgeDOrtizFuent>
Successful compilation! Thanks a lot, guys! 👏
<JorgeDOrtizFuent>
ii Is any of you doing Zigbee development? I am considering doing a project using zigbee using an ESP32-C6. I have done something similar with Bluetooth and I used a mobile app to act as BLE central while developing the BLE peripheral in the MCU. How do people do this with zigbee (since mobile devices don't have a zigbee antenna)? Do they use a zigbee dongle on a RPi (like the Sonoff one)? If so, what application do they
<JorgeDOrtizFuent>
use?
<JorgeDOrtizFuent>
s/ii//
chodzikman[m] has quit [Quit: Idle timeout reached: 172800s]
dan_moore[m] has joined #rust-embedded
<dan_moore[m]>
Hello! I'm working on a no_std embedded project and am running into an issue where I can't seem to turn off stack unwinding before my panic_handler gets called. I've tried all of the suggestions I can find online (setting panic = "abort", providing and empty eh_personality function, etc). I've verified that my backtrace code works correctly by calling it before the panic handler, but once I attempt to call it within the panic
<dan_moore[m]>
handler, it only goes back to rust_begin_unwind. Any suggestions would be much appreciated :-)
<JamesMunns[m]>
> I can't seem to turn off stack unwinding
<JamesMunns[m]>
What target/OS are you working on? By default, no stack unwinding will occur for most embedded targets, like cortex-m
<JamesMunns[m]>
On cortex-m, there's a setting we had to enable in our target to never clobber the LR, even in divergent functions like panic handler
<dan_moore[m]>
I just instantiated a struct that implements drop() on the stack before calling panic and it doesn't appear that drop is being called, so I think that confirms that we're not actually unwinding before panic_handler (and instead likely trashing the LR)
<dirbaio[m]>
unwinding is not supported at all on cortex-m fwiw
<dan_moore[m]>
Looks like we're correctly passing -Cforce-frame-pointers=yes to rustc:
<dirbaio[m]>
> The Machine Outliner pass is enabled by default inside the aggressive code size optimization level -Oz for AArch64 and M-profile cores for 32-bit Arm
<PeterHansen[m]>
dirbaio: I have many still with "s"...
<dirbaio[m]>
perhaps it's also enabled on s then? but for some reason it decides to not outline anything in my firmware
<dirbaio[m]>
that explains why my llvm grepping efforts yielded nothing 😂
<PeterHansen[m]>
How big is the code base? This one builds to text size 392K with lto=fat and "z", fixed. I may also just be doing more of whatever type of thing it wants to outline.
<PeterHansen[m]>
But note the "wc" word count above... "s" has very very few outlined routines relative to "z" without the rustflag. 100:1 ratio
<PeterHansen[m]>
No, wait... probably pilot error here. I have my own code opt level under a separate section than other crates... :(
<PeterHansen[m]>
i.e. [profile.dev.package."*"]
<dirbaio[m]>
220k-280k with lto=fat, opt-level=s
<PeterHansen[m]>
The outlined routines in supposed "s" were from "z" with some of the embassy code and a few others. Clearly my own code has far more places where outlining kicks in though.
<PeterHansen[m]>
So you're right, no outlining in "s" when applied to everything. :)
<PeterHansen[m]>
So release code size here with "s" is 381, "z" is 455, and "z" without outlining 392. Pretty reasonable tradeoff until there's a fix.
<dirbaio[m]>
why use z if it's bigger? just use s
<dirbaio[m]>
(are these numbers right? it doesn't make sense that outlining makes code bigger)
<PeterHansen[m]>
Yeah, was just trying to decipher that...
<PeterHansen[m]>
I'm an idiot again... just mixed up the "s" and "z" numbers. So full "z" is 381, removing outlining it goes to 392, and switch to "s" it goes to 455.
<PeterHansen[m]>
* is 455 (edit: got those two reversed), and
<dirbaio[m]>
ah, makes more sense then!
<dirbaio[m]>
that's a big firmware
<dirbaio[m]>
* big firmware you got there
<PeterHansen[m]>
And it's almost half done! :)
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
I'm on beta now, so it's better to disable it.
<sourcebox[m]>
Not true, I went back to nightly because of cargo-binutils not working anymore.
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
<dirbaio[m]> "the issue is not all pins can be..." <- I asked about this a long time ago, and someone pointed out that a gpio expander would need to use a refcell/mutex anyway if it has multiple pins
<Socke>
what library would i want to use when I want to render some "fancy" 2D shapes (basically some clocks) on a raspberry pi? I looked at google forma but it seems to be unmaintained.
<K900>
Bare metal?
<K900>
Or on top of Linux?
<Socke>
on top of linux
<Socke>
it is not really an embedded question
<Socke>
I guess
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
egui
<Socke>
however I want to try to avoid Xorg/wayland
<diondokter[m]>
If you're using the SPI of the Pi to control a screen, then this is a good place to ask though.
<diondokter[m]>
But that's likely not what you mean
ziguana[m] has quit [Quit: Idle timeout reached: 172800s]
<Socke>
okay after having a closer look at slint I think I might prefer egui
<sourcebox[m]>
I used egui for some of my desktop apps, never tried it on an RPi.
<Auri[m]>
This might come as prejudiced (coz I work at Slint and having worked at Qt and Nokia) but my opinion is that immediate mode GUIs are not optimal for embedded use - from performance and resource consumption perspective.
<sourcebox[m]>
Yes, that's completely true. Especially if you're targetting a display via SPI. But an RPi is a different beast with way more power and bandwidth compared to a MCU.
<Auri[m]>
We used to work with customers who had quad core processors running embedded linux but they were very wary of resource consumption and performance. Their concern was that higher processor usage led to heat and then they had to invest into bigger heat sinks or else the device would be become too hot to use (and also interfere with comms on the data buses)
<Auri[m]>
Sometimes bigger heat sinks were no option because of the form factor of the device.
<Auri[m]>
For example, one customer was making a version of a desktop phone with display for use in stock markets
<Socke>
the largest painpoint about slint that I see is that it basically brings it's own language into rust - and it immediately broke rustfmt
<sourcebox[m]>
You probably have to check it in detail. The load is dependent on the amount of elements you render and also the frame rate, which you can limit.
<sourcebox[m]>
So if you're doing animations and have to render frames anyway, it's maybe ok to use immediate mode.
<Socke>
yeah its kind-of animated. I want to show a bunch of gauges in the main view, in other views lists with data
<vollbrecht[m]>
while egui works in immediate mode, if you run something like eframe you can choose if you let it run in immediate mode or reactive mode
<vollbrecht[m]>
so the web-demo for example runs in reactive mode
<sourcebox[m]>
You can request repaints either manually or after some timeout.
<Auri[m]>
* Sometimes bigger heat sinks were no option because of the form factor of the device.
<Auri[m]>
For example, one customer was making a version of a desktop phone with a display for use in stock markets by traders.
<Auri[m]>
<Socke> "the largest painpoint about..." <- Is that because of using the slint! macro?
<Auri[m]>
Alternative would be to put the slint code in a .slint file so that the rust code and slint code is separated.
<Auri[m]>
s/is/are/, s/separated/in separate files/
<Socke>
Auri[m]: yes it comes from the slint! macro
<Auri[m]>
<Socke> "the largest painpoint about..." <- Is that because of using the slint! macro? Alternative would be to put the slint code in a .slint file so that the rust code and slint code are in separate files.
<Auri[m]>
Auri[m]: Some of our users find it useful as they can independently develop the UI - for example using the online editor SlintPad https://slintpad.com
<vollbrecht[m]>
Auri: since are knowledgeable around current slint. One of our users in esp-idf rust had a problem with respect to the fallout of removed atomic64 + atomic-polyfill. He was using slint + rust on esp. I think you guys pullet that in thorugh the usage of once_cell. Are you aware of that problem or did you already fixed it. I think its fixed on once_cell master
<vollbrecht[m]>
* Auri: since you are knowledgeable around current slint. One of our users in esp-idf rust had a problem with respect to the fallout of removed atomic64 + atomic-polyfill. He was using slint + rust on esp. I think you guys pullet that in thorugh the usage of once\_cell. Are you aware of that problem or did you already fixed it. I think its fixed on once\_cell master
<Auri[m]>
vollbrecht[m]: Oops!! tronical ^
<Auri[m]>
> <@vollbrecht:matrix.org> Auri: since you are knowledgeable around current slint. One of our users in esp-idf rust had a problem with respect to the fallout of removed atomic64 + atomic-polyfill. He was using slint + rust on esp. I think you guys pullet that in thorugh the usage of once\_cell. Are you aware of that problem or did you already fixed it. I think its fixed on once\_cell master
<Auri[m]>
* Oops!! tronical did you know about this? ^
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<vollbrecht[m]>
yep looks like it. Without it you can only use compilers that are not newer than i think 5-6 weeks now? :D
<tronical[m]>
Fingers crossed a single cargo update fixes it then...
<vollbrecht[m]>
the goal here in the end is that the enduser can set the correct critical-section implementation with respect to what he is running via a feature flag
<vollbrecht[m]>
* to what environement/target he is
<vollbrecht[m]>
i think no_std and std hal's should also be all updated in esp-rs with respect to that problem so tronical if you have any other problems of breakage there feel free to ask around
<tronical[m]>
👍️ Thanks
<Socke>
Auri[m]: i will definitely have a second look again. but I'm currently also looking at lvgl
<Auri[m]>
<Socke> "Auri: i will definitely have a..." <- 👍 if you have any questions, feel free to reach out here or on Slint Mattermost chat https://chat.slint.dev
Dr_Who has quit [Read error: Connection reset by peer]
jamwaffles[m] has joined #rust-embedded
<jamwaffles[m]>
Does anyone have a Rust impl of the 1Wire protocol for a device, a la OneWireHub. I want to emulate an EEPROM using an MCU and would prefer to not reinvent the wheel 🙂
<firefrommoonligh>
Is this for that temp sensor?
<jamwaffles[m]>
Nah, DS2402 EEPROM spoofing
crabbedhaloablut has quit []
IlPalazzo-ojiisa has quit [Remote host closed the connection]