Previous thread: >>2909001

Here we discuss microcontrollers (MCUs), single board computers (SBCs), and their accessories, such as Atmel mega and tiny AVRs (Arduinos), PICs, ARM boards such as blue/black pill STM32, ESP8266/32s, RP2040, Raspberry Pi, and others.

For general electronics questions (power supplies, level shifting, motor driving, etc.) please ask /ohm/.

>where can I find verified quality microcontrollers and other electronic sensors or parts
digikey.com
mouser.com
arrow.com
newark.com

>but that's too expensive
aliexpress.com (many parts here are fake, particularly specific parts out of stock in the above sites)
lcsc.com

>I need a part that does X and Y, with Z specifications. How can I find it?
use DigiKey's or Octopart's parametric part search. Then purchase from one of the sellers listed above.

>how do I get started with microcontrollers, where should I start?
There is no defined starting point, grab a book and start reading or buy an arduino off ebay/amazon and start messing around. There are a plethora of examples online to get started.

>resources:
https://github.com/kitspace/awesome-electronics

>RISC-V microcontroller list:
https://codeberg.org/20-100/Awesome_RISC-V/raw/branch/master/RISC-V_MCU_development_boards.pdf

>>2928655 (OP)
I want to sink 10, maybe 15 mA from uart mcu pins that i cannot determine the type of because it's embedded into something and non-reachable so i can't look up the specs. Is this current acceptable for uart connections on most mcu's? The sink is to drive a serial isolation optocoupler. The signal is 5V and outputs some data every second at 19200bps.

>>2929363
Probably not on newer MCUs. An older type like the ATmega328 (arudino uno mcu) would be able to but newer types would likely see a significant rise in Vol when trying to sink 15mA. You might see 1v when you should be seeing under 100mV. The exact voltage rise would be dependent on the mcu and may or may not be acceptable depending on the characteristics of you optoisolator. Also, I would be careful putting 5v on a digital input if the mcu is unknown. Newer types would may run on 3.3v rather than 5v and there is no guarantee that the pins would be 5v tolerant. Since 19200bps is very slow by modern standards, I would buffer the output with a transistor. I imagine the LED on the optoisolator is connected to 5v through a resistor and you want to connect the cathode to the mcu pin to turn it on when the pin is low? If that is the case you can go with normal non-inverted logic and connect the tx pin on the mcu to a bjt inverter. pic related

>>2929370
>I imagine the LED on the optoisolator is connected to 5v through a resistor and you want to connect the cathode to the mcu pin to turn it on when the pin is low?
Yes that was my plan.

But this pic inverts the signal right?

>>2929372
Yes the output on the isolated side will be high when the mcu output is low. If you don't want this you can invert the logic on the mcu. If you can't change the mcu firmware, you can add another npn to invert the signal. Since your baud rate is only 19200 the difference in propagation time will be negligible.

>>2929390
What are you retarded? Just put a pull-down resistor on the phototransistor instead of a pull-up. It’s floating, it doesn’t have to be common-emitter.

>>2929392
Good point. With 5v logic a 0.7v drop can be tolerated.

Should work. Thanks guys

>>2928655 (OP)
Do you have the sauce for the banana dev board or a high resolution pic? Here's some CRT porn in exchange

>>2929405
Nvm found it

>>2929405
I’ve never been able to find a source file for the WTFduino, but I’m pretty sure it’s just a 328P nano.

That CRT doesn’t look to have a front electrode to dissipate the charge from the phosphor. Man I want to make a vector display. Good thing we have laser galvos. Or maybe I should feed a component/VGA signal into a laser galvo to make a raster display? I should look into that.

man, the (tr)usdx HF transceiver is insanely impressive for an ATmega328P. I think they’re doing I and Q decoding AND voice input and output. Somehow. I don’t see any mixers or filters on their circuit.

I just spent the better part of somewhere between 4 and 6 hours figuring out a relatively simple and stupid bug in some code for a pair of STM32s trading a pair of bytes and ACK signals over UART.

