00:31 <re_irc> <@f​irefrommoonlight:m​atrix.org> I thought it was odd too

00:31 <re_irc> <@f​irefrommoonlight:m​atrix.org> What do commercial iot projects tend to use?

00:32 <re_irc> <@f​irefrommoonlight:m​atrix.org> *odd it's hard to find cortex with wifi given it's a popular and useful feature

00:33 <re_irc> <@f​irefrommoonlight:m​atrix.org> Are most IOT things embedded Linux?

00:38 <re_irc> <@9​names:m​atrix.org> Lol no, most things are either esp8266 or use the esp8266 as a separate network processor

00:39 <Darius> I have a wifi power switch that does run linux(!)

00:39 <re_irc> <@9​names:m​atrix.org> Though there are definitely a few arm9 and MIPS Linux things out there

00:39 <Darius> was pretty early on though, pre ESP8266. It has a low end Atheros chipset in it

00:41 <Darius> for most IoT stuff the ESP is pretty hard to beat - very cheap and all in one. Good ecosystem if you just want to make stuff

00:46 <re_irc> <@t​halesfragoso:m​atrix.org> Darius: Sad that you don't have any control over the wifi stack, including if it dynamic allocates

00:47 <Darius> sure, but for most people that is a non issue, or even a feature - writing your own wifi stack is a pretty daunting exercise

00:52 <re_irc> <@9​names:m​atrix.org> And if you're using it as a co-processor you don't care about the implementation anyway.

00:52 <re_irc> <@9​names:m​atrix.org> But yeah, that's why I'm generally excited about bl602/esp32-c3, they're the same price as esp8285, aren't Harvard machines and already have better toolchain support.

00:53 <re_irc> <@j​ohn_socha:m​atrix.org> Hi. I'm new to embedded rust (but not to embedded C++) and am trying to understand how I can determine what I can do with different pins. I'm using an STM32F103RB Nucleo board with the stm32f1xx_hal crate. I'm trying to set a pint to be an input pull-up pin. If I use gpioa.pa1.into_pull_up_input, it works...

00:53 <re_irc> ... fine. But when I try using pa15 instead, I get two messages: "method cannot be called on `PA15<Debugger>` due to unsatisfied trait bounds" and then "doesn't satisfy `Debugger: stm32f1xx_hal::gpio::Active`". I've noticed I get the same message for PA13-15, but it seems to be fine for pins with lower numbers. Can someone explain what's...

00:53 <re_irc> ... going on here?

