fabic has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> I thought it was odd too
<re_irc> <@f​irefrommoonlight:m​atrix.org> What do commercial iot projects tend to use?
<re_irc> <@f​irefrommoonlight:m​atrix.org> *odd it's hard to find cortex with wifi given it's a popular and useful feature
<re_irc> <@f​irefrommoonlight:m​atrix.org> Are most IOT things embedded Linux?
<re_irc> <@9​names:m​atrix.org> Lol no, most things are either esp8266 or use the esp8266 as a separate network processor
<Darius> I have a wifi power switch that does run linux(!)
<re_irc> <@9​names:m​atrix.org> Though there are definitely a few arm9 and MIPS Linux things out there
<Darius> was pretty early on though, pre ESP8266. It has a low end Atheros chipset in it
<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
<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
<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
<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.
<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.
<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...
<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...
<re_irc> ... going on here?
<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).
<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...
<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
<re_irc> <@a​damgreig:m​atrix.org> same deal with PA13 and PA14, and also PB3
<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)
<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).
<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.
<re_irc> <@a​damgreig:m​atrix.org> which documentation?
<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
<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
<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
<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.
<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
<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?
<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
<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
<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)
<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!
<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
<re_irc> <@j​ohn_socha:m​atrix.org> adamgreig: Thank you. This will keep me busy for a while 😀
<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
<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
<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...
<re_irc> ... implicitly))
<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"
<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
<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.
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a nasty trap! Good find agg
<re_irc> <@f​irefrommoonlight:m​atrix.org> The info about it in the user manuals isn't explicit. Eg lines like:
<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
<re_irc> <@f​irefrommoonlight:m​atrix.org> pins and the internal pull-down on PA14 pin are activated
<re_irc> <@f​irefrommoonlight:m​atrix.org> And `PA15(JTDI)` instead of juse PA15 in the definition table
<re_irc> <@f​irefrommoonlight:m​atrix.org> The RM< as you pt out, is more explicity:
<re_irc> <@f​irefrommoonlight:m​atrix.org> > To use the serial wire DP to release some GPIOs, the user software must change the GPIO
<re_irc> <@f​irefrommoonlight:m​atrix.org> (PA15, PB3 and PB4) configuration mode in the GPIO_MODER register.This releases
<re_irc> <@f​irefrommoonlight:m​atrix.org> PA15, PB3 and PB4 which now become available as GPIOs
<re_irc> <@d​ngrs:m​atrix.org> john_socha: what I often find helpful is image search for "<your board> pinout"
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, I'm apparently using all 2 of those trap pins, as pull-up inputs
<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/
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think I'm not hitting these issues since my HAL code explicitly sets mode on init
<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!
<re_irc> <@d​ngrs:m​atrix.org> yw, I guess :D
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 258 seconds]
fabic has quit [Ping timeout: 240 seconds]
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmmm.. I wonder if these gpio traps could be why the debugger disconnects randomly...
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
<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
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 255 seconds]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
tokomak has joined #rust-embedded
fabic has joined #rust-embedded
<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!
<re_irc> <@a​damgreig:m​atrix.org> hopefully that will be the last 0.6 release
<re_irc> <@t​herealprof:m​atrix.org> john_socha: Those images are "stolen" from https://os.mbed.com/platforms/ST-Nucleo-F103RB/
<re_irc> <@t​herealprof:m​atrix.org> The Mbed pages are actually a great resource for a lot of board pinouts and other information.
<re_irc> <@m​arcuss2:t​edomum.net> I have tried to get the HD44780-driver library working with avr-hla
<re_irc> <@m​arcuss2:t​edomum.net> Turns out the pins don't implement OutputPin Trait, so I had to create a wrapper.
<re_irc> <@m​arcuss2:t​edomum.net> Should I add the implementation to the hal?
<re_irc> <@m​arcuss2:t​edomum.net> rahix
<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 :)
<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...
<re_irc> ... fundamentals, and a bit of time pitching the tool we want to build.
<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!
<re_irc> <@j​amesmunns:m​atrix.org> If you can't tell, this is a topic I have *opinions* about :D
<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.
<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.)
<re_irc> <@j​amesmunns:m​atrix.org> `</plug>`
<re_irc> <@e​ldruin:m​atrix.org> Great initiative! You may also be interested in supporting IEC62304 for medical device software
fabic has quit [Remote host closed the connection]
creich_ has joined #rust-embedded
mightypork_ has joined #rust-embedded
fabic has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
mightypork has quit [Ping timeout: 255 seconds]
creich has quit [Ping timeout: 255 seconds]
cr1901 has quit [Ping timeout: 255 seconds]
bpye has quit [Ping timeout: 255 seconds]
cr1901 has joined #rust-embedded
<re_irc> <@j​ordens:m​atrix.org> https://godbolt.org/z/7oqW15Ecd Anybody know why two of these don't tailcall?
<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
<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.
<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"
<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.
<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.
<re_irc> <@r​yan-summers:m​atrix.org> Also +1, there aren't many great requirement tracing tools out there
<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
<re_irc> <@j​amesmunns:m​atrix.org> I have more opinions than I have time to share at the moment, unfortunately :D
<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.
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Dude. This is the sort of thing the rust embedded community needs. Thank you
<edm> +1 jamesmunns, am a colleague and friend of adam’s and this is something that will be useful to us
<edm> i will email you seperately
<re_irc> <@j​amesmunns:m​atrix.org> Sounds good!
<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 :)
<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?
<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)
<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.
<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.
<re_irc> <@a​lmindor:m​atrix.org> what's the full name of the channel? gd32v-rust ?
<re_irc> <@j​amesmunns:m​atrix.org> #gd32v-rust:matrix.org
<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
<re_irc> <@j​amesmunns:m​atrix.org> I think Adafruit has a QT Py RP2040 too
<re_irc> <@j​amesmunns:m​atrix.org> (basically same form factor, though I think the XIAO came first)
<re_irc> <@t​herealprof:m​atrix.org> The formfactor is great... plus USB-C.
<re_irc> <@d​irbaio:m​atrix.org> USB C yay
<re_irc> <@d​irbaio:m​atrix.org> Can't wait for microUSB to die :D
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've even been using USB-C as power for embedded projects without data
<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
<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
tokomak has joined #rust-embedded
fabic has joined #rust-embedded