dkhayes117[m] has quit [Quit: Idle timeout reached: 172800s]
dodothattried[m] has joined #rust-embedded
<dodothattried[m]>
heya. Does anyone know of any crates that do matrix multiplication (floating or fixed point) using hardware acceleration on a Cortex-M(33) core
<dodothattried[m]>
dodothattried[m]: ah, just saw that there is an FFI crate to the CMSIS DSP library
HumanG33k has quit [Ping timeout: 264 seconds]
notgull has quit [Ping timeout: 246 seconds]
<dodothattried[m]>
dodothattried[m]: not maintained and doesn't seem to do too much though
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #rust-embedded
HumanG33k has joined #rust-embedded
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 276 seconds]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
It's FFI; it works
<firefrommoonligh>
But requires LLVM=15 (old version) to work. I should probably figure out how to do FFI and make an updated version
<firefrommoonligh>
What makes you think it doesn't do much?
<firefrommoonligh>
It's a raw binding; does the full CMSIS-DSP feature set
rjmp[m] has quit [Quit: Idle timeout reached: 172800s]
ainedixon[m] has joined #rust-embedded
<ainedixon[m]>
Hi guys, Where can i find resources that can help me learn embedded programming with rust on arduino kits
<ainedixon[m]>
I have no any experience with embedded programming, and yet based on my location, aquiring the micro:bit used in the discovery book is very expensive and I can't afford it. I only have access to arduino kits
K900 has joined #rust-embedded
<K900>
Maybe look for some STM32 or ESP32boards off Aliexpress
<K900>
* Maybe look for some STM32 or ESP32 boards off Aliexpress
<ainedixon[m]>
<K900> "Maybe look for some STM32 or ESP..." <- Thank you very much, I just realized they do free shipping.
<ainedixon[m]>
Shipping is what has been making everything very expensive
<K900>
Depends on the seller
<K900>
But many at least have a cheap "shove it into HK Post and pray" shipping method
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 256 seconds]
<Darius>
michaeldesilva[m: why do you think it is unstable?
notgull has joined #rust-embedded
<GrantM11235[m]>
michael.desilva: Based on your description on the arduino forum, it sounds like it could be a pwr config problem. I don't really know how that system is supposed to work though
<Darius>
I guess you don't have a debugger..
<michaeldesilva[m>
I have a jtag link mini
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
sjm42[m] has quit [Quit: Idle timeout reached: 172800s]
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
<adamgreig[m]> "and the couple day embedded..." <- Is this actually getting shape? At least the timeframe? This would comming to delft make a no brainer for me.
<adamgreig[m]>
Yep, we expect it to go ahead, most likely the 9/10 may
<sirhcel[m]>
Hooray! Thank you! then i can already block these days.
loki_val has quit [Ping timeout: 264 seconds]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<AdamHott[m]>
I had a board manufactured and soldered some components, tested it out. It didn't fry or overheat when I plugged it into a USB charger. But the reading with the multimeter came back at 7 volts on the 5V rail and 1.7V on the 3V rail. It didn't short out. Am I safe to plug this into my computer you think, or are those voltages off?
<JamesMunns[m]>
uh
<JamesMunns[m]>
that sounds very extremely weird
<JamesMunns[m]>
I cannot think of a reason at all you would read 7v on the 5v rail?
<FreeKill[m]>
Indeed - please don't plug 7v into your usb ports!
<AdamHott[m]>
ok thanks!
<FreeKill[m]>
But it is very bizarre that you would get 7V if your board is _powered_ by the usb. Is that the case? I assume if you were doing usb power delivery you would know it
<AdamHott[m]>
Hmm... I used a wall charger, don't know if that makes any difference?
<FreeKill[m]>
Usually not, no. Is it usbc ?
<AdamHott[m]>
Just for testing purposes. Maybe I did something wrong with my multimeter. It's micro-usb
<FreeKill[m]>
Or usb micro/mini
<FreeKill[m]>
Okay then it really really shouldn't be anything except 5V
<FreeKill[m]>
If you can, measure the voltage as near to the usb as possible. It really, really should be 5V. If it's not, then either your charger or your multimeter is not working correctly!
<AdamHott[m]>
ok I'll try another charger, this multimeter was working fine last time I used it
<JamesMunns[m]>
If you have another dev board, measuring voltages there will help you decide if it's a problem with your meter or board
<JamesMunns[m]>
like, if you have normal dev board, plugged into your PC, and the meter says VUSB is 7v or something, then something is wrong. Like, maybe your battery in the meter is dead.
<JamesMunns[m]>
(or you have the wrong dial setting)
<FreeKill[m]>
7 imperial volts maybe
<AdamHott[m]>
I think I'm just having trouble with the multimeter. I did get a 5V read on the 5V rail, but I couldn't get an accurate read on the 3V rail. What do you think now about plugging it into the computer?
<K900>
If it's powered from the USB port
<K900>
And you don't have anything on there that would INCREASE the voltage
<K900>
It's probably safe.
<AdamHott[m]>
It will be an adapter from USB A to USB C
<K900>
As in, it should be safe unless you just short out the power
<K900>
USB ports should have overcurrent protection
<AdamHott[m]>
ok I'll give it a try
<dirbaio[m]>
<FreeKill[m]> "7 imperial volts maybe..." <- not to be confused with nautical volts
<AdamHott[m]>
ok computer is fine
<AdamHott[m]>
does anyone have the link the repo for the stm-32?
<AdamHott[m]>
thanks everyone!
<AdamHott[m]>
got it, nm!
<dodothattried[m]>
<firefrommoonligh> "What makes you think it doesn'..." <- Just that it doesn’t do anything to wrap the APIs in a way that might make them easier to use or possibly extend their functionality. Last time I fiddled with CMSIS DSP in C I struggled with it. That said, providing just that functionality is fine.
<AdamHott[m]>
well the board is a dud, isn't recognized by my computer and can't be flashed. But the overall process of designing the board, getting it manufactured, selecting the components, soldering the board, testing its voltage, all of this was new to me so it's a win overall. I still have 4 more test boards and components.
<ragarnoy[m]>
<dirbaio[m]> "or you can do `dyn SpiBus<u16..." <- i'm bouncing back on this, what if embedded_hal::spi::ErrorType had spi::Error + Into<ErrorKind> (if that makes any sense), it would ease the job to make adapters+ a macro could be made to generate SpiAdapters ?
<dirbaio[m]>
you can already do that with the current trait bounds, just writing .kind() instead of .into()
<ragarnoy[m]>
true, my bad :x
<AdamHott[m]>
I've put another tutorial together for a SHT31 temperature and humidity sensor. It works as expected, but the only kink in the code that I'm trying to work out is why I'm getting a print to the terminal of "Write Read I2C Error!" which is the Error handler. It prints this after a proper temperature and humidity reading printed to the terminal. Anyone have any ideas?
<K900>
So presumably one iteration succeeds and then the next one doesn't
<ragarnoy[m]>
is there a quick way to find what triggers this?
<ragarnoy[m]>
`error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait`
<ragarnoy[m]>
I think i may have added a dependency somewhere or included something that needs alloc but a quick search turns nothing up
<michaeldesilva[m>
<K900> "So presumably one iteration..." <- Yup. That makes sense.
<vollbrecht[m]>
Adam Hott: a multimeter is a must have tool, but quite often it can be really simple to confuse the hell out of them. While many have a dc and a ac "true rms" label for reading voltage, the real world is often more complicated ;) For example if you have some device that can create a pwm. Just try to create a pwm with 50% duty cycle and let it run on 500Hz, 5khz, 50khz etc and then try to "measure" that voltage on that pwm pin.
<vollbrecht[m]>
The readings will be all over the place. This can be just a simple illustration of the problem that if a real world signial is in most cases never a clean DC or a clean one frequency AC signal.
<michaeldesilva[m>
vollbrecht[m]: Would an FFT on this line help?
<michaeldesilva[m>
* line help? Just to see what the other frequencies are?
<michaeldesilva[m>
Of course if you’re using an oscilloscope make sure your taking your signal reference to ground.
<AdamHott[m]>
<K900> "So presumably one iteration..." <- thanks! I think what is happening is my periodic measurement is set to read every half second but my loop is delayed for longer.
<jr-oss>
ragarnoy[m], add a global allocator that panics and see the backtrace
<michaeldesilva[m>
* to ground. If not, use a differential probe.
<michaeldesilva[m>
* Of course if you’re using an oscilloscope make sure you’re taking your signal reference to ground. If not, use a differential probe.
<vollbrecht[m]>
The problems with FFT's are that they are "discrete" and lot more complicated that many people will not understand in a simple test. You can also simply get a lot of garbage signals inside a FFT that are not there "in the real signal". So you first need to know how your signal behaves before you even analyze it ;D some catch 22
<michaeldesilva[m>
* Of course if you’re using an oscilloscope make sure you’re taking your signal reference to ground (otherwise you risk shorting your oscilloscope!!). If not, use a differential probe.
<michaeldesilva[m>
Gotcha 😅
<vollbrecht[m]>
you dont need to have all the equipment, but you still need to be aware that real voltage lines can have all sorts of crap into them, and that your equipment can be thrown of quite easy in a lot of times. So its more about learning what your tool can accurately measure and where it begins to struggle.
<vollbrecht[m]>
* The problems with FFT's are that they are "discrete" and lot more complicated under the hood. Many people will not be able to read out the potential wrong data because of wrong windowing for example . You can also simply get a lot of garbage signals inside a FFT that are not there "in the real signal". So you first need to know how your signal behaves before you even analyze it ;D some catch 22
<AdamHott[m]>
<michaeldesilva[m> "Of course if you’re using an..." <- thanks michael!
<AdamHott[m]>
<vollbrecht[m]> "you dont need to have all the..." <- thanks!
<thejpster[m]>
is it possible to set a cortex-m-rt exception handler to be a C function which I cannot control the name of?
<thejpster[m]>
I could write a rust function which does extern "C" { fn RealCHandler(); } RealCHandler(); , but I want to call a naked assembly routine
georgetta[m] has joined #rust-embedded
<georgetta[m]>
anyone got a link to the other rust room?
<georgetta[m]>
i can't find it anymore
<K900>
#rust:matrix.org
<georgetta[m]>
K900: >You do not belong to any of the required rooms/spaces to join this room
<K900>
Set it back to public
<K900>
We've been getting bots
<georgetta[m]>
Oh that's why it disappeared
<georgetta[m]>
Spam bots?
<K900>
Yes
<dirbaio[m]>
<thejpster[m]> "is it possible to set a cortex-m..." <- maybe you can alias it in the linker script? `HardFault = RealCHandler;`. maybe with `PROVIDE()`, I have no idea
<dirbaio[m]>
or you can write your own naked asm with the right name, that does b RealCHandler.. wasting a few cycles
<thejpster[m]>
the linker script already does a PROVIDE to map SysTick to DefaultHandler
<thejpster[m]>
I solved it the other way and managed to rename the C symbol to match what cmrt wanted
<Ecco>
Would you be interested in any of the comments I made?
<Ecco>
(i.e. renaming HSI/HSE to HSI16/HSE32 and/or ditching PllSource?
<Ecco>
(They're all public so I didn't dare doing it right away)
<Ecco>
Also, WBA has a HSE prescaler (like WB), so I might do a PR for this too (it's a different matter tho)
<dirbaio[m]>
I was writing the response 🤣
<Ecco>
oh ok sorry :)
<Ecco>
Ok perfectly clear
<Ecco>
Let's leave it at that then
HannoBraun[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco>
Damn, one of the tests failed, but I have no clue why
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
random failure
<Ecco>
ok :)
<Ecco>
regarding the prescaler thing: I'm looking at the code for STM32WB (l.rs). There's support for a HSE prescaler, but… is it actually implemented?
<Ecco>
Here the CR register is just *written*, not *updated*
<Ecco>
(so it's a write, not a read/modify/write)
<Ecco>
Is it on purpose?
<Ecco>
I mean… for the most part it does the job ok
<Ecco>
But usually I'd rather update than write
<dirbaio[m]>
true, that should be an update. (it's resetting all the other bits to 0, which might happen to work since it's the first CR write, but still)
<dirbaio[m]>
s/an/a`.modify()`./, s/update.//
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #rust-embedded
<Ecco>
well, it also accidentally happens to shut down HSI, which I guess is good
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
georgetta[m] has left #rust-embedded [#rust-embedded]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<ragarnoy[m]>
hey, is there anything that one should be careful about when including a c library ? I pretty much finished a wrapper over a pretty big C SDK for a radar, it's my first attempt flashing it to my radar antenna, and not only i'm not getting any of the defmt prints after i run `probe-rs run`, but when running `probe... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zfnxOhqkUknHDuwplAvJJKfD>)
<ragarnoy[m]>
* hey, is there anything that one should be careful about when including a c library ? I pretty much finished a wrapper over a pretty big C SDK for a radar, it's my first attempt flashing it to my radar antenna, and not only i'm not getting any of the defmt prints after i run `probe-rs run`, but when running `... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HLdAghUueKyhXNSjTmCfGkFv>)
mameluc[m] has joined #rust-embedded
<mameluc[m]>
I want to stop a timer when a comparator triggers on a stm32 chip. I have done this before with other vendors but does anybody know if this is generally possible with stm chips?
<mameluc[m]>
I could do this via an interrupt but doing it in hw would yield more accurate results
<FreeKill[m]>
Yes, in general it is possible
<FreeKill[m]>
You will need a comparator that is hooked up internally to a timer. If it is, you can set the timer to stop when the comparator triggers
<FreeKill[m]>
Obviously that will mean you are restricted to appropriate comp/tim pairs, but this is a pretty common thing to want to do so most chips will likely be configurable that way
<mameluc[m]>
great! now just to find the right terminology. Seems like what I need is in TIM1_AFx
<FreeKill[m]>
I think you actually want TIM1_ICx
<mameluc[m]>
seems like this stm32wl has no ICx but I am sure I will find something suitable
<FreeKill[m]>
Yeah it looks different in that device - but the comparator text still says it's possible 😁
pflanze has quit [Remote host closed the connection]