NGL I kind of feel like shit about this, and how often things like this happen to me. Is embedded dev actually just like this? Does it get better? Is there some magic trick to not think like a fucking retard? Or is the best course of action about 50g of acetaminophen and a bottle of everclear?

I only do this as a hobby and I'm not that experienced, so I have no real context for whether or not struggling so badly for ridiculous amounts of time on what end up being relatively simple single-line problems is an everybody issue or just a me issue. I've heard plenty of joking about it, but I don't have a clue how much of that is exaggerated for comedic effect.

>>2929798
Is it something where an oscilloscope would have helped?
Sometimes just not being completely blind to what's on a wire that makes a big difference, and it can be easier to hook up than a printf debug on something with no console.
These cheap handheld ones are only like 80 bucks or so, and well worth it.

>>2929798
I made an app dev debug something for weeks because my firmware had a trivial bug.

>>2929798
Are you using debugging via GDB or otherwise through your IDE? Printf “debugging” doesn’t count. Being able to step through clock-cycles and see what values are in your registers and on each pin can be very useful for tracking down spurious bullshit. Or so I’m led to believe. Doing this on two MCUs at once may not be easy, but it should be doable.
I think CNLohr wrote some sort of development environment that made compiling and uploading code to STM32s really damn fast for more rapid prototyping, but I don’t know if it includes debugging.

While I wouldn’t recommend asking an LLM to write a program for you, asking an LLM why your code has this buggy result may steer you in the right direction.

You could also take the ASIC+analog pill and avoid anything you have to program. Most projects can be greatly simplified with the right hardware, and even if the microcontroller can’t be taken out of the equation maybe you can use an existing codebase for it, or make the programming far simpler. Why solve a problem today in software if you could have solved it yesterday in hardware?

>>2929887
>I think CNLohr wrote some sort of development environment that made compiling and uploading code to STM32s really damn fast
"make"?
>asking an LLM why your code has this buggy result may steer you in the right direction.
lol

>>2929798
>Is it something where an oscilloscope would have helped?

I already have a DSO. I'm not a complete novice here, though perhaps only just barely this side of it. That's part of the problem. I feel like I shouldn't be fucking up in ways this stupid at this point, at least not for this long.

>>2929887
>Are you using debugging via GDB or otherwise through your IDE?
GDB via the STM32 extension for VScode. Which actually was what ended up being part of the problem: It didn't occur to me that the peripheral registers have no way of knowing whether they're being read/written by the MCU itself or by the debug...meaning that flags that are set/reset on register read are flipped "at random" when the debugger pauses the MCU and checks register values.

IDK, I guess I'm mostly just looking for confirmation that either failing this hard is semi-normal or that I am, in fact, retarded.

Just for reference: Picrel for what ended up being the root of the problem. I couldn't figure out why the timeout for the first byte always worked fine, but the second wouldn't time out. USART_WaitForAck() would always return true (transfer received in time) even with impossibly short wait times...unless the receiving MCU was held under reset and not responding at all, at which point it would time out as expected. I eventually set the receiving MCU to just never send the second ACK and measured how long the timeout actually took, which was suspiciously close to 65535µs. Turns out, when I wrote the TimeoutSetup_uSec() routine at the core of the delay, I had implicitly assumed that the counter would be stopped at the start of that function. But, if the delay is long enough that it can be called again BEFORE the counter hits the set AutoReload (maximum/top) value, setting another, lower AutoReload value will cause the counter to dodge the original and the new timeout value won't be hit until the counter overflows.

