<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]
<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]> "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?
<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?
<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