GenTooMan has quit [Ping timeout: 250 seconds]
Shell has quit [Quit: ZNC 1.8.2 - https://znc.in]
Shell has joined #rust-embedded
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
fabic has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc> <@w​00tspeaks:m​atrix.org> I'm looking at the cortex-m-semihosting crate. The version published to crates.io appears to be a very old version from before the code was moved to the same repo as the cortex-m crate. Has it been intentionally held back, or is it okay to use?
fabic has quit [Ping timeout: 250 seconds]
<re_irc> <@w​00tspeaks:m​atrix.org> Also, I'm very unclear about how to use it with my board. Is there anything I could look at to help me? I have a cortex-m33 board (lcpxpresso55s16-evk). I'd love to use rust instead of C with it.
<re_irc> <@w​00tspeaks:m​atrix.org> If anyone has pointers, I'd love to get them.
<re_irc> <@9​names:m​atrix.org> i think the general advice is to use RTT instead of semihosting if you can
<re_irc> <@f​irefrommoonlight:m​atrix.org> An interrupt with a lower priority should be allowed to fire in the ISR of a higher one right? (Cortex-M) I'm running into an issue where a sub-interrupt of a higher priority isn't firing if the programs polling in an ISR of lower pri. If I move this code to the main loop, it works. So, something's...
<re_irc> ... blocking the higher-pri from firing if it's in an ISR
<re_irc> <@f​irefrommoonlight:m​atrix.org> Any ideas on what I could be doing wrong?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Wren T: use Probe-run
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://github.com/knurling-rs/app-template
<re_irc> <@f​irefrommoonlight:m​atrix.org> Use this target: thumbv8m.main-none-eabihf
<re_irc> <@j​orgeig:m​atrix.org> > An interrupt with a lower priority should be allowed to fire in the ISR of a higher one right? (Cortex-M) I'm running into an issue where a sub-interrupt of a higher priority isn't firing if the programs polling in an ISR of lower pri. If I move this code to the main loop, it works. So, something's blocking the...
<re_irc> ... higher-pri from firing if it's in an ISR
<re_irc> <@j​orgeig:m​atrix.org> is there a confusion of lower/higher in this message? 😅 If I understand it right, in Cortex-M, the higher priority (as expressed by a higher priority value, not meaning that it has higher priority) will not interrupt a lower priority ISR
<re_irc> <@f​irefrommoonlight:m​atrix.org> SOrry, I used confusing words
<re_irc> <@f​irefrommoonlight:m​atrix.org> Higher pri = lower number
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw... When I set the low priority interrup to 32 just now, it worked ?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I noticed a comment in the cortex-m `get_priority` doc statement: "*NOTE* NVIC encodes priority in the highest bits of a byte so values like `1` and `2` map
<re_irc> <@f​irefrommoonlight:m​atrix.org> /// to the same priority. "
<re_irc> <@f​irefrommoonlight:m​atrix.org> Could be related?
<re_irc> <@j​orgeig:m​atrix.org> yes
<re_irc> <@f​irefrommoonlight:m​atrix.org> cp.NVIC.set_priority(pac::Interrupt::RTC0, 2); // or any val through 31 doesn' twork
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> cp.NVIC.set_priority(pac::Interrupt::TIMER1, 1);
<re_irc> <@j​orgeig:m​atrix.org> if you set the value to 1 or 2 or 4, it's all the same
<re_irc> <@f​irefrommoonlight:m​atrix.org> but if I set the RTC interrupt to `32` or higher, the pri 1 interrupt is allowed to fire within the pri 32 interrupt's ISR??
<re_irc> <@j​orgeig:m​atrix.org> it's the highest 3 or 4 bits if I remember right
<re_irc> <@f​irefrommoonlight:m​atrix.org> Why's that? `0b01` and `0b10` have different bits in both positions
<re_irc> <@f​irefrommoonlight:m​atrix.org> I could just trial and error this
<re_irc> <@j​orgeig:m​atrix.org> which cortex-m are you using?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie my thing works now. Maybe I need to look at the cortex-m RM. The Nordic one (This is on nrf52) has very little info on NVIC. The STM32 manuals have detailed tables, but not an answer for htis conundrum
<re_irc> <@f​irefrommoonlight:m​atrix.org> Cortex-M4
<re_irc> <@j​orgeig:m​atrix.org> oh then it has 256 levels, it's all the bits
<re_irc> <@j​orgeig:m​atrix.org> I've never worked with nrf52, but got curious
<re_irc> <@j​orgeig:m​atrix.org> are you working with the soft device too?
<re_irc> <@9​names:m​atrix.org> Which has 256 levels? Don't nrf52's only have 16?
<re_irc> <@j​orgeig:m​atrix.org> AFAIU cortex-m4 itself has 256 priorities (a full byte per interrupt), nrf might have something different on top
<re_irc> <@j​orgeig:m​atrix.org> I was looking at their softdevice C code and they only allow three interrupt priorities in there
<re_irc> <@j​orgeig:m​atrix.org> jorgeig: or this might be completely wrong, I just found a few lines of code that restrict the priority levels so it looks like you can't just set whatever you want when you use their API
<re_irc> <@j​orgeig:m​atrix.org> not applicable here, I guess, since he was just using the Rust PAC methods
<re_irc> <@f​irefrommoonlight:m​atrix.org> Nope. I'm doing ESB stuff
<re_irc> <@f​irefrommoonlight:m​atrix.org> Taking a reading with an IR thermometer, and sending to another board. WOrking now that I by chance tried a very high interrupt number
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm also confused by that - found some info on interrupts re soft device, but the manual is oddly blank about normal interrrupts
<re_irc> <@f​irefrommoonlight:m​atrix.org> Compared to ST's
<re_irc> <@f​irefrommoonlight:m​atrix.org> (ESB is a simple RF protocol that doesn't need softdevice)
<re_irc> <@9​names:m​atrix.org> Says there are only 8 levels
<re_irc> <@9​names:m​atrix.org> so only the top 3 bits matter
<re_irc> <@f​irefrommoonlight:m​atrix.org> That appears to be for softdevice
<re_irc> <@f​irefrommoonlight:m​atrix.org> Perhaps it's more broadly applicable though?
<re_irc> <@j​orgeig:m​atrix.org> It says it's for the SoC
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ohh
<re_irc> <@f​irefrommoonlight:m​atrix.org> Wait does top 3 bits mean in this context?
<re_irc> <@j​orgeig:m​atrix.org> So even though it's in the softdevice docs, it might be for everybody!
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie, `0b001` and `0b010` have differnet top 3 bits
<re_irc> <@9​names:m​atrix.org> "The nRF52 SoC has eight configurable interrupt priorities ranging from 0 to 7 (with 0 being highest priority). On reset, all interrupts are configured with the highest priority (0)."
<re_irc> <@9​names:m​atrix.org> that does not sound remotely softdevice specific
<re_irc> <@f​irefrommoonlight:m​atrix.org> You're right
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm curious how this maps to NVIC bits
<re_irc> <@f​irefrommoonlight:m​atrix.org> And what's special about the 6th bit being significant (Why I need to set the low-priority interrupt to 32 in NVIC to allow it to be overridden)
<re_irc> <@j​orgeig:m​atrix.org> If you look at the cortex m4 manual, each interrupt has a byte in a 32 bit register5
<re_irc> <@j​orgeig:m​atrix.org> So in the nrf implementation, they're only using the 3 MSBits
<re_irc> <@j​orgeig:m​atrix.org> Looks like
<re_irc> <@j​orgeig:m​atrix.org> Which matches with what you're seeing
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you. I'll dive into that manual
<re_irc> <@j​orgeig:m​atrix.org> It's weird that you have to do that manually though
<re_irc> <@j​orgeig:m​atrix.org> I would expect the PAC to take care of it?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Maybe it's in there. I'm using the `cortex-m` crate to do this
<re_irc> <@f​irefrommoonlight:m​atrix.org> Maybe thi sis differnet? https://docs.rs/nrf52840-pac/0.10.1/nrf52840_pac/struct.NVIC.html#method.unmask
<re_irc> <@f​irefrommoonlight:m​atrix.org> Found the Cortex-M table you referred to:
<re_irc> <@f​irefrommoonlight:m​atrix.org> Total number of interrupt lines in groups of 32:
<re_irc> <@f​irefrommoonlight:m​atrix.org> 0b0010 = 65...96
<re_irc> <@f​irefrommoonlight:m​atrix.org> 0b0001 = 33...64
<re_irc> <@f​irefrommoonlight:m​atrix.org> 0b0000 = 0...32
fabic has joined #rust-embedded
<re_irc> <@w​00tspeaks:m​atrix.org> firefrommoonlight: Is this a tip for using my board, or an alternative to cortex-m-semihosting?
<re_irc> <@t​hejpster:m​atrix.org> dkhayes117: No, just an introduction to rust in general
<re_irc> <@f​irefrommoonlight:m​atrix.org> cortex-m semihosting
<re_irc> <@w​00tspeaks:m​atrix.org> Looks neat. Thx.
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
dcz has joined #rust-embedded
<dcz> hi! anyone here who maintains the sd-mmc library? my change seems stalled https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/38
GenTooMan has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> thejpster already approved it, eldruin could also merge it I think.
<dcz> I'm somewhat disappointed by merge requests lingering when the project is in the official rust-embedded community. Is there a way to help this? Join the group perhaps?
<re_irc> <@e​ldruin:m​atrix.org> @dcz PR looks good. will merge once CI is through. thanks!
<dcz> seems I have to cargo fmt this
<re_irc> <@t​herealprof:m​atrix.org> dcz: Just NB: This is *not* part of the official Rust Embedded WG, it's a community project.
<dcz> oh, is it the -community namespace?
<re_irc> <@e​ldruin:m​atrix.org> I will rename the org to rust-embedded-unofficial, just haven't found the time yet
<re_irc> <@e​ldruin:m​atrix.org> yes
<dcz> this one is official Rust Team project though, right :)? https://github.com/riscv-rust/longan-nano/pull/24
<re_irc> <@e​ldruin:m​atrix.org> the official repositories for RISCV are limited to riscv and riscv-rt: https://github.com/orgs/rust-embedded/repositories?q=riscv
<dcz> that's weird judging by the copyright note in the readme, but maybe someone copy-pasted it thoughtlessly
<re_irc> <@e​ldruin:m​atrix.org> hmm, the readme hints at the riscv team within rust-embedded
<re_irc> <@d​isasm-ewg:m​atrix.org> dcz: I've received your ping, will try to review the PR in ~8 hours
<dcz> cool! no hurry, I just want to be sure that someone actually cares about the projects I contribute to
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
<re_irc> <@d​khayes117:m​atrix.org> dcz: I'm a new riscv team member, and I had planned on reviewing your PR. Currently, I am working on getting ADC and PWM PRs merged for gd32vf103xx-hal, which is why I hadn't yet 🙂
<re_irc> <@h​egza:m​atrix.org> I'm teaching a short seminar course on embedded Rust at Tampere University, do you think it would be alright to include the embedded Rust logo (also this channel's logo) in 'marketing'? The course involves a small set of exercises to give an overview of what's available, and the students making a small embedded...
<re_irc> ... Rust project in groups.
<re_irc> <@h​egza:m​atrix.org> I find it kind of sketchy because I don't represent the Rust Embedded WG -team, but I thought to ask anyway since it's pretty convenient.
<re_irc> <@h​argonix:m​atrix.org> adamgreig: should know or should know someone who knows the answer
<re_irc> <@a​damgreig:m​atrix.org> the policy to follow is https://www.rust-lang.org/policies/media-guide
<re_irc> <@a​damgreig:m​atrix.org> the rust embedded logo contains the rust trademark (with permission), so that's what applies
<re_irc> <@h​egza:m​atrix.org> I think it might be better to use something else for my purpose here, perhaps a microcontroller or something. In my context it might be interpreted as "an endorsement by the Rust project".
<re_irc> <@j​platte:f​lipdot.org> Just added this room to the (unofficial) Rust Matrix Space: #rust-space:matrix.org (following xiretza's suggestion)
fabic has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> heksa: if it's non-commercial (i.e. at a university) and you just use it to identify that it's rust I think would be fine, as in "Using the Rust trademarks (even in modified form) for social events like meetups, tutorials, and the like is allowed for events that are free to attend. "
<re_irc> <@a​damgreig:m​atrix.org> (that latter is explicitly permitted)
<re_irc> <@a​damgreig:m​atrix.org> I guess you might debate whether free to attend applies to university courses :/
<re_irc> <@a​damgreig:m​atrix.org> jplatte: cool! I guess we should transition the embedded community to a space...
<re_irc> <@h​egza:m​atrix.org> adamgreig: Yeah! I actually just tried to make it (nationally...) public via FiTech, but the thing got lost in bureaucracy and I can't reach the person responsible. You get used to it at the university though and it's mostly amusing 🥲
<re_irc> <@a​damgreig:m​atrix.org> hehe, I understand
<re_irc> <@j​platte:f​lipdot.org> adamgreig: Not sure how that would fit into the current space hierarchy where there's a libraries and an applications sub-space and a few rooms like this one that are just in the top-level space, but if you do add another space let me know and I can add it as a sub-space :)
<re_irc> <@a​damgreig:m​atrix.org> there's a bunch of other embedded rooms
<re_irc> <@a​damgreig:m​atrix.org> #probe-rs:matrix.org #rtic:matrix.org #stm32-rs:matrix.org #rust-embedded-graphics:matrix.org #embassy-rs:matrix.org #rp-rs:matrix.org and also the nrf and riscv and other ones I'm not in
<re_irc> <@a​damgreig:m​atrix.org> https://app.element.io/#/group/+rust-embedded:matrix.org
<re_irc> <@j​platte:f​lipdot.org> If you want them in the current hierarchy I can give you rights to manage the existing spaces (you seem to be well-established in the community)
<re_irc> <@j​platte:f​lipdot.org> Or you create a space and I add it as a sub-space
fabic has quit [Ping timeout: 240 seconds]
<re_irc> <@a​damgreig:m​atrix.org> I've created #rust-embedded-space:matrix.org
<re_irc> <@y​atekii:m​atrix.org> #nrf-rs:matrix.org is a thing too :)
<re_irc> <@j​platte:f​lipdot.org> adamgreig: Added as a sub-space 👍️
<re_irc> <@a​damgreig:m​atrix.org> thanks!
<re_irc> <@a​damgreig:m​atrix.org> I guess removed this channel from the top-level too?
<re_irc> <@j​platte:f​lipdot.org> Yeah, just did that now
<re_irc> <@a​damgreig:m​atrix.org> thanks
<re_irc> <@a​damgreig:m​atrix.org> added the other rust-community rooms to the new rust-embedded-space
<re_irc> <@a​damgreig:m​atrix.org> if anyone knows of any other rooms that should be there please shout :)
<re_irc> <@a​damgreig:m​atrix.org> hm, if I'm in rust-space it folds it into the rust-embedded-space and I only get one sidebar icon?
<re_irc> <@a​damgreig:m​atrix.org> ah I see, if I expand the sidebar they're nested, fair enough
<re_irc> <@y​atekii:m​atrix.org> yep :)
<re_irc> <@y​atekii:m​atrix.org> quite neat the feature :)
<dcz> dkhayes: nice, I want to add better RTC support at some point. Also USB would be nice but I'd need some help, judging by my attempts with another micro
fabic has joined #rust-embedded
richardeoin has quit [*.net *.split]
jasperw has quit [*.net *.split]
richardeoin has joined #rust-embedded
jasperw has joined #rust-embedded
zBeeble has quit [Read error: Connection reset by peer]
zBeeble has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@n​ewam:m​atrix.org> Anyone got rust code for a STM32 SPI bus running as a slave?
<re_irc> <@n​ewam:m​atrix.org> I got the STM32WL end-to-end latency down to 75ms, but majority of that is server-side ECDSA verification which I want to offload to a faster CPU.
<re_irc> <@n​ewam:m​atrix.org> SPI seems like the fastest bus this thing has.
<re_irc> <@n​ewam:m​atrix.org> (actual end-to-end latency is like 5ms if you skip signing/encryption)
<re_irc> <@l​uojia65:m​atrix.org> How to set a feature gate for RISC-V targets to test if the platform supports atomic instructions?
<re_irc> <@n​ewam:m​atrix.org> There is this if you can use nightly: https://github.com/rust-lang/rust/issues/32976
<re_irc> <@n​ewam:m​atrix.org> Otherwise I don't know 😕
<re_irc> <@l​uojia65:m​atrix.org> Thanks! Nightly is enough for this issue
<re_irc> <@h​argonix:m​atrix.org> Well only riscv targets with the A extension should have atomics and rust supports:
<re_irc> <@h​argonix:m​atrix.org> riscv32i-unknown-none-elf
<re_irc> <@h​argonix:m​atrix.org> riscv32imac-unknown-none-elf
<re_irc> <@h​argonix:m​atrix.org> riscv32imc-unknown-none-elf
<re_irc> <@l​uojia65:m​atrix.org> Thanks
<re_irc> <@l​uojia65:m​atrix.org> I'm writing an UEFI-like bootloader environment in Rust
<re_irc> <@l​uojia65:m​atrix.org> So I guess it's correct to look into bare metal Rust targets to find out what I need to know
<re_irc> <@a​lmindor:m​atrix.org> > this one is official Rust Team project though, right :)? https://github.com/riscv-rust/longan-nano/pull/24
<re_irc> <@a​lmindor:m​atrix.org> LGTM, I'm afraid i don't have write on that repo tho
<re_irc> <@d​khayes117:m​atrix.org> almindor: dcz: disasm said he'd look at it later. If he is unable to, I will get it merged.
<re_irc> <@j​orgeig:m​atrix.org> has anyone used https://github.com/BlackbirdHQ/defmt-persist ?
<re_irc> <@j​orgeig:m​atrix.org> I will try it next week but just wanted to get some impressions if someone has used it
<re_irc> <@d​khayes117:m​atrix.org> That looks neat.
<re_irc> <@n​ewam:m​atrix.org> jorgeig: I have not used that specifically, but I did something similar before.
<re_irc> <@n​ewam:m​atrix.org> it worked well, but I needed to put the githash into the firmware to make the matching of specific firmware to ELF file easier.
<re_irc> <@j​orgeig:m​atrix.org> thanks!
<re_irc> <@m​athias_koch:m​atrix.org> jorgeig: I am the author of it, and it is still wip. But any kind of contribution would be more than welcomed! It's on our Todo to incorporate it into our production iot devices soon 😅
<re_irc> <@j​orgeig:m​atrix.org> awesome! hopefully we can add some PRs to help
fabic has quit [Ping timeout: 240 seconds]
<re_irc> <@a​damgreig:m​atrix.org> @room meeting time again! agenda is https://hackmd.io/Tl-2msMzTOmn9uhtmClQlQ, please add anything you'd like to discuss, we'll start in about 5min
<re_irc> <@a​damgreig:m​atrix.org> please do add anything you'd like to discuss because I'm not sure of anything to put on the agenda this week 😓 just checked all my rust-embedded emails over the last 7 days but it's not been too noisy
<re_irc> <@h​argonix:m​atrix.org> Just a little announcement, I'm basically through with the discovery book except that there is a bug in the nrf51-hal regarding Countdown timers I have to fix aaaand that on my micro bit v1 the magnetometer is strongly convinced that the X value of the magnetic field of hte earth is always negative for some...
<re_irc> ... reason but apart from that its all PRed in at the discovery repo \o/
<re_irc> <@e​ldruin:m​atrix.org> Great work! I'll go through the PRs in the next few days
<re_irc> <@h​argonix:m​atrix.org> Oh and I convinced some guy at work who hasnt done anything with embedded yet but knows rust to go and try it out so we even got ourselves somewhat of a lab rat i guess xd
<re_irc> <@e​ldruin:m​atrix.org> hahaha nice
<re_irc> <@e​ldruin:m​atrix.org> we could discuss how to go about the different versions
<re_irc> <@e​ldruin:m​atrix.org> since the F3 is back on business but the book is outdated in several regards (cargo-embed, differing magnetometer/accelerometer)
<re_irc> <@a​damgreig:m​atrix.org> yea, swapping over to the probe-rs tools instead of openocd and gdb would make it a lot easier for new users i bet
<re_irc> <@d​khayes117:m​atrix.org> Are the micro bit PRs separate chapters, exclusively for the micro bit, or re-written to be sort of universal with the discovery board?
<re_irc> <@a​damgreig:m​atrix.org> just use rtt instead of all the painstaking gdb operations perhaps
<re_irc> <@a​damgreig:m​atrix.org> ok, well, let's "start" the meeting :P
<re_irc> <@h​argonix:m​atrix.org> dkhayes117: they live on a seperate branch and provide code etc. for the micro bit v1 v2...but its largely dependent on embedded HAL really so it should be *tm* easy to switch between
<re_irc> <@a​damgreig:m​atrix.org> so yea, we're soon to have the new micro:bit version of discovery, at the time we started the idea was to swap completely over to it, replacing the f3disco one, since that seemed to be out of production
<re_irc> <@a​damgreig:m​atrix.org> now of course it's seemingly back in production... but i think the arguments at the time about microbit being a possibly better introductory board still apply
<re_irc> <@a​damgreig:m​atrix.org> and it's a bunch cheaper and millions of people already have one
<re_irc> <@e​ldruin:m​atrix.org> yeah I agree
<re_irc> <@t​herealprof:m​atrix.org> Same.
<re_irc> <@a​damgreig:m​atrix.org> (millions? i remember at the time it was advertised that 1 million UK schoolkids would get one, I don't know if that fully happened or what)
<re_irc> <@e​ldruin:m​atrix.org> how about promoting the microbit rewrite to default and keep the f3 somewhere else?
<re_irc> <@e​ldruin:m​atrix.org> but also published I mean
<re_irc> <@a​damgreig:m​atrix.org> yea
<re_irc> <@h​argonix:m​atrix.org> yeah we could host it at e.g. https://docs.rust-embedded.org/discovery/ and the other version at https://docs.rust-embedded.org/discovery-old or something
<re_irc> <@h​mvp:m​atrix.org> adamgreig: Doesn't this also apply for the rp2040 (pico)
<re_irc> <@t​herealprof:m​atrix.org> Running into the risk of repeating myself: I'm still not too happy with the name discovery for a book not about an STM discovery board. 😉
<re_irc> <@a​damgreig:m​atrix.org> Hmvp: the pico board doesn't seem ideal since it doesn't come with any onboard peripherals
<re_irc> <@h​argonix:m​atrix.org> its about discovery of embedded rust! therealprof
<re_irc> <@e​ldruin:m​atrix.org> therealprof: yeah, valid point, but we get into bikeshedding
<re_irc> <@a​damgreig:m​atrix.org> yea, we lose the pun of it being both about the discovery board and the discovery process, but I don't think it's the end of the world, plus we'll still have the discovery-board-based version too
<re_irc> <@t​herealprof:m​atrix.org> Hmvp: Yes, but it not only is way less supported, it also has pretty much no external peripherals on board.
<re_irc> <@t​herealprof:m​atrix.org> hargonix: Heh, fair!
<re_irc> <@a​damgreig:m​atrix.org> the additional thing is the talk last week of a risc-v version of the discovery book though
<re_irc> <@a​damgreig:m​atrix.org> I don't really know how that would best fit in, though, should it be the same target audience but with risc-v or would it be more useful to be an introduction to risc-v and rust rather than to embedded in general?
<re_irc> <@a​damgreig:m​atrix.org> much higher maintenance too of course
<re_irc> <@e​ldruin:m​atrix.org> yeah but I think the books are so different that it does not make sense to have some sort of small switch between f3/microbit/riscv versions
<re_irc> <@a​damgreig:m​atrix.org> having "the discovery book" be the micro:bit one, with a link from the front page to "the old discovery book using the f3 discovery board", means we don't have to keep both fully up-to-date or anything
<re_irc> <@e​ldruin:m​atrix.org> more like full-on separate builds
<re_irc> <@a​damgreig:m​atrix.org> yea
<re_irc> <@a​damgreig:m​atrix.org> right, I don't think it makes sense to have like little tabs on each code snippet or anything, enough things are quite different between the devices
<re_irc> <@t​hejpster:m​atrix.org> Fyi, I have an invite in my diary from the Raspberry Pi Foundation to talk to them about Rust.
<re_irc> <@e​ldruin:m​atrix.org> so it would be something like hargonix proposed. publish to /discovery, /discovery-f3 /discovery-riscv or whatever
<re_irc> <@a​damgreig:m​atrix.org> thejpster: you should let jamesmunns know, he'll be jealous :P
<re_irc> <@a​damgreig:m​atrix.org> eldruin: should it be /discovery-microbit ?
<re_irc> <@t​hejpster:m​atrix.org> I think the RP2040 is going to flatten the Arduino Uno and a bunch of other boards. It has performance, availability and price on its side.
<re_irc> <@a​damgreig:m​atrix.org> and probably instead of -riscv it should be the board name (but idk what board one would pick?)
<re_irc> <@t​hejpster:m​atrix.org> Oh he knows ;)
<re_irc> <@d​khayes117:m​atrix.org> So would you expect the RISC-V version to mirror the other discovery versions?
<re_irc> <@t​hejpster:m​atrix.org> For the price of a Disco you can put a Pico on any number of carrier boards full of fun things.
<re_irc> <@d​khayes117:m​atrix.org> chapters wise
<re_irc> <@e​ldruin:m​atrix.org> hmm, we could also publish an index to /discovery with the links to the different versions, then publish the books in /discovery-microbit,...
<re_irc> <@a​damgreig:m​atrix.org> because it's a separate book I don't think it would have to mirror the others at all
<re_irc> <@a​damgreig:m​atrix.org> eldruin: if we do this they could stay in one repo too perhaps? /discovery, /discovery/microbit, etc
<re_irc> <@h​argonix:m​atrix.org> thejpster: Yeah sure you can do that but then beginners have to put circuits together as well and buy lots more components, thats just unnecessarily hard and adds more possibilities for errors.
<re_irc> <@h​argonix:m​atrix.org> After all the target audience for the discovery book is "has never done embedded before"
<re_irc> <@d​khayes117:m​atrix.org> I was thinking of targeting the FE310-G002 riscv chip since it is on several dev boards...Hifive1, Lowfive, Red-V (both versions), Dr. Who inventor board...
<re_irc> <@a​damgreig:m​atrix.org> yea, I could imagine one day in the future there will be some dev board with an rp2040 and some peripherals on it and we write a discovery book using it, perhaps
<re_irc> <@e​ldruin:m​atrix.org> adamgreig: one repo may be a good idea
<re_irc> <@a​damgreig:m​atrix.org> dkhayes117: for the other books it's quite focussed on a single dev board with some peripherals on, so the users just get that dev board and follow through, since the objective is to teach embedded from 0
<re_irc> <@a​damgreig:m​atrix.org> single repo is probably easier for us to manage and deploy and all the rest of it
<re_irc> <@d​khayes117:m​atrix.org> adamgreig: fair
<re_irc> <@h​mvp:m​atrix.org> adamgreig: Yeah there are already some quite complete plug and play boards...
<re_irc> <@a​damgreig:m​atrix.org> dkhayes117: but maybe there's not such an obvious single board to pick, or you want to be slightly wider-ranging in what you cover, I guess the question is whether it's a "discovery" book or a "riscv-embedded-rs" book or what
<re_irc> <@t​hejpster:m​atrix.org> What prompted the change? Is the F3 Disco EOL or something? The incremental benefit of switching boards otherwise seems small.
<re_irc> <@t​heunkn0wn1:m​atrix.org> hargonix: perhaps, but at the same time it may be more friendly to beginners; who could potentially mix and match the parts they want to learn about.
<re_irc> <@t​heunkn0wn1:m​atrix.org> I, for one, found the existing books difficult to work with for, among other reasons, it used hardware I didn't have (I had a nucleo, the books used something more complete) and hardware I didn't have much use for.
<re_irc> <@t​heunkn0wn1:m​atrix.org> IMHO, having the user build the circuit off a breadboard would be more beneficial, from my beginners point of view
<re_irc> <@a​damgreig:m​atrix.org> thejpster: it was out of production and not in stock anywhere when the microbit rewrite began, which was before the rp2040 came out
<re_irc> <@l​ulf_:m​atrix.org> hargonix: Just to add to this point. I think the Discovery book should not necessarily keep up with the latest and greatest of boards, but go for the commonly available ones. Time will tell how popular and commonly available risk-v or pico will be.
<re_irc> <@d​khayes117:m​atrix.org> I think a lot of the discovery book skills are very much transferable to risc-v, so maybe not a full-on start from zero point
<re_irc> <@t​hejpster:m​atrix.org> Ah, I see. I'm fine with the Microbit by the way. It's fine.
<re_irc> <@a​damgreig:m​atrix.org> thejpster: yea, perhaps if we were doing the same thing a year from now an rp2040 board would be the obvious choice, and like you I expect to see it become extremely widespread in hobbyist stuff
<re_irc> <@a​damgreig:m​atrix.org> but it wasn't on the table at all back then, and even today I don't think the support is fully fledged enough to make sense to write a new book on it? or in any event people wanted to write a book using the micro:bit and have done so, so...
<re_irc> <@t​herealprof:m​atrix.org> thejpster: And it has BLE built-in which ups the game quite a bit (not that we can really utilize it at the moment...).
<re_irc> <@a​damgreig:m​atrix.org> micro:bit is also extremely available worldwide, cheap, has a range of fun peripherals onboard, etc
<re_irc> <@d​khayes117:m​atrix.org> Longan Nano wouldn't be a bad choice for risc-v, super cheap and got a cool LCD attached. Could include embedded graphics :)
<re_irc> <@a​damgreig:m​atrix.org> even in the face of the rp2040 it seems like a decent choice for an introduction to embedded
<re_irc> <@t​hejpster:m​atrix.org> No one gets fired for buying BBC.
<re_irc> <@a​damgreig:m​atrix.org> dkhayes117: ooh, I have one of these :)
<re_irc> <@a​damgreig:m​atrix.org> embedded graphics, USB, couple of buttons...
<re_irc> <@a​damgreig:m​atrix.org> anyway
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: There's also variants like the sino:bit and the other one the name of which I forgot. At some point we could also support those variants. I've heard the sino:bit is really popular in China (not sure whether that's accurate info though).
<re_irc> <@a​damgreig:m​atrix.org> so for a concrete proposal, basically what eldruin suggested: we keep a single "discovery" repo, put each book into its own subfolder /f3, /microbit, and put an index landing page that introduces the concept and book and has the links?
<re_irc> <@a​damgreig:m​atrix.org> we might need some thought around maintaining old URLs and the like
<re_irc> <@t​hejpster:m​atrix.org> Do we target micro bit V2 or V1?
<re_irc> <@h​argonix:m​atrix.org> therealprof: we have someone here from china, maybe luojia65 knows?
<re_irc> <@h​argonix:m​atrix.org> thejpster: both
<re_irc> <@t​herealprof:m​atrix.org> thejpster: Both. 🕺
<re_irc> <@t​hejpster:m​atrix.org> A toofer. Nice.
<re_irc> <@a​damgreig:m​atrix.org> and we advertise the micro:bit as the one to look at over the f3, I think?
<re_irc> <@a​damgreig:m​atrix.org> i.e. "here's the latest version of the book, using a micro:bit, but if you have an f3 discovery, the previous version is available here"
<re_irc> <@a​damgreig:m​atrix.org> once there's a risc-v book on the scene we can reword that a bit
<re_irc> <@n​ewam:m​atrix.org> The microbit is also (partially) implemented in QEMU if I recall correctly.
<re_irc> <@e​ldruin:m​atrix.org> yeah that sounds good to me
<re_irc> <@h​argonix:m​atrix.org> oh i sort of removed all remarks to the f3 but sure we could get that in
<re_irc> <@t​hejpster:m​atrix.org> Edition, not Version.
<re_irc> <@a​damgreig:m​atrix.org> hargonix: oh, I mean this would be on the front page that links to the microbit book, so the microbit book doesn't need to include it
<re_irc> <@t​hejpster:m​atrix.org> "micro:bit edition - new and updated!"
<re_irc> <@e​ldruin:m​atrix.org> hargonix: that is fine, we only add info on the different versions in the index page, outside of the books
<re_irc> <@d​khayes117:m​atrix.org> https://www.hifiveinventor.com/
<re_irc> <@t​herealprof:m​atrix.org> dkhayes117: lol, the shape. 😀 Also BBC supported, sweet!
<re_irc> <@a​damgreig:m​atrix.org> haha is that, like, a micro:bit risc-v?
<re_irc> <@h​argonix:m​atrix.org> RGB LEDs even, micro:bit cant keep up with that shit
<re_irc> <@a​damgreig:m​atrix.org> thanks BBC :D
<re_irc> <@d​khayes117:m​atrix.org> Pricey though, the kit is $75 from adafruit
<re_irc> <@h​mvp:m​atrix.org> dkhayes117: I'd rather have this then: https://www.adafruit.com/product/5128
<re_irc> <@h​argonix:m​atrix.org> but the rp2040 is not riscv is it?
<re_irc> <@d​khayes117:m​atrix.org> Hmvp: That is RP though not riscv
<re_irc> <@n​ewam:m​atrix.org> Hmvp: Adafruit is unfortunately restrictive for many parts of the world, the shipping can be difficult for non-US folks.
<re_irc> <@d​khayes117:m​atrix.org> It is BBC thing, its not adafruit exclusive
<re_irc> <@n​ewam:m​atrix.org> dkhayes117: Yeah, I was replying to the Adafruit MacroPad which as far as I know is an adafruit exclusive.
<re_irc> <@t​herealprof:m​atrix.org> I find the marketing a little bit too much on the BS side.
<re_irc> <@d​khayes117:m​atrix.org> Oh, I see
<re_irc> <@d​khayes117:m​atrix.org> There isn't a ton of RISC-V dev boards to choose from, mostly SiFive or GD32V based
<re_irc> <@t​herealprof:m​atrix.org> As in, too many weird claims and very light on any details, especially compared to a RP Pico or micro:bit.
<re_irc> <@e​ldruin:m​atrix.org> I think the microbit and f3 versions are solid choices for now
<re_irc> <@h​argonix:m​atrix.org> I mean in the end the Rust Embedded eco system is sort of trying to abstract away whether we are dealing with RISCV, Cortex M-X etc. apart from a few details right? So the RISCV specific things to teach for beginners shouldnt be too many if we are doing a good job with that
<re_irc> <@a​damgreig:m​atrix.org> I'd love to read some kind of "intro to risc-v" and rust on it, but yea, for me it doesn't need to be a "intro to embedded" at the same time
<re_irc> <@a​damgreig:m​atrix.org> where that ends up living, then, idk
<re_irc> <@a​damgreig:m​atrix.org> I can see the appeal of having complete introductory material for risc-v too though
GenTooMan has quit [Ping timeout: 250 seconds]
<re_irc> <@t​hejpster:m​atrix.org> if it's an open ISA, it should be an open PCB too though (and ideally an open SoC, but that's going to take a while, even if I complete this ASIC design course)
<re_irc> <@a​damgreig:m​atrix.org> so I think in some sense it's up to what you want to write dkhayes117; we can have another discovery book alongside micro:bit if there's some suitable cheap dev board people can use, or it could be more of an addendum; "you've learnt some embedded and rust on the discovery book, here's how things work on...
<re_irc> ... risc-v"
<re_irc> <@d​khayes117:m​atrix.org> I see the RISC-V part as exntension chapters to the discovery portion
<re_irc> <@a​damgreig:m​atrix.org> cool
<re_irc> <@a​damgreig:m​atrix.org> that sounds nice, and I guess it could go as a third book linked from the front page
<re_irc> <@a​damgreig:m​atrix.org> "discovery: the X chapters"
<re_irc> <@a​damgreig:m​atrix.org> s/X/V :P
<re_irc> <@e​ldruin:m​atrix.org> exactly
<re_irc> <@d​khayes117:m​atrix.org> I'm okay with that, less to maintain too
GenTooMan has joined #rust-embedded
<re_irc> <@d​khayes117:m​atrix.org> I would do a brief overview with links in a "RISC-V book shelf" for in-depth research (no need to reinvent the wheel) then continue with risc-v specific examples in rust like the privileged specs
<re_irc> <@e​ldruin:m​atrix.org> yeah, maybe something like: remember that example for the microbit? here is what you need to change for the hifive
<re_irc> <@a​damgreig:m​atrix.org> cool, thanks everyone! so I think hargonix press on with the last bits, and then when it's all ready we'll reorganise the file structure to serve both from the same repo, with a new front page
<re_irc> <@h​argonix:m​atrix.org> 👍️
<re_irc> <@a​damgreig:m​atrix.org> anyone have anything else to discuss for the last few minutes?
<re_irc> <@e​ldruin:m​atrix.org> 1. 2 times in this chat somebody from a company has come and say, we would like to help, what can we do
<re_irc> <@e​ldruin:m​atrix.org> there have been a couple things I wanted to bring up here
<re_irc> <@e​ldruin:m​atrix.org> 2. there was a suggestion for more detailed commercial testimonials in the awesome-e-r repo
<re_irc> <@e​ldruin:m​atrix.org> but we can discuss these next week
<re_irc> <@e​ldruin:m​atrix.org> too big topics I guess
<re_irc> <@a​damgreig:m​atrix.org> yea, makes sense
<re_irc> <@a​damgreig:m​atrix.org> for the testimonials, thinking of links to people talking about using rust commercially, or actually asking companies to write something up to put on a-e-r?
<re_irc> <@d​khayes117:m​atrix.org> That is a vaild point (and important)
<re_irc> <@d​khayes117:m​atrix.org> Ha, that is exactly what you said @eldruin, I just read it lol
<re_irc> <@a​damgreig:m​atrix.org> cool, let's discuss them further next week
<re_irc> <@a​damgreig:m​atrix.org> thanks everyone!
<re_irc> <@d​irbaio:m​atrix.org> I've always found the "I want to help, what can I do" strange
<re_irc> <@d​irbaio:m​atrix.org> you want to do X? then do it, then if you find Y is missing you contribute it
<re_irc> <@d​irbaio:m​atrix.org> that's what drives opensource forward :P
<re_irc> <@j​axter184:m​atrix.org> i feel like thats a question that comes from people who have never contributed to a project before
<re_irc> <@j​axter184:m​atrix.org> ive definitely had that sentiment in the past, but im not sure if ive ever said it
<re_irc> <@t​herealprof:m​atrix.org> Guidance is very important. Especially when you have limited or expensive resources you don't want to spend that on fruitless discovery or just implement something noones cares deeply enough (or worse: goes into an undesireable direction) to get it merged before it bitrots...
<re_irc> <@j​axter184:m​atrix.org> yeah, it seems like if someone asks you that, the best thing to do is give them a small task, or even a useless task that will get them in the groove
GenTooMan has quit [Ping timeout: 250 seconds]
<re_irc> <@j​axter184:m​atrix.org> the goal being to help guide them to more autonomy in future contributions
<re_irc> <@j​axter184:m​atrix.org> if that makes any sense
<re_irc> <@t​herealprof:m​atrix.org> Never hand out useless tasks, that's quite demotivating.
<re_irc> <@j​axter184:m​atrix.org> well not like "go twiddle your thumbs", and more like "go mess around with this part of the library"
<re_irc> <@j​axter184:m​atrix.org> immediately useless, but useful in the grand scheme of things
<re_irc> <@n​ewam:m​atrix.org> The clap repo (command line argument parsing) is good at onboarding new contributors.
<re_irc> <@n​ewam:m​atrix.org> The downside is that there is quite a bit of work involved in writing up a formal description of the work to be done.
<re_irc> <@j​axter184:m​atrix.org> maybe im just making an erroneous assumption about the kinds of people that ask for stuff to do?
<re_irc> <@n​ewam:m​atrix.org> It's the whole "a problem well stated is a problem half solved" thing.
<re_irc> <@n​ewam:m​atrix.org> Stating the problem well enough to hand it off to a newcomer is 50% of the work :P
<re_irc> <@j​axter184:m​atrix.org> im just thinking theyre like college CS first years who have the interest and the time and the energy, but not necessarily the expertise or understanding of the ecosystem
GenTooMan has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> newam: If you say so. I'm super annoyed that they still haven't managed to release v3. How long has that been after they managed to distract the excellent work on `structopt` by announcing the integration? And still making a lot of fuss about it...
<re_irc> <@n​ewam:m​atrix.org> therealprof: You can be good at on-boarding newcomers while still being bad at other things 😉
<re_irc> <@d​irbaio:m​atrix.org> how dare they not release v3 for free and fast
<re_irc> <@t​herealprof:m​atrix.org> dirbaio: That is *NOT* what I said.
GenTooMan has quit [Ping timeout: 250 seconds]
<re_irc> <@t​herealprof:m​atrix.org> The best beginner tasks are those easy ones you're stoked about yourself but just couldn't get to due to being too far down the priority list...
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
dcz has quit [Ping timeout: 250 seconds]
<re_irc> <@d​avidgoodenough:m​atrix.org> adamgreig: you might want to look at the esp32-c3, risc-v and under 10 dollars.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@d​khayes117:m​atrix.org> David Goodenough: Hows the support? Last I checked it needed a compiler fork and relied heavily on ESP-IDF stuff.
<re_irc> <@b​obmcwhirter:m​atrix.org> That was the xtensa variant.
<re_irc> <@a​damgreig:m​atrix.org> ah yea it's pretty cool seeing all the esp32 risc-v stuff come along for sure
<re_irc> <@a​damgreig:m​atrix.org> though again for discovery it's really about having a single readily available hardware platform suitable for total newcomers to rust _and_ embedded, that has enough toys onboard to make it interesting
<re_irc> <@t​herealprof:m​atrix.org> Has anyone checked out https://github.com/HUST-OS/tornado-os?
<re_irc> <@t​herealprof:m​atrix.org> The Chinese is above my paygrade I'm afraid.
<re_irc> <@a​damgreig:m​atrix.org> it was linked here a day or two ago iirc
<re_irc> <@t​herealprof:m​atrix.org> Yes it was. But that didn't quite answer my question. 😉
<re_irc> <@a​damgreig:m​atrix.org> https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$eJJQeWE2Snmb4P1Ga30gcC-XzMbNSBA5jclq0N7uWYE?via=matrix.org&via=psion.agg.io&via=tchncs.de
<re_irc> <@a​damgreig:m​atrix.org> ah, indeed, I cannot read it either
<re_irc> <@a​damgreig:m​atrix.org> sounds cool tho >;o
<re_irc> <@d​irbaio:m​atrix.org> looked biefly through the code, seems like a hybrid async/threaded kernel?
<re_irc> <@d​irbaio:m​atrix.org> like, each task has a future but also its own stack? with kernelspace/userspace switching and al
<re_irc> <@n​ewam:m​atrix.org> Machine translation of their intro paragraph:
<re_irc> <@n​ewam:m​atrix.org> > The operating system kernel has gone through several major development stages, from bare metal applications, batch processing systems to multi-tasking systems, and has evolved into the mainstream threaded operating system so far. This system is based on thread switching to schedule tasks; in order to further...
<re_irc> ... improve performance, some modern programming languages ​​reuse thread resources at the application layer, and propose 协程concepts to save task scheduling overhead.
<re_irc> <@n​ewam:m​atrix.org> In this project, we propose a new kernel development idea: schedulers are shared by different resources, and coroutines are provided at the operating system level. We hope that this newly designed kernel will not only meet the ease of use of traditional kernels, but also possess the high-performance characteristics...
<re_irc> ... of proprietary kernels, "fast as the wind", hence the name hurricane kernel - tornado-os .
<re_irc> <@d​irbaio:m​atrix.org> it's not clear whether they do preemptive scheduling.. can't find anything
<re_irc> <@d​irbaio:m​atrix.org> but if it doesn't preempt then why allocate a stack per task..
<re_irc> <@n​ewam:m​atrix.org> preemptive scheduling kind of defeats the purpose of `async`, no?
<re_irc> <@d​irbaio:m​atrix.org> mostly
<re_irc> <@d​irbaio:m​atrix.org> certainly defeats the advantage of "tasks are light": in cooperative async you don't need a stack per task, because the task saves all its state inside its future
<re_irc> <@d​irbaio:m​atrix.org> if you do preempt, you do need a stack per task
<re_irc> <@d​irbaio:m​atrix.org> you may still want preemption if you want one task to have priority over others
<re_irc> <@d​irbaio:m​atrix.org> for example in embassy you can create multiple executors: a low prio one using wfe/sev and higher-prio ones using software interrupts
<re_irc> <@d​irbaio:m​atrix.org> so the higher-prio tasks can preempt lower-prio tasks, but within each prio it's all cooperative
<re_irc> <@d​irbaio:m​atrix.org> and since it's "strictly nested" preemption you can still use a single stack for all prios
<re_irc> <@d​irbaio:m​atrix.org> but yea
<re_irc> <@d​irbaio:m​atrix.org> hard to tell what the execution model of tornado-os is without english docs 🤣
<re_irc> <@d​khayes117:m​atrix.org> Im almost convinced that dirbaio is actually a brain in a jar in some scientist's lab pushing the boundaries of biological possibilities.
<re_irc> <@d​irbaio:m​atrix.org> what 😂
<re_irc> <@n​ewam:m​atrix.org> Every-time someone uninstalls IEs he gets faster.
<re_irc> <@d​khayes117:m​atrix.org> You always have 3 conversations going at once
tokomak has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<re_irc> <@j​axter184:m​atrix.org> does anyone have any experience with ethernet on the stm32?
<re_irc> <@j​axter184:m​atrix.org> i just flashed the stm_ethernet example, and it looks like it worked, but idk what to do now
<re_irc> <@j​axter184:m​atrix.org> the stm32-eth crate also seems to be like something i should be looking into
<re_irc> <@j​axter184:m​atrix.org> like how should i be testing to make sure that it works?
<re_irc> <@j​axter184:m​atrix.org> i can see the device in nmap, but pinging the ip works regardless of whats flashed on the chip
<re_irc> <@j​axter184:m​atrix.org> like i flashed a blinky at one point and still got ping responses, which seems like it shouldnt work
<re_irc> <@a​damgreig:m​atrix.org> yea, sounds like you're pinging the wrong IP in that case
<re_irc> <@a​damgreig:m​atrix.org> (or two devices have the same IP and the other one is responding, something like that)
<re_irc> <@n​ewam:m​atrix.org> ICMP (ping) can be weird, when starting low-level Ethernet things I usually try sending out junk to the UDP broadcast address, easy to capture with wireshark.
<re_irc> <@a​damgreig:m​atrix.org> the other thing to test is implement some network functionality on your firmware, like a UDP server that just responds with whatever you sent it, and then you can try that out (e.g. using netcat on linux: `nc -u <ip address> <port>` to open a console, any line you type is sent to that IP/port in a UDP packet,...
<re_irc> ... any packets received are printed)
<re_irc> <@a​damgreig:m​atrix.org> yea, that's good too, easier to get right at first
<re_irc> <@a​damgreig:m​atrix.org> but if you're pinging the IP and it's responding even with blinky firmware (or, presumably, with no firmware at all?) then something's wrong
<re_irc> <@a​damgreig:m​atrix.org> which stm32? what board is it on?
<re_irc> <@j​axter184:m​atrix.org> stm32f429 nucleo
<re_irc> <@j​axter184:m​atrix.org> i think f429ZI?
<re_irc> <@a​damgreig:m​atrix.org> cool
<re_irc> <@j​axter184:m​atrix.org> im seeing the ip disappear and reappear when i unplug and reconnect the ethernet
<re_irc> <@j​axter184:m​atrix.org> the broadcast address is 192.168.0.255, right? or am i thinking about something else?
<re_irc> <@a​damgreig:m​atrix.org> should work fine with stm32-eth then, which `stm_ethernet` example are you using?
<re_irc> <@j​axter184:m​atrix.org> uhhh i just picked a random one lol
<re_irc> <@j​axter184:m​atrix.org> just to see if it would flash
<re_irc> <@a​damgreig:m​atrix.org> right, what one?
<re_irc> <@j​axter184:m​atrix.org> mesygen
<re_irc> <@a​damgreig:m​atrix.org> the ip disasppearing and reappearing when you unplug and reconnect the ethernet is possibly the local IP of your own computer
<re_irc> <@n​ewam:m​atrix.org> 255.255.255.255 is broadcast; it's handy because you can use it without an IP
<re_irc> <@a​damgreig:m​atrix.org> (though 192.168.0.255 is also a broadcast for that subnet if you're on that subnet)
<re_irc> <@a​damgreig:m​atrix.org> but maybe you need to give your computer a static IP on the wired interface you're plugging in to, and hardcode another static IP in the same subnet to the stm32 firmware
<re_irc> <@a​damgreig:m​atrix.org> unless you know otherwise, your computer is probably not running a DHCP server that can give out IP addresses, and the STM32 firmware is probably not asking for a DHCP-assigned IP address
<re_irc> <@j​axter184:m​atrix.org> ah i see, that makes sense
<re_irc> <@j​axter184:m​atrix.org> it did seem a little fishy
<re_irc> <@j​axter184:m​atrix.org> ill try the broadcast stuff really quick
<re_irc> <@a​damgreig:m​atrix.org> but it's hard to say for sure without knowing which example you're using exactly.. you might try the stm32-eth example, it should work on the f429 nucleo board
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, you need to start your own DHCP server to auto-assign addresses if you're running some of the stm32 ethernet examples via a USB-ethernet dongle. I use that setup daily for a project
<re_irc> <@r​yan-summers:m​atrix.org> Like adam said, assign static IPs at first to make sure things are working right
<re_irc> <@r​yan-summers:m​atrix.org> Once you have that working, you can try out using smoltcp's DHCP server to auto-assign things - I use it extensively and it appears to work quite well, but you should definitely get your network stack debugged before jumping into it
<re_irc> <@d​irbaio:m​atrix.org> Smoltcp dhcp server?
<re_irc> <@r​yan-summers:m​atrix.org> Sorry, DHCP client*
<re_irc> <@d​irbaio:m​atrix.org> I was like "👀 I want that 👀"
<re_irc> <@d​irbaio:m​atrix.org> 🤣
<re_irc> <@n​ewam:m​atrix.org> What's the usecase for an embedded DHCP server? 👀
<re_irc> <@d​irbaio:m​atrix.org> +5 coolness points
<re_irc> <@n​ewam:m​atrix.org> Accurate.
<re_irc> <@d​irbaio:m​atrix.org> Jk, you could do fun stuff like having devices talk to each other without a router
<re_irc> <@d​irbaio:m​atrix.org> But I guess there's easier ways to do that
<re_irc> <@r​yan-summers:m​atrix.org> Or you know, making a router
<re_irc> <@d​irbaio:m​atrix.org> Heh thatd require multi-interface and routing in smoltcp
<re_irc> <@n​ewam:m​atrix.org> Router SoCs are pretty hard to beat for cost/power anyway :P
<re_irc> <@r​yan-summers:m​atrix.org> Just pointing out the (probably biggest) use case for an embedded DHCP server ;)
<re_irc> <@r​yan-summers:m​atrix.org> But a router SoC wouldn't be managed, would it?
<re_irc> <@r​yan-summers:m​atrix.org> I guess that's a massive "it depends"