>>2929923
(cont'd.)

It just seems so fucking obvious now that I see it. Yeah, other problems took up a portion of the near full day I spent on this (like the debug clearing flags, or that it's not pointed out in the datasheet that the overrun detection bit being set practically halts the entire USART peripheral, or any of half a dozen smaller code bugs), but saying that just feels like cope.

Anyway, thank you for coming to my blog, have a nice day.

>>2929923
>>2929924
I didn't try to understand your problem (tl;dr), but it's common that shit close to hardware, especially timing related stuff, can be hard to figure out. It simply drains a lot of time and energy. I'd recommend to have good ways to debug, like using a scope to view what happens on the UART, or making sure gdb shows real values (it often lies to me).

Bought a ESP32 and decided to run some tests with a 4-digit 7-segment display. I wired it and uploaded the sketch from this
https://microcontrollerslab.com/esp32-74hc595-4-digit-7-segment-display/

It works fine for any number up to 5555, but entering any number higher than that into the serial monitor causes errors. Random numbers, symbols that aren't even numbers, and blank screens. I looked through the code and I didn't see anything wrong with it, and I swapped out the 74HC595, resistors, and wires incase there was any fault there.

Is my ESP32 just borked in a completely retarded way?

>>2930572
>It works fine for any number up to 5555
how certain of you of this statement? that would be a very strange bug, as theres nothing very special about numbers higher than 5555.
does 7777 work?

>>2930572
have you tried another code or ide with that board?

>>2930572
Probably shitty code. That does not sound like a hardware problem. If you write the code yourself, not only will you understand why it works, but also understand where to look if it doesn't work.

Or ask an AI to do that for you, jeez.

>>2930577
Because the moment I noticed the bug I went through the numblers. First by the thousandth state, then the hundrendtg stat, finally the tenths, I didn't dive into the single digits because literally ever single numble above 5555 glitched out.

>>2930611
Yeah, I ran a basic blink sketch on this board multiple times with zero errors.

>>2930775
I spent all of Friday night and half of yesterday going over the code and see zero issues. The code should work. The board should work, in reality nothing works.

I pulled out my Fluke and tested every resistor. They resistors I used were 220 and rated at ±1 but actually read at 217.3Ω. I sat down and did the math and that variance should not in any way effect this. I switched out the 74HC595 with an honest to God Texas Instruments 74HC595. I replaced the 7seg4 with three different ones I had in my bench stock and got the same results ever time.

>>2931163
Those symptoms are not indicative of any issue in hardware, it’s definitely in the code, even if it isn’t obvious. Assuming you’re not in a workflow that has GDB available, try putting some printf() statements at various points in the code. Try to send 5556 to the screen and check key variables for overflow or corruption. Displaying binary values as decimals requires division by 10, and most
Microcontrollers don’t have hardware division, so memory might be a problem. If you don’t calculate the last digit and leave it as 9 all the time, do you still get the bug?

>ardushitto code written by retards
kek

>>2931203
it was in the code

>>2931216
Was? You fixed it?

>>2931228
yah, I am a retard

>>2931232
Explain the problem so we can learn. And laugh.

I wrote a little something to monitor sensor data and display a history. Now I'm wondering, are there better libraries for this? It's an ESP32, so I might even do it in micropython which could make use of the time information.

>>2929443
>front electrode to dissipate the charge
You mean the aquadag coating? This tube was a 1930s demo piece so I'm guessing that aquadag was either not a thing back then or they didn't bother because it was just a demo tube.

>Man I want to make a vector display
If you want to use a CRT it's pretty simple if you're willing to work with high voltage. Picrel was my setup before I dismantled it. I plan on coding an mcu to connect to the drive circuitry so I can play pong on the CRT in the near future so I may post here if I get around to it.

>>2933043
>aquadag
Yeah, though I didn’t know it stopped short of the phosphor. Guess the electrons can still move to it after striking the screen. Bet if they put an ITO layer under the phosphor too you’d get less static buildup.
>MCU for pong
Cmon man, pong is the perfect project for a diy analogue computer. Can probably make it in 40 ICs or so.

>>2933058
>Analogue computer for pong
To be fair I find this idea appealing and was initially going to go down that route since I prefer hardware over software but I have my hands full with other projects at the moment and it should probably be possible to write the program for it in a single day. I've already prototyped one deflection plate amplifier and it works fine at low frequencies. I didn't have any high voltage BJTs so I had to improvise and use IRF740s (not suitable for use in their linear region, I know) but even with those MOSFETs the deflection plate drivers are probably more than fast enough for pong. I've built up another amp to go with the first one so I can have independent control over X and Y deflection but I haven't tested the second one yet.

Micropython, I kneel. Why didn't I try this before? It's so much easier in the field than getting my laptop with esptool, platformio or the Arduino IDE.

>>2933911
What is it?