<M9names[m]>
i don't think it's UB? as long as you told the linker that it lives in that exact place in RAM and you're on a von-neumann machine it should work fine.
<M9names[m]>
you do have to watch out for the compiler adding function calls to things in flash though - things like memcpy are especially hard to avoid because they're implicit.
sroemer has joined #rust-embedded
pcs38 has joined #rust-embedded
Farooq has joined #rust-embedded
<Farooq>
What is the search query for IO response times for different MCUs and Processors? Like how much time between pulling up an input pin and the time which the MCU notices this. I'm thinking about building a custom keyboard. And I wonder if it's a good idea to use a Cortex-A53 instead of an MCU.
<Farooq>
Obviously, I want to have dual function for the keyboard, also acting as a mini computer.
<Darius>
you would have to read the datasheets for the GPIO peripherals and CPU to work it out
<Darius>
but.. the GPIO side will be "a few clocks"
<Darius>
(synchroniser delays then edge detection)
<Farooq>
what parameters influence it other than the processor clock?
<Farooq>
Do GPIOs have got different clocks?
<Farooq>
s/got//
<Farooq>
The options I'm thinking about are either Raspberry Pi Pico 2 WH or Milk V Duo with SG2002
<Farooq>
Similar prices, but Milk V duo can do tons more
<Farooq>
At the cost of more software work, of course
<thejpster[m]>
If you want it interrupt driven it’s the sum of: GPIO controller interrupt latency + interrupt controller latency + time for CPU to enter interrupt handler + time for CPU to work it which interrupt happened and run the appropriate handler
<Farooq>
are these the search keywords to look in datasheet or TRM?
<thejpster[m]>
Cortex-M is very good at those last two (10’s of clock cycles). I suspect ) but have not measured) that a Cortex-A might be more like hundreds of clock cycles. But if the chip runs at 1 GHz, you can still do most things just fine.
<Farooq>
Milk V Duo has got 3 cores
<thejpster[m]>
The GPIO controller is described in the TRM. CPU interrupt latency probably isn’t - you’d need to look at your CPU reference and the architecture reference.
<Farooq>
You can have a processor which can run something like Linux, either RISC V or Cortex A53, a RISC V core running an RTOS and a 8051
<thejpster[m]>
Or just measure it. Write a handler that flips when the input flops. Send a square wave. Look at the phase shift.
<Farooq>
@thejpster:matrix.org Thanks
marmrt[m] has joined #rust-embedded
<marmrt[m]>
This is very likely to not be an issue for a keyboard
<Farooq>
@marmrt:matrix.org Even for gaming?
<Farooq>
And another thing, How Milk V Duo offers better hardware than Pico but at about the same price?
<thejpster[m]>
Most people do keyboards contain like a 2 MHz 8051 microcontroller.
<thejpster[m]>
s/people do//
<Farooq>
thejpster[m]: but not gaming keyboards I think?
<Farooq>
And about USB, is it something the hardware provides, or I should write a software for it? Or both can be possible depending on the processor?
<Farooq>
Farooq: I think they use Cortex-M. They advertise using a 32 bit ARM MCU
<thejpster[m]>
What makes a keyboard “gaming”, apart from RGB LEDs?
<Farooq>
mechanical switches which you could do keystrokes very fast and without jamming or something. And they advertise fast response times, not sure if it's marketing or real
<Farooq>
Like they advertise 3k Hz pull
<Farooq>
However I would say that number is more marketing
<Farooq>
even if it's real, network latency is far greater
<Farooq>
so having 3kHz or 800Hz wouldn't make a difference
<thejpster[m]>
I thought the USB protocol doesn’t normally let you poll faster than 1ms, or 1000 Hz. And mostly it’s set to 100 Hz.
<Farooq>
or even 100Hz
<Farooq>
thejpster[m]: then it's just marketing :)
<thejpster[m]>
And at 100 Hz the cheapest slowest microcontroller will be fine
<Farooq>
Or even Cortex-A53 :)
<Farooq>
<Farooq> "And another thing, How Milk V..." <- how about this?
<Farooq>
I mean they are not exactly the same prices. But very close
<Farooq>
And yeah, Pico consumes only a tiny fraction of the power Milk V consumes
<Farooq>
I was thinking maybe Milk V Duo is cheap because it's low quality
<Farooq>
hmm is it true that for using ARM cores in your processor, you have to pay ARM holding? And for each core you have to pay a different price?
<Farooq>
Like Having a dual Core Cortex-M0 is twice cost of a single core Cortex-M0. And prices of Cortex-A5 and Cortex-M1 are different
<Darius>
Farooq: "it depends" but any vaguely modern micro is not going to be the limiting factor in speed
<Darius>
you only have to pay ARM if you are making silicon
<Darius>
or putting it in an FPGA
<M9names[m]>
there will definitely be a price difference for the cortex-a5 and cortex-m0 IP (one of these things is significantly more complex than the other).
<M9names[m]>
but it shouldn't matter to you how much the vendor payed for the IP, that's their problem.
<Farooq>
I see. So that would explain why RPi Pico 2 has almost the same price as Milk V Duo. Milk V Duo got a much better processor and few hundred megabytes of RAM. But it has got RISC V instead of ARM
<Farooq>
M9names[m]: I am wondering why RPi Pico and Milk V Duo have got roughly the same price while Milk V Duo offering a hardware which is tons better
<boru>
I don't use matrix, but is this "file message at <obnoxiouslylong.url>" thing normal?
<boru>
Full message, rather
<boru>
Do users really open their browser to view people's IRC messages?
<Darius>
I imagine the cost has more to do with it being made in China than the IP cost
<Darius>
boru: it is a tedious side effect of the impedance mismatch between IRC and Matrix..
<M9names[m]>
yep. don't want to spam the matrix side with tons of little messages, but then IRC users suffer.
<boru>
Is it really that much? I mean, it's just text.
<Darius>
I wonder what the debug experience is like on the RISCV stuff.. having done some code on the Rp2350 I am quite impressed by how well the debugging works
<boru>
It makes conversations seem one sided, since all of the context of one side of the conversation requires opening a web browser.
<Darius>
yep
<M9names[m]>
yeah. also not great because the logs are from the IRC side and so finding old conversations is hard.
<boru>
WRT debugging on riscv, it's just jtag. There was a fork of openocd, but I was also able to more or less trivially add support for various riscv MCUs
<M9names[m]>
i'll try to remember to keep my messages a bit shorter
<boru>
Apart from that jimtcl stuff, which is awful
<boru>
Not sure if any of the riscv support has been merged upstream
<M9names[m]>
not really, the wch riscv stuff doesn't all use jtag - they invented their own 1 and 2 wire protocols
<boru>
JTAG, as in where JTAG applies, which, IME is many, if not most, of the parts out in the wild.
<M9names[m]>
but cortex-m is generally better than most targets for debugging because you don't need to stop the core to read memory, and they have a bunch of nice tracing hardware built in
<M9names[m]>
you can have no-halt debugging on riscv, but since it's optional most vendors opt out
<boru>
True up to armv7e-m, but it got worse with armv8-m
<M9names[m]>
how so?
<boru>
e.g. fault addresses
<boru>
On v8-m it's "fault happened _somewhere_ around here"
<Darius>
boru: yeah I more mean the day to day QoL - how reliable is it? how fast? does "weird shit" happen? does the debugger crash? etc etc
<boru>
That's fair, yeah
<M9names[m]>
is that true for all v8-m?
<boru>
I mean, I'm not a huge fan of riscv, generally. I have a lot of gripes with it, overall.
<boru>
Cool idea, but it's a pity they didn't talk to any programmers when they were designing the ISA
<boru>
Many missed opportunities
<boru>
The EABI was the poor relation when it came to getting some love from the foundation. No formal standard for years.
<M9names[m]>
there's lots i like about riscv! but the architecture stuff that has been standardised (interrupt controllers, debug interface) definitely feels like it's several generations behind where arm is at.
<M9names[m]>
vendors have done a decent job filling in the gaps but that means it doesn't have a consistent+coherent ecosystem for embedded that compares well to cortex-m
<boru>
The have the benefit of not carrying around legacy cruft like arm. The benefits of riscv will only realised when vendors pick it up. Same happened to arm.
<boru>
Partnerships with xilinx, Si Labs, NXP etc brought ARM's processors from very average to better.
<boru>
Third parties found a lot of silicon bugs.
<boru>
When riscv goes maintstream, I hope we'll see improvements to the ISA which introduce all of the missed opportunities for usability and optimisation.
<boru>
ARM turned out lemons on more than one occasion; Jazelle and Thumb 1, for example.
<boru>
Absolutely worthless.
<boru>
Even in the cortex-m space, the fragmented ISA makes me wonder what they were thinking.
<boru>
But that's where riscv is at now, IMHO. It'll probably get better with time.
<Farooq>
Thank you folks. One question got lost. Is USB device something the hardware should provide, or it is something that I have to write software for it to use some pins as USB?
<boru>
Typically, you'll get a phy, but you may have to implement USB stacks in software e.g. HID and friends.
<boru>
You'll set up clocks, power and pins yourself.
<Farooq>
I don't know about PHY. What should I search to read more?
<boru>
USB PHY, or you target's datasheet
<Farooq>
I literally have no experience at programming MCUs
<Farooq>
s/at/in/
<boru>
Hmm. I wouldn't recommend reading the USB specs, because you'll be there for a while. Have a look at your target's datasheet, if it has a PHY, and read up on terms you don't understand. There's no royal road, and all that.
<Farooq>
okay thanks
<Farooq>
It says "One USB Host/Device interface"
<boru>
But...do yourself a favour, and start small. Start with what it takes to set up clocks, power and GPIOs, and what the implications are.
<boru>
After that, you can start looking at setting up peripherals.
<Farooq>
yeah that's what I'm thinking. I've bought RGB LED Array and a STM32 to do a simply toy for my little cousin
<M9names[m]>
It is possible to implement low-speed USB in software, but you shouldn't do it.
<M9names[m]>
Pick something that already has good rust support. A good idea of what would work well for a keyboard is the list of systems where someone has already built one.
<Farooq>
hmm Milk V Duo is not an MCU. It's a processor which runs something like Linux
<Farooq>
And it's RISC V
<boru>
What are your requirements?
<boru>
ARM and bare metal?
<Farooq>
It has a RISC-V/ARM application processor, a RISC V co processor and a 8051
<boru>
8051's great fun
<boru>
I thought only silabs were making them, still.
<boru>
Now I just need someone to start making 6800s again...
<Farooq>
boru: My requirement is more a playground. I want to build a mechanical split keyboard. But by using something like Milk V and adding some HDMI output, I could also have a portable tiny computer.
<boru>
I've done precisely that, before.
<boru>
It ran a Forth implementation I wrote, and had a little screen console. You could reprogram that keyboard firmware...using the keyboard.
<Farooq>
I could do a button to switch between keyboard and "micro" pc
<boru>
All on-target.
<Farooq>
@libera_boru:catircservices.org Would you recommend I do this? I want to have HDMI output, speaker and microphone
<boru>
Doesn't have to be mutally exclusive, but I'd forget about HDMI
<boru>
I'd be inclined to just get a little SPI LCD or something. Not like you're going to be running X/Wayland on your microcontroller.
<Farooq>
For instance since there is Wifi, I could do ssh
<Farooq>
and miracast
<Farooq>
of course no GUI
<boru>
Wait, so you want to run Linux on it?
<Farooq>
CLI is enough for ssh
<boru>
I think you're at crossed purposes here.
<Farooq>
boru: told you. it's an application processor with a RISC V coprocessor and a 8051 coprocesser
<boru>
You actually didn't state that you were using it.
<boru>
> I've bought RGB LED Array and a STM32 to do a simply toy for my little cousin
<boru>
This is what I thought you were talking about.
<Farooq>
these two are two different projects. I'm doing the STM32 thing to get started with bare metal programming
<Farooq>
then like a year later I could do kernel development
<boru>
Well, with the application processor, there isn't really anything to do other than install BSD or Linux and set up some services.
<boru>
Unless you need go hacking on device trees or something.
<Farooq>
I'm thinking about porting Asterinas to it, when I have the required skills which should be in ~1 year
<M9names[m]>
Not too hard to wire up gadget-mode in Linux to a user-space application that polls inputs, no need to mess with devicetree for that
<Farooq>
The device already has partial mainline support
<Farooq>
s/device/SoC/
<boru>
No idea what asterinas is.
<Farooq>
a Linux compatible kernel written in Rust
<boru>
Oh, I see. Cool.
<Farooq>
Is it a good idea to do keyboard firmware on an application processor which runs Linux? I fear response times will be slow
<Farooq>
Not sure about the architecture, maybe I could get the 8051 to do that
<M9names[m]>
Not really a good idea, but it will probably work just fine
<Farooq>
what if I do the keyboard firmware on the MCUs? either 8051 or the RISC V coprocessor?
<M9names[m]>
That should be fine
<Farooq>
oh man
<M9names[m]>
But I'd pick the riscv coprocessor unless you have a good reason for using the 8051.
<M9names[m]>
Learning is a good reason if you're keen.
<Farooq>
TRM says "USB DRD can act as HID mouse or keyboard"
<Farooq>
* as HID such as mouse or
<M9names[m]>
But there are simpler systems with 8051's if you want to learn about those
<boru>
You're not going to be doing USB on the 8051 unless you bitbang FS which is still pushing it, unless it's from a vendord that added some peripherals.
<boru>
If it's a true 8051, you've got a UART and some GPIOs.
<Farooq>
it says 8051 can do peripherals. 25Mhz to 300Mhz. doesn't say how much RAM
<boru>
"Can do peripherals" could mean PS/2, which is a piece of cake to implement, and far superior to USB HID.
<Lumpio->
I think the "8051" just refers to the CPU core usually nowadays, because it's been put into so many different chips
<Lumpio->
Not necessarily the original INtel one
<Lumpio->
There's plenty of chips with an 8051 compatible code and peripherals like USB
<Lumpio->
boru: Did you mean "inferior"?
<boru>
Absolutely not :)
<Farooq>
@libera_Lumpio-:catircservices.org I would second that
<Farooq>
boru: Milk V doesn't support PS/2. only USB host/device
<boru>
But yeah, as I said "unless it's from a vendor that added some peripherals"
<Farooq>
* Milk V Duo doesn't support
<boru>
PS/2 is easy to bitbang. Anything can support it.
<Farooq>
Note that for the AP, it can be either the RISC V one or the ARM one but not both
<Farooq>
* not both at the same time
<boru>
Lame
<Lumpio->
The "unless it's from a vendor that added some peripherals" is a bit silly because I have a feeling that the majority of "8051" chips are like that now
<boru>
Perhaps
<Farooq>
BTW, what language should I use to write for 8051? From my childhood books I remember you had to do assembly
<boru>
Did you work with the original?
<Lumpio->
Me? No
<Lumpio->
That chip is from before I was born
<boru>
Ah, I see.
<Farooq>
Lumpio-: same here XD
<boru>
And yeah, assembly, but there were compilers for high level languages like algol, C, fortran etc.
<boru>
That said, in the industries I worked in, assembly was fairly common even into the 2000s, because you couldn't rely on compiler output in some circumstances.
<Farooq>
I think I will forget about the 8051 there
<Lumpio->
I'd feel dirty using a C compiler for an 8-bit chip
<Lumpio->
(Then again the arduinoites are using C++)
<boru>
Thankfully, formal verification is more common, now.
<Lumpio->
What is this chip even by the way
<Lumpio->
It has like 4 different kinds of cores?
<boru>
AVR is a truly awful ISA, so fitting they should use an awful language...
<boru>
Lots of multi-ISA packages out these that you might not realise. When I worked in semiconductors, we had packages with 12-24 cores with 6 different ISAs.
<boru>
You probably have a few of them in close proximity to you at the moment.
<boru>
Not uncommon to have separate DSP cores in, say, RF ASICs etc.
<boru>
The thing in question seems to be this Milk V Duo, which I've also never heard of.
<Lumpio->
Yes, look, I know, but I was wondering what they were using this for
<Lumpio->
Most people here seem to be working with relatively simple microcontrollers, this looks like some big complicated SoC
<Farooq>
boru: what are applications of these?
<boru>
Which?
<Farooq>
Lumpio-: Did you see the "Cortex-A53" there and the RISC V running Linux?
<Lumpio->
The amount of typos makes me think that the manufacturer is one of those who doesn't provide much details and you'd have to reverse engineer a whole bunch to even get something of your own to boot on it
<Farooq>
boru: packages with 12 cores and 6 different ISAs
<Farooq>
Lumpio-: English TRM is available
<boru>
In this case, they were multi-radio RF ASICs.
<Farooq>
but yeah might be a good idea to avoid Milk V Duo
<Farooq>
boru: I see
<Lumpio->
What did you want to implement on this btw
<Farooq>
a keyboard + micro PC combo
<Farooq>
* a mechanical split keyboard +
<Farooq>
But if the only thing I want to do is ssh, I can do that already with Pico 2 WH with much less software work
<Lumpio->
A keyboard that can SSH? neat
<Farooq>
no
<Farooq>
there will be a button, one option is just keyboard with speaker and microphone. And the other option is a micro PC which can output HDMI or Miracast
<Farooq>
doing DVI on Pico is feasible and easy. and you can do DVI to HDMI
<M9names[m]>
feasible: yes.
<M9names[m]>
easy: not so much. there is no way that I could have written the PIO implementation required to drive it on rp2040.
<M9names[m]>
hstx looks much easier, but it's still so much further along the difficulty gradient than interacting with the USB peripheral or polling a key matrix
<Farooq>
hmm people have done VGA on it
<Farooq>
worst case is VGA to HDMI convertor
<M9names[m]>
i could do vga. very different problem
Kaspar[m] has joined #rust-embedded
<Kaspar[m]>
<Farooq> "doing DVI on Pico is feasible..." <- I was looking into this. IIUC DVI is a different encoding than hdmi, that doesn't transfer sound. Which is a pity ...
<Farooq>
Kaspar[m]: no sound required for ssh :)
<Kaspar[m]>
* pity ... I wonder if that can be hacked in.
<M9names[m]>
DVI can transfer sound, actually. (non-standard but surprisingly well supported)
<Farooq>
oh
<Kaspar[m]>
M9names[m]: hmmm, interesting!
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
adding `#[doc(hidden)]` to `pub type $app_name = ...` in the macro resolves this. or should i rather add some text? based on the big comment above it i don't think that this is really something that should show up in the docs in the first place since it seems to be a workaround? alternatively i can of course generate something along the lines of `/// This defines the postcard-rpc app implementation for $app_name`, if you prefer?
<Ralph[m]>
(PR incoming once i have your answer)
<JamesMunns[m]>
Not sure, I think `$var` in doc comments doesn't work, I realize the current macro just generates that literally (not substituted)
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
lulingar[m] has joined #rust-embedded
<lulingar[m]>
Hi! I just got to learn about this matrix chat! I'm at the RustWeek and, if possible, would like to attend the Unconference! Maybe adamgreig can you invite me?
<lulingar[m]>
* attend the Embedded WG Unconference! Maybe
<adamgreig[m]>
Hi lulingar! Right now I think we are fully at capacity, are you coming to the hackathon anyway? If it turns out we have space or someone doesn't show up you might be able to join but it probably doesn't make sense to travel there just in case
<lulingar[m]>
Yeah sure, I'll come to the hackathon and keep an eye on you guys.
<jason-kairos[m]>
sidebar comment: "magic_numbers" versioning etc. - it's sort of difficult to keep track of compatibility of structures in flash between different firmware versions.
<jason-kairos[m]>
Having a "magic_number" makes it possible to detect it, but one does have to remember to increment it each time something changes.
<jason-kairos[m]>
Is it possible to get a "hash" of a type (ie. names of fields and the type name hashed together) to somewhat automate this?
<adamgreig[m]>
<lulingar[m]> "Yeah sure, I'll come to the..." <- Ah, sorry, I've just found out the hackathon isn't actually at the same venue, I thought it was nearby but it's not
<adamgreig[m]>
If you are around on Saturday then we will certainly have some more space then, because some people are only able to come for Friday
<lulingar[m]>
<adamgreig[m]> "If you are around on Saturday..." <- Ah I see. I'll fly out on Friday evening. Hopefully next year then!
<diondokter[m]>
thejpster you might find this interesting
<dirbaio[m]>
yeah it's soooooooo weird :D
<dirbaio[m]>
you pass a block of Rust code to the asm macro?? :D
<diondokter[m]>
Ha yeah, really cool idea
<dirbaio[m]>
I guess it makes sense, it removes the pitfalls of classic unrestricted goto
<diondokter[m]>
Radically new approach where you let the compiler do the ABI and calling conventions
<jason-kairos[m]>
That feels wrong ('yet it's so right') - I bet Linux and other kernels kernel will make use of that feature. (goodbye branch instruction relative offset limitations on Cortex-M0)
<jason-kairos[m]>
* That feels so wrong ('yet
<jason-kairos[m]>
* That feels so wrong ('yet it's so right') - I bet Linux and other kernels will make use of that feature. (goodbye branch instruction relative offset limitations on Cortex-M0)
<jason-kairos[m]>
once or twice with cortex-m and related crates I'd been bitten by the lack of this
<jason-kairos[m]>
panic handlers and etc.
<diondokter[m]>
You were calling the panic handler from asm?
<jason-kairos[m]>
Hubris OS's hardfault handler does stuff like that
<jason-kairos[m]>
and it produces very pretty error messages when it compiles
<jason-kairos[m]>
pretty sure I encountered the same sort of thing doing bare metal on a STM32C0xx.
<JamesMunns[m]>
<dirbaio[m]> "no rust native way to do it, no..." <- I talked to the cargo folks and there's interest in adding something vaguely like toml-cfg to cargo
<JamesMunns[m]>
<dirbaio[m]> "no rust native way to do it, no..." <- I chatted with Eric Page and Josh Triplett, will try to chase the idea some more this week
<JamesMunns[m]>
Also talked with some folks about having a dedicated "outptr" syntax to allow for "placement new"-like behavior, talked to Taylor Cramer and Eric Holk and Cliff from Oxide about it