<re_irc>
<@contradict:matrix.org> Is there a way to use embedded_time to compute a count from a rate and a duration? Something like `let count: u32 = Hertz(800_000) * Microseconds(60)` that produces count == 48?
dcz_ has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> You don't need to do all this stuff to ensure that your `board` struct is unique, `cortex-m::Peripherals::take`, and whatever `take` method from your HAL/PAC already does that for you.
<re_irc>
<@grantm11235:matrix.org> Just do `let core_peripherals = cortex-m::Peripherals::take()?` in your `Board::take` method
<re_irc>
<@luojia65:matrix.org> Hello, I published first version of crate `sifive-core`! This crate is a low level access to SiFive RISC-V processor cores with platform specific instructions, registers and other features. :) Star the repo at https://github.com/luojia65/sifive-core/ if you'd like to, and the documents are at https://docs.rs/sifive-core/
troth has quit [Ping timeout: 256 seconds]
troth has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Awesome
<re_irc>
<@firefrommoonlight:matrix.org> I think it's too easy to get stuck in the Cortex-M mentality currently with Rust
troth has quit [Ping timeout: 268 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> I don't want to be a "Cortex-M" programmer! Looking forward to trying that RISC
<re_irc>
<@huntc:matrix.org> ryan-summers:matrix.org: I've not had a great deal of luck being able to determine stack sizes either. Did you manage to find something?
troth has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> No, I never dug too deeply. Was able to figure out that recursion depth was only like 3-5, so it wasn't too bad on the stack
<re_irc>
<@01luiss:matrix.org> Hi, I have copied a working rust project to a different folder, and on the new folder I'm getting:
<re_irc>
<@k900:0upti.me> I've been doing it in normal Rust cause I have no hardware
<re_irc>
<@k900:0upti.me> Well, I have a Raspberry Pi, but that's taken over by being a sensor hub
<re_irc>
<@k900:0upti.me> And a Prometheus node
<re_irc>
<@k900:0upti.me> And a pile of other random unrelated shit
<re_irc>
<@k900:0upti.me> That makes me not want to mess with it much
<re_irc>
<@henrik_alser:matrix.org> Haha i see!
<re_irc>
<@k900:0upti.me> And the only other board I have on hand is an Intel Edison and honestly fuck that thing
<re_irc>
<@henrik_alser:matrix.org> I just made a little desktop app that can stream the input data cobs encoded over usb serial in chunks
Kumar has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> K900: Would you mind toning down the language a bit?
<re_irc>
<@k900:0upti.me> Noted, will do
troth has quit [Ping timeout: 268 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 268 seconds]
Kumar has quit [Quit: Client closed]
troth has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> Are you fucking serious?
<re_irc>
<@firefrommoonlight:matrix.org> Is there a rule against naughty language?
<re_irc>
<@ryan-summers:matrix.org> Judging by the banner, it's the rust-lang code of conduct. However, it seems like it explicitly does allow swearing
<re_irc>
<@ryan-summers:matrix.org> (As long as it's not directed at another user)
<re_irc>
<@firefrommoonlight:matrix.org> Thanks
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@zentux:zwergenfreun.de> Im currently on a stm32l4a6.. and I'm trying to make SPI work, however, a simple example (https://gist.github.com/LordSentox/30ef0a1887c8753bce806cbf27c5ea15) does not work for me, since the read operation blocks indefinitely. Looking into the setup code in the hal it seems like it's set up correctly, but the sr.rxne bit is apparently never set. I also tried to send multiple bytes, even to the point where..
<re_irc>
... SPI send gave me the error "would block". Any ideas?
<re_irc>
<@firefrommoonlight:matrix.org> Have you checked using a logic analyzer?
<re_irc>
<@zentux:zwergenfreun.de> Don't have one here atm. Tomorrow I can check with an oscilloscope, until then I'm pretty much blind.
<re_irc>
<@firefrommoonlight:matrix.org> Have you checked what SPI speed it's setting, and if that's within the range accepted by the device? 100kHz seems low, and the SPI periph operates in discrete scalers off an APB clock
<re_irc>
<@firefrommoonlight:matrix.org> (A scope would also answer this)
<re_irc>
<@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: Everything is easier with one :D
<re_irc>
<@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: I'll check that out
<re_irc>
<@firefrommoonlight:matrix.org> For some context re clocking, the APB used by SPI on L4 is often 80Mhz. It can be divided in powers of 2 between 2, and 256. So, the lowest it can go is 312.5k. I've no idea what the API from your code is doing in that case, since it *can't* be 100kHz unless you adjust your periph clock scaler
<re_irc>
<@firefrommoonlight:matrix.org> *It looks like you're running 20Mhz periph clocks. So, you could get an SPI clock of 156kHz, or 78kHz. Check which it is, and if that's OK from the datasheet
<re_irc>
<@firefrommoonlight:matrix.org> Also, I don't notice any CS going on. Most SPI devices need that
<re_irc>
<@firefrommoonlight:matrix.org> Although if it's only 1, some can work with it tied low
<re_irc>
<@zentux:zwergenfreun.de> Tried it out with numbers that should™ be okay. (2.5 MHz for instance). Still nothing.
<re_irc>
<@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: In the original code I'm using it, but since it didn't make a difference in blocking I omitted it in the gist
<re_irc>
<@firefrommoonlight:matrix.org> Is the SPI mode you have set one the device can use?
<re_irc>
<@zentux:zwergenfreun.de> Tried to configure it using the stm32cubemx without problems, although I have not actually run it. (Not with the frequency though)
<re_irc>
<@firefrommoonlight:matrix.org> *I mean, that the slave device can use. Polarity and transition
<re_irc>
<@zentux:zwergenfreun.de> Ah, I was pretty confused about the question. Yeah, it's the right mode
<re_irc>
<@zentux:zwergenfreun.de> But even when there's nothing selected shouldn't it just say that it has received some data and still set the bit after the "transaction"?
<re_irc>
<@firefrommoonlight:matrix.org> Not sure - maybe someone else around later will know the answer. Gotta run! I bet you'll have this solved by tomorrow once you use the scope
<re_irc>
<@zentux:zwergenfreun.de> Sure, thanks for your help.
<re_irc>
<@mehmet:grusbv.com> firefrommoonlight:matrix.org: I have had a case where releasing CS was required by the peripheral.
<re_irc>
<@mehmet:grusbv.com> In cases I pulled CS down and released it after multiple commands, I wasn't able to get the peripheral working.
<re_irc>
<@mehmet:grusbv.com> I have a question regarding the `cortex-m-rt`.
<re_irc>
<@jamesmunns:beeper.com> Formatting is a little messy, but I think that "enable_interrupt" call does "step two" -> enabling the event/interrupt generation in the peripheral.
<re_irc>
<@jamesmunns:beeper.com> e.g. you're telling GPIOTE to GENERATE the interrupt, and you're telling the NVIC to cause that interrupt to actually fire
<re_irc>
<@jamesmunns:beeper.com> So: defining the handler is you making the GPIOTE function, enabling it in the periph is the GPIOTE enable_interrupt call, and the unmask function is enabling it in the nvic
<re_irc>
<@mehmet:grusbv.com> Although I wrestled a git with the formatting, I think they match.
<re_irc>
<@jamesmunns:beeper.com> I wouldn't suggest mixing bullet point lists with code blocks :D
<re_irc>
<@mehmet:grusbv.com> Learned it the hard way (:
<re_irc>
<@jamesmunns:beeper.com> 1 is actually your function like this:
<re_irc>
<@hargonix:matrix.org> Ah yes that's what you get when you abstract over embedded_hal traits
<re_irc>
<@mehmet:grusbv.com> Where I cannot find `PinError` defined explicitly.
<re_irc>
<@k900:0upti.me> mehmet:grusbv.com: It's a generic parameter
<re_irc>
<@hargonix:matrix.org> becuase it isnt, its a generic argument.
<re_irc>
<@hargonix:matrix.org> In embedded_hal error types are attached to the trait as associated types and the syntax you are seeing above basically maps the Error type of OutputPin onto the name "PinError" so you can use it below
<re_irc>
<@fragadaleta:matrix.org> K900: can you also advice a supported board for cortex family? As I would like to focus on the actual embedded app, I'd also love to have less headaches with setup.
<re_irc>
<@fragadaleta:matrix.org> Needless to say, for Rust toolchain
<re_irc>
<@k900:0upti.me> STM32DISCOVERY is probably the easiest
<re_irc>
<@k900:0upti.me> A bunch of people are running blue pills/black pills
<re_irc>
<@k900:0upti.me> But those are kind of all over the place quality wise these days
<re_irc>
<@fragadaleta:matrix.org> K900: yeah i saw that. I was looking for something with more sensors and that i can expand with a camera & co.
<re_irc>
<@k900:0upti.me> Fun for hacking, less fun if it catches fire in prod
<re_irc>
<@mehmet:grusbv.com> hargonix:matrix.org: I see. When I dig that, I end up in
<re_irc>
<@k900:0upti.me> Camera is out of scope for any embedded ARM stuff generally
<re_irc>
<@hargonix:matrix.org> right where you are supposed to end up yes
<re_irc>
<@k900:0upti.me> Too much processing involved
<re_irc>
<@k900:0upti.me> Unless you get a separate ISP
<re_irc>
<@k900:0upti.me> Sensors are generally something you'd wire up to the board externally, not have integrated
<re_irc>
<@fragadaleta:matrix.org> no i mean a board i can plug other sensors to
<re_irc>
<@k900:0upti.me> Over like I2C or something
<re_irc>
<@k900:0upti.me> Yeah that's what I meant
<re_irc>
<@fragadaleta:matrix.org> indeed i don't mean integrated but a board that allows me to wire later
<re_irc>
<@mehmet:grusbv.com> hargonix:matrix.org: But I cannot go till the definition of that.
<re_irc>
<@k900:0upti.me> Even if you plug in a camera into an STM32 board somehow, it won't be fast enough to process the data for the camera
<re_irc>
<@hargonix:matrix.org> you are already at the definition
<re_irc>
<@k900:0upti.me> mehmet:grusbv.com: There is no definition, it's generic
<re_irc>
<@hargonix:matrix.org> your package is abstracting over the embedded hal trait, it is supposed to be generic accross all chips that implements embeddeed hal so you are not supposed to find a concrete definition
<re_irc>
<@fragadaleta:matrix.org> yeah stm32 is probably too tiny
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: Realistically if you need anything involving real time video, you probably want like an RPi or some other Linux board
<re_irc>
<@k900:0upti.me> 32-bit ARM® Cortex™-M4 CPU running at 64 MHz
<re_irc>
<@k900:0upti.me> Nah
<re_irc>
<@k900:0upti.me> That camera module Mehmet Ali linked has an M7 running 480 MHz
<re_irc>
<@k900:0upti.me> And it's still limited to 640x48060 grayscale
<re_irc>
<@k900:0upti.me> Which is _not a lot_, generally
rardiol has joined #rust-embedded
<re_irc>
<@mehmet:grusbv.com> hargonix:matrix.org: The reason that I am on this is that I would like to put my device instance into the Resources struct of RTIC.
<re_irc>
<@mehmet:grusbv.com> Well, if I were to do camera stuff, I would look at NXP imx8, there we are talking in another level.
<re_irc>
<@hargonix:matrix.org> since you are probably running on a specific chip you'd have to get the error type that the chip placed into its trait implementation of OutputPin and put it there then
<re_irc>
<@mehmet:grusbv.com> Maybe iMX RT series, they have super high clock speeds but leaner cores.
<re_irc>
<@firefrommoonlight:matrix.org> Make a dummy Error type
<re_irc>
<@firefrommoonlight:matrix.org> Like an empty struct
<re_irc>
<@hargonix:matrix.org> just `()`
<re_irc>
<@firefrommoonlight:matrix.org> *Actually yeah, nvm. You can't store the trait statically. Use the actual type
<re_irc>
<@hargonix:matrix.org> it will be somewhere in the GPIO implementation of your specific HAL....i would imagine if you just put a random type here and attempt to stick the stuff from your HAL into it the compiler will tell you what the type is even
rardiol_ has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> I used that trick in the past. Ie replace the trait with `i8` or something. Ideally, the HAL docs or examples will make this explicit
<re_irc>
<@mehmet:grusbv.com> error[E0277]: the size for values of type `(dyn nrf52840_hal::prelude::OutputPin<Error = DummyError> + 'static)` cannot be known at compilation time
<re_irc>
<@fragadaleta:matrix.org> but once you have it trained i can't appreciate differences
<re_irc>
<@fragadaleta:matrix.org> Mehmet Ali: what board are you experimenting? and what do you suggest me i would start with?
<re_irc>
<@mehmet:grusbv.com> mehmet:grusbv.com: I am wondering whether adding the trait Sized would help.
<re_irc>
<@mehmet:grusbv.com> fragadaleta:matrix.org: Well, for a rather large model we used Espressif.
<re_irc>
<@mehmet:grusbv.com> And I believe they have a modest Rust support too? But we used C there.
<re_irc>
<@mehmet:grusbv.com> The data was not a video data though.
<re_irc>
<@fragadaleta:matrix.org> gotcha yeah it's too long i don't touch C... i'd stay on a rust supported board as much as i can
<re_irc>
<@mehmet:grusbv.com> The issue is that TFLite has a native C API for micro.
<re_irc>
<@fragadaleta:matrix.org> true and libtorch too (C++)
<re_irc>
<@fragadaleta:matrix.org> or maybe for the time being i could play with my rpi3 ? 😛
<re_irc>
<@k900:0upti.me> That is probably a good option
<re_irc>
<@k900:0upti.me> You can do all the embedded_hal stuff on it
<re_irc>
<@fragadaleta:matrix.org> yeah
<re_irc>
<@fragadaleta:matrix.org> and i can connect a camera module too
<re_irc>
<@therealprof:matrix.org> l0uisc:matrix.org: Yes. The ability to properly do properly do compile time assertions and panics without weird tricks is huge.
<re_irc>
<@therealprof:matrix.org> Don't underestimate a MCU core running at multiple hundred MHz, the first laptops with a built-in webcam had far less punch than such a MCU.
<re_irc>
<@therealprof:matrix.org> IIRC it was a ThinkPad with a 100MHz PowerPC CPU (or so).
<re_irc>
<@firefrommoonlight:matrix.org> Even on 480Mhz Cortex M7, it's easy to run out of computational power for realtime audio if you're running too many FIR taps!
<re_irc>
<@sourcebox:matrix.org> What I ideally want to have is a bare-metal Cortex-A with at least 2 cores and NEON engine. Yes, the RPi would be a candidate, but there are also reasons not to use one.
<re_irc>
<@firefrommoonlight:matrix.org> I was wondering what those noble gas notes were in the CMSIS-DSP docs;
<re_irc>
<@sourcebox:matrix.org> Some time ago I put some effort in getting an STM32MP1 running from scratch, but this project is pending. Nevertheless this chip would be a good choice for some projects.
<re_irc>
<@sourcebox:matrix.org> Unfortunatly, ST has no interest in bare metal support for it but just supports Linux. Overall I think this is a marketing mistake.
<re_irc>
<@therealprof:matrix.org> The MP1 is a very odd system. Neither meat nor fish. Outstandingly slow CPU core with little useful peripherals connected to a Cortex-M4 in a really weird way.
<re_irc>
<@sourcebox:matrix.org> therealprof:matrix.org: I disagree on that.
<re_irc>
<@therealprof:matrix.org> Which part? The slow CPU cores? The weird connection to the M4? The lack of useful peripherals?
<re_irc>
<@sourcebox:matrix.org> Why is dual core 800MHz NEON slow?
rardiol_ has quit [Ping timeout: 252 seconds]
<re_irc>
<@therealprof:matrix.org> Cortex-A7 is pretty much the very lowend when it comes to Cortex-A cores.
<re_irc>
<@sourcebox:matrix.org> That's right, but for industrial design, rules are sometimes a little bit different.
<re_irc>
<@sourcebox:matrix.org> That's also the reason why companies hesitate to use a RPi.
<re_irc>
<@therealprof:matrix.org> Okay, I bite: What does a Cortex-A7 specifically qualify for "industrial designs"?
<re_irc>
<@therealprof:matrix.org> sourcebox:matrix.org: I'm not suggesting you throw any consumer graade hardware into any system.
<re_irc>
<@sourcebox:matrix.org> Industrial design is a real conservative thing. You have to ensure reliability, long-term availibility and such things.
<re_irc>
<@therealprof:matrix.org> I am aware.
<re_irc>
<@sourcebox:matrix.org> Also, the MP1 is one of the few chips that has a reference design by ST for making own PCBs. In most cases, you have to rely on a third-party that produces a SOM.
<re_irc>
<@therealprof:matrix.org> I am very certain you can get reference designs from any manufacturer...
<re_irc>
<@therealprof:matrix.org> I know for sure that you can get reference designs from Broadcom, Qualcom and Intel.
<re_irc>
<@sourcebox:matrix.org> You can, question is more if you have the knowledge to produce them.
<re_irc>
<@therealprof:matrix.org> If you want to design your own "industrial grade" hardware you better have the knowledge. If you don't the chances to fail don't differ that much between chip vendors.
<re_irc>
<@therealprof:matrix.org> The only novel thing about the STM32MP1 is that they're basically making everything public whereas other chip vendors are a lot more secretive.
<re_irc>
<@sourcebox:matrix.org> This is also an important aspect.
<re_irc>
<@therealprof:matrix.org> From where I'm standing that is really the only aspect.
<re_irc>
<@therealprof:matrix.org> And the parts they have made public are also not that great.
<re_irc>
<@sourcebox:matrix.org> There's a lot missing that you need to know when not relying on their premade images. This is what I also critisize.
<re_irc>
<@therealprof:matrix.org> (Spoiler alert, I had early access to a MP1 dev kit back when I had more time and I gave up after one week for a number of reasons including CPU slowness, quirky and incomplete SDK and instructions, missing documentation and uninspiring combination of MCU/CPU)
<re_irc>
<@sourcebox:matrix.org> I also have the DK1.
<re_irc>
<@therealprof:matrix.org> I still have the devkit and despite multiple offerings to donate it to someone with interest and time to do something exciting with it, noone wanted to have it. 😉
<re_irc>
<@sourcebox:matrix.org> I assume they way I want to use it is a little bit different from what most people want to do.