<barnabyw[m]>
(not that it’s important, but in this case pub const NAME = [0x21_u8, 0xb1] would have a fixed type, it wouldn’t be possible for type inferrence to decide that it’s something different)
<holo[m]>
| ^^^^^^^^^ help: a local variable with a similar name exists: `response`
<M9names[m]>
Abort(NoAcknowledge) means the target device did not respond, which means it could be the wrong address, wrong wiring, bad power or missing/insufficient pull-up resistors
<M9names[m]>
and maybe not "wrong wiring" but "bad wiring"
<M9names[m]>
just to be clear: you should always check the schematics when available, rather than guessing what will be there or assuming what purpose components on the board will have
<JamesMunns[m]>
heel yeah wire that bad boy up to SDA and SCL
<holo[m]>
i never used it before 😄
<holo[m]>
ok give me some time 🙂
<JamesMunns[m]>
s/heel/hell/
<JamesMunns[m]>
I'm gunna go to bed (it's europe, late here), but basically you should have two probes, CH1 and CH2. they have a ground clip and a hook for what they are measuring. connect one of the ground clips (doesn't matter which one) to the GND of the breadboard, and CH1 to SDA and CH2 to SCL
<JamesMunns[m]>
Maybe someone else here can help you set a trigger on falling edge of the SCL line with a capture window of "a while"
<holo[m]>
im from europe too 2am here, no worry i think i will leave it for tommorow too
<barnabyw[m]>
maybe the sensor board just needs a good night’s sleep and it’ll work perfectly in the morning
<holo[m]>
i will check tommorow some tutorials how to use this thing and if something will back to you
<JamesMunns[m]>
tho, learning how to do the basics with an oscilloscope or logic analyzer (and really, just having one) is seriously one of the best skills you can learn as an embedded developer
<JamesMunns[m]>
to start, maybe just forget the i2c stuff, and set a pin low and high every 100ms
<JamesMunns[m]>
then make sure you can read the square wave, then make sure you can set triggers on the falling edge
<JamesMunns[m]>
once you can do those two things, and see the square wave clearly, then capturing the I2C pulses should be a good step forward
<holo[m]>
for now i need to learn how to wire this thing and check if ist working i ordered it few years ago from alie when i wanted to learn risc-v board but it was to hard then for me for begining so its waited for now 🙂
<JamesMunns[m]>
You're making progress, and are fairly close!
<holo[m]>
thanks for helping i will try to read something how to use it tommorow and will back to you
Guest7282 has left #rust-embedded [Error from remote client]
markov_twain has joined #rust-embedded
Guest7282 has joined #rust-embedded
ruan[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
tr09[m] has quit [Quit: Idle timeout reached: 172800s]
<AdamHott[m]>
Question to the group: for designing PCB, I found that flux.ai has some AI features to help build schematics. But for actually preparing for a quote for PCB prototype manufacturing, I know I have to upload the gerber file. But there are a lot of other fields I don't understand in the quoting process. Is there a reference that would be good for me to learn these materials?
<AdamHott[m]>
And I've found some additional software to analyze Gerber files, like AutoDesk Eagle, KiCAD, Altium Designer, Gerbv, and ViewMate. Wonder if anyone has opinions on these?
Lakier15[m] has quit [Quit: Idle timeout reached: 172800s]
<barnabyw[m]>
AdamHott[m]: you could ask an ai about them :P
<JamesMunns[m]>
idk, I'm of the opinion "things are twice as complex to debug as they are to design", so if the AI helps you design something more complex than you understand, you're probably out of luck if it doesn't work perfectly.
<barnabyw[m]>
what other fields are you referring to, and what PCB manufacturing service are you looking at?
<JamesMunns[m]>
KiCAD is pretty widely used for hobbyists, as well as for decently complex commercial usage as well. There are also a fair number of "design your first board and get it manufactured" tutorials on youtube for KiCAD
<JamesMunns[m]>
Many of the other tools you mentioned are paid tools, for better or worse: If you DO pay for them there are like training materials for them (possibly also paid).
<barnabyw[m]>
IIRC fritzing has a simplified PCB manufacturing flow, if you’re okay with its limitations and the price likely being much higher than what you’d pay at JLC, PCBWay etc. I’d second the recommendation for KiCAD though, it’s very good and constantly improving
<AdamHott[m]>
<barnabyw[m]> "what other fields are you..." <- So far I've looked at PCBWay and a number of low quantity prototyping PCB shops in the US like Pentalogix, Sierra Circuits, and OSH Park:
firefrommoonligh has joined #rust-embedded
<AdamHott[m]>
<barnabyw[m]> "e.g. this one which covers..." <- This would be great to go through, thank you!
<firefrommoonligh>
Confirming KiCad is nice
<firefrommoonligh>
So the prob with OSHpark is it doesn't do assembly
<barnabyw[m]>
soldering it yourself is more fun anyway 🤓
<AdamHott[m]>
barnabyw[m]: yes this is what I want to do, to learn soldering well
<AdamHott[m]>
barnabyw[m]: So I could just get the boards manufactured, order the parts, and solder away, right?
<firefrommoonligh>
Yes
<firefrommoonligh>
Might be a good learning exercise for a small board'
<barnabyw[m]>
that’s how I’ve always done custom boards, yes. once you reach a certain density of components (or want more than one board) paying for assembly is definitely worth it though
<firefrommoonligh>
Maybe use large passives
<firefrommoonligh>
It will be tedius and error-prone
<firefrommoonligh>
But maybe not a bad exercise
<firefrommoonligh>
Yea try 0603 or greater
<firefrommoonligh>
0402 is the sweet spot for voltage dividers, bypass caps etc or really anything that doesn't need a high capacitance value, but will be trickier to hand solder
<barnabyw[m]>
0805s with handsoldering footprints are pretty much perfect for comfortable hobbyist handsoldering IMO
<barnabyw[m]>
manageable without any particularly special equipment
<firefrommoonligh>
I will say this: Almost all the faults on my own boards are from dorking up the hand-soldering of a part that is out of stock at JLC or w/e
<firefrommoonligh>
It's never because the manufacturer fucked it up
<firefrommoonligh>
(*Or for design faults on my part)
<JamesMunns[m]>
AdamHott[m]: Adam Hott have you soldered before? Or done surface mount soldering before?
<JamesMunns[m]>
if y'all are suggesting 0603 for a first soldering experience, on a board you actually expect to work, you are setting him up for failure :p
<JamesMunns[m]>
like, after you burn the first dozen passives and scorch the first boards, yep, I'm sure he can get the swing of it, but like, maybe start with through hole if he's never held an iron before :D
<firefrommoonligh>
Obligatory safety message: Both lead and flux fumes are bad for you!
<firefrommoonligh>
In the not-immediately-obvious, but will damage your body over time way
<AdamHott[m]>
JamesMunns[m]: I've done soldering before, did a lot of it when I was a kid in my grandpa's workshop. And I have painted in oils before which gives me that fine grain detail needed for smaller components. That being said I've never done surface mount soldering!
<barnabyw[m]>
once I learned SMD soldering I’d never want to go back to through-hole (sooo many leads to clip and reflow, ugh) but yes, some small through-hole project is a good starting place if you’ve never held an iron before
<firefrommoonligh>
* 0402 is the sweet spot for voltage dividers, bypass caps etc or really anything that doesn't need a high capacitance/inductance/voltage or current-handling, but will be trickier to hand solder
<barnabyw[m]>
maybe buy a lil kit rather than jumping straight into designing your own PCB, if you’ve not soldered anything before
<firefrommoonligh>
Yea IMO THT is not practical outside of larger ports
<firefrommoonligh>
But still important because you will end up with those ports most likely
<firefrommoonligh>
So you have to learn both
<AdamHott[m]>
If I start with Through-Hole, what size components would I use?
<firefrommoonligh>
Whatever the connectors spec you need is
<barnabyw[m]>
might be worth backing up a step: do you have a specific goal at the moment? i.e. a particular project you want to make?
<firefrommoonligh>
This is a 2023 board demoing that THT is still a thing. Mostly larger ports that need high current handling and structural stability
<AdamHott[m]>
barnabyw[m]: I need some ideas for a pretty complicated project. I want to do something that stands out. I'm wanting to get a job in embedding and need some complex examples.
<barnabyw[m]>
might I recommend several smaller projects in slowly increasing scope and complexity, each of which builds on the skills you developed in the previous one?
<AdamHott[m]>
That sounds good
<firefrommoonligh>
Ok how about this
<firefrommoonligh>
Make a dev board for your favorite MCU
<firefrommoonligh>
Or do something relevant to a hobby
<AdamHott[m]>
firefrommoonligh: This sounds great
<ijager[m]>
A LED cube is fun too, starts with basic GPIO, and to make it more advanced keep adding interfaces to control it from your computer. Control it via hardware timers instead etc.
<ijager[m]>
I would advise to have a more clear goal for. your project, a dev board is too generic in my opinion. Like when is it finished? What software are you going to write for it?
Foxyloxy has joined #rust-embedded
<ijager[m]>
Unless it is only about the PCB design
<AdamHott[m]>
ijager[m]: I basically want an example where 1) I successfully get a board printed 2) I solder simple components to learn board soldering and 3) get some type of components attached like a USB hub for a keyboard and an LCD for keyboard output
<AdamHott[m]>
And then write the software to glue it all together
<AdamHott[m]>
It just needs to be somewhat impressive for an example to discuss in interviews
<ijager[m]>
With a microcontroller or a rpi?
<AdamHott[m]>
whichever works better for the example. The Raspberry Pi Pico W is affordable so that would be ideal.
<AdamHott[m]>
Hey all, I chatted with ijager and decided on project for this, thanks!
<AdamHott[m]>
:)
<dirbaio[m]>
📣 we're looking for help testing a new version of `probe-rs` using the `nusb` crate (pure Rust replacement for libusb, fixes lots of pains for example around cross-compilation). If you use probe-rs (either the CLI or lib) we'd appreciate if you can give it a test and report whether it works or not!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YumOCIppcTEkUXvsiETeTTOH>)
kpcyrd[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901>
JamesMunns[m]: I love postcard-rpc, but I can't use it for my use case b/c I need a UDP or TCP connection, not serial. So uhhh... is there a quick porting guide? :D
<cr1901>
Additionally, I don't want to use tokio executor for this app, b/c the compile times are horrific on ARM SBCs (So I don't think "new_manual" applies)
<dirbaio[m]>
you can crosscompile from your main PC
<dirbaio[m]>
cross makes it relatively easy
<cr1901>
I don't want to cross-compile. I like my current workflow and don't feel like changing it. :)
<dirbaio[m]>
¯\_(ツ)_/¯
<cr1901>
That said, tokio might not be the problem, but rather the RPC crates I'm using/want to get rid of. So we'll see
<cr1901>
(How do you make executor-independent async functions? Aren't a bunch of the embassy helper crates executor-independent?)
<dirbaio[m]>
on Linux, you need a "reactor" to drive async io.
<dirbaio[m]>
Tokio folks decided to integrate the reactor into the executor, probably for speed. so tokio io futures only work on tokio executor
<dirbaio[m]>
but tokio is the exception really
<dirbaio[m]>
most other async io crates are executor-independent
<dirbaio[m]>
for example async-io
<dirbaio[m]>
async-io launches its own reactor in a background thread, independent from the executor, so it works on any executor
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
The whole idea behind Rust async is that the functions should be independent of the runtime.
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
and all crates that build on top of async-io are also executor-independent, like async-net.
<dirbaio[m]>
yeah
<cr1901>
The leaf futures either launch a reactor or communicate with an already existing one?
<dirbaio[m]>
it's actually Tokio who "screwed it up" by integrating the reactor into the executor. Since it's the most popular async runtime, people think "stuff is not executor-independent" is a rust async problem, while it's not, it's a tokio problem
<dirbaio[m]>
I imagine first one creates it and then it gets reused for the whole lifetime of the program
<dirbaio[m]>
haven't checked tho
<cr1901>
(Actual question I want to ask: How do you do a single-threaded runtime?)
<dirbaio[m]>
just use any single-threaded executor
<dirbaio[m]>
though if you use async-io with a single-threaded executor you'd actually have 2 threads I think? one for the reactor from async-io, and another for the executor
<cr1901>
You have to pass "here's how you communicate with the reactor" down to leaf futures, but I can't visualize it
<dirbaio[m]>
but that shouldn't "matter", your futures can stll be !Send etc
<cr1901>
yea I meant "only a single thread period", but noted
<dirbaio[m]>
I think tokio's single-threaded runtime is actually a single thread (for executor+reactor)
<dirbaio[m]>
I imagine leaf futures "find" the reactor through a thread local?
<dirbaio[m]>
* thread local variable?
<cr1901>
what does embassy executor/reactor do?
<dirbaio[m]>
embassy is different, there's no "reactor"
<dirbaio[m]>
the "reactor" is just interrupts
<dirbaio[m]>
HAL code stores wakers in a global, interrupts wake the wakers
<dirbaio[m]>
leaf futures from the HAL store wakers in globals*
<dirbaio[m]>
so I guess it's kinda the hardware equivalent as async-io, but instead of a background thread you have interrupts triggered by the hardware
<dirbaio[m]>
so it's also executor-independent
<dirbaio[m]>
like, you can use embassy-stm32 HAL on top of RTICv2 executor instead of embassy-executor and it all works fine
<cr1901>
Hmmm, I think I'll have to take a look to understand why leaf futures that store to wakers in globals are executor independent (b/c wouldn't embassy define the waker types? Does the RTICv2 executor also use embassy waker types?)
<dirbaio[m]>
it contains a vtable, so each executor can make it do a different thing when woken. (typically push the task into its run queue)
<JamesMunns[m]>
cr1901 there's not a porting guide, but there's an "escape hatch" where you can make your own connection logic, basically exchanging frames (UDP would be a decent match).
<JamesMunns[m]>
THAT BEING SAID, tbh, you might be better off with just using REST, or gRPC, or other existing concepts
<cr1901>
(I'm trying to get rid of the HTTP server, so REST is out)
<cr1901>
That is indeed something to play with, thanks!
<JamesMunns[m]>
so you'd do something like take the UDP frames back and forth
<cr1901>
A lot of the postcard stuff (pretty-hal-machine, postcard-rpc) is for serial ports, which fair, it's your library. But, in general I've not found the serial stuff very useful for my own work :(.
<JamesMunns[m]>
I'm actually currently getting away from that a bit, for USB at least
<JamesMunns[m]>
in a private project, I've switched to using nusb with bulk transfers, which means I end up with frames, sort of like UDP
<JamesMunns[m]>
that one is fun because it also has multiple devices, which means I've had to add a routing layer on top of it (one USB device acts as a bridge for multiple devices, and you can have multiple USB bridges)
<cr1901>
Nothing wrong with serial ports, I just don't find them ergonomic and/or "brings joy" when I have to provide my own USB CDC device or "RX/TX/GND cable"
<cr1901>
(God all I do is bitch at your work, I swear I think it's awesome)
<JamesMunns[m]>
:)
<JamesMunns[m]>
I don't feel complained at!
<cr1901>
:)
<cr1901>
dirbaio[m]: So a waker has a vtable, one entry for "each possible executors the waker could ever be accessed by"? Why is this info needed at runtime (why would you ever modify a waker from two runtimes simultaneously?)?
<dirbaio[m]>
a waker has a vtable with methods for "wake, clone, drop"
<dirbaio[m]>
so embassy-executor will create a waker where "wake" points to embassy-executor code
<dirbaio[m]>
RTIC will create a waker where "wake" points to RTIC code
<dirbaio[m]>
so
<cr1901>
(I think I'm used to a narrow definition of vtable for "dynamic dispatch to multiple possible implementations, and you can't know which one until runtime". Which I guess is technically true for Wakers too...)
<cr1901>
But you'd only have one executor typically in your application, so the vtable could be set at compile time? Idk... :P
<dirbaio[m]>
it's set up this way so you don't have to configure anything at compile time
<dirbaio[m]>
and you can even mix executors. for example you could use embassy-executor and rticv2 on the same app. So some wakers go to one, some go to the other
<dirbaio[m]>
would be silly to do, but async is designed to support that
<cr1901>
Ahhh, I didn't realize you could compose runtimes
<cr1901>
actually, scratch that
<dirbaio[m]>
or on std, you might be using tokio but call a lib that's using smol underneath
<cr1901>
Yea, this is nested event loops, correct?
<dirbaio[m]>
could be nested, could be on separate threads
<dirbaio[m]>
the dynamic dispatch does add a slight overhead
<cr1901>
I remember a while ago (2018) a convo w/ Graydon on hellsite saying that "composing runtimes wasn't really possible/practical". Interesting that changed
<JamesSizeland[m]>
vaknin[m]: Welcome! https://esp-rs.github.io/no_std-training/ esp and ferrous systems have some training material that might be a good jumping in point for you?
<barnabyw[m]>
<JamesSizeland[m]> "Welcome! https://esp-rs.github...." <- I’d start by getting a basic blinky example working on each board so you know you have a working dev environment and can build+flash firmware
<jessebraham[m]>
We have a bit more of a general introduction for the ESP32 stuff as well:
<jessebraham[m]>
Ahh, I guess the training links to that, doesn't it 😅
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
<barnabyw[m]> "I’d start by getting a basic..." <- Teaching university courses in embedded systems, my experience is that Rust by far is the preferred path for getting into this stuff (EE and CS students with no prior Rust nor embedded experience)
eZioPan[m] has quit [Quit: Idle timeout reached: 172800s]
<henrik_alser[m]>
<henrik_alser[m]> "Teaching university courses in..." <- (Thanks to the superior tooling, disregarding the obvious language benefits)
<vaknin[m]>
<henrik_alser[m]> "Teaching university courses in..." <- ha, that's interesting, thanks for sharing!
<vaknin[m]>
What 'framework' would you suggest to start with? I've seen 'embassy', 'RTIC', and so many other libraries, I'm quite confused
<holo[m]>
hey, like i told yesterday i played with my osciloscope with trial and errors i get some outputs from I2C communication
<JamesMunns[m]>
could you try using the not-blocking methods?
<JamesMunns[m]>
also, please stop pasting big blocks of code in chat, it'll be much easier to help you if you make a github repo
<holo[m]>
ok sorry will do that
<holo[m]>
And i have one more question about osciloscope what if coumication will be longer than my displacy? i mention its only showing this what fits on my screen
<holo[m]>
how to make it non blocking?
<holo[m]>
s/displacy/display/
<henrik_alser[m]>
<vaknin[m]> "ha, that's interesting, thanks..." <- > <@vaknin:matrix.org> ha, that's interesting, thanks for sharing!
<henrik_alser[m]>
> What 'framework' would you suggest to start with? I've seen 'embassy', 'RTIC', and so many other libraries, I'm quite confused
<henrik_alser[m]>
Those two are both great options, for general work i tend to go with embassy these days as a first resort
<holo[m]>
* how to make it non blocking i thought im using non blocking functions 🙂?
<holo[m]>
And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<barnabyw[m]>
henrik_alser[m]: even if you don‘t end up using embassy, the embassy docs have a nice walkthrough showing how you’d implement the same application at several layers of abstraction https://embassy.dev/book/dev/layer_by_layer.html
<holo[m]>
And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<holo[m]>
* how to make it non blocking i thought im using non blocking functions because im using non blocking example 🙂?
<JamesMunns[m]>
holo[m]: > <@holo:matrix.org> how to make it non blocking i thought im using non blocking functions because im using non blocking example 🙂?
<JamesMunns[m]>
> And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<JamesMunns[m]>
I mean to use the `async` version
<holo[m]>
ahh
<holo[m]>
ok will try
<JamesMunns[m]>
I think the async hal bits are more commonly used, so its possible the blocking one has a bug
<JamesMunns[m]>
if it "just works" with the async version, then it's probably an embassy bug
<JamesMunns[m]>
(or rather, a "blocking hal method bug")
<holo[m]>
thanks trying this second example in that case
<henrik_alser[m]>
barnabyw[m]: If you’re familiar with async programming from other fields it should be a smooth onboarding to embedded programming
<holo[m]>
and what with osciloscope? what if communication wont fit screen? is it some rewind option or something? when i was using horizotal positioning, graph was cutted on edge of screen
<JamesMunns[m]>
Usually scopes will have some "sample depth", where the sample depth / sample rate is how long of a "snapshot" you can record
<JamesMunns[m]>
> Thanks to a sample rate of 1 GSa/s and a memory depth of 8 Mpts you can easily work with this oscilloscope
<JamesMunns[m]>
so, if you are sampling at 8msps, you can record one second
<JamesMunns[m]>
for I2C at 100khz, you probably want to be recording at 200ksps+, 1msps wouldn't be bad. at 1msps you'd get 8s of recording time
<holo[m]>
looking for this setting i remember i it somwher but not remember whenre
<JamesMunns[m]>
It does show the value at the top center, where it says "5.00 MSa/s"
<vaknin[m]>
henrik_alser[m]: thanks a lot, everyone
<henrik_alser[m]>
holo: Are you using external pullup resistors?
<holo[m]>
its included on board
<holo[m]>
James Munns: setting up this 4M depth didnt change anything, only this what is placed on one screen, i do not see too optoin to change sample rate. Its changing based on depth setting i choose
<holo[m]>
its showing only first part/command exactly like it was before with blocking
<holo[m]>
right now i do not see even try of sending second command
<JamesMunns[m]>
is it panicking on the second command? or the first one?
<JamesMunns[m]>
the first one seems to complete successfully?
<holo[m]>
according to log info on first its not going to "Wait 5 second"
<JamesMunns[m]>
(gotta run for a bit)
<holo[m]>
"writing" information not showint at al
<holo[m]>
wheni reverted to previous blocking its like it was, strange Same logic is failing on other commands
crabbedhaloablut has quit []
notgull has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<holo[m]>
i made few additional tests, i added additional command (wake up) on beggining and im getting same error. So its not problem just with read_write. I tried same on blocking example, and first writing command is working and second writing command is breaking same way like read_write before, s on second byte. Looks like its always hanging on second command (no matter which it is) and on first command with await even its sending it
<holo[m]>
properly. Can it be broken sensor?
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
<barnabyw[m]>
if you have a dev board lying around with arduino support, maybe try making an arduino sketch which communicates with it using the official library from sensiron? then you at least know a) whether or not the sensor works, and b) what successful i2c communication with it looks like https://github.com/Sensirion/arduino-i2c-scd4x
<holo[m]>
i have rp5 too
<holo[m]>
on other i2c pins same, ok will try your advice and will try to find something for rp
<holo[m]>
to check if that sensor working at all
<holo[m]>
😆
<holo[m]>
working
<barnabyw[m]>
that was quick!
<holo[m]>
i turned pico w off and on
<holo[m]>
and started work 😄
<barnabyw[m]>
huh
crabbedhaloablut has quit []
<GrantM11235[m]>
Maybe it was the spinlock reset bug? I don't remember the exact details, hopefully someone else does
<holo[m]>
After few next flashes happened same and i needed to take out usb power from pico to reset make it usable again. Ok now i need to decode what get back but after i will walk and thake some fresh air. Thank you all for helping
<henrik_alser[m]>
holo: are you using the ”critical-section-impl” feature of embassy-rp?
<henrik_alser[m]>
If you do, make sure you unlock spinlock 31 as suggeated above
<henrik_alser[m]>
(rp2040 has a bug in it, where a reset won’t also reset the spinlocks)
<henrik_alser[m]>
(one of which are used for the multicore safe critical section implementation)
<henrik_alser[m]>
If you’re only using a single core, you can remove this feature and use the ”critical-section-single-core” feature on the cortex-m dependency instead
Noah[m]1 has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 260 seconds]
<henrik_alser[m]>
* a reset,, * as triggered by probe-rs, won’t also
Guest7282 has left #rust-embedded [Error from remote client]
vancz_ has quit []
vancz has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<holo[m]>
<henrik_alser[m]> "holo: are you using the ”..." <- thanks for info, i will add it to my code What i mention it is crashing each second or third flash by a row
<henrik_alser[m]>
holo[m]: Sounds very much like a spinlock issue
<barnabyw[m]>
is there a no_std equivalent of anyhow which can work without an allocator?
<holo[m]>
and looks like i added this line before i2c config and now 5th time in row flash working
<holo[m]>
henrik_alser[m]: and looks like, i added this line before i2c config and now 5th time in row flash working
<holo[m]>
nope
<holo[m]>
i was celebrating to fast
<holo[m]>
but, what i mention too this problem appear too when i remove sleep between commands
<henrik_alser[m]>
Do you have it at the first line in main?
<holo[m]>
ahh no
<holo[m]>
will try
<holo[m]>
same
<holo[m]>
i think is something with sleep times between commands it looks itw working when i have 5 sec between each of them
<holo[m]>
but with 1 sec it stoping working again
<holo[m]>
exactly.. hmm maybe im missed something from datasheet
<henrik_alser[m]>
holo[m]: Yeah or just retry if you get an Err when attempting to read measurement would do aswell i guess (maybe with a little delay)
<holo[m]>
ok i added thos e reses and info but still same and not showing anything: