GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #rust-embedded
vadimcn[m] has joined #rust-embedded
<vadimcn[m]>
Hi! Are there any common patterns for handling errors in no-std embedded environment while writing code that uses embedded-hal trait abstractions?
<vadimcn[m]>
As a concrete example, let's say I am writing a function that uses both digital pins and an SPI bus. Each of these traits has its own associated error type, so what error type can my function use to unify them?
<JamesMunns[m]>
it's pretty common to use an enum for this
<JamesMunns[m]>
Then impl From for both types so you can use it with ?.
AaronTsui[m] has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has quit [Ping timeout: 272 seconds]
<GrantM11235[m]>
<JamesMunns[m]> "Then impl From for both..." <- That doesn't work, you need to convert the errors manually with `map_err`
<GrantM11235[m]>
The reason it doesn't work is because it is possible for SpiErr and DigitalErr to be the same type, for example `MyError<(), ()>`. That would mean there are two conflicting `From` impls, which rust doesn't allow
<JamesMunns[m]>
if you are willing to specify the specific error types you will use
<JamesMunns[m]>
Might just be better to remove the generics, actually. That would be just as fine for an application
<vadimcn[m]>
James Munns: but I don't know the concrete types of the peripherals, I have them only as generic parameters of my driver struct. The only way to instantiate the enum type I can think of is as an associated type on the impl of my driver struct. However those are unstable... Or is there some other way?
<JamesMunns[m]>
Sorry, is this for an application, or a library?
<JamesMunns[m]>
If it's for a library, then I'd agree with GrantM11235, I did forget about the blanket impl issues. For an app it might be possibly to specify the type.
<JamesMunns[m]>
s/possibly/possible/
crabbedhaloablut has joined #rust-embedded
<vadimcn[m]>
A library
GenTooMan has joined #rust-embedded
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
Guest7221 has joined #rust-embedded
vrakaslabs[m] has joined #rust-embedded
<vrakaslabs[m]>
<mciantyre[m]> "The example on the `broken..." <- Thanks for taking a look @mciantyre.
<vrakaslabs[m]>
That would do it. I guess I shouldn’t assume Rust disarms all footguns! I’m surprised this sort of thing isn’t checked, but I guess checking at runtime would either require the hardware MPU, or slow down execution. Isn’t it possible to detect this sort of thing by worst-case static analysis (assuming no recursion)? Are there other tools in the ecosystem that handle that sort of thing? I’ve done SP high-water-mark
<vrakaslabs[m]>
tracking before, just curious.
<vrakaslabs[m]>
I think I’ve got some refactoring to do (looks like I should call it a “Device” not a “Phy”), and I’d like to try to get PTP timestamps working. But I appreciate having eyes on it.
<vrakaslabs[m]>
s///, s///
<vrakaslabs[m]>
s///, s///
<vrakaslabs[m]>
vrakaslabs[m]: Also, while I’ve got you, is there a single-stepping debug solution that works with the Teensy? I’m missing my JTAG. If not I’ll probably spin a PCB with an ethernet PHY wired up.
corecode has joined #rust-embedded
notgull has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
notgull has joined #rust-embedded
Kaspar[m] has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has joined #rust-embedded
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
ni has quit [Ping timeout: 252 seconds]
JamesZow[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has left #rust-embedded [Error from remote client]
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
ni has joined #rust-embedded
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
mciantyre[m] has quit [Quit: Idle timeout reached: 172800s]
mciantyre[m] has joined #rust-embedded
<mciantyre[m]>
<vrakaslabs[m]> "Also, while I’ve got you, is..." <- I haven't used it, but I'm aware of [cargo-call-stack](https://github.com/japaric/cargo-call-stack) and its forks.
<mciantyre[m]>
mciantyre[m]: I don't know of anything off-the-shelf that provides step debugging on the Teensy 4. As far as customization goes, I think Charles had success hacking a Teensy 4.1 and / or Micromod with JTAG. And I think it worked with probe-rs. https://github.com/probe-rs/probe-rs/pull/1174#issuecomment-1272525095
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
TomB[m] has joined #rust-embedded
<TomB[m]>
is there an cortex-a9 equivalent to the cortex-m/aarch64 crate?
<TomB[m]>
I thought there was a cortex-a crate at one point
<TomB[m]>
was trying to build the simplest elf possible to run on a zynq for a little homebrew synth with vhdl logic I've been cooking forever and day...
<TomB[m]>
I know there's zynq-rs but its all gpl'ed and what not, so I don't even want to look at it
<thejpster[m]>
I certainly would not want to try and ship complete and corresponding object code for my Rust application such that one LGPL crate can be replaced.
<thejpster[m]>
You may have some luck acquiring a non-GPL commercial licence to the crate if that's what you need.
<ryan-summers[m]>
Yeah if you need it I can get you in touch with M-labs :)
<ryan-summers[m]>
* M-labs :) Tom B
<ryan-summers[m]>
I don't know if they offer it or not, but I can forward you to Sebastien
cr1901_ is now known as cr1901
<thejpster[m]>
I have a minimal ARMv8-A Aarch64 example for Ferrocene. Working out if I can share that now we did our launch.
<thejpster[m]>
I expect an ARMv7-A or ARMv8-A Aarch32 example to be fairly similar, but the registers have different names. Basically you need some asm to set the stack pointer and turn on the FPU.
<thejpster[m]>
Can't help with the FPGA side though.
<TomB[m]>
The FPGA side is a secondary thing it seems, there's some initial bootup sequence to setup clocks and power gates in the reset vector, followed by cache and mmu setup
<TomB[m]>
like on zynq anyways, the fpga fabric, as far as I can tell, comes after that at some point
<TomB[m]>
or maybe before... unclear
<TomB[m]>
learning ✌️
<ryan-summers[m]>
I did a project with the Zynq a few years back (It's an awesome chip) and I believe the firmware loads the bitstream etc.
<ryan-summers[m]>
So your assessment feels right to me
<TomB[m]>
right... like vitis maybe takes care of this for you when you dump an xsa file, but u-boot for example seemingly sets up plls, power, clocks, etc and doesn't know anything about the PL side... presumably the same with cyclone v soc
<TomB[m]>
but with a different flow and less slow-ass java tools
<TomB[m]>
I swear... vivado could make any machine feel slow
<TomB[m]>
I kind of gave up on it and started doing all my logic testing with ghdl, so much damn faster
<TomB[m]>
* my logic development and testing with, * with ghdl and emacs, so
<ryan-summers[m]>
To be honest, Vivado HDL is actually pretty cool. But yes, very slow
<ryan-summers[m]>
It's nice for the uninitiated to be able to do block-based design at a high level without having to care about all the HDL jargon
<TomB[m]>
yeah the tool is cool, love the block diagramming abilities and such, but my goodness
<TomB[m]>
right
<TomB[m]>
"lemme just drop this axi peripheral, and oh look at that, its all wired up"
<ryan-summers[m]>
Yeah, Oh I need to cross a clock domain? Don't mind using this clock domain crosser you gave me!
<ryan-summers[m]>
The integrated real-time logic analyzer is also so incredibly useful
<TomB[m]>
it only took 100gb of storage and 10 min to build a bitstream after you drop the block in, but I'll be damned if that isn't a neat feature for sure
<adamgreig[m]>
cyclone v lets you just use the pl without turning on the ps at all
<adamgreig[m]>
which is really nice imo
<TomB[m]>
quartus has that as well, and it is really nice to probe
<adamgreig[m]>
and has a simple lowest-level primitive to connect them too, you can instantiate it directly if you want
<TomB[m]>
oh that is really nice
<TomB[m]>
I don't believe that's possible with zynq
<ryan-summers[m]>
Why even get an embedded FPGA+MCU if you don't want the MCU on?
<adamgreig[m]>
right, i haven't used it but i also understand the ps has to load the pl
<TomB[m]>
testing the logic
<ryan-summers[m]>
Why not just get an FPGA along at that point?
<ryan-summers[m]>
Ah okay
<adamgreig[m]>
yea, for development/because you have a dev board/whatever
<adamgreig[m]>
you can load the pl from the ps of course
<TomB[m]>
like I have an artix-7 board because of the hassles of programming the zynq
<adamgreig[m]>
but it sure is quicker and easier to test by just jtag loading the pl the latest logic from your dev computer
<TomB[m]>
that's how annoyed i was, I spent $200 more to avoid the hassles
<adamgreig[m]>
and seems so needless to not support it
<TomB[m]>
not to mention quartus is so much faster...
<TomB[m]>
vivado... still routing, quartus already in the logic analyzer showing whats happening
<TomB[m]>
java is always a mistake for these things I feel like... somehow
<adamgreig[m]>
no wizards or guis or giant IP blocks or whatever
<adamgreig[m]>
that gist is the entire full project for putting some logic into the pl that controls the dev board switches/LEDs and interacting with it via the axi3 memory bus from the c code on the ps
<adamgreig[m]>
so i quite liked that over what i've seen of the zync stuff
<TomB[m]>
you are strongly making me reconsider the zynq usage
<TomB[m]>
though the pricing of cyclone v socs is higher I believe, and harder to get?
<adamgreig[m]>
sadly zync is extremely popular and cyclonev-soc is not
<adamgreig[m]>
people just put up with towering stacks of annoying software
<adamgreig[m]>
i think quartus is nicer than vivado too 💀
<TomB[m]>
maybe agilex 3 parts will start moving things back in the right direction
<adamgreig[m]>
but these days i almost exclusively use ecp5 with yosys/nextpnr and any mcu is either a soft core or an external thing, soooo
<TomB[m]>
and Intel spinning of PSG into its own self directed entity again
<adamgreig[m]>
yes i am vaguely optimistic for agilex3 or subsequent generation plus altera going independent again
<adamgreig[m]>
maybe a slight new focus on the low/midrange... maybe......
<TomB[m]>
yeah would be nice, seems like the low/midrange has lagged for sure, they kept pumping out monsterous agilex parts
<TomB[m]>
"oo 1m+ luts"
<TomB[m]>
I don't need 1m luts, I need like 25k
<adamgreig[m]>
everyone's still using parts from like 2010
<TomB[m]>
xilinx too, lattice seems to be the only one producing smallish new parts
<TomB[m]>
I haven't looked too hard, but I guess they are pretty power efficient as well?
<TomB[m]>
would be neat if they made one with a riscv core or two...
<adamgreig[m]>
7 series, cyclone iv, i think ecp5 was around then too
<adamgreig[m]>
the new lattice parts are ok but real focus on video processing
<TomB[m]>
I guess that's where the $ is
<adamgreig[m]>
maybe gowin and the like will eat that market
<TomB[m]>
video -> fpga -> cpu kind of flows
<TomB[m]>
I kind of get it, I haven't done any video with an fpga myself, still very much learning :-) but I get it
<TomB[m]>
last time I did any real video work it was using a gpu
<ryan-summers[m]>
Used it to do fast rate sampling on hydrophones to localize in a pool and move towards a pinger
<TomB[m]>
neat!
<TomB[m]>
adamgreig[m]: maybe, i kind of wonder if other prc semis will eat at stuff like nordic and st's bread and butter as well...
<TomB[m]>
though the docs/sdks suck
<TomB[m]>
so maybe not
<adamgreig[m]>
they don't have to suck, look at espressif
<TomB[m]>
like that ox64 board from pine is wildly inexpensive for what it is
<TomB[m]>
linux capable device with all the wireless for $8
<TomB[m]>
so you just know the part is like $1 at quantity presumably
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
<Jonas[m]1>
<TomB[m]> "maybe, i kind of wonder if other..." <- isn't the edge for nordic that they are good on low power and well documented bluetooth? In other cases, alternatives are probably cheaper? (I am new to this, but that is my picture so far)
<dirbaio[m]>
espressif is eating a lot of nordic's lunch in wifi/bluetooth iot
<dirbaio[m]>
they're still nowhere near as good for low-powered tho
<dirbaio[m]>
s/powered/power/
wassasin[m] has joined #rust-embedded
<wassasin[m]>
Mainly due to cost: esp32 is ridiculously cheap and NRF is very expensive. The positioning of the NRF700x Wifi family of chips is not great
<wassasin[m]>
Positioned for high throughput 5GHz, whilst most IoT applications require only SSID scanning or low throughput, easy to use
<dirbaio[m]>
there's the nrf7001 which is 2.4ghz only. still mega expensive though lol
<dirbaio[m]>
if you need just bluetooth, nrf52 is a good price
<dirbaio[m]>
but if you do need wifi, esp32 crushes nrf52+nrf70x
<wassasin[m]>
You also have the nrf7000 which does only SSID scanning
<wassasin[m]>
But it is still a few euro's
<wassasin[m]>
Insanity
<dirbaio[m]>
I wonder if they have a single-chip MCU+BLE+WiFi in the roadmap
<wassasin[m]>
Without a doubt
<dirbaio[m]>
they'd have to price it very aggressively tho
<wassasin[m]>
nrf700x is ofcourse the same silicon but features ripped out in firmware
<firefrommoonligh>
<ryan-summers[m]> "By the way, if anyone is..." <- V cool. I'm actually interesting in integrating a hydrophone as payload for a project I'm working on
<firefrommoonligh>
But have to get the platform in a more polished state
<firefrommoonligh>
Working the power-management/solar charging ATM
<firefrommoonligh>
Haven't done any research on the hydrophones themselves. Not sure if I'd use a codec and convert to digital audio or what. Back of the envelope calcs should you should be able to send that on a FD CAN bus along with lower-bandwidth signals without saturating the bus, but we'll see, and depends on the specifics like bit depth and frequency range
<firefrommoonligh>
Sounds like what you're working on would be how to process that data once you have it in digital form
<ryan-summers[m]>
That was an old project, but was both acquisition and processing. Was relatively high sample Rates (5MHz or so simultaneous on 4 channels)
<TomB[m]>
<wassasin[m]> "Without a doubt" <- I've been thinking that since nrf52 came out, and what was that now... like 4-5 years ago at this point?
<JamesMunns[m]>
<TomB[m]> "I've been thinking that since..." <- Looks like 2017 (close to 6 years). That's actually more recent than I thought!
<JamesMunns[m]>
> <@halfbit:matrix.org> I've been thinking that since nrf52 came out, and what was that now... like 4-5 years ago at this point?
<JamesMunns[m]>
* Looks like early 2018 (close to 6 years). That's actually more recent than I thought!
<firefrommoonligh>
<ryan-summers[m]> "That was an old project, but was..." <- Ok not passing that through CAN lol
<dirbaio[m]>
JamesMunns[m]: it's a bit earlier. nrf52832 is from 2016
<dirbaio[m]>
nrf52840 is from 2018. I remember at work we started using it when it was very new,the DKs were a bit hard to get because everyone wanted them.
<TomB[m]>
yeah time seems to be going much much faster for me these days... feels like it should be 4-5 years ago, but clearly not haha
<dirbaio[m]>
brain's reference clock gets slower as we age 🥲
<TomB[m]>
dirbaio[m]: a fun way of putting it, and certainly seems to be true
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
ilpalazzo-ojiis4 has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has left #rust-embedded [Error from remote client]
crabbedhaloablut has quit []
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]