ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
HumanGeek has quit [Remote host closed the connection]
HumanGeek has joined #rust-embedded
Darius has quit [Quit: Bye]
Darius has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]> Today’s thought: HALs should distinguish between GPIO drivers and Pin Control drivers (https://docs.zephyrproject.org/3.0.0/guides/pinctrl/index.html)
<thejpster[m]> Because GPIO is just one function you could make a Pin do.
<thejpster[m]> Further I’m wondering if a future Embedded-HAL should do more to harmonise how all the various HAL implementations do Pin Control.
FreeKill[m] has joined #rust-embedded
<FreeKill[m]> Does anyone happen to know if there's a Rust library for parsing linker map files? I've not found anything just searching
<dirbaio[m]> are those even supposed to be machine-parseable?
<dirbaio[m]> with stuff like symbol names being able to contain spaces etc..?
<dirbaio[m]> maybe you can parse the output ELF instead (assuming the map file has no info that's not in the ELF?)
<FreeKill[m]> It does, I think. The map contains the memory regions defined in the linker script :(
<FreeKill[m]> My colleague was frustrated with the lack of a tool that could succinctly say "here are your memory regions, here's how full they each are, and here's what's in them"
<FreeKill[m]> Which is really nicely displayed in STM32CubeIDE. Every other tool we've found is much less pleasant
<dirbaio[m]> ohhhh... then I dunno
<FreeKill[m]> that's alright. It won't be hard to write something just for extracting that one thing
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> Does size (arm-none-eabi-size or cargo size from cargo-binutils) with -B do anything useful for you?
<adamgreig[m]> It will show every section and how big they are, but not what's in them (but maybe objdump can do that, but it's basically just the linker map file at that point)
<FreeKill[m]> I haven't tried those! I can report back
<FreeKill[m]> But it's not (only) sections I'm after, but also memory regions
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> <thejpster[m]> "Today’s thought: HALs should..." <- Do you have an example API? I'm having a tough time understanding the application from the article.
<firefrommoonligh> * the article. I'm having a tough time with the article in general. I gather the distinction is `Pin control` is defined as configuration, while `GPIO` is a subset of high vs lowo state.
<firefrommoonligh> * Do you have an example API? I'm having a tough time understanding the application from the article. I'm having a tough time with the article in general. I gather the distinction is `Pin control` is defined as configuration, while `GPIO` is a subset of high vs lowo state. Would this be an example of GPIO... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WnVShFNvUheUZoFHBjkAsPLu>)
<firefrommoonligh> Where `Pin` control is the configuration of these as output GPIO pins?
<firefrommoonligh> ```
<firefrommoonligh> * Do you have an example API? I'm having a tough time understanding the application from the article. I gather the distinction is `Pin control` is defined as configuration, while `GPIO` is a subset of high vs low state. Would this be an example of GPIO, and not pin control?:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ekHtQqDSiJNqTttGJQCyiAuB>)
<adinack[m]> <thejpster[m]> "Further I’m wondering if a..." <- isn’t this kind of what embassy did? like if you look at the blink example for an stm32 and an nrf52 the way the gpio is configured is like *basically* the same.
<adinack[m]> also on that note, embedded hal has the pwmpin trait, but no complementary pwm pin trait, so every hal does complementary pwm completely differently, would be nice if the interface was standardized
<firefrommoonligh> In the context of that, the article makes more sense: IMO PWM makes more sense as a timer setting than a pin setting.
<firefrommoonligh> * > also on that note, embedded hal has the pwmpin trait, but no complementary pwm pin trait, so every hal does complementary pwm completely differently, would be nice if the interface was standardized
<firefrommoonligh> In this context, the article makes more sense: IMO PWM makes more sense as a timer setting than a pin setting.
starblue has quit [Ping timeout: 255 seconds]
<adinack[m]> yeah idk anything about that separation of those two things i was just referring to what he said about standardizing it
<firefrommoonligh> Gotcha
IlPalazzo-ojiisa has quit [Remote host closed the connection]
diondokter[m] has joined #rust-embedded
<diondokter[m]> Not really Rust related, but has anybody here got an idea what's going on with my RS485 transceiver?
<diondokter[m]> I've rechecked all pins and they should be fine. Power supply is nice, stable and of the proper 3v3 voltage.
<diondokter[m]> But for some reason there's this ~200KHz block signal on everything. The A output is also at practically 0 volts
<diondokter[m]> * Not really Rust related, but has anybody here got an idea what's going on with my RS485 transceiver?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DCQHmrJkFIGpbrbdooJgRpWV>)
<diondokter[m]> * Not really Rust related, but has anybody here got an idea what's going on with my RS485 transceiver?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/miEhzvXjUnRWhOMFSOIKtihF>)
<thejpster[m]> What is the scope showing? Is there 200 kHz on the UART output of your MCU? Is the pinout right? Is the chip hot? Is the DE pin doing what you expect? Does a second board do the same thing?
<thejpster[m]> Are there shorts on the pcb? Or on the cable?
danielb[m] has joined #rust-embedded
<danielb[m]> do you happen to have a high-power, 200kHz noise generating circuit connected?
<diondokter[m]> danielb[m]: Nope, just the MCU with internal clock
<thejpster[m]> Did you ground your scope correctly? Can you see a siggen correctly?
<diondokter[m]> <thejpster[m]> "What is the scope showing? Is..." <- 1. I colored the schematic in the same colors to show which pins they're connected to.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XWzqWthTPkzaJWdjvMTSGiNz>)
<diondokter[m]> <thejpster[m]> "Are there shorts on the pcb..." <- 7. With a multimeter I've checked for shorts and everything seems to be fine.
<danielb[m]> how do you power the MCU? what is the reference ground you use to probe the circuit? using the same ground, what happens if you measure the 3V3?
duderonomy has quit [Ping timeout: 256 seconds]
<danielb[m]> * same ground point, what
<danielb[m]> do you have the termination resistor fitted?
<diondokter[m]> <thejpster[m]> "Did you ground your scope..." <- 8. Probes share a ground with the board through the little clip cable. If you mean if the scope is hooked to net earth, then no. I live in an old house with earth only available in the bathroom and kitchen
<diondokter[m]> 9. Yes, looks like the normal block wave signal you'd expect
<diondokter[m]> danielb[m]: Power is through a lab supply @12v through an LDO to 3v3. Refence ground is the `-` terminal on the board which is the only ground on the board. The 3v3 look very stable on the scope
<diondokter[m]> It's also not LED interference. Tried switching my lights off an nothing changed :P
<diondokter[m]> It also persists when I unplug my debug probe
<diondokter[m]> s/an/and/
<danielb[m]> I was wondering about those but if you can measure a smooth enough 3V3 then your problem is at least not that arcane
<diondokter[m]> Haha yeah, I tried checking all the usual stuff, but I can't find anything weird... Pretty frustrating lol
<thejpster[m]> If you put the MCU in Reset, pull the DE pin appropriately and drive the bus manually, does the pin from the txcvr to the mcu look ok?
<diondokter[m]> Worth a try I guess
<thejpster[m]> Oh wait. Did you accidentally enable Consumer Infrared or IrDA mode?
<diondokter[m]> No, just using the embassy uart new_with_de. Doesn't do anything special
<thejpster[m]> I might be tempted to lift the txcvr until you get good MCU outputs.
<diondokter[m]> Results are the same if I drive the DE pin from the MCU manually
<thejpster[m]> To save lifting the txcvr can you put the code on a dev kit or breakout board?
<diondokter[m]> I don't have the same mcu as dev board, but I do have STMs of the same generation
<thejpster[m]> Ah. Do you definitely have the right STM32 selected?
<diondokter[m]> Yep
<danielb[m]> stupid question, but is the IC soldered in the correct orientation?
<diondokter[m]> Unless mouser sent me the wrong ones ;P
<thejpster[m]> Not impossible
<diondokter[m]> Yep, both MCU and transceiver
<thejpster[m]> I’d go back to first principles. Flash the cpu with the most basic wfi loop. Then use a debugger to poke the registers.
<thejpster[m]> Write a Python script to put the pins in GPIO mode and slowly set them high or low.
<thejpster[m]> That’ll tell you the pin out is ok. You can read the input pins this way too.
<thejpster[m]> Drive the bus and observe the R line moving.
<thejpster[m]> If that all works, it’s your firmware.
<thejpster[m]> And I still suspect CIR or IrDA mode.
<diondokter[m]> Yeah, that would be a pretty sane approach
<thejpster[m]> It takes time, but less time than spinning in circles for a week. Which I have done before.
<diondokter[m]> Haha yep
<thejpster[m]> First firmware is always PCB test firmware.
<thejpster[m]> And ideally off-chip firmware.
<diondokter[m]> At least it's just a hobby project, so no angry stakeholders :P
<thejpster[m]> Best of luck with it!
<diondokter[m]> Thanks for the help!
<thejpster[m]> I plugged in an audio Jack into my project and the board reset…
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]> fwiw, 200khz makes me think "switch mode power supply noise". Surprising if you are using an LDO (tho 12v to 3v3 is a big drop for that, but I'm guessing you aren't using much current). Do you have a cable plugged into the rj12 jack while measuring?
<diondokter[m]> JamesMunns[m]: No, but the jumper for the terminating resister is bridged (connected)
<diondokter[m]> Not a lot of current no
<diondokter[m]> Basically just the MCU
<diondokter[m]> And transceiver
<JamesMunns[m]> That should be fine, "long cable" is just "a antenna", which is attached to your ground plane
<JamesMunns[m]> s/a/an/
<JamesMunns[m]> Was wondering if it was on/around something else noisy :)
<JamesMunns[m]> But yeah 1v PTP ringing is pretty gnarly
<diondokter[m]> Err wait, I did have the (short) cable plugged in. Just the other side was unpowered. But the weirdness remains when I unplug it
<diondokter[m]> Hmmm though it now manages to drive the A somewhat
<JamesMunns[m]> Also really sure you got the chip on the left and not the right?
<diondokter[m]> Good point. Let me double check
starblue has joined #rust-embedded
<diondokter[m]> There is no 'V' on the package, so I probably have the correct left one. But there are other markings and the datasheet doesn't mention what they mean
<JamesMunns[m]> Did you order the parts from digikey or whatever?
<diondokter[m]> mouser
<danielb[m]> do you have extras? can you swap it?
<JamesMunns[m]> The "V" Version should definitely say "V"
<diondokter[m]> This is what it says on the packaging: 't1449 ti 2bh zsw2g4'
<diondokter[m]> If I google it nothing comes up
<diondokter[m]> danielb[m]: I do. I ordered 3 and got 4 which now makes me suspicious
<firefrommoonligh> GL! This sort of thing is always a little frustrating to troubleshoot
<diondokter[m]> The order was correct and the bag it came in says the correct component number too
<JamesMunns[m]> If you lift it, I'd definitely scope the inputs with no chip to see if the ringing is still there before you replace it
<diondokter[m]> Yeah, that's probably the best first option to check
<JamesMunns[m]> But yeah, rs485 xcvrs are "dumb", so you could just strobe the pins as gpios at 1hz or whatever to see what it does. It should be super stable.
<JamesMunns[m]> (on the MCU side)
<JamesMunns[m]> (before you lift the chip)
<diondokter[m]> Already tried that. Was there too
<JamesMunns[m]> But if it looks all wiggly at 1hz, something with the board or parts is weird, and if you lift the chips and it still wiggles, something else on the board is very wrong
<JamesMunns[m]> s/chips/chip/
<diondokter[m]> Chip has been lifted. Signals from the MCU look super clean 🙈
<diondokter[m]> At least now I can try a replacement chip :P
<JamesMunns[m]> Did you design the board? If so do you have the kicad project somewhere?
<diondokter[m]> Yes
<diondokter[m]> WAIT HOLD UP
<diondokter[m]> How do I know what pin 1 is?
<diondokter[m]> Is it like this?
K900 has joined #rust-embedded
<K900> There's usually a marker somewhere around the pin itself
<diondokter[m]> If so, I've done that wrong. There's a marking on the backside that points to a different pin
IAmnesia[m] has joined #rust-embedded
<IAmnesia[m]> you count counter-clockwise. I suppose the line marks "up"
<K900> Like a small dot or an arrow
<IAmnesia[m]> it'll usually be a dot
<diondokter[m]> Does a dot at the bottom count?
<IAmnesia[m]> the dot marks the top, but yes
<diondokter[m]> With 'dot' I mean the plastic molding hole
<diondokter[m]> There's no 'dimple' that I would expect
<diondokter[m]> This is the bottom. I guess this doesn't mark pin 1...
<IAmnesia[m]> oh yeah, my bad, I misunderstood
<IAmnesia[m]> what does the top side look like?
<K900> Uhh, got a more focused picture maybe?
<IAmnesia[m]> enahnce!
<K900> Top left looks like it might be it but hard to see
<IAmnesia[m]> pretty sure the line marks the top, so bottom left would be pin 1
<diondokter[m]> Making a better photo is hard
<diondokter[m]> I've marked the line white here and red marks where the marking at the bottom is
<K900> Top right looks completely blank to me
<K900> The bottom marking is very likely not it
<diondokter[m]> Yeah, top right is blanc
<diondokter[m]> Ok, then I think I had the chip rotated wrong lol
<K900> My money is on top left or bottom left
<diondokter[m]> Only option then is bottom left
<danielb[m]> one has to appreciate datasheets that don't mark pin1 unambiguously :D my favourite is when they mark from "bottom view" instead of top
<IAmnesia[m]> this confirms
<K900> Actually wait no
<K900> It can't be top left
<K900> Because then it would have to go clockwise
<K900> To make any sense
<IAmnesia[m]> it's not common, but the band seems to be way to mark it
<diondokter[m]> Dang
<diondokter[m]> Ok, let's try it!
<K900> Like if it's top left it would be 6781 / 2345
<K900> Which I sincerely hope no vendor is actually insane enough to do
<diondokter[m]> No it's gotta be bottom left or top right. I had it rotated so top right landed on pad 1
<K900> Then it's very likely the other one
<IAmnesia[m]> also, usually, if you can read the text, pin 1 is on bottom left
<IAmnesia[m]> I dunno, the band seems to be a less common standard, but it's definitely there to mark the pin 1 row
meptl[m] has joined #rust-embedded
<meptl[m]> I'm having issues creating a USB device via keyberon with my WeAct Black Pill (STM32F411CEU6). I'm using a minimal usb/led blink example:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/sIyIHhPMFTOgWtlLRZSSiaNN>)
<danielb[m]> <diondokter[m]> "image.png" <- [package drawing](https://www.ti.com/lit/ml/msoi002k/msoi002k.pdf?ts=1693079890972&ref_url=https%253A%252F%252Fwww.ti.com%252Fpackaging%252Fdocs%252Fsearchtipackages.tsp%253FpackageName%253DSO) (identified from family/package name + pin count) seems to suggest opposite from red dot here (bottom left)
<danielb[m]> danielb[m]: if I can see it correctly and this side is steeper
<danielb[m]> * this side's, * beveling is steeper
<diondokter[m]> ITS WORKING!
<IAmnesia[m]> \o/
<diondokter[m]> Thanks y'all for picking your brains!
<diondokter[m]> Dang, unclear markings are the devil!
<danielb[m]> nice
<danielb[m]> so which corner is pin 1 for real? 🤣
<diondokter[m]> My top side picture bottom left.
<diondokter[m]> So the text is up and then the bottom of the left line marking
<diondokter[m]> <diondokter[m]> "SOIC8.jpg" <- So like this picture
<danielb[m]> nice
<diondokter[m]> TI should've used an assert for this. Would've loved to get a panic with a nice error message :P
<danielb[m]> in hardware that means smoke
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit []
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio> <meptl[m]> "I'm having issues creating a USB..." <- > <@meptllc:matrix.org> I'm having issues creating a USB device via keyberon with my WeAct Black Pill (STM32F411CEU6). I'm using a minimal usb/led blink example:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OlXdUqLlKuDlsRQEqzYHNpts>)
<dngrsspookyvisio> <danielb[m]> "one has to appreciate datasheets..." <- oh jeez I hate this
<adinack[m]> guys this whole thing is making my blood boil
<adinack[m]> it's like how capacitor manufacturers disagree whether the anode or the cathode should have the mark
<JamesMunns[m]> diondokter *usually* marks on the bottom don't matter, unless they state so in the datasheet, and the "bar" marking would have made me guess that was the side with pin 1
<JamesMunns[m]> buuuuut yeah, sometimes manufacturers just do shenanigans
<diondokter[m]> Yeah, I should've second guessed myself, but the mark on the bottom convinced me enough
<JamesMunns[m]> especially for things that come in tape: you usually never see the bottom, because they get pick-n-placed, so it has to be on the top if you are doing visual inspection after placement
<adinack[m]> does anyone know how to build an embassy project to a .uf2 file so i can load it onto a seeeduino?
<adinack[m]> omg the seeeduino has exposed swd pins
<adinack[m]> how