<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> <@grantm11235:matrix.org> I made a PR to impl the I2C traits for `&RefCell`s: https://github.com/rust-embedded/embedded-hal/pull/330
<re_irc> <@firefrommoonlight:matrix.org> Owning buses still doesn't make sense to me
<re_irc> <@firefrommoonlight:matrix.org> They're used by multiple devices by definition!
dcz_ has quit [Ping timeout: 252 seconds]
tokomak has joined #rust-embedded
troth has quit [Ping timeout: 252 seconds]
troth has joined #rust-embedded
<re_irc> <@sajattack:matrix.org> https://github.com/rust-lang/rust/issues/91442
troth has quit [Ping timeout: 268 seconds]
troth has joined #rust-embedded
PyroPeter has quit [Ping timeout: 252 seconds]
PyroPeter has joined #rust-embedded
<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> <@01luiss:matrix.org> ``
<re_irc> <@01luiss:matrix.org> error: linking with rust-lld failed: exit status: 1
<re_irc> <@01luiss:matrix.org> = note: rust-lld: error: memory.x:3: region 'FLASH' already defined
dcz_ has joined #rust-embedded
<re_irc> <@01luiss:matrix.org> So.. I'm not sure what was going on. I just copied the folder again and it works now.
<re_irc> <@henrik_alser:matrix.org> Any advent of embedded coders out there?
<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> <@mehmet:grusbv.com> Here I am trying to 'attach' to the interrupt, but I am missing something.
<re_irc> <@mehmet:grusbv.com> ```rustz
<re_irc> <@jamesmunns:beeper.com> Mehmet Ali if you aren't using RTIC, you need to enable the interrupt in the NVIC too
<re_irc> <@mehmet:grusbv.com> Ah perfect
<re_irc> <@mehmet:grusbv.com> Let me look at that.
<re_irc> <@jamesmunns:beeper.com> Yeah, the three step process is:
<re_irc> <@jamesmunns:beeper.com> * Define a handler
<re_irc> <@jamesmunns:beeper.com> * Enable the event generation in the peripheral
<re_irc> <@jamesmunns:beeper.com> * Enable the interrupt in the NVIC
<re_irc> <@jamesmunns:beeper.com> the last step is done for you automatically in RTIC
<re_irc> <@hargonix:matrix.org> therealprof const panic has landed \o/
troth has quit [Ping timeout: 252 seconds]
<re_irc> <@mehmet:grusbv.com> jamesmunns:beeper.com: Does this include a CLK configuration step within?
<re_irc> <@mehmet:grusbv.com> I mapped those as:
<re_irc> <@mehmet:grusbv.com> .channel0()
<re_irc> <@mehmet:grusbv.com> * ``` gpiote
<re_irc> <@mehmet:grusbv.com> * ```let gpiote = Gpiote::new( p.GPIOTE)```
<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> <@jamesmunns:beeper.com> #[interrupt]
<re_irc> <@jamesmunns:beeper.com> ```rust
<re_irc> <@jamesmunns:beeper.com> fn GPIOTE() { ... }
<re_irc> <@jamesmunns:beeper.com> that declares a handler, that gets put into the vector table
<re_irc> <@jamesmunns:beeper.com> This just creates a HAL handle to the peripheral, which is convenient, but not strictly required.
<re_irc> <@jamesmunns:beeper.com> let gpiote = Gpiote::new( p.GPIOTE);
troth has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> Oh, and Mehmet Ali, don't forget to clear the event in your function here: https://github.com/Grus-BV/iis3dwb-rs/blob/1f812a4402709444e5f5bb99ec6f7397d9ce5cb3/examples/nrf52dk-irqs.rs#L36-L39, or the interrupt will retrigger forever!
<re_irc> <@mehmet:grusbv.com> Argh, right!
loki_val has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.0]
starblue has joined #rust-embedded
hifi has quit [Changing host]
hifi has joined #rust-embedded
<re_irc> <@therealprof:matrix.org> hargonix:matrix.org: Seems someone is as excited as I am. 😀
rardiol has joined #rust-embedded
<re_irc> <@l0uisc:matrix.org> therealprof:matrix.org: First time I heard about const panic, but after reading what it is, it could be really useful.
<re_irc> <@fragadaleta:matrix.org> between freeRTOS and tockOS what do you folks advice as a starter?
dcz_ has quit [Ping timeout: 252 seconds]
<re_irc> <@fragadaleta:matrix.org> architecture of reference arm cortex m4 m7
rardiol has quit [Read error: Connection reset by peer]
<re_irc> <@mehmet:grusbv.com> Is there a good introduction for Error types in embedded Rust, about how they are implemented?
<re_irc> <@hargonix:matrix.org> They are usually just plain enums
<re_irc> <@k900:0upti.me> fragadaleta:matrix.org: Why not RTIC?
<re_irc> <@k900:0upti.me> It seems to be the most mature
<re_irc> <@fragadaleta:matrix.org> oh wow i missed that.
<re_irc> <@fragadaleta:matrix.org> Thanks.
<re_irc> <@mehmet:grusbv.com> hargonix:matrix.org: I see this pattern a lot.
<re_irc> <@mehmet:grusbv.com> impl<SPI, CS, E, PinError> Adxl355<SPI, CS>
<re_irc> <@mehmet:grusbv.com> where
<re_irc> <@mehmet:grusbv.com> ```rust
<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> <@mehmet:grusbv.com> ```rust
<re_irc> <@mehmet:grusbv.com> /// Single digital push-pull output pin
<re_irc> <@mehmet:grusbv.com> pub trait OutputPin {
<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> <@fragadaleta:matrix.org> maybe arduiino?
<re_irc> <@k900:0upti.me> And if you need anything involving _hard_ real time video, you're getting into heavy industry stuff
<re_irc> <@mehmet:grusbv.com> fragadaleta:matrix.org: I have seen some high end STM32s run OpenMV with a camera
<re_irc> <@k900:0upti.me> Arduinos are ATmega
<re_irc> <@k900:0upti.me> Even slower
<re_irc> <@k900:0upti.me> The ones that aren't ATmega are tiny M0 cores so also slow
<re_irc> <@mehmet:grusbv.com> mehmet:grusbv.com: https://openmv.io/products/openmv-cam-h7
<re_irc> <@mehmet:grusbv.com> But most STMs were unobtainium anyway.
<re_irc> <@fragadaleta:matrix.org> arduino nano 33 ble?
<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> ```rust
<re_irc> <@mehmet:grusbv.com> const APP: () = {
<re_irc> <@mehmet:grusbv.com> struct Resources {
<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
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rardiol_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rardiol has joined #rust-embedded
<re_irc> <@mehmet:grusbv.com> Most Errors are defined of type
<re_irc> <@mehmet:grusbv.com> use void::Void;
rardiol has quit [Client Quit]
<re_irc> <@fragadaleta:matrix.org> K900: there's no RTIC for risc-v arch?
rardiol_ has joined #rust-embedded
<re_irc> <@mehmet:grusbv.com> mehmet:grusbv.com: and it comes from the fact that it implements embedded_hal
<re_irc> <@mehmet:grusbv.com> and void seems to be std
<re_irc> <@k900:0upti.me> fragadaleta:matrix.org: Not sure, but also you're not getting a RISC-V board that can run a camera
<re_irc> <@fragadaleta:matrix.org> k900:0upti.me: what do you think of https://github.com/oxidecomputer/hubris
<re_irc> <@k900:0upti.me> Haven't used it, but the Oxide folks are very experienced and know their stuff
<re_irc> <@k900:0upti.me> But also, again, don't expect a camera (unless you handroll a driver)
<re_irc> <@fragadaleta:matrix.org> what do they use hubris for?
<re_irc> <@fragadaleta:matrix.org> like what are some use cases and hw for such an OS ?
<re_irc> <@k900:0upti.me> We don't really know yet, but probably a hardware trust root
<re_irc> <@mehmet:grusbv.com> fragadaleta:matrix.org: They actually announced that 3 days ago.
<re_irc> <@firefrommoonlight:matrix.org> Hubris, at a glance, looks like it's for complex programs that have potentially non-cooperative processes
<re_irc> <@mehmet:grusbv.com> But the documentation looks top notch.
<re_irc> <@fragadaleta:matrix.org> agree. doc is amazing
<re_irc> <@firefrommoonlight:matrix.org> Do y'all have any projects that seem like they would benefit from it?
<re_irc> <@firefrommoonlight:matrix.org> What is everyone working on?
<re_irc> <@firefrommoonlight:matrix.org> I have nothing complex enough at this time
<re_irc> <@fragadaleta:matrix.org> i am learning. But my purpose is controlling actuators with some tiny ML models
<re_irc> <@fragadaleta:matrix.org> and sensors
<re_irc> <@firefrommoonlight:matrix.org> Ie, the 3 main projects I have are all simple enough to work with ISRs, RTIC, DMA directly
<re_irc> <@mehmet:grusbv.com> fragadaleta:matrix.org: Good to know that. I use tensorflow lite micro a lot too.
<re_irc> <@fragadaleta:matrix.org> ah no i dont really like tf
<re_irc> <@mehmet:grusbv.com> Oh, which TinyML then?
<re_irc> <@mehmet:grusbv.com> I only knew TFLite
<re_irc> <@fragadaleta:matrix.org> i am considering torch
<re_irc> <@fragadaleta:matrix.org> and tch-rs
<re_irc> <@fragadaleta:matrix.org> bindings
<re_irc> <@mehmet:grusbv.com> I see, I should try that sometime.
<re_irc> <@mehmet:grusbv.com> Heard a lot about Torch, but stuck with TF.
<re_irc> <@fragadaleta:matrix.org> yeah i find torch to be way more flexible especially when defining the model
<re_irc> <@mehmet:grusbv.com> hargonix:matrix.org: ```
<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> <@mehmet:grusbv.com> --> examples\nrf52dk-rtic.rs:38:24
<re_irc> <@mehmet:grusbv.com> |
<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> k900:0upti.me: Not quite true. There're even MCUs which have specialised camera interfaces... https://www.st.com/resource/en/application_note/dm00373474-digital-camera-interface-dcmi-on-stm32-mcus-stmicroelectronics.pdf
<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> <@therealprof:matrix.org> Hah, found it: http://oldcomputer.info/portables/tp850/index.htm
<re_irc> <@sourcebox:matrix.org> In fact, a Cortex-M7 like i.MX RT is quite powerful. Bottleneck is mostly the limited amount of RAM.
<re_irc> <@sourcebox:matrix.org> As long as everything fits into tight coupled RAM, it outperforms a Cortex-A easily.
<re_irc> <@sourcebox:matrix.org> Of course not when using stuff like the NEON engine on Cortex-A.
<re_irc> <@mehmet:grusbv.com> sourcebox:matrix.org: Some RTs are clocked at 1GHz.
<re_irc> <@sourcebox:matrix.org> Yes, that's the upper limit these days.
<re_irc> <@mehmet:grusbv.com> Still looking for a project to justify the purchase for those.
<re_irc> <@sourcebox:matrix.org> Everything DSP related, audio/video.
<re_irc> <@sourcebox:matrix.org> I mostly work for companies that do DSP for audio. Experience is that there's never enough processing power.
<re_irc> <@sourcebox:matrix.org> AFAIK this unit uses a Cortex-M7 for the sound engine: https://polyend.com/tracker/
<re_irc> <@mehmet:grusbv.com> sourcebox:matrix.org: Beauty.
<re_irc> <@sourcebox:matrix.org> There are a lot of small to medium sized companies that use MCUs for sound generation and processing.
<re_irc> <@sourcebox:matrix.org> Interestingly, the well-known company Elektron has a job offer for Rust audio development: https://www.elektron.se/rust-audio-developer/
<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.
<re_irc> <@therealprof:matrix.org> That's certainly possible. 😀
<re_irc> <@therealprof:matrix.org> I was trying to find a use for it but couldn't.
<re_irc> <@sourcebox:matrix.org> As a Linux platform, I regard it as nearly pointless. There are much better options.
<re_irc> <@therealprof:matrix.org> As a MCU platform there're also much better choices. So what is it good for?
<re_irc> <@sourcebox:matrix.org> The combination of A7/M4 makes it interesting as a pure DSP workhorse.