00:54 <cyrozap> MediaTek made some 192 MH Cortex-M4F IoT WiFi chips a while back (used on the LinkIt 7697: https://www.seeedstudio.com/LinkIt-7697-p-2818.html), but their SDK was kind of a mess, and IIRC was mostly just "source available" and not truly FOSS (never mind that the firmware for the Andes N9 core that actually handled the WiFi protocol is a closed blob).

00:54 <re_irc> <@a​damgreig:m​atrix.org> john_socha: 👋 the document you really want is RM0008 from ST, which is the reference manual for the STM32F103 series, and tells you all about all the functions of all the pins, but...

00:55 <re_irc> <@a​damgreig:m​atrix.org> ...in this particular case the issue is that PA15 is by default used as a debugger pin (the JTDI signal when using JTAG), so when the chip turns on it's already configured in that mode

00:55 <re_irc> <@a​damgreig:m​atrix.org> same deal with PA13 and PA14, and also PB3

00:56 <re_irc> <@a​damgreig:m​atrix.org> (in RM0009, this is section 31.4.1, and 31.4.2 talks about how you can reconfigure them to use as general purpose i/o, but if you do that it becomes trickier to debug/reprogram the chip)

00:56 <cyrozap> And now I think that product line (MT7687F, MT7697, MT7697D) might have been discontinued (or at least the LinkIt 7697, the only dev board using that chip, has been out of stock for a while now).

00:57 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: That's what I guessed. How can I determine this without trial and error with compiler warnings? I looked at the documentation for both PA1 and PA15 and couldn't see anything that would indicate PA15 is different.

00:57 <re_irc> <@a​damgreig:m​atrix.org> which documentation?

00:58 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: https://docs.rs/stm32f1xx-hal/0.7.0/stm32f1xx_hal/gpio/gpioa/struct.PA15.html

00:59 <re_irc> <@a​damgreig:m​atrix.org> https://docs.rs/stm32f1xx-hal/0.7.0/stm32f1xx_hal/gpio/index.html#accessing-pa15-pb3-and-pb14

00:59 <re_irc> <@a​damgreig:m​atrix.org> (it's often useful to have ST's documentation for the chip open too, so RM0009 and also the datasheet at https://www.st.com/resource/en/datasheet/stm32f103rb.pdf

01:00 <re_irc> <@a​damgreig:m​atrix.org> but it's quite an overwhelming about of stuff to read until you already know where everything you need is

01:01 <re_irc> <@a​damgreig:m​atrix.org> the datasheet has the pin assignments, so for example when you search PA15 there you'll see its main function is "JTDI", and not really many clues as to what that means, the rest of the details are in the (longer) reference manual

01:02 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Thanks. Yes, that's what I noticed right away from the two embedded Rust books. They skipped over a lot of this stuff.

01:02 <re_irc> <@a​damgreig:m​atrix.org> unfortunately this is just for the f103, and it's the same or more again for pretty much every other of the hundreds of STM32s, and then the many other families of popular cortex-m microcontrollers

01:03 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Is there a pattern of how you might find these types of limitations for different variations? Or is it pretty much up to whoever wrote the hal?

01:04 <re_irc> <@a​damgreig:m​atrix.org> for me the answer is generally "read the reference manual" rather than looking to the HAL, but otherwise yea, it's up to whoever wrote the HAL

01:04 <re_irc> <@a​damgreig:m​atrix.org> often the pins are generated somewhat automatically, so it's not necessarily easy to put an extra comment on just some pins, though perhaps it's possible here; the section I linked in the gpio module at least points you to the function to call to release those pins for your own use

01:05 <re_irc> <@a​damgreig:m​atrix.org> (for example here, that PA15 struct is generated by this macro call: https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/gpio.rs#L1253 so it has to be more or less uniform with the other pins)

01:07 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Ah ha! That's really useful. That looks like it will help answer some of my question. Thanks!

01:07 <re_irc> <@a​damgreig:m​atrix.org> you can also see this PR where this debugger-pin functionality was added: https://github.com/stm32-rs/stm32f1xx-hal/pull/79

01:09 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Thank you. This will keep me busy for a while 😀

01:09 <re_irc> <@a​damgreig:m​atrix.org> it sounds like the error message could have done a better job pointing you towards that part of the docs, though

01:09 <re_irc> <@a​damgreig:m​atrix.org> hah, no problem! please don't hesitate to ask any other questions, there's also #stm32-rs:matrix.org for stm32-specific chat too

01:10 <re_irc> <@a​damgreig:m​atrix.org> (I think it's worth noting that this sort of compiler-assisted pin checking is one of the features people like about rust - you can imagine with a typical C library this would have silently not worked (if it configured the GPIO but didn't disable JTAG), or silently broken debugger access (if it disabled JTAG...

01:10 <re_irc> ... implicitly))

01:10 <re_irc> <@a​damgreig:m​atrix.org> and in either case would probably have been a lot trickier to debug "why isn't this pin working" than "why am I getting an error only on PA15 talking about Debugger"

01:11 <re_irc> <@a​damgreig:m​atrix.org> though, luckily, those same pins are used for debug on basically all stm32s, even though the methods to disable them differ, so whenever someone has a problem with those specific pins it's usually this problem

01:15 <re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Yup, that's something I figured out last night and very much appreciate. What I couldn't figure out is how to find out before compiling, and you answered that question for me.

01:21 <re_irc> <@f​irefrommoonlight:m​atrix.org> That's a nasty trap! Good find agg

01:23 <re_irc> <@f​irefrommoonlight:m​atrix.org> The info about it in the user manuals isn't explicit. Eg lines like:

01:23 <re_irc> <@f​irefrommoonlight:m​atrix.org> > After reset, these pins are configured as JTAG/SW debug alternate functions, and the internal pull-up on PA15, PA13, PB4

01:23 <re_irc> <@f​irefrommoonlight:m​atrix.org> pins and the internal pull-down on PA14 pin are activated

01:23 <re_irc> <@f​irefrommoonlight:m​atrix.org> And `PA15(JTDI)` instead of juse PA15 in the definition table

01:24 <re_irc> <@f​irefrommoonlight:m​atrix.org> The RM< as you pt out, is more explicity:

01:24 <re_irc> <@f​irefrommoonlight:m​atrix.org> > To use the serial wire DP to release some GPIOs, the user software must change the GPIO

01:24 <re_irc> <@f​irefrommoonlight:m​atrix.org> (PA15, PB3 and PB4) configuration mode in the GPIO_MODER register.This releases

01:24 <re_irc> <@f​irefrommoonlight:m​atrix.org> PA15, PB3 and PB4 which now become available as GPIOs

01:25 <re_irc> <@d​ngrs:m​atrix.org> john_socha: what I often find helpful is image search for "<your board> pinout"

01:26 <re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, I'm apparently using all 2 of those trap pins, as pull-up inputs

01:26 <re_irc> <@d​ngrs:m​atrix.org> john_socha: this one looks useful: https://www.b4x.com/android/forum/threads/how-to-implement-stm32-into-b4r.68034/

01:27 <re_irc> <@f​irefrommoonlight:m​atrix.org> I think I'm not hitting these issues since my HAL code explicitly sets mode on init

01:29 <re_irc> <@j​ohn_socha:m​atrix.org> dngrs (spookyvision@github): I wasn't looking for that. But...that's much nicer than what I was working from. Thank you!

01:29 <re_irc> <@d​ngrs:m​atrix.org> yw, I guess :D

01:52 <re_irc> <@f​irefrommoonlight:m​atrix.org> Hmmm.. I wonder if these gpio traps could be why the debugger disconnects randomly...

03:51 <re_irc> <@b​urrbull:m​atrix.org> john_socha: For PA15, PB3 and PB4 are special pins. You need to disable jtag first. https://github.com/stm32-rs/stm32f1xx-hal/blob/master/examples/nojtag.rs

11:01 <re_irc> <@a​damgreig:m​atrix.org> hi cortex-m-rt users, just published 0.6.15 with a few backported fixes from the development branch, changelog is here: https://github.com/rust-embedded/cortex-m-rt/blob/v0.6.x/CHANGELOG.md#backport-release-v0615---2021-07-12 but nothing especially exciting, please shout if anything seems to break though!

11:02 <re_irc> <@a​damgreig:m​atrix.org> hopefully that will be the last 0.6 release

11:36 <re_irc> <@t​herealprof:m​atrix.org> john_socha: Those images are "stolen" from https://os.mbed.com/platforms/ST-Nucleo-F103RB/

11:42 <re_irc> <@t​herealprof:m​atrix.org> The Mbed pages are actually a great resource for a lot of board pinouts and other information.

11:43 <re_irc> <@m​arcuss2:t​edomum.net> I have tried to get the HD44780-driver library working with avr-hla

11:44 <re_irc> <@m​arcuss2:t​edomum.net> Turns out the pins don't implement OutputPin Trait, so I had to create a wrapper.

11:44 <re_irc> <@m​arcuss2:t​edomum.net> Should I add the implementation to the hal?

11:44 <re_irc> <@m​arcuss2:t​edomum.net> rahix

11:57 <re_irc> <@r​ahix:m​atrix.org> marcuss2: That must have gone missing during the refactor... If you want to take care of it, please, go ahead :)

12:25 <re_irc> <@j​amesmunns:m​atrix.org> Misc/off-topic-ish plug: but I'm gunna give a webinar on requirement management and traceability (which lots of you probably have to deal with in your day jobs), and share some ideas Ferrous has about how to make a better, developer-focused, tool/workflow. I'll spend most of the time talking about the...

12:25 <re_irc> ... fundamentals, and a bit of time pitching the tool we want to build.

12:25 <re_irc> <@j​amesmunns:m​atrix.org> Tweet is here: https://twitter.com/bitshiftmask/status/1418178738215391232, if you're interested, I'd appreciate an email at `alm [at] ferrous-systems.com` if you/your company would want to attend!

12:25 <re_irc> <@j​amesmunns:m​atrix.org> If you can't tell, this is a topic I have *opinions* about :D

12:27 <re_irc> <@j​amesmunns:m​atrix.org> Spoiler: we want to build this tool so we can use it for https://ferrous-systems.com/ferrocene/, and embedded projects written in Rust that need to meet ISO26262/IEC61508/DO-178 standards, where these kinds of tools are required.

12:27 <re_irc> <@j​amesmunns:m​atrix.org> (BUT: we want to build a tool that also doesn't suck, and is OSS, so it could be used in *any* rust project that ends up decently complex.)

12:28 <re_irc> <@j​amesmunns:m​atrix.org> `</plug>`

13:13 <re_irc> <@e​ldruin:m​atrix.org> Great initiative! You may also be interested in supporting IEC62304 for medical device software

13:50 <re_irc> <@j​ordens:m​atrix.org> https://godbolt.org/z/7oqW15Ecd Anybody know why two of these don't tailcall?

13:53 <re_irc> <@r​yan-summers:m​atrix.org> eldruin: I am constantly working with 62304 and I imagine the traceability is nearly identical. Medical devices are a bit on-their-own, but the general process is just a traceability from high level -> low level requirements, which I imagine is pretty universal

13:56 <re_irc> <@j​amesmunns:m​atrix.org> Yeah, I'm hoping (based on my experience with 61508 and DO-178, and familiarity with 62304), that what we have in mind should fulfull those general objectives.

13:57 <re_irc> <@j​amesmunns:m​atrix.org> Next steps are "working tool, usable by developers, and that makes requirements visible to other stakeholders", then probably "GUI tool that makes requirement tracking/etc. accessible to work with for non-developers", way before we get to "pre qualified for official use in safety critical workflows"

13:57 <re_irc> <@j​amesmunns:m​atrix.org> though, we'll be BUILDING it to be suitable to produce all the qualification evidence you typically need (traceability verification, exception reports, etc.), so you could probably self-write a safety justification for that.

13:58 <re_irc> <@j​amesmunns:m​atrix.org> and it's out of the can-directly-cause-errors part of tool qual evaluation in most safety standards, so mixing in a little right-before-the-release manual review is likely to be enough, IMO.

13:58 <re_irc> <@r​yan-summers:m​atrix.org> Also +1, there aren't many great requirement tracing tools out there

13:58 <re_irc> <@r​yan-summers:m​atrix.org> At least the ones I've seen in use seem to be completely lacking in some details

13:59 <re_irc> <@j​amesmunns:m​atrix.org> I have more opinions than I have time to share at the moment, unfortunately :D

14:00 <re_irc> <@j​amesmunns:m​atrix.org> If anyone wants to see the (informal, mostly implementation focused) design doc/notes we have around this, let me know, but fair warning, it's not a great "pitch doc" for non-programmer stakeholders ATM.

16:26 <re_irc> <@f​irefrommoonlight:m​atrix.org> Dude. This is the sort of thing the rust embedded community needs. Thank you

16:30 <edm> +1 jamesmunns, am a colleague and friend of adam’s and this is something that will be useful to us

16:30 <edm> i will email you seperately

16:32 <re_irc> <@j​amesmunns:m​atrix.org> Sounds good!

16:32 <re_irc> <@j​amesmunns:m​atrix.org> firefrommoonlight: For now it's just a pitch. If we don't get enough interest, I'll publish all of my notes so maybe someone else can pick it up :)

16:40 <re_irc> <@k​aeso:m​atrix.org> jacobrosenthal: wrt https://github.com/jacobrosenthal/hf2-rs/issues/41, can you maybe show me the `lsusb` output of a proper hf2 bootloader?

16:49 <re_irc> <@k​aeso:m​atrix.org> jacobrosenthal: also, I briefly skimmed through the sources of the bootloader, and I didn't seen any reference to an HID mode (not even behind a build knob)

16:54 <re_irc> <@d​khayes117:m​atrix.org> almindor should join the gd32v rust channel, it wont let me send an invite. I got my risc-v pmp PR fully functional, just gotta clean up the code some and possibly re-base a bit. I'm pretty happy with what I have though. I haven't pushed to the main branch yet. Probably will do so tonight or tomorrow.

17:10 <re_irc> <@a​lmindor:m​atrix.org> > almindor should join the gd32v rust channel, it wont let me send an invite. I got my risc-v pmp PR fully functional, just gotta clean up the code some and possibly re-base a bit. I'm pretty happy with what I have though. I haven't pushed to the main branch yet. Probably will do so tonight or tomorrow.

17:10 <re_irc> <@a​lmindor:m​atrix.org> what's the full name of the channel? gd32v-rust ?

17:22 <re_irc> <@j​amesmunns:m​atrix.org> #gd32v-rust:matrix.org

17:58 <re_irc> <@t​herealprof:m​atrix.org> Oooh... https://www.seeedstudio.com/XIAO-RP2040-v1-0-p-5026.html?utm_source=mailchimp&utm_medium=edm&utm_campaign=bazaar_0722&ct=t()&mc_cid=214a84ebe5&mc_eid=4899818630

18:11 <re_irc> <@j​amesmunns:m​atrix.org> I think Adafruit has a QT Py RP2040 too

18:12 <re_irc> <@j​amesmunns:m​atrix.org> (basically same form factor, though I think the XIAO came first)

18:36 <re_irc> <@t​herealprof:m​atrix.org> The formfactor is great... plus USB-C.

19:18 <re_irc> <@d​irbaio:m​atrix.org> USB C yay

19:19 <re_irc> <@d​irbaio:m​atrix.org> Can't wait for microUSB to die :D

19:43 <re_irc> <@f​irefrommoonlight:m​atrix.org> I've even been using USB-C as power for embedded projects without data

19:44 <re_irc> <@f​irefrommoonlight:m​atrix.org> It's a common format with small footprint, and the cables and wall-adapters are cheap, compact, and readily available. And the reversible quality

19:44 <re_irc> <@f​irefrommoonlight:m​atrix.org> There are even THT models (I don't think they have full 3.0 speed though) that are easy to solder and inspect