leonardvdj[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
<M9names[m]>
<StephenD[m]> "I asked about this a while ago..." <- linux doesn't need a tool like zadig to use libusb, as long as you've got permissions to access the device you just use it.
<M9names[m]>
if you install dfu-util it will have already installed the correct udev rules file, so if you still don't have access you probably just need to add yourself to the plugdev group
<StephenD[m]>
M9names[m]: > <@9names:matrix.org> linux doesn't need a tool like zadig to use libusb, as long as you've got permissions to access the device you just use it.
<StephenD[m]>
> if you install dfu-util it will have already installed the correct udev rules file, so if you still don't have access you probably just need to add yourself to the plugdev group
<StephenD[m]>
Right, sorry I meant for windows systems
<M9names[m]>
zadig comes with libusb drivers.
<M9names[m]>
you select the device and change the driver to libusb. that's it, that's the whole process.
<StephenD[m]>
<M9names[m]> "zadig comes with libusb drivers...." <- > <@9names:matrix.org> zadig comes with libusb drivers.
<StephenD[m]>
> you select the device and change the driver to libusb. that's it, that's the whole process.
<StephenD[m]>
Yes I did that already. The problem is that libusb doesn't appear to work with the dfu tools
<StephenD[m]>
So I either need to fix that or source another driverf
<M9names[m]>
do you get an error message like the one shown in this blog post?
<StephenD[m]>
No, I get libusb access denied errors
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
<M9names[m]>
can you share a screenshot?
emerent_ has joined #rust-embedded
emerent is now known as Guest3157
emerent_ is now known as emerent
notgull has quit [Ping timeout: 268 seconds]
notgull has joined #rust-embedded
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
Guest1 has joined #rust-embedded
Guest1 has quit [Quit: Client closed]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
Guest7282 has quit [Quit: Gateway shutdown]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #rust-embedded
SzczepanCielik[m has joined #rust-embedded
<SzczepanCielik[m>
Hey, can someone suggest best approach to persitent memory? Imagine I use some ESP to generate random key every X time and if power goes down and up again I can still have the same? (I see there is esp-storage and cbor but maybe there is different, more general approach for simple key value storage?)
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
complex solution in most of the time.
<vollbrecht[m]>
A simple solution for example could be something like using postcard to serialize the objects and then store them. If you want something ready made you can use esp-idf-svc nvs api, though if you are talking about esp-storage i presume you are using the no_std hal?
<vollbrecht[m]>
that heavily depend on the time frame of "X time" here. Though if your goal is already fixed as in - you want to write the data into the spi flash chip - well than is just a question of accessing it. But a simple solution might not be a "best" solution here. For example do you want some partition schema for your storage, what about were leveling if you reuse cell's over and over. So a more abstract solution would entail a more
<SzczepanCielik[m>
`no_std` - exactly
<SzczepanCielik[m>
second, more important, I want this to run fan for given amount of hours, like 20, and if this goes down (power outage, or simply turned off with button) I want to know how much time is left; ideally I could update memory each second, but quantyfing it by 10 min is fine; so here I want to update state each 10 min so I can start from where I stopped process because of outage
<SzczepanCielik[m>
as for values I have two cases - first is to hold API key - I could compile that in with `!env()` but I don't like it
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Happy New year folks 🥂 The resolution this year is to get actually involved with the ecosystem 😁 looking forward to it
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #rust-embedded
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
I had a situation where I need to test whether a sensor is working or not, or if my soldering is short circuiting two points on a pcb and causing the sensor to fail. I was looking at this flipper zero, and wondered how handy it would be for testing and debugging, and I wonder what people's opinion is whether these would be helpful or not? https://flipperzero.one/
K900 has joined #rust-embedded
<K900>
It's much cheaper to just get a scope
<AdamHott[m]>
What's a scope?
<K900>
Or any small microcontroller board or even SBC
<K900>
An oscilloscope
<K900>
The Flipper is a very cool piece of kit
<AdamHott[m]>
Any recommendations on an affordable scope that's also quality?
<K900>
But hardware debugging isn't its primary purpose
<K900>
Or its secondary purpose
<StephenD[m]>
Agree, I would love a flipper zero but my scope is so much more useful for hardware debugging
<StephenD[m]>
AdamHott[m]: Second hand, imo
<K900>
If you want something specifically designed for that, get a Glasgow
<StephenD[m]>
K900: Had to look this up but it's nifty
<vollbrecht[m]>
the biggest place where you can find out more about oscilloscopes is on eevblog, even if the owner is maybe not for everyone its with the most information out there.
<K900>
AdamHott[m]: There's some surprisingly OK stuff on Aliexpress
<AdamHott[m]>
K900: Do you have a link to the glasgow tool? I'm getting all the wrong tools pulled up in search :/
<StephenD[m]>
vollbrecht[m]: What's wrong with the owner?
<vollbrecht[m]>
nothing really - its just a character, and some people just judge by character when it comes to that kind of info places so i personal would say unjust, but if i recommend someone something i try to be neutral and directly point things like that out.
<FreeKill[m]>
A cheap logic analyser will also cost you only ~€10. It serves a different purpose to a scope, but is also an invaluable tool for this sort of purpose
<K900>
For the kind of thing you want
<FreeKill[m]>
s/purpose/debugging /
<AdamHott[m]>
The Tigard is a lot more useful, or the Glasgow?
<AdamHott[m]>
FreeKill[m]: Any recommendations?
<esden[cis]>
It depends. Both have their dis/advantages
<AdamHott[m]>
AdamHott[m]: Or are you talking about the required logic analyser required in addition to the Tigard?
HumanG33k has quit [Quit: WeeChat 3.8]
<esden[cis]>
Tigard is useful on its own I have a bunch scattered on my desk hooked to projects. Same with Glasgow.
<FreeKill[m]>
More often than not in embedded work, I find that I'm either concerned about DC things - in which case I want a voltmeter... Or I'm concerned about logic errors, in which case a logic analyser is usually better than a scope
<FreeKill[m]>
There are absolutely lots of cases where only a scope is appropriate - but for embedded it would be my third tool, most of the time
<AdamHott[m]>
My project is measuring humidity using the SHT31 Grove Temperature and Humidity Sensor
<AdamHott[m]>
It has Ground, VCC, SDA, and SCL
<FreeKill[m]>
yep, so a logic analyser is probably as useful as anything else (plus a voltmeter ;P)
<AdamHott[m]>
Would I be able to connect up this €10 logic analyzer to tell if it's working properly?
<esden[cis]>
You will not be able to drive the sensor, only see the traffic on the communication cables.
<esden[cis]>
LA is a passive device. If you want to drive something, Tigard or Glasgow are a better choice.
<AdamHott[m]>
esden[cis]: I'm sorry I'm so green, what does "drive" the sensor mean?
<AdamHott[m]>
Apologies
<esden[cis]>
Send data to the sensor. You can not jiggle the data lines with a LA.
<esden[cis]>
You can only look at the lines what they are doing with an LA.
<AdamHott[m]>
Ok, but I'll see that it's able to be powered on and that it's sending traffic?
<AdamHott[m]>
on the SDA and SLC lines?
<FreeKill[m]>
If you have another system powering it on and talking to it
<esden[cis]>
Read the datasheet of the sensor first.
<FreeKill[m]>
then you can "snoop"
<esden[cis]>
Familiarize yourself with how it works, what it does when you power it on.
<K900>
SPI is generally request based
<esden[cis]>
That is the first thing you need to do before you do anything else.
<K900>
As in, it will not send anything to the bus until asked
<esden[cis]>
It will likely not send anything out without you actively configuring it.
<FreeKill[m]>
It's I2C not SPI
<esden[cis]>
And for that you need to "speak" SPI. or I2C
<AdamHott[m]>
Yeah that sensor is IC2
<K900>
I2C is also that
<esden[cis]>
I2C especially
<esden[cis]>
Adam Hott: Find the datasheet of the sensor you want to use and read it. It will explain a lot of what you are asking here.
<AdamHott[m]>
Ok, will do! I'll research this more!
<AdamHott[m]>
Thanks everyone!
<FreeKill[m]>
So your device is an I2C slave, and requires a bus master connected to it that can tell it what to do. If you just connect the device to power and that's it, then nothing will happen.
<FreeKill[m]>
Once you have the device connected to a master that's actually asking things, then is the appropriate time to snoop with a logic analyser.
<korken89[m]>
So eh, does anyone know how much UB it is to construct a slice from an area of the flash memory? I have an area of flash written with a key which is exposed via a linker variable. So I want to do core::slice::from_raw_parts(__my_linker_var, some_size). This works in practice, but am I standing on some weird landmine? 😅
<FreeKill[m]>
I think it should be fine? But is there a reason it's not a static array that's linked into a certain location?
<korken89[m]>
How do you mean?
<korken89[m]>
The key is provided by a production tool and flashed into a specific area of the flash, to give some context.
<FreeKill[m]>
Well if you have a static array of some length, you can just link it to wherever you need in the binary. Then you don't need to construct the slice unsafely, it's just where the variable is
<korken89[m]>
Ah, the production tool does not know where this is plus it would mean performing surgery on the binary to be flashed
<FreeKill[m]>
I don't quite understand what you mean by that
<FreeKill[m]>
How is __my_linker_var_pointer produced, and how is it used by the production tool?
thejpster[m] has joined #rust-embedded
<thejpster[m]>
korken89: as long as each T in the slice is validly initialised, I think this is fine
<korken89[m]>
Which is fine if the data provided was fixed size :D
<FreeKill[m]>
ahhhhhh fun
<korken89[m]>
The keys I'm getting are either compressed or uncompressed SEC1 (fun), and I only know by checking if all bytes after 33th is 0xff :P
<korken89[m]>
But I can just as well have max size and slice it down
<korken89[m]>
Should be equal amount of unsafe
<korken89[m]>
As if the amount of unsafe can be measured 😅
<FreeKill[m]>
I only mentioned this approach because I thought you could maybe sidestep unsafety altogether. But if not then I think your way sounded fine too :)
<korken89[m]>
Accessing a linker variable requires unsafe so that ship has already sailed 😅
<FreeKill[m]>
I will say that I have had weird and annoying issues in the past where variables provided by the linker - if they're marked static (const in c) - the compiler realises that it never gets written to and replaces all the reads with 0
<FreeKill[m]>
So just watch out for that i guess
<korken89[m]>
Oof
<FreeKill[m]>
yeah incredibly annoying, I never found a really good resolution to that particular issue unfortunately...
<FreeKill[m]>
You either make it non-const, or add volatility. Both suck
<korken89[m]>
Yeah does not sound nice
<korken89[m]>
So far I've not run into something similar with accessing linker variables, but I'm sure something weird can happen if you're not careful
<korken89[m]>
<thejpster[m]> "korken89: as long as each T in..." <- On this when building it like this I guess strict pointer provenance is broken?
<korken89[m]>
As the origin and size of the area pointed to by the pointer cannot be verified
<korken89[m]>
Not sure though, I'm way too deep into the details of the compiler now
<thejpster[m]>
If you are worried, make a wrapper type that accesses the bytes through a pointer, maybe copying into a stack allocated array?
<FreeKill[m]>
As long as everything is accessed through the same one pointer provided by your linker, I don't think you can have provenance issues right? There is one source of provenance, and it's that pointer.
<korken89[m]>
Yeah, that would be the safe approach
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
<korken89[m]> "On this when building it like..." <- Provenance from int casts isn't specified yet, the idea is to have a function for that eventually
<thalesfragoso[m]>
So, for now, it's any provenance
<korken89[m]>
Ah that's nice (for my usecase)
<FreeKill[m]>
Also korken89: at least in GCC, it claims that the section attribute should only be applied to initialised globals! So I would avoid the other way I mentioned just in case. Having the linker provide a dummy variable that you use to get a pointer to the correct area sounds less questionable to me
<thalesfragoso[m]>
korken89[m]: That's kinda necessary for any MMIO to work
<korken89[m]>
Yeah, the entire register space is sort of dependent on that we can conjure it from thin air
<korken89[m]>
Then I'll put my worries to rest for now :D
<thalesfragoso[m]>
korken89[m]: Just make sure to not use with things that might try to write to it
IlPalazzo-ojiisa has quit [Ping timeout: 268 seconds]
<thalesfragoso[m]>
Like AtomicU8::load ...
<thalesfragoso[m]>
(depending on the Ordering)
<korken89[m]>
Ah yeah, as it is in flash that would be instant hardfault :)
<thalesfragoso[m]>
Although I would expect the compiler to be sane enough for our usual `none` targets
dbristow-rs[m] has quit [Quit: Idle timeout reached: 172800s]
<barnabyw[m]>
does anyone have experience using bitfield_struct with defmt? I’m getting some kind of debug_assert collision from within a macro which I can’t figure out how to fix