processors with factory programmed bootloaders over UART - Page 1
Forum section: electronics / general

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 03:08:13 am
content: Are there any processors out there that have a factory programmed bootloader that can work over a standard uart ( through an USB to serial chip like fti / cs340 , cp2101 or whatever )Note : the processor must be able to run off 5 volts. not just be 5 volt tolerant on its i/o. true 5v power rail.I do not want to muck with programmers that need drivers that don't work on operating system xyz, or only on operating system abc.I have several development platforms and they all have issues. x doesn't work on y , that one only works when plugged in a usb2.0 ( plug it in a usb 3.0 and it hangs )i'm tired of all that crap. i need tools that work.i need a simple processor. a bunch of i/o pins , an i2c port, a simple uart . don' need anything else.i can do this in less than 1 kilobyte of code on an 8051. but physically programming them is a problem. i want to have the ability to load the blank cpu as it comes off the factory over a standard uart.there used to be something called FLIP but that require java to be installed and that's a no-starter

author: brucehoult
author_rank: Super Contributor
timestamp: September 10, 2025, 03:33:15 am
content: I mean ... yeah.https://www.amazon.com/ATmega328P-PU-Microcontroller-Bootloader-Compatible-Arduino/dp/B0DGQRSV2FAlso, if you already have ANY working Arduino-compatible board (doesn't matter whether it has a AVR CPU or not) then you can load a standard sketch onto it which then allows you to load the serial bootloader onto blank AVRs.https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP/

author: oPossum
author_rank: Super Contributor
timestamp: September 10, 2025, 03:45:57 am
content: CH552, CH554 and CH559 have USB and UART bootloader as supplied by the manufacturer.3 to 5 volt operation. "single cycle" 8051 core.

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 04:13:55 am
content: Thanks for the suggestions so farlet me clarify a couple more things :- tqfp44 pins or more. i need lots of i/oNo arduino. not an option. AVR is not the issue. The processors as sold on digikey do not have the bootloader in it. It needs to have a FACTORY bootloader. not something flashed by some external tool. ( those external tools are again a pain in the butt. ).Processor needs to be available on digikey/mouser. so CHxxx or any other chinese thing is outI'm leaning towards a 32U4 now ... ( A UPDI port is acceptable as i can wire up a simple usb-uart to make a UPDI. It requires no flashing of anything.)Having to preloading of bootloader and the requirement of drivers is key thing i want to avoid. It's a board with a USB port. Either through as USB <> uart or using the built-in USB of the processor.FLIP is an option (32U4. and that guy can also work over UPDI, so you don't really need flip)I am currently trying to use the ATxmega4809 but my experience has been horrible with that processor. The documentation is very bad. Especially the usage of the port mux and what peripherals override pins under what conditions. I spend more than a day just figuring out when the UART enables XCK and or XDIR on the pins. Now i'm stuck getting the interrupts to work ... The simulator in AVR Studio can't simulate it properly.

author: Berni
author_rank: Super Contributor
timestamp: September 10, 2025, 05:49:27 am
content: Most modern ARM based MCUs have a bootloader baked into a hidden ROM inside. Some are just smart enough to boot from external flash, others do the whole shebang of UART, I2C, SPI, USB, CAN...etc. But most of these are 3.3V parts (tho to be fair i haven't used 5V with MCUs for over a decade, most digital chips are 3V3 nowdays).That being said i would NEVER use this built in bootloader for development. You don't get any form of in circuit debugging capability with these bootloaders (since while bootloader is running your user code is not running). So as a result tracking down bugs in your code devolves into blinking an LED at various parts of the code, debug printing..etc, recompiling the code every time, flashing the entire chip every time, having to manually get the chip in bootloader mode every time etc.. This wastes SO much time. I do often use these bootloaders to implement in-field firmware updates tho.Alternatively i can buy a dev board with a USB to JTAG/SWD interface built into it for around 10€, bring out the programming lines onto a cable with a plug on the end, plug that into the MCU based board i am developing and suddenly i have full in circuit debug capability. With after changing a line of code it takes just 1 click to compile and program the code into the MCU. Programing takes <1 second since it only rewrites parts of the flash that changed. Then i can single step trough my code, look at any variable, change any variable, look at all hardware registers, can even poke IO pins directly live by writing to the GPIO peripheral registers. This saves so much time that the 10€ investment in the programmer board pays itself back in 1 day of bug hunting.As for documentation for MCUs. It is mostly all not very good. The difference is just that some documentation is only slightly bad while others are horrendously bad. It is partially due to it being more difficult to write good documentation for the more modern MCUs due to how much more complex they are. Best solution is to simply stick to a very popular MCU series so that if you get a problem you can google your way out of it.

author: pqass
author_rank: Super Contributor
timestamp: September 10, 2025, 06:30:39 am
content: QuoteWith regards to ATmega or ATtiny (what I know)...Downloading your compiled program to an MCU will require some kind of program on your host.A bootloader (listening on the MCU UART) just mimics a well-known hardware programmer protocol so that the host program thinks it's talking to a serially-attached hardware programmer.Like this setup: (a) host USB ---> USB-TTL UART RX/TX/RESET pins on MCUOtherwise, with a blank MCU, your setup would be:(b) host USB ---> HW programmer ---> MISO/MOSI/SCK/RESET pins on MCU(c) host USB ---> USB-UART TTL RX/TX+resistor ---> UPDI pin on MCUWhat brucehoult suggested was to install the ArduinoISP example program (from the Arduino IDE) on a loose Arduino UNO or Nano to use that as the "HW programmer" in (b) above.Then use that UNO/NANO HW programmer to install the Optiboot bootloader on blank chips from Digikey.The host program to download your compiled code to the MCU (blank or with bootloader) is "avrdude" and is available for Windows/MacOS/Linux.It's part of theArduino IDE zip/installeror standalone fromGithub.The advantage of using a bootloader (listening on the MCU UART) allows you to use the same externally accessible serial port for both your application-specific use and updating the firmware without having to open up the product enclosure. (b) and (c) setups will require different pins than TX/RX/RTS which usually require access to the PCB.

author: Psi
author_rank: Super Contributor
timestamp: September 10, 2025, 06:42:00 am
content: Digikey offers a programming service for MCUs, never used it myself. but you can buy chips on tape/reels already programmed with your codeYou can do the same directly from the Microchip store which sells AVRs. Look for the "Factory programmable" option.eghttps://www.microchipdirect.com/product/ATMEGA128-16AUI know Mikeselectricstuff uses this service so the price should be fair, but 'fair' is probably relative to your MCU cost and what your time is worth. I think it's around $0.30 for 0 - 0.5k volume.It seems the Digikey URL for it is 404 atm,https://www.digikey.co.nz/en/resources/dk-services/programming-servicesBut I have seen the program service show up as an option on Digikey MCU's in the past.(Have already reported 404 page to digikey.)Quote from: free_electron on September 10, 2025, 04:13:55 amI use the ATMega (16/32/48)09 and (16/32/48)08 ranges and have not had any issues. But i dont use XCK/XDIR just raw UART TX/RX. The only issue i had was blowing them up due to me stupidly putting the AVCC cap on the wrong side of the series inductor and damaging the pin from ringing caused by pulsed current flow.

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2025, 08:28:03 am
content: Quote from: free_electron on September 10, 2025, 03:08:13 amThe only option that pops into my mind are the old 8051 based microcontrollers from Philips. Don't know if these are still active parts. NXP continued having fully featured bootloaders in their ARM offerings (LPC series) but no 5V power.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 10, 2025, 08:34:19 am
content: Quote from: free_electron on September 10, 2025, 03:08:13 amThe SiLabs EFM8BB5x series are 5V and have UART bootloaders, with 1T 8051 50Mhz cores & ADC and some have DAC.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 10, 2025, 08:56:13 am
content: Quote from: free_electron on September 10, 2025, 04:13:55 amThe older Atmel AT89LP51Rx2 series have UART loaders.Nuvoton recently expanded the pin-count choices, so their MG51LD1AE comes in TQFP48FWIU these are UART bootloader capable, but do not have order codes yet for factory installed loaders.The ISP system is included on their eval boards or standalonehttps://www.techdesign.com/market/categories/development-tool/development-board/8051_evb?search=MG51LD1AEThey have a PC-less programming solution, that stores the code in the USB dongle SPI flash and you just press a button, no PC software needed at all, once set up.https://www.techdesign.com/market/categories/development-tool/other-tools/debugger-programmer?search=NU-LINK-PROAddit: And some news reporting on the new MG51 serieshttps://www.hackster.io/news/nuvoton-technology-dusts-off-the-classic-8051-architecture-for-its-numicro-mg51-microcontrollers-29a820386303For that they support Keil/Iar and SDCC/Eclipse, which has a file parsing editor that catches many semantic/typo bugs pre-compile.

author: Whales
author_rank: Super Contributor
timestamp: September 10, 2025, 10:35:42 am
content: STC are my favourite 8-bit for this.For programming: UART + stcgal software (win or Linux)For compiling: sdcc (or any other 8051 compiler)

author: 8goran8
author_rank: Contributor
timestamp: September 10, 2025, 11:11:21 am
content: The PIC32CM JH00/JH01 family might suit your needs.You can read more about the factory bootloader in Appendix 1 of the datasheet.I must mention that I have never used this microcontroller family.

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 12:17:11 pm
content: Thanks for all the suggestions.Here is the dilemma i am trying to solve :i build a product , put it in the field and at some point a software update is made. I can not expect the user of the product to have a programming cable, chunk of hardware or the skills to perform brain surgery.I want the ability to give the user a file and point him to a software tool ( something i do not have to make, maintain or support ) to load that file onto the processor over a common USB port ( either through the baked-in USB , or a usb to uart that i have put in the product. )It's already bad enough that there invariably will be questions like "i am using operating systems xyz and there is no tool for that"For example the RP2040 and 2350 emulate a mass storage device. simply drag the firmware file and magic happens.Where are the other processors that have a DFU baked in by their maker ? Mass storage class, CDC class or through a UART.Something that does not need drivers , has the loader available for Windows XP,7,8,9,10,11 , MacOs -x (any flavor) , linux (an even bigger can of worms and verions) ,and most importantly does not need ANY ACTION ON MY PART to get it on the processor or maintain it.I may have to bite the bullet and switch to a 3.3 volt processor. i'll have to do everything over I2C and use I/O expanders . I want to avoid level shifters as much as possible. they are also a headache. There's only like 6 signals that would need level shifters as they are interrupt inputs to the processor.I have a drawer full of dongles and boards , each requiring their own software and driver to program and debug various processors. some of them cost a lot of money and their makers are no longer existing or don't support them anymore.Every couple of years there is a new "picKit" or other tool that goes out of support and you need to buy a new one if you want to use a newer processor or the newer development tool.it is annoying and a waste of time and money.So i want to switch to a processor that doesn't need all that stuff.Again , it is the problem after development of supplying the end user with firmware updates that does not require them to open the device, buy a extra piece of hardware , muck with drivers and software and becomes a support headache.It also solves the problem on my end of requiring the same tools or a programming service to load the initial DFU code .

author: Psi
author_rank: Super Contributor
timestamp: September 10, 2025, 12:30:02 pm
content: Do you care about protecting your firmware binary, because a lot of MCUs that are programable over the UART require you to send an unencrypted copy of your binary. So if you give out firmware for your customer to flash you are giving out the raw unencrypted firmware file.Some MCUs do have encrypted factory bootloader options, STM32 has one.Just something to consider.One thing i've seen people do is throw a $0.50 ESP8266 or similar onto their PCB connected to the main processors programming lines, and have the ESP running a webserver that just allows you to connect over wifi from any phone and upload a bin file through the HTML page that automatically loads when you open a browser (eg captive portal).The ESP handles the reprogramming of the main MCU in a user friendly way. You cannot brick your main MCU and if you dont like the fact that your product now has wifi you can have it only power on the ESP8266 through some jumpers or button or something when the user puts the device into a programming mode.One downside is your product now has a RF transmitter on it so there are certification implications.Pretty sure you could get all that working pretty easily as i think there's lots of arduino examples on doing that on an ESP

author: Pseudobyte
author_rank: Frequent Contributor
timestamp: September 10, 2025, 12:44:17 pm
content: Yeah I think you will be hard pressed to find a true 5V micro with a baked in USB mass storage device bootloader.If you can find a 5V micro with USB you could always write the bootloader yourself.I have products that all serve up single page web apps as the primary HMI. Through that web interface our customers can simply upload a new encrypted firmware package (encrypted to prevent someone from loading something malicious). The bootloader will decrypt and load the the new firmware when the unit is power cycled. Doing it this way does require a real file system though.Another option would be to skip the bootloader all together and just have your application do direct firmware upgrades. I would only go this route if the micro you are using has multiple flash banks and you can preserve the old firmware until the new firmware boots.

author: ftg
author_rank: Frequent Contributor
timestamp: September 10, 2025, 12:52:31 pm
content: Renesas RA4M1 series is used Arduino UNO R4 Minima.Can do 5V and seems to have some USB bootloader.Nuvoton seems to have NUC131LD2AE and that's also 5V tolerant and a modern ARM.

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2025, 01:51:01 pm
content: Quote from: free_electron on September 10, 2025, 12:17:11 pmAgain, NXP's LPC series. LPC11U6xx series for example does this. You can drag& drop new firmware into the microcontroller when it is connected to a USB port. You'd need a button though to put the device into this state. Alternatively, create firmware which has this functionality while the device is running normally.

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 02:39:10 pm
content: Quote from: Psi on September 10, 2025, 12:30:02 pmnope. i even share the source code.QuoteThat's again requiring an effort from my side to write such thing, flash it on the esp32... and the ESP is not friendly. QFN package, rf antenna issues. I don't want shoes, hats, capes or other noseplucking. no stacked modules.i do not want the burden of having to support all that !

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 02:40:12 pm
content: Quote from: Pseudobyte on September 10, 2025, 12:44:17 pmthat's exactly what i don't want !

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 02:44:41 pm
content: Quote from: ftg on September 10, 2025, 12:52:31 pmRenesas and Nuvoton don't work for me. No workable toolchain for me.

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 02:54:37 pm
content: Quote from: nctnico on September 10, 2025, 01:51:01 pmi need to take a look at those. problem will be finding a toolchain. i need a BASIC compiler... not interested in C/C++not 5 volt ...

author: BradC
author_rank: Super Contributor
timestamp: September 10, 2025, 03:00:50 pm
content: The old 68hc11 had a uart bootloader baked in. Probably a bit old for your tastes though.

author: ftg
author_rank: Frequent Contributor
timestamp: September 10, 2025, 03:01:24 pm
content: It might be quite hard to find a 5V tolerant chip with TQFP-44 or larger and embedded USB or UART bootloader that requires no installation of anything on the PC side.But I'm surprised there's no BASIC compiler compatible with the R4 Minima from Arduino.

author: squadchannel
author_rank: Frequent Contributor
timestamp: September 10, 2025, 03:22:22 pm
content: b.....BASIC!?!?

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 03:40:35 pm
content: Quote from: squadchannel on September 10, 2025, 03:22:22 pmYES BASIC ! i have my reasons and i'm not going into endless discussions on the why. Those always become endless .

author: bingo600
author_rank: Super Contributor
timestamp: September 10, 2025, 05:57:57 pm
content: Quote from: free_electron on September 10, 2025, 02:54:37 pmBasic, but 3v3https://geoffg.net/picomite.html

author: Berni
author_rank: Super Contributor
timestamp: September 10, 2025, 06:50:20 pm
content: Quote from: free_electron on September 10, 2025, 03:40:35 pmWell in that case the BasicStamp. It runs Basic out of the box and has a UART interface to load it in(don't think you can even overwrite the built in interpreter/bootloader), but as usual it runs at basic interpreter speeds.Tho if you really needed Basic on MCUs there are quite a few Basic to C translator tools out there. From there on open source or vendor supplied compilers can build a working binary for pretty much any kind of MCU or computer under the sun. Just don't expect hardware drivers to just work out of the box, they never do on most modern MCUs

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 07:38:12 pm
content: i'm familiar with mmbasic but for this program it is too slow.interpreters won't work.The program is simple:wait for an interrupt from an external pin (this one comes every 4 milliseconds. see why an interpreter won;t work ?) , then launch a hardware timer counting in microseconds (again interpreters won't work.When the timer passes a threshold ( this can be hitting zero in countdown , but it would be preferrable to have an actual timer that has multiple hardware compares like in the 4809) fire another interrupt.The external pin inthandler onlystarts the timeron interrupt int0 : timer1.start =1on interrupt timer_compare1 :porta.1 = 1nopnopnopporta.1 = 0on interrupt timer_compare2 :porta.2 = 1nopnopnopporta.2=0timer.stoptimer.compare1 =triggervalue1timer.compare1 =triggervalue2the main program reads a rotary encoder and allows you to change the two compare times.there is some other stuff but none of that is not time critical.This thing waits for a trigger coming from an oscilloscope ( beam start ) and produces two markers on screen ( the ports control the blanking input of the scope). the users can change the marker position using an encoder.at the marker time it reads also 4 adc's and displays the values on an lcd display. that isthe orignal system used an 8051 with 8 kilobyte of code.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 10, 2025, 07:55:47 pm
content: Quote from: free_electron on September 10, 2025, 12:17:11 pmDoes your system use the usb/ uart for normal operation?Most loaders expect a boot button, to be closed at power up.You might hide that button close by using a usb-uart with two handshake lines, but you will need to supply and support the loader tool.CDC usb-uart have become more common, so driver creep is better now.STC have usb loaders, but their standard software has a lot of tick boxes, not really novice ’no support’ territory.Not sure if they have a batch loader ?

author: free_electron
author_rank: Super Contributor
timestamp: September 10, 2025, 08:18:44 pm
content: doesn't use usb or uart for normal operation.. adding a button was always the intent.hold button : power up -> enter updating modei could even strap a transistor from vbus so that the board goes into DFU when you plug in the USB port. but on a 32U4 there is no need for that since it has USB DFU built-in.i'm looking at using FLIP from atmel on a 32u4 now ... That is freely available.It allows people to write their own firmware as well. Arduino platform supports that processor. so we are not stuck to one toolchain. the 32u4 is supported in all the MikroE compilers (C pascal and basic) , Bascom-AVR, Oshonshoft , Great-cow basic. Arduino and of course the microchip/atmel environment and GCC and others.run's off 5 volts and is cheap. so it ticks all the boxes so far.The big thing is that i don't want to muck with programmers and drivers and dongles and other things. it is a headache to support and debug.DFU is simple. Here is the binary : load it over a standard USB port. you don't need anything apart from some software.

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2025, 12:49:46 am
content: The new AVR programming interface (UPDI) hardware essentially consists of a UART port, plus a resistor and a diode. Put the diode and resistor on your board, and you ought to be able to program the board with standard OSSW tools (like AVRDude) and a standard USB/Serial converter. No bootloader required.Things would be more complicated if you wanted to use the same USB/Serial converter for application communications...Of course, you'd still need some connector for this special programming port - you wouldn't want someone to plug in a DB9 Serial cable, and "standards" for a TTL Serial port connection are ... lacking.

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 04:05:07 am
content: Quote from: westfw on September 11, 2025, 12:49:46 amThat was the original solution i had in mind. atmega4809 with a cp2101 wired permanently in UPDI configuration. But i'm running into problems with the toolchain and the processor itself. The documentation of the processor lacks information on when certain peripherals override port pin functions. I tried figuring it out using Atmels START and the MCC tools but it is still not clear what bits cause certain peripherals to grab the i/o pin.The simulator is incomplete and can't simulate interrupts so i would need real hardware. I am not going to send the board out for manufacturing to find out there is an issue with the processor I/O. My confidence needs to be high that the processor will behave.THe 32u4 is easier to get. just ordered 3 small boards, same day on amazon. I know digikey has the little 9$ eval boards but i'm not willing to spend 100$ in shipping and handling for a 9% board. i don't need anything else from digikey right now... so it's blocking me.Yes there is the arduino nano every that has a 4809 but the problem there is the on-board programmer is a samd11 which doesn't do UPDI (not like behaving as a uart-emulating updi like a simple ch340 , cp2101 or ft232. you need to fidget with the arduino ide and loading additional stuff on there. too complicated. )I could strip off the updi connection and hook up a simple cp2101 updi board. maybe i will look into that path as well.But even then the arduino board doe not bring out all the pins. which makes it again annoying for me. i am use almost all pins ( only 2 analogs are not used). so i'd have to fidget with soldering tiny wires to the tqfp ... not looking forward to that.maybe i need to make a small breakout board that has every pin brought out to 100 mil header and an onboard ch340b in updi mode. jlcpcb or pcbway should be able to spin that quickly.It's ridiculoous how every twist and turn makes things more and more complicated while what i want is really simple.I long back to the olden days where you had a flash 8051 in dip40 and a hardware emulator. jack the emulator in the dip40 socket and off you go. it just worked. tracing, breakpoints, single stepping. it all worked.now its endless driver issues, toolchain issues, library issues and layers upon layers of code nobody understand slathered in datasheets full of mistakes and omissions.i'm spending more time mucking with the tools than actually writing the application.

author: cunningfellow
author_rank: Regular Contributor
timestamp: September 11, 2025, 04:11:22 am
content: Quote from: BradC on September 10, 2025, 03:00:50 pmI was going to suggest HC11 but you beat me too it.OP should be careful if going down this route though, it was only the E series (E2/E9) that had the ROM bootloader from memory. The others got programmed like a parallel 27Cxx

author: squadchannel
author_rank: Frequent Contributor
timestamp: September 11, 2025, 04:39:42 am
content: why are you assuming customers will use UPDI and Microchip Studio? That's a strange assumption.UPDI is intended for debugging purposes. If customers who don't know anything use it, it will only cause problems.you (or Microchip) should pre-program a bootloader that allows writing via UART.should build software that sends a special command via UART to enable programming mode, then send the firmware with a checksum appended, sized to fit within the micros memory.When micro receives a special command, it enables the registers required for self-programming, allocates memory space for the firmware, and upon receiving the firmware, verifies the checksum. if it matches, it proceeds with self-programming.However, if this process fails midway, it becomes a brick.Encrypting(not necessary) the firmware will also prevent customers from installing incorrect firmware. This is the approach you should take.https://ww1.microchip.com/downloads/en/Appnotes/AN2634-Bootloader-for-tinyAVR-and-megaAVR-00002634C.pdfNVMCTRL register.

author: fchk
author_rank: Frequent Contributor
timestamp: September 11, 2025, 05:46:48 am
content: Do you remember the STK500?There was an AVR90S8515 on board, and and for flashing this chip there was an AVR90S1200, which could flash the 90S8515 from scratch. In later revisions they updated the chips to Mega8515 and Tiny2313.This could also be a way out for you. Simply provide your own programmer. Today a sensible choice would be a PIC16F1454, which is an inexpensive 14-pin chip with 5V capability and USB2.0 hardware. This could provide an CDC-ACM virtual serial interface with an XMODEM uploader, for example, that can flash code into an AVR via ISP, or into an dsPIC33EV via ICSP, or into some ARM via SWD.These people have done this approach for ARM:http://dangerousprototypes.com/blog/2014/01/25/pic16f1454-used-as-inexpensive-arm-debugger/

author: peter-h
author_rank: Super Contributor
timestamp: September 11, 2025, 07:12:30 am
content: ST 32F4 can load via a UART, SPI, IIRC I2C, and some weird mode of USB.The UART mode is pretty slow though. Using a debugger (STLINK V2 is about 10-20 quid, V3 ISOL about 50) is very fast and great for production. You also get a post-program verify (with some programmers).I develop under win7-64 and everything works, including "win10+ only" Cube IDEBut I froze Cube at v14.1 which is another good technique for hassle reduction.

author: langwadt
author_rank: Super Contributor
timestamp: September 11, 2025, 08:34:35 am
content: Quote from: free_electron on September 11, 2025, 04:05:07 amhttps://en.wikipedia.org/wiki/Rosy_retrospection....

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 11, 2025, 01:05:58 pm
content: Quote from: peter-h on September 11, 2025, 07:12:30 amI suppose you're refering to USB-DFU. It's actually not that weird, it's a standard USB device class. But it turns out it's not been very widely used for firmware updating for some reason. Maybe one of them is (I think, at least?) the lack of native support from OSs (at least Windows), requiring to install a custom driver, which is always a pain for users.

author: peter-h
author_rank: Super Contributor
timestamp: September 11, 2025, 02:50:16 pm
content: Yes; I don't think many people can use it, except in a narrow production setup, where you freeze the Windows version etc.Back to the UART:The STM32 built-in bootloader commonly uses a default baud rate of 115200 bps, although some STM32 families have an auto-detection feature that allows for various baud rates between 1200 and 115200 bps. For successful communication, the host device (e.g., your computer) must be configured with the same baud rate, 8-bit data length, no parity, and one stop bit.115k is 100 seconds to write 1MB, so that is the price you pay for not using SWD+debugger. Also some report it as not reliable, presumably because auto baud rate detection needs to be done the right way, not just by measuring the bit(s) and calculating the baud rate. You need to do window detection so you actually set 115200 and not say a (calculated) 102765Have ST published their boot loader source code?

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 03:51:03 pm
content: Quote from: squadchannel on September 11, 2025, 04:39:42 amyou are not locked into microchip studio. UPDI can be accessed from many different tools. even open source tools and Arduino. That's the nice thing about it. All it uses is a simple usb <> uart like cp2102 , ch340 or ftdi chip.That's my goal : not lock you in to one devtool, or requiring you to buy additional breakout boards and wires and other annoyances.The whole project will be open source/hardware under CC0 . You can bring your own development tools. The design has an on-board usb<>uart strapped to the UPDI pin already so you don't need anything else.i do not want to muck with boatloaders unless they are factory programmed by the processor maker. it is a pain to get those things flashed. if new firmware overwrites the loader the thing is bricked. and then you need more shenanigans to get it working again.with UPDI that issues is non-existent.

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 03:54:48 pm
content: Quote from: fchk on September 11, 2025, 05:46:48 amNO ! you have not read my original post. The whole idea is to NOT need external stuff. That is an adidtional headache, cost, maintenance, support.Look at how a RPI2040 and 235x series do it : it mounts as a virtual flashdrive. drag the new firmware on and off you go. no need for anything. I can't use the Rpi for multiple reasons. only the 2354 would work but it is unobtainium and has bugs on the I/O (supposedly fixed but you need a4 stepping which is also unfindable. and it's QFN ... hard to solderOver the years i have collected a whole drawer full of programmers. various incarnations of pickits, icd , stm32, segger, iar , keil . every couple of years there is a new one, the older ones are no longer supported. it's endless hell. this toolkit only works with that version ,on that operating system on a monday , wind blowing from the north if you have your left big toe in your right ear while praying to the flying spaghetti monster.i'm tired of it ! Whenever i want to do something i need to spend half a day finding the files, drivers , cables , board. NO MORE ! I don't want it anymore.That's what this is. Solving the misery once and for all. Have processor with programming capability that does NOT need anything apart from a USB port (on board USB<> uart converter is acceptable) and a download utility.So far only UPDI seems to fit that bill.Are there others ?

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 03:58:21 pm
content: Quote from: langwadt on September 11, 2025, 08:34:35 amLOL. i've lived it. Dallas DS5000 in a socket, PL/M compiler under dos. I knew the 8051 inside out. The compiler was barely 40 kilobyte. upload over simple serial port. could get a system going in hours. So far i've spent already 3 days downloading various toolchains , installing updates, trying to figure out half-baked datasheets , wading through tons of library code to figure out what it really does.An 8051 was simple. you could understand it in a day.

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 03:59:38 pm
content: Quote from: SiliconWizard on September 11, 2025, 01:05:58 pmDFU has been around for a long time , yet almost no processors have it. Some vendors have their own twist on it. So the idea was good , but the implementation is broken. Like the CDC . also broken

author: langwadt
author_rank: Super Contributor
timestamp: September 11, 2025, 04:16:49 pm
content: Quote from: free_electron on September 11, 2025, 03:58:21 pmin a day? you are probably misremembering by a few orders of magnitude. Today is faster,simpler,cheaper and if you are stuck, 99% of the time the solution is a google search away, not three days reading through a manual and trying things

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 04:36:23 pm
content: Quote from: langwadt on September 11, 2025, 04:16:49 pmThe program i need is simple:An external interrupt comes in. The handler for that loads a hardware timer and starts it.When the timer hardware interrupt fires the handler for that interrupt makes a pin high , waits 3 NOP and makes the pin back low.The initial trigger comes every 4 milliseconds.When idle the processor reads a rotary encoder and increments/decrements the value that the timer uses.That's the core. It's not even 50 bytes of code on an 8051. The rest is reading some ADC when the tier fires and show it on a 2x40 character LCD in 8 bit parallel mode. Those display behave just like a 2 byte memory. hang it off the databus and you need almost no code.I'm 3 days in, trying to set up the 4809 to do this. The timer has so many options , and the interrupt system is very complex to get going. The tool has bugs, the datasheet is incomplete (the i/o mapping is not completely documented when it comes to what peripheral allocates what pin under what condition). Lack of a working simulator is also problematic. The interrupt handling can't be simulated. (they have not implemented it for that processor)For the 8051 i had a hardware emulator (Nohau) . i could simply write a skeleton code and then alter the i/o registers and see what the thing did. The emulator could be single stepped and you could alter any bit in any register at any point of time without having to write code. The emulation memory was RAM. you could type in assembly mnemonics and it would directly write them into the emulator as the processor was running.Anyway, all those things are irellevant for this topic.Solve one problem at a time. First problem is a reliable way to load the firmware on a processor that does not need custom dongles and programmers. Debugging-wise JTAG would be good but i'm also sitting on a stack of various Seggers , J-links, and Keil boxes that are no longer supported. And those things are pricey.I want cheap.

author: Pseudobyte
author_rank: Frequent Contributor
timestamp: September 11, 2025, 05:22:15 pm
content: Would you be happy doing firmware updates via a USB drive?I am pretty sure most of the coldfire MCUs from NXP (freescale) can run at 5V and come with a Mass Storage Device bootloaderbaked into the IC**edit** (on second inspection not sure it actually comes baked in). You can just put a USB host port into the design and hook it up to the MCU.https://www.nxp.com/docs/en/application-note/AN4368.pdfexample MCF51JM128VLHR

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 05:54:44 pm
content: Quote from: Pseudobyte on September 11, 2025, 05:22:15 pmyes. that's what the rpi2040 and 2350 do. TGhey behave like a mass storage device. plug it in to the pc, drag the file on it. it reboots after upload. no drivers neededoh, wait. host ? like i have to plug in a memory stick ? no. it has to behave like a memory stick.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 11, 2025, 07:31:22 pm
content: Quote from: free_electron on September 11, 2025, 03:54:48 pmThe atmel AT89LP51Rxx series have a ROM uart loader you can force with a USB handshake line (iirc 1k to PSEN)I don’t think there is a user way to erase the rom loader.For STC 8051’s there is interesting work over athttps://github.com/grigorig/stcgal/And looking more recent device wise is command line loaderhttps://github.com/IOsetting/stc8progI think the background is herehttps://en.eeworld.com.cn/news/mcu/eic600935.html

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 11, 2025, 08:20:30 pm
content: The RPi MCUs implement a UF2 bootloader in ROM, this is something you can of course implement in Flash otherwise. There are a few available for various MCUs. If not, as long as you implement a MSC device, the rest is not really hard to implement, the UF2 format is "dead simple".

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 08:43:56 pm
content: Quote from: PCB.Wiz on September 11, 2025, 07:31:22 pmi've been looking at 89LP series. FLIP can flash them out of the box. I can use either MikroE or Bascom-8051 and i know the 8051 in and out...but it's slim pickings. not many in stock and the question is how much longer. i think they will kill it off soon.8051 is getting a bit old.... like me

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 08:49:44 pm
content: Quote from: SiliconWizard on September 11, 2025, 08:20:30 pmnope. nope nope and nope again.i don't want to implement anything. It needs to come out of the factory. It's a support headache and it blocks me toolchain-wise. i need to learn how that works and it detracts from the actual thing i am trying to build.That's exactly the stuff i'm tired off. All the "side" requirements to get going. you need this programmer, that library, that toolchain, fidget with this, fidget with that.The Rp2040 solves that beautifully. costs nothing, works out of the box. ( but i can't use it for other reasons. 3.3volt , annoying qfn package , needs external flash that is finickey. the 2354 could work as it has onboard flash and is 5v tolerant but is still an annoying 0.4mm qfn and is unfindable and suffers from IO issues ( errata 9 , presumably fixed in the new stepping)The goal is simplicty. from loading it , soldering it and working voltage and writing code for it. it needs a basic compiler

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 11, 2025, 10:48:25 pm
content: Quote from: free_electron on September 11, 2025, 08:43:56 pmDigikey has stock in the thousands, how many do you need ?I doubt they will kill the entire line, so long as they have customers.What may happen is the smaller flash variants of AT89LP51RB2, AT89LP51RC2 users may be moved to AT89LP51RD2 but right now Digikey have good stocks of AT89LP51RB2-20AAU, and even more of AT89LP51RD2-20AAUMouser have good stocks too, the highest stock is the superset part AT89LP51ED2-20AU

author: free_electron
author_rank: Super Contributor
timestamp: September 11, 2025, 11:05:44 pm
content: ow.... i was looking at TQFP... i had the package filter set to tqfp not noticing there was also lqfp (same pitch , just a bit thicker, not important for me)the tqfp variant only had like 300 in stock. such low numbers worry me ... it's either not very popular or dwindling....AT89LP51RD2-20AU is TQFP 1.2mm ThickAT89LP51RD2-20AAU is LQFP . 1.6mm thickand i can get a dip40 for breadboarding.FLIP supports it .. slap on a cp2102 or ftdi232x and off we go ...I have compiler licenses for it as well and i know the 8051 inside out.. been using it since 1986 ...it runs off 5 volt. has plenty of flash and ram ... timers ... single cycle core. this is looking good.Thanks a lot !

author: Davor
author_rank: Contributor
timestamp: September 11, 2025, 11:25:05 pm
content: If 28 pins is enough than EFM8BB50 series as PCB.Wiz recommended earlier.5V supply with pre-loaded UART bootloader:https://www.silabs.com/documents/public/application-notes/an945-efm8-factory-bootloader-user-guide.pdfSilicon Labs is US company, 8051 is familiar to you, Keil is bundled-in for free.Mouser prices for Qty 100:EFM8BB50F4I-A-SOIC16 - 0.424 USDEFM8BB51F8G-C-TSSOP20 - 0.597 USDEFM8BB52F16G-C-TSSOP28 - 0.629 USD

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 11, 2025, 11:30:55 pm
content: Quote from: free_electron on September 11, 2025, 11:05:44 pmA similar ROM bootloader scheme exists in the EFM8BB52: reset with a pin low forces protected ROM boot loader.That is 1v8-5V, and lower price than AT89LP, but comes in TSSOP28 and QFN32, with 25-29io pins, so a simple io expander is needed to get to same IO count as AT89LPIt has better ADC/DAC and more precise on chip clock, but has no crystal support. An external active oscillator is needed for high precision tasks.Could be worth qualifying ?https://www.silabs.com/documents/public/application-notes/an945-efm8-factory-bootloader-user-guide.pdf

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 12:19:57 am
content: those are a bit too "light" . only 8k rom , 512 bytes ram. little i/o and QFN. don't want QFN. not "user-friendly"and apparently the bootloader can be erased . .. not bullet-proof. but it could but it could be acceptable as it is in the protected flash zonei've used the 8051Fxxx series from Silabs in the past a lot. But they are almost all gone obsolete as well.i need ot check what others they have that come with the bootloader ...those are good pointers. keep em coming ... thanksi just found the EFM8UB2. more ram/rom and USB bootloader.....

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 12:35:00 am
content: EFM8UB20F64G-B-QFP48 could be worth a try .... and they are cheap. 3$ one-off price

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 12, 2025, 12:55:34 am
content: Quote from: free_electron on September 12, 2025, 12:19:57 am? The EFM8BB52 has 32KB Flash 2.25KB RAM and comes in TSSOP28Quote from: free_electron on September 12, 2025, 12:19:57 amThat's simpler as it does not need external UARTs. but it is 5V tolerant only on the IO. Maybe that is OK ?

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 02:16:34 am
content: Quote from: PCB.Wiz on September 12, 2025, 12:55:34 amneed more pins ... 48 or 64

author: JoeyG
author_rank: Regular Contributor
timestamp: September 12, 2025, 02:24:25 am
content: It depends on the mcu architecture, boot code is loaded in one memory section(address) and application section (address).So the application code needs to written at the application section , which is no often the RESET address (and the bootloader runs first).Hence management of these memory sections needs careful consideration.

author: JoeyG
author_rank: Regular Contributor
timestamp: September 12, 2025, 02:37:41 am
content: Microchip have developed a universal bootloader that spans across many architectures (PIC, AVR,ATMEGA, Cortex M0,M23,M33,M7) etc that works with the tool chain.You can create your own targeted / specific bootloader (and not tied or locked down to a specific bootloader)ThenYou can order small/large volumes of you preprogrammed boot image on the mcu via Microchip Direct.https://www.microchip.com/en-us/microchipdirect/programming-servicesMDFU (Microchip Device Firmware update)It's been out for several months and expanding.https://onlinedocs.microchip.com/oxy/GUID-58904FDA-338A-488F-A88D-766D29B27E37-en-US-1/GUID-0962C0F5-3664-43F2-819A-B561B0639B5C.html#:~:text=of%20Terms%20section.-,1.1%20MDFU%20Protocol%20Characteristics%20and%20Benefits,to%20support%20the%20attached%20client.The external PC / Laptop software is written in Python that can work on many platforms and or be modified to suit the application.The HAL is provided for the core of choice and a config file + the application hex image are used to bootload the new image with the Python script.https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SupportingCollateral/Microchip-Device-Firmware-Update-MDFU-Protocol-DS50003743.pdfYou can order small volumes of you preprogrammed boot image - so you can tweak the bootloader via Microchip Direct.It seems to be well documented from a specification point of view.Some effort is required and a few full examples herehttps://github.com/topics/mdfuhttps://mplab-discover.microchip.com/v2?dsl=MDFU

author: Psi
author_rank: Super Contributor
timestamp: September 12, 2025, 03:21:51 am
content: If you used a MCU that can run code from an external flash chip maybe you could setup a system where the external flash is in a module on a connector and you can handle customer updates simply be sending them a new module to plug in.I wonder if any mcus can load/run code from an external parallel/I2C flash IC without needing any firmware programmed to them, anyone know?Then all you need is your own system to load code onto the modules once.I guess the cost of having external modules to supply for a firmware change might make it uneconomical. But you could get the old ones back and reflash them.Just trying to think outside the box in case some ideas shake loose.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 12, 2025, 04:07:15 am
content: Quote from: free_electron on September 12, 2025, 02:16:34 amWell.. yes...The point was this part is low cost enough, to afford adding some simple IO expansion.lcsc have TSSOP24 16 bit i2c gpio expanders TCA9535PWR(UMW) for 20-30c, or HC595 parts are 3-4c for 8 CMOS OP.

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2025, 09:23:34 am
content: QuoteI guess that's nice. About time, and I guess competing with Microsoft's UF2 bootloader (which is USB only, I think?)AVR-DA example:QuoteAbout 5k. That's not very impressive. :-(

author: tooki
author_rank: Super Contributor
timestamp: September 12, 2025, 11:28:04 am
content: If you’re willing to use a 3.3V MCU, and low power consumption isn’t a concern, you could consider ESP32.Both the “classic” ESP32 as well as newer variants (that have native USB) can be programmed using a dumb UART. Most ESP32 dev boards have a two-transistor circuit that uses the flow control lines to put the MCU into bootloader mode so you don’t have to press a button. (Of course, you could leave that out if you want to require a button.)The “normal” tool for flashing the firmware is the esptool.py script that comes with the IDE, or using Espressif’s standalone flashing utility, but people long ago figured out other approaches, precisely for your kind of situation. This discussion covers many:https://community.platformio.org/t/esp-stand-alone-programming/32573/4Adafruit has an open-source web-based flashing tool:https://adafruit.github.io/Adafruit_WebSerial_ESPTool/With that, you could just host a web page that can update the firmware of a connected board.Next, it’s also super trivial to set up WiFi firmware updates, where the ESP32 has its own web server that lets you upload the binary. I have used this myself to enable closed-box firmware updates on my own projects.Meanwhile, the newer ESP32 models with native USB (e.g. -S3) offers additional options, including presenting a USB mass storage device, using Adafruit’s tinyUF2 project:https://github.com/adafruit/tinyuf2(I know it’s not factory-preloaded. Though it may not be a dealbreaker, given that only UART is needed to upload the bootloader if need be.)The official debugger for ESP32 is nothing more than an FTDI bridge, and only costs around $12, even from Digikey and mouser. It’s not the best debugger in existence, but it does work and it’s cheap. IIRC some models with native USB also allow direct debugging.

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 03:48:08 pm
content: Quote from: Psi on September 12, 2025, 03:21:51 amnot feasible. support headache.Quotethe silabs can be flashed over i2c. they even have a demo where they use a usb <> i2c dongle. cp2112 chip i believe. Their bootloader can load over uart, usb and i2c.Quoteit's a good idea but not what i want. It's just replace one dongle with another dongle. and now it needs shipping..Download file , done.the next problem is that mcu's with EMIF are also thin these days, unless you go to high pincount...and most of them are 16 or 32 bitter so you need lots of pins for data or address bus. It also brings with it the problem of toolchains. I need to have a basic compiler for it... other languages are welcom, the more the better, but that first requirement is basic.

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 04:03:37 pm
content: Quote from: PCB.Wiz on September 12, 2025, 04:07:15 ami use PCAL9555 for the non critical i/o , but there are some pins that need to sit on processor. i can't afford the delay incurred by I2C or even SPI. When the interrupt fires the ISR needs to write i/o as fast as possible.We are getting bogged down in "application development" world. Let's ditch the application for now.The application It is not important.The goals are :- lots of i/o- acceptable packages :44, 48 or 64 pin packages. TQFP. NO QFN or BGA . Too hard to solder. lower pincounts don't have enough i/o- 5 volt capable. 5v tolerance is already a bit of a problem as it requires level shifters. many 5volt devices are not happy with the 3.3volt output of a pin.- Firmware loadable out-of the box, without requiring additional hardware (apart for usb<uart) . No flashing of bootloaders allowed ( that still requires getting the bootloader on it , which in turn again requires additional hardware, software, drivers. endless chicken and egg problem )- cheap ( max 5 to 6$ in one-off )- availability of a BASIC compiler. Other compilers welcome but BASIC is a must. COMPILER , not interpreter.- NO MODULES. Don't suggest things like the parallax picbasic or arduino boards or other boards. naked chip.So far we have:Processors with UPDI like the atmega4809. only requires a simple usb<>uart converter.AVR32U4 , AT90Uxxx: flashable over on-chip USB using FLIPMany Atmel 89LP and 89C. flashable over USB<>UART using FLIP.Silabs Busybee and EM8.

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 04:09:29 pm
content: Quote from: tooki on September 12, 2025, 11:28:04 amQFN package. disqualifiedmodules are also not acceptable. naked chip.3.3 volt is also an issue. many external things run on 5 volt. everything would require level shifters. even if the processor io is 5 volt tolerant on inputs, the external hardware is not happy with a 3.3 volt "high".

author: free_electron
author_rank: Super Contributor
timestamp: September 12, 2025, 04:53:21 pm
content: i've been rethinking a bit.the main bottleneck is 5 volt ... if i drop to 3.3 volt the world opens.I can work around most of the issues by using I/O expanders on I2C that have dual power rails. The PCAL9xxx family (NXP) and TCAL6xxx (TI) have multi voltage domains. the i2c bus sits on the 3.3 volt domain but the I/O has a true 5 volt domain. These chips have two power pins. On for the i2c bus, one for the i/o bus. They can work form 1.1 volt to 3.6 volt on the i2c bus , and 1.65 to 5.5 volt on the i/o sideIn situations where i truly need on-processor output i can use byte wide level shifters. There are devices with dual power rails. no need to go mucking about with loose mosfets.If the processor is otherwise 5v tolerant the inputs will work as well.i really only want 16 output pins on processor and 5 or 6 input pins (mainly external interrupts). everything else can go over i2c. so 48 pin device would cover my needs.Almost all of the STM32 have a baked-in (factory) bootloader over UART or USB That opens a ton of possibilities. They are cheap, easily available and well supported (toolchain wise) . Their programmer software is frightening though. 1.2 Gigabyte ..i did some playing with the programmer and they have an option to toggle RTS or DTR... so i can wire that signal to the BOOT pin. a simply usb<>uart can do the work then. I want to retain the ability to have a uart for "print" and "input". Using the dedicated on-chip USB for that is too difficult for me. The basic compiler has no ability to implement a CDC class (well, it has through external libraries, but they are a headache to deal with and sometimes drop packets. a FTDI solves that problem nicely)MikroE has a basic compiler for them (for which i already have a license. there is a free version also, code size limited) and they support debugging sourcecode through their codegrip or microprog programmers (which i also have)Maybe i just need to bite the bullet and ditch all those old processors like AVR and 8051. They are too restrictive on multiple domains.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 12, 2025, 07:19:59 pm
content: Quote from: free_electron on September 12, 2025, 04:03:37 pmThe 5V tolerant parts can pull up to 5V with a resistor, on those pins that really need to drive 5V hi.

author: tooki
author_rank: Super Contributor
timestamp: September 12, 2025, 10:15:33 pm
content: Quote from: free_electron on September 12, 2025, 04:09:29 pmI have to be blunt: that’s just stupid. I trained dozens of first-year apprentices to solder QFN’s, it’s not that hard. ESP32 modules are even easier to hand-solder. Both are trivial to do by reflow soldering with a paste stencil.Quote from: free_electron on September 12, 2025, 04:09:29 pmWhy is a module out of the question? (They’re the most common way of implementing an ESP32, since they already have all the radio certifications.)Quote from: free_electron on September 12, 2025, 04:09:29 pmYou’d be surprised how many 5V devices actually do just fine with 3.3V logic signals. It’s not all devices, so you do need to test it, but I found that it works more often than not!

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 13, 2025, 12:24:01 am
content: Quote from: free_electron on September 12, 2025, 04:03:37 pmThis link has many down loaders for parts with inbuilt bootloaders,https://github.com/wagiminator/MCU-Flash-Tools/blob/main/pypi_packages/puyaisp/puyaisp/puyaisp.pyThere are 8051 / ARM and RISC V parts and many are 5V operation.STC 8051's come up to 64 pins and up to 64kF and 32kRThere are also 32 bit MCUs in 5V / wide supply, most common at low pin counts, but still available at 48-64 pins.Addit : STC are this month bringing up first silicon of their new Ai8052 part : 144K SRAM, 256K Flash 74Mhz core 230MHz PWM FPU 12b ADC 12b DAC 2Msps(Ai8051U older sibling is 144Mhz PWM 64kF 34kR no DAC )forum updates are here:https://www.stcaimcu.com/thread-19786-1-1.html

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 01:38:04 am
content: Quote from: tooki on September 12, 2025, 10:15:33 pmmy hands are shakey and my vision is not what it was. it's too hard for me. i don't want to work with stencil and paste. I can still perfectly drag solder a 0.5MM tqfp.Why is a module out of the question? (They’re the most common way of implementing an ESP32, since they already have all the radio certifications.)ESP32 is no-go for many reasons. Not going to elaborate further on this. we are sinking again in the swamp. It doesn't fit what i have in mind.Quote from: free_electron on September 12, 2025, 04:09:29 pmEven a simple HD44780 display doesn't work right on 3.3 volt.It's a gain a pile of headache i'm trying to avoid.For the "unimportant" stuff i can run it over I2C using I2C i/o chips with dual power domains. issue solved.But there are other things where i may need real level shifting. There are some "directionless" devices out there. Like a 74245 but they don't need a direction signal. And they have two power pins.

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 02:11:19 am
content: Quote from: PCB.Wiz on September 13, 2025, 12:24:01 amowwww. a bunch of python code. with dependencies. Sorry, disqualified. not for me, thanks.Anyway the STCube programmer can work fine. Nice GUI.I am not familiar with PUYA brand. Digikey and mouser don't have it. So that disqualifies it. Same for STC. IT needs to be commonly available.I'm still leaning towards either :- Something AVR like an Atmega4809 with UPDI. Can use a simple USB<>uart to do UPDI.- STM32 and live with the 3.3 volt. Many come with UART (bring your own USB<>uart) or on-board USB. Flashing through STMCube Programmer software. I would probably still only use the UART boot and have my own USB<>UART. If i ever want to talk serial i am not blocked by not being able to use the on-board USB.I looked at the silabs parts and some others and decided no. It's too restrictive an ecosystem. AVR and STM32 are far more popular.They were all good suggestionsI just want something where i don't have to fight through a learning curve. Python , C , libraries, ... not for me anymore. I'm tired of all of it.I want something that runs out of the box. Is easy to solder down. install a GUI flashing tool and doesn't require "dongles"I've dropped the 5volt requirement. It's too restrictive. I can use i2c based dual domain chips. But i still have a requirement for at least 24 I/O pins on the processor. I need some I/O that has no latency.I want to thank everyone that posted in this topic.If i come off as cranky , i'm sorry. I am struggling. I am burned out. There's a reason i have been off the forum for a long time. I'm not going to bore anyone with it.For 40+ years I've fought my way through learning 6802, 6809, 8048, 8051, ARM7 and some others. It was fun, but I don't have the energy anymore to learn yet another system. The processors today are very complex. The toolchains are incomprehensible for me, it's all middleware and layers upon layers of "drivers". I don't want to learn it anymore. It's a drag on my time and mental health. I need simple things.BASIC is simple. It doesn't care about whitespace. It knows when = means assign and when compare. It's case insensitive . I like that.5v is simple.TQFP and 0603 are still simple. QFN and 0402 and below are not.I have some projects in mind i still want to do. I need a simple to use micro for that .Again, thanks to all and sorry if i came off as cranky.

author: BradC
author_rank: Super Contributor
timestamp: September 13, 2025, 06:53:37 am
content: Quote from: cunningfellow on September 11, 2025, 04:11:22 amNope, they all had the rom bootloader. You just used that to bootstrap a second stage in ram and then you could do what you liked.

author: bingo600
author_rank: Super Contributor
timestamp: September 13, 2025, 05:30:58 pm
content: Quote from: free_electron on September 12, 2025, 04:53:21 pmJust use Tormod'shttps://sourceforge.net/projects/stm32flash/

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 05:43:58 pm
content: Quote from: bingo600 on September 13, 2025, 05:30:58 pmi'll give it a swing. ordered some discovery boards

author: bingo600
author_rank: Super Contributor
timestamp: September 13, 2025, 05:49:27 pm
content: Quote from: free_electron on September 13, 2025, 05:43:58 pmHave a look at the MCU DS , lots of the STM32 has FT (5v tolerant) pinsI don't know if all the new series does , but the F1 & F4 does have lot's of them.Ohh ... And remember to download the errata-sheetYou might be in for some "surprising read there" ...

author: tooki
author_rank: Super Contributor
timestamp: September 13, 2025, 06:38:53 pm
content: Quote from: free_electron on September 13, 2025, 01:38:04 amI think you’re being too rigid. If a really good chip exists as a QFN, for example, the worst-case scenario is that you use an assembler to solder it for you. This is a commercial project, right?Quote from: free_electron on September 13, 2025, 01:38:04 amThat’s for a completely different reason that has nothing to do with logic voltages: they need an LCD bias voltage that’s somewhere around 4V lower than the positive drive voltage, so when driving them from 3.3V, you actually need a negative voltage — which is exactly what 3.3V HD44780-type displays accomplish with an onboard 7660 charge pump. (Large-character versions need an even more-negative bias voltage, so even the 5V versions of those use a charge pump.)Quote from: free_electron on September 13, 2025, 01:38:04 amRight. So a very… solved problem.

author: tooki
author_rank: Super Contributor
timestamp: September 13, 2025, 06:54:01 pm
content: Quote from: free_electron on September 13, 2025, 02:11:19 amLook, if I can learn to program an MCU in C, anyone can. I am NOT a gifted programmer.C is simply where all the action is (with python growing rapidly, though I haven’t done anything with it yet).You’re not wrong that many of the toolchains are complex and layered.You dismissed Arduino early on, but I think the Arduino framework is a great platform to build on, and has the massive advantage of being available on a quite large array of MCU families, from small Atmegas all the way to beefy STM32s and the even beefier SoCs used in the Teensy boards. I love the fact that I can write a program on an Atmega, but easily port it to an STM32 (which is far, far more complex).I cannot imagine there’s anything one can do in BASIC that one can’t do better with the Arduino framework. Where do you even get a BASIC interpreter or compiler for most modern MCUs, anyway?? (That’s an honest question; I was under the impression they don’t exist for many of them.)And finally, a bit of a reality check: if you keep disqualifying everything, eventually there will be nothing left. And if you disqualify anything that requires you to learn something, then you can give up now, because such a thing does not exist. (The only things that require you to learn nothing are the ones you already know intimately, but if one of those were suitable, you wouldn’t be here asking for a suggestion.) There WILL be some kind of effort required of any solution you choose.Quote from: free_electron on September 13, 2025, 02:11:19 amAppreciated, since you kinda did.

author: Atlan
author_rank: Frequent Contributor
timestamp: September 13, 2025, 07:04:10 pm
content: Latency and Arduino don't go together. Standard pin control takes a very long time on Arduino.

author: tooki
author_rank: Super Contributor
timestamp: September 13, 2025, 07:39:27 pm
content: Quote from: Atlan on September 13, 2025, 07:04:10 pmSure, but that is easily remedied by using a fast GPIO library for the target MCU, or by modifying the GPIO registers directly. It doesn’t stop you from doing that.Also, the slowness of the regular Arduino GPIO manipulation is fundamentally CPU-bound, so the faster the MCU, the faster the regular GPIO functions become. They’re far, FAR faster on an STM32, for example, than an Atmega328p.

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 08:50:39 pm
content: Quote from: tooki on September 13, 2025, 06:38:53 pmno. pure hobby.Quote from: tooki on September 13, 2025, 06:38:53 pmwell., yes and no. it requires additional stuff. stuff that is not easily breadboardable. stuff that needs additional software. I'm trying to keep simple things simple. i can't handle complexity

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 09:20:10 pm
content: Quote from: tooki on September 13, 2025, 06:54:01 pmC is a source of irritation i don't want to deal with. So is Python.While Arduino's solve a lot of that the problem is the libraries. They are incomprehensible. All people do is call 300 times some function just to configure some i/o pins. Same for the St code. Nobody just sets the registers anymore. It's code bloat.QuoteI Don't have to deal with curly braces, semicolons , getting frustrated to find out i forgot again to use == instead of =, or got some capitalization wrong. Every library seems to have it differently. Or Pythons whitespace obsession.They are sources of irritation i don't need. I can't explain how irritating it is when compiling a program for the first time to have to fix a bunch of typos. I mentally cannot handle it anymore. I Have limiting factors.From that perspective interpreters are great. you can start running and solve issues as you go. it leads for a lot more experimental approach.QuoteInterpreters : Annex RDS on ESP8266 and ESP32. MMBasic exist for many different machines. even STM32, PIC32 and RP2040 and 2350.Compilers : MikroE. Pic 16 18 24 32 , FTxxx, Many AVR , 8051 , STM32, TI Arm , NXP Arm. Bascom 8051, Bascom AVR, Coridium . Oshonsoft has them for z80 8085, AVR, PIc 16 and 18 and some others. And they are true compilers. Not P-code with a runtime engine.QuoteThe things i knew are gone. Yes there's still some 8051 around but there's no point clinging to them anymore. so i am looking forward. But i want this to be the last time i learn a new architecture.I want something simple. Solder TQFP is still simple, QFN not so. 5 Volt would have been nice but i have workarounds. Yes there will be effort required and that's fine. This is part of that effort : weeding out the things that will be a headache. Most likely i will end up with a STM32 or AVR machine. I will create some sort of base platform. A set of schematics and a precanned layout i can just drop down in any project i want to make. Most of the stuff will sit on I2c anyway. I like that bus.I am simply trying to pre-empt stuff i don't want to deal with anymore : the erratic development tools with programmer drivers that don't work or need weird tricks to get running( like Zadig) , Dongles (stlink, j-link, seggers, ulinks) that have gone obsolete or no longer supported. I have a whole drawer full of those things. they are all useless. I don't want to fight those battles anymore. they are a drain on me.I want to ditch all those annoyances and focus on doing something.

author: free_electron
author_rank: Super Contributor
timestamp: September 13, 2025, 09:27:29 pm
content: Quote from: tooki on September 13, 2025, 07:39:27 pmWhich is the approach i want to take. The problem is the peripherals are very poorly documented these days. They all bank on "middleware". I've been fighting with the 4809 trying to figure out what exactly they do in that middleware.I finally gave up. I used their configurator, let it generate all the c code. , compiled it into an empty program, just run the initialisation and dumped it in a simulator. I placed a breakpoint , dumped the registers. There's like 17 registers that need a write. But for every little thing they perform read-modify write. set one bit at a time. This is also the Arduino approach.The Silabs tools for their 8051 solved it differently. There was also a GUI but they modified the register bits directly from the GUI with needing middleware.

author: tooki
author_rank: Super Contributor
timestamp: September 13, 2025, 10:00:30 pm
content: Quote from: free_electron on September 13, 2025, 09:20:10 pmIncomprehensible?!?The “Arduino language” (which really just means the Arduino base library functions) wasliterallyoriginally designed to allow artists (stereotypically the least-technical users imaginable) to do basic programming.Quote from: free_electron on September 13, 2025, 09:20:10 pmIt is true that in Arduino, you configure pins individually. IMHO this is eminently sensible for most applications, and reduces the chances of errors.Regardless, if you understand setting registers, not only does it mean you are 1000% capable of easily understanding Arduino, it also means you can set registers when using Arduino! As I stated already: the Arduino environment does NOT stop you from performing direct register manipulation. People can, and very much do, do this in Arduino projects for various reasons.As for bloat: it often doesn’t matter.Just the other day, I used an Arduino board to quickly lash together a cable tester to test the 50 four-pin cables I had just assembled and wanted to make sure had no shorts (I trust my skills and the chances of a short were minuscule, but I prefer the certainty). In an hour, I wrote and tested some code that a skilled programmer would likely have done in half the time and in a third as many lines of code. All it does is read one button, check for continuity from each wire to the others, buzz one buzzer, and flash some blinkenlights. A 4-bit microcontroller would have been adequate. It could also be made from a few logic ICs. But my “bloated” code is easy to follow, doesn’t rely on hacks for performance or efficiency, instead doing things extra-explicitly so that I know everything is in a known state. The Atmega328p is so oversized for this application that it simply does not matter one bit if it’s bloated or not.Quote from: free_electron on September 13, 2025, 09:20:10 pmOK, I do understand the frustration of that kind of stuff. But in all fairness, modern IDEs with code completion and the like make it MUCH easier, since they fix a lot of those things automagically on the fly, show you context-sensitive help on the functions you call, etc.Quote from: free_electron on September 13, 2025, 09:20:10 pmUhhh… what? Those are just basic characteristics of C. A library most certainly does not handle any of those things differently than another. Only the capitalization of functions is within the library’s purview.Quote from: free_electron on September 13, 2025, 09:20:10 pmFor sure. At least modern real-time code checking (the red squiggly underlines and so on) flag a ton of errors before you ever bother compiling.Quote from: free_electron on September 13, 2025, 09:20:10 pmWow, I honestly had no idea there was that much!!Quote from: free_electron on September 13, 2025, 09:20:10 pmOK, I can understand that.Quote from: free_electron on September 13, 2025, 09:20:10 pmI’m just not sure that’s an entirely reasonable set of expectations.

author: tooki
author_rank: Super Contributor
timestamp: September 13, 2025, 10:17:47 pm
content: Quote from: free_electron on September 13, 2025, 09:27:29 pmWell, that kind of abstraction does have some advantages (in particular, code portability and error handling), so it’s not entirely unreasonable to use that approach for many things.But I also have to wonder… do you struggle with datasheets or something? (I ask this seriously, not as sarcasm or anything.) I mean… the 4809 datasheet is 550 pages that document its registers in detail. As I cannot emphasize enough, I’m a very mediocre programmer, and I still was able to use the datasheet for a PIC microcontroller (a chip family I had never touched before, in an IDE I had never used before) and figure out how to configure the timer I needed by diddling its registers.You clearly have ample microcontroller experience, so I’m kinda trying to figure out why you appear to be struggling with certain things — or anticipating or creating a struggle where there probably wasn’t one.(This is one area where the ESP32 really diverges from most MCUs, in that Espressifreallydoesn’t document most of the registers and absolutely expect or demand you to use the API calls.)

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 14, 2025, 03:03:57 am
content: Quote from: free_electron on September 12, 2025, 04:53:21 pmIf that 1.2GB is frightening, there are simpler smaller downloaders.The two ISP USB / UART loaders on the Megawin website are much smaller, at either sub 2MB or sub 1MBIt looks like the megawin 1T 8051 parts have ROM bootloader and do not have a code offset on user code.Looks to use a single pin merged TXD/RXD for loading, so saves a MCU pin.Looks like you can buy 64kF and 64 pin 1T 8051 MG82F6D64-LQFP64 here - at just over $1 @ 20+ free shipping?https://www.ebay.com/itm/134239637938https://www.megawin.com.tw/product/MG82F6D64Summary : 1T 8051 MG82F6D64 64kF 3840R 144MHz PWM, 6 timers, 4 UARTand an eval board, for quick checks of any feature (includes USB-UART):https://www.ebay.com/itm/134239639168Good english docs and very little new to learn.

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2025, 10:36:16 am
content: Quote from: free_electron on September 13, 2025, 09:27:29 pmI see you have not looked into NXP's LPC series microcontrollers yet as these have excellent documentation and the peripherals are designed and documented by sensible people. Also these controllers come with drivers baked into ROM (like dealing with the internal flash). For accessing flash, the ROM api is mandatory (simple enough to use), but basic peripherals like SPI, timer, UART, clocking, etc are so simple to get going you don't need middleware at all. Yes, they cost a few dollars more but you make that back in spades by not having to waste your time second guessing what has not been documented. In the past I have done extensive comparisons between various ARM microcontrollers where it comes to ease of use and NXP's LPC series just come out on top.

author: guenthert
author_rank: Frequent Contributor
timestamp: September 14, 2025, 11:44:48 am
content: Parallax BASIC Stamp has been mentioned (and dismissed). Their Propeller has also a boot-loader over UART built in ROM. And an interpreter (for a proprietary, slightly weird, language, not BASIC, but a little BASIC-like) also in ROM. That one is fairly fast, but for performance critical applications one would use machine code there (too little RAM and too awkward an architecture to be a good target for high level language compilers). That would be my, a bit tongue-in-cheek, recommendation for hobby projects.As others had mentioned already, your requirements are too strict and unusual. Programming of Flash EEPROM over SWD/JTAG generally works for ARM (R. Pico makes it even easier, implementing a USB storage protocol) and is faster than UART. More peculiar is the quest for a BASIC compiler. It's not the eighties anymore. The step from BASIC to C isn't actually all that far and the latter is still (for the better or worse) commonly used and supported. Most of us made it (some 30 years ago) and don't want to go back.

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 01:56:13 pm
content: Quote from: tooki on September 13, 2025, 10:17:47 pmI'm not going to go into detail but I ended up in the ER three times in a 4 day timeframe, twice the same night. They promised me free yoghurt if i had to come back. Some of the medication makes it hard to focus and i am exhausted after an hour or two

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 01:59:46 pm
content: Quote from: PCB.Wiz on September 14, 2025, 03:03:57 amSorry. digikey/mnouser/TmeI'm not going down the ebay path

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 02:22:19 pm
content: Quote from: guenthert on September 14, 2025, 11:44:48 amWhat's unusual about- being able to download a program without requiring external hardware, out of the box off-factory ? Is that really so much to ask ?- 5 volt would be desirable but i can live with 3.3 volt- Easily solderable. TQFP is easy , QFN not.- obtainable through sources like digikey/mouserSo far the STM32 seem to fit the bill. So do several TI and NXP parts.

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 02:26:45 pm
content: Quote from: nctnico on September 14, 2025, 10:36:16 amI've been digging into the Kinetis MK series. the LPC is not supported by MikroE. But many of the MK series have a rom based uart bootloader.

author: DavidAlfa
author_rank: Super Contributor
timestamp: September 14, 2025, 02:39:09 pm
content: All STM32 have it.Set BOOT0=1 to enable the embedded bootloader.UART is the most basic one, the bootloader will also support additional peripherals depending on the model (I2C, USB...).

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 03:11:13 pm
content: Quote from: DavidAlfa on September 14, 2025, 02:39:09 pmyup. I'm now leaning towards either STM32 or NXP Kinetis (MK22F or MKV42 series). I'm a bit surprised the NXP devices often only have only one I2c ...The advantage is there's plenty of devices and i only have to learn the architecture once.

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2025, 03:15:57 pm
content: Quote from: free_electron on September 14, 2025, 02:26:45 pmThe MK series is formerly from Freescale (Motorola) which got bought up by NXP. The LPC series is NXP's own ARM series and is a continuance from their 8051 portfolio. Starting from the 8051 portfolio, NXP always had strong support for programming their microcontrollers over a UART. The protocol they use in their ARM microcontrollers is pretty robust (including checksums and retries). Maybe MikroE has support for the LPC series in the making but is not advertising it. Then again, Freescale documentation isn't bad either.BTW, to me programming microcontrollers through a serial port comes very natural as I have been doing this for decades. So don't feel outlandish for whishing to use serial port programming. Tools to do this are lightweight and don't need much in terms of installing software or exotic hardware (contrary to jtag/swd adapters which typically lean on some OpenOCD incarnation and other middleware). However, I did develop a rugged UART to USB interface for use in the field. Over the past 20 years I have yet to come across a customer or field engineer who didn't got the NXP serial port programming tool (Flashmagic) to work.

author: wraper
author_rank: Unknown
timestamp: September 14, 2025, 03:33:35 pm
content: Silicon Labs ships the vast majority of their 8051 and ARM MCUs pre-programmed with UART, SMBus or USB bootloader.

author: free_electron
author_rank: Super Contributor
timestamp: September 14, 2025, 03:45:34 pm
content: Quote from: nctnico on September 14, 2025, 03:15:57 pmCould be, but it's not there now. Anyway , if go down the ARM path i have plenty of choice. STM , MK , maybe LPC in the future. The number of ARM Cortex based machines is growing. ( MikroE also supports TI and even two Microchip devices that ate ARM based...).AVR and PIC are closed ecosystems. One vendor. Another reason i'm leaning towards Cortex: many vendors. Like the 8051 used to be. Everyone and their neighbor had chips with that core.QuoteOr worse.... only work with specific development tools. Like the Keil uLinks, IAR J-link (which are not true segger but bound to their tools. ). Segger is also a royal pain in the patooie. They are expensive, There's at least 5 hardware revisions. They don't support the older hardware with newer firmware anymore and the newer tools can't use the older hardware (who on earth uses a Mitsubishi processor anyway ? The first segger was a Mitsubishi micro...). A couple of months i cleaned out part of may drawer. I threw away at least 10 J-links and anther 5 or uLink and uLink2 boxes.that's the reason i want to ditch all of it.I've got plenty of USB<>uart boards, even galvanically isolated ones. and sticking an FTDI on a board for a project is easy-peasy . Never had a problem with them (offical, not shady fleabay bough ones).simple works. i like simple now

author: bingo600
author_rank: Super Contributor
timestamp: September 14, 2025, 04:30:37 pm
content: Maybe cheatingBut it seems like avrdude can "bitbang" program an AVR, using a ftdi.Seems to be ICSP, not UDPI.https://acedio.github.io/ProgrammingAVRswithFTDIcableorFTDIFriend/You could try on a Mega328 "Nano board" from your "drawer", along with one of the FTDI's you have.Btw:This url comes in handy , when using avrdudehttps://www.engbedded.com/fusecalc/See pict , for where to find avrdude arguments on the html pageYou could then use a Mega64/128 or even a Mega2560 MCU , for many pins.Plain jumper(s) would prob. let you use the ftdi as avr-programmer or avr-usb serialportOr CD4053 if going fancyEdit: According to the below, programming speed won't be "stellar" on windows.https://github.com/avrdudes/avrdude/issues/1253Latest download link for Win-64bithttps://github.com/avrdudes/avrdude/releases/download/v8.1/avrdude-v8.1-windows-x64.zip@VH here's the relevant part (definitions using - ftdi_syncbb) , snipped out of the avrdude.conf file.They just differ in how the ftdi pins are used & connected to the AVR chip.The id: "name" in the below table , would be what you specify as the-cargument to avrdude ... -c (~ cable name/type)Code:#------------------------------------------------------------# ft245r#------------------------------------------------------------# Ftdi_syncbb-type programmers utilise FTDI chips for programming# in a bit-banging mode. In contrast to avrftdi-type programmers,# the pin mapping to the main ISP signals (reset, sck, sdo, sdi) is# somewhat arbitrary and will be determined by the actual routing# of the FTDI IC pins to the ISP header of the physical programmer.programmer # ft245rid = "ft245r";desc = "FT245R based generic programmer";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;reset = 4; # D4sck = 0; # D0sdo = 2; # D2sdi = 1; # D1;#------------------------------------------------------------# ft232r#------------------------------------------------------------programmer # ft232rid = "ft232r";desc = "FT232R based generic programmer";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;is_serialadapter = yes;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403; # For use as serial adapterusbpid = 0x6001; # "reset = 4; # DTRsck = 0; # TxDsdo = 2; # RTSsdi = 1; # RxD;#------------------------------------------------------------# bwmega#------------------------------------------------------------# see http://www.bitwizard.nl/wiki/index.php/FTDI_ATmegaprogrammer # bwmegaid = "bwmega";desc = "BitWizard ftdi_atmega builtin programmer";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;reset = 7; # RIsck = 6; # DCDsdo = 3; # CTSsdi = 5; # DSR;#------------------------------------------------------------# arduino-ft232r#------------------------------------------------------------# This programmer helps programming the Arduino Diecimila, NG and# Duemilanove (but not the Uno) without bootloader or external# programmer using the on-board FT232RL chip. Instructions here:# https://make.kosakalab.com/arduino/bootloader/index_en.html# Note that the -c diecimila avrdude.conf entry mentioned in above post# is the same as the -c arduino-ft232r entry here.programmer # arduino-ft232rid = "arduino-ft232r", "diecimila";desc = "Arduino: FT232R connected to ISP";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;reset = 7; # RI X3(4)sck = 5; # DSR X3(2)sdo = 6; # DCD X3(3)sdi = 3; # CTS X3(1);#------------------------------------------------------------# tc2030#------------------------------------------------------------# See https://www.tag-connect.com/product-category/products/cables/ftdi# for details.programmer # tc2030id = "tc2030";desc = "Tag-Connect TC2030";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;# FOR TPI devices:reset = 3; # CTS = D3 (wire to ~RESET)sck = 2; # RTS = D2 (wire to SCK)sdo = 0; # TxD = D0 (wire to TPIDATA via 1k resistor)sdi = 1; # RxD = D1 (wire to TPIDATA directly);#------------------------------------------------------------# uncompatino#------------------------------------------------------------# There is a ATmega328P kit PCB called "uncompatino".# This board allows ISP via its on-board FT232R.# This is designed like Arduino Duemilanove but has no standard ICPS header.# Its 4 pairs of pins are shorted to enable ftdi_syncbb.# http://akizukidenshi.com/catalog/g/gP-07487/# http://akizukidenshi.com/download/ds/akizuki/k6096_manual_20130816.pdfprogrammer # uncompatinoid = "uncompatino";desc = "uncompatino with all pairs of pins shorted";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;reset = 7; # risck = 5; # dsrsdo = 6; # dcdsdi = 3; # cts;#------------------------------------------------------------# ttl232r#------------------------------------------------------------# FTDI USB to serial cable TTL-232R-5V with a custom adapter for ICSP# - https://ftdichip.com/product-category/products/cables/usb-ttl-serial-cable-series/# - http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf## For ICSP pinout see, e.g., http://ww1.microchip.com/downloads/en/DeviceDoc/doc2562.pdf# (Figure 1. ISP6PIN header pinout and Table 1. Connections required for ISP ...)# TTL-232R GND 1 Black -> ICPS GND (pin 6)# TTL-232R CTS 2 Brown -> ICPS SDO (pin 4)# TTL-232R VCC 3 Red -> ICPS VCC (pin 2)# TTL-232R TXD 4 Orange -> ICPS RESET (pin 5)# TTL-232R RXD 5 Yellow -> ICPS SCK (pin 3)# TTL-232R RTS 6 Green -> ICPS SDI (pin 1)## Except for VCC and GND, you can connect arbitrary pairs as long as the# following table is adjusted.programmer # ttl232rid = "ttl232r";desc = "FTDI TTL232R-5V with ICSP adapter";type = "ftdi_syncbb";prog_modes = PM_TPI | PM_ISP;extra_features = HAS_BITCLOCK_ADJ;connection_type = usb;usbvid = 0x0403;usbpid = 0x6001;reset = 0; # txdsck = 1; # rxdsdo = 3; # ctssdi = 2; # rts;

author: tooki
author_rank: Super Contributor
timestamp: September 14, 2025, 04:54:15 pm
content: Quote from: free_electron on September 14, 2025, 01:56:13 pmI’m genuinely sorry you have to deal with that, and hope it gets better.But that is going to be a challenge no matter what you choose. STM32 may have an onboard bootloader, but you may find it a much more difficult, complex MCU family in other ways. So whatever solution you go with, make sure you’re not trading a small problem for a much bigger one.Do youhaveto design your own PCB? Since this is a hobby project, could you design your board as a shield that just pops onto an off the shelf dev board?Quote from: free_electron on September 14, 2025, 02:22:19 pmHonestly, I think that’s quite unusual indeed. Folks, please correct me if I’m wrong, but I have the distinct impression that in modern manufacturing, MCUs are either purchased pre-programmed, or are initially programmed with some form of in-circuit programming that usually isn’t USB. Devices using full-fledged SoCs do seem to often be programmed with USB DFU mode as part of production testing.Quote from: free_electron on September 14, 2025, 02:22:19 pmThe 5V ship sailed years ago.Quote from: free_electron on September 14, 2025, 02:22:19 pmAgain, I think you’re being silly on that point. Again, it’s a ship that has sailed: most new ICs are coming out as some form of leadless package, often BGA (which cannot be soldered with an iron at all; reflow is the only way to do those). Even if you manage to avoid QFN for your MCU, it’s a problem you’ll run into with other parts.You said you have shaky hands: try using a microscope. Really. It might make a huge difference; it does for me. (It is normal to be much steadier under magnification. It seems to me that precision hand movement is limited by visual resolution, in the sense of %-of-field-of-view. Under a microscope, a small item becomes a much larger part of your field of view, so the same % of field of view represents a much, much smaller physical movement.) I have EVERY confidence that if you can drag-solder a TQFP, as you have said you can, that you can place a QFN onto some paste.Quote from: free_electron on September 14, 2025, 02:22:19 pmThis is the only one of your requirements that I consider 100% reasonable.

author: Berni
author_rank: Super Contributor
timestamp: September 15, 2025, 06:35:20 am
content: QFN is not hard to solder.With the right footprint and plenty of flux it is easier to solder a QFN than a TQFP. The pins on QFNs are not completely hidden under the package, they extend up the side, so with a sufficiently pointy soldering tip you can just drag it along the side of a QFN and it solders nicely. Any solder bridges can usually be easily fixed by just flicking them away with a dry tip. It is not that easy to fix bridges on a 0.5mm pitch TQFP (i just flood solder those anyway, they are too tiny to solder pin by pin). It is BGAs where the can of worms is opened, but very rarely are you forced to use those(plenty of non BGA alternatives).As said above use aopticalmicroscope, it makes the fine motor movements a lot easier. Also experiment with a few different random objects as hand rests around the work area. Finding a exact comfortable rest for your hand makes a huge difference with shaking hands.However when it comes to software sounds like drivers are your problem not the language.All of the modern 32bit MCUs are much more complex than the chips from the good ol 8bit days. You got fancy PLLs with >4 outputs, clock domains, multiple internal buses, caches, wait states, vectored interrupt controllers with priority management, protected execution CPU modes..etc This means datasheets get huge and also a huge amount of reading is needed to understand how to drive a certain peripheral. Then the vendor supplied drivers often try to be overly universal (while still somehow missing the most obvious use of the peripheral) and so end up a mess of C code that is hard to understand. The MCU configurator/generator tools are a way to skip all this mess (but they aren't always well made).Coding is C is not that bad these days because modern code editors have good syntax highlighting that alerts you to most mistakes while you type (Even the == versus =). I admit that C is not a great language by modern standards, but we don't have any good commonly used alternatives for the really low level things that C can do. The MikroE compilers are all the same compiler under the hood, difference is just in the syntax. Their MikroBasic is a pretty C-fied form of Basic so the code translates nearly 1:1 into C by just changing syntax.Id say stay with PICs and AVRs if you are not willing to get into the weeds of modern MCU development. If you are doing simple projects that don't need the performance of a 200MHz ARM CPU then you are not missing out on anything. You can still buy very old 8bit MCUs on Digikey/Mouser/Farnell..etc no problems. Programmers that can get stuff done within the limitations of a 8bit MCU are a dying breed, so hold onto it (the modern programmers expect particularly infinite memory and computation resources).

author: tycz
author_rank: Regular Contributor
timestamp: September 15, 2025, 09:54:25 am
content: I find QFN parts an absolute bastard solder. There is a little bit of pad on the side of the chip, but it's not enough to reliably hand solder to on recent parts. I've tried every method I've read about over and over again. The only 100% reliable way to replace a QFN that I've found is to remove it with hot air, remove all the components around it (and there's usually a lot, because I only used them in applications in which I'm space constrained), cut a stencil down to the minimum size I can get away with, stencil out some paste using a piece of old credit card as a squeegee, put it in the oven to reflow, hand solder all the components around it back on the board with the iron. The whole operation takes hours. I can believe that others can do it easily, but I absolutely cannot. I have good tools and reasonably good soldering skills (I replaced 25 0.5mm pitch TQFP chips in a single day earlier this year), but my experience too is that TQFP is easy, QFN is not!These days I try to use an 8051 core microcontroller if I can get away with it. Arm tool chains and peripherals are a bit too complicated for my taste. There are several companies in Asia making fast, 5V compatible 8051 micros. New parts come out every year. I think only STC Micro has built in serial boot loaders in everything, the rest need some kind of programmer. Not available at Digi-key either.

author: Berni
author_rank: Super Contributor
timestamp: September 15, 2025, 11:19:52 am
content: Oh the one thing with QFN is that they are much more sensitive to oxidation.If you are soldering old QFN chips that sat around for years then the pins oxidize and refuse to take solder. This happens with all chips and flux does eat it, but for QFNs most of the pin is hidden so it is harder to give the pin a poke with the soldering iron to help scrape trough the oxide layer. That initial scrape helps kickstart the wetting of solder over the rest of it.Drowning the chip in ridiculous amounts of good quality flux during soldering usually helps get around this. If it still doesn't work a last resort can be flipping the chip over and pre tinning all the pins using a soldering iron and fresh solder, flip it back the right way and try to solder it again. Of course all with good ol leaded solder, none of this lead free junk (the original pins are tinned in lead free).The other thing is QFNs with a heat dissipation pad in the middle, that does need hot air to do it. But you don't need any stencil or paste, simply pre tin both the chip and PCB pads with lots of solder, place the chip down and heat with hot air until it reflows onto the PCB. Using a microscope here helps a LOT as you can see the chip shift by fractions of a milimeter when the solder flows and pulls it into alignment.

author: tooki
author_rank: Super Contributor
timestamp: September 15, 2025, 12:33:54 pm
content: Quote from: tycz on September 15, 2025, 09:54:25 amFor repairs:Use proper thermal shielding to protect nearby components. (E.g. Kapton and/or aluminum tape heat shields.)Use hot air to remove old IC.Use board preheating so you can significantly reduce the amount of local heat needed.Clean up the pads, then use an appropriate tip to pre-load each pad with the right amount of solder. It doesn't need much.Clean it all thoroughly. (This may cause your heat shielding to release. Attach new heat shielding if needed.)Apply a high quality tacky flux to the all the pads, or to the IC.Place the chip onto the pads.Use hot air (again with preheating) to reflow the IC.

author: nctnico
author_rank: Super Contributor
timestamp: September 15, 2025, 12:59:52 pm
content: I strongly recommend not cleaning the pads except if it means removing old flux residu. In my experience taking tin from pads is very prone to taking the entire pad of the board. When I replace a QFN, I take the old one from the board with hot air, clean the board with ethanol (or another flux remover), apply flux and reflow the new QFN part using the existing tin. From there I touch up any pin which has too much or too little tin.For handsoldering QFNs, a footprint which has the pads extending by 0.3mm to 0.4mm makes life a lot easier. I use a round tip with a flat edge for getting into difficult to reach corners.

author: wraper
author_rank: Unknown
timestamp: September 15, 2025, 01:00:10 pm
content: Quote from: tycz on September 15, 2025, 09:54:25 amIt's quite a bit easier to solder than TQFP if you know what you're doing.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 15, 2025, 01:40:06 pm
content: Quote from: nctnico on September 15, 2025, 12:59:52 pmThermaltronics M7DS525 is really good for this - much better than the equivalent Metcal one, as the edges are sharper.

author: tooki
author_rank: Super Contributor
timestamp: September 15, 2025, 01:58:26 pm
content: Quote from: nctnico on September 15, 2025, 12:59:52 pmFixed those for you.I definitely agree to not using desoldering wick to remove solder from pads like that. Especially not with the wretched wicking technique so many people use. (They love to wipe around with it, which is exactly what you shouldnotdo!)But with vacuum desoldering equipment (especially with Pace's lovely Flo-D-Sodr tips designed specifically for pad cleaning), it's easy to remove excess solder without damaging the pad. Removing all the old solder has the advantage of ensuring that your reflow process occurs with a specific, known solder alloy.

author: free_electron
author_rank: Super Contributor
timestamp: September 15, 2025, 06:20:11 pm
content: i'm going to go with something ARM based. Largest ecosystem,Most likely STM32F070 to start.- UART or USB-DFU so i don't need anything. USB<>uart for loading and if i need a serial port.- i have the compiler- the datasheets are readable.- it's 3 volt only but i can live with it. I2C with multi domain I/o solves a lot. And in the few cases i need parallel I/O there are level shifters- tqfp 48 or 64. easy peasy to solder for me. And all the i/o i want.- lots of flash and ram for what i do.- everyone and their neighbor has stockThanks you all. case close as far as i am concerned

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 15, 2025, 08:57:09 pm
content: Quote from: free_electron on September 15, 2025, 06:20:11 pmYou do nothaveto be constrained to 3v, 5V is still very much alive.It is only if you chasevery high MHzin MCUs that 5V thins out.Mouser shows 164 part codes, in stock, for5VTQFP64 pin ARM MCU, from 20 ~ 168MHz

author: temperance
author_rank: Super Contributor
timestamp: September 15, 2025, 09:27:46 pm
content: QuoteSome GPIO pins are five volt tolerant and some I2C pins are 5 V tolerant and also support I2C FM+ mode.

author: free_electron
author_rank: Super Contributor
timestamp: September 16, 2025, 12:18:05 am
content: Quote from: PCB.Wiz on September 15, 2025, 08:57:09 pmI know. the compiler is an issue for all of those. I don't have anything for Toshiba/renesas/nuvoton/microchip/infineon.only NXP but not in the families that can run off 5vanyway, i can live with 3.3 volt. It's only for cases where i must have parallel I/O (like an 8 or 16 bit bus) to drive something time-locked in 5volt domain.reading buttons and driving led works in 3v3 just as well.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 16, 2025, 01:53:07 am
content: Quote from: free_electron on September 16, 2025, 12:18:05 am?They are all ARM cores, so compiled code should be quite portable.Or did you mean the language you have, does not have libraries support for the peripherals of all vendors?

author: free_electron
author_rank: Super Contributor
timestamp: September 16, 2025, 02:15:47 am
content: Quote from: PCB.Wiz on September 16, 2025, 01:53:07 amI don't care about the libraries. i write the registers directly from the datasheet .But for many ARM based machines there is a chunk of startup code to set up timers , the system clocks and domains, the memory access. Some peripherals sit on different internal busses. some port multiplexers. Sometimes even bugfixes.That is missing. And there is no mechanism to make your own. Not something i want to figure out how to do. Headache i don't want/need/ can't handle.Same for all the register names. Every named bit in every named register is predeclared as a constant/variable. So it's easy to write code. you can use the name from the datasheet directly.I know how to set up an i/o port, timer, adc or uart by twiddling the bits in the registers. But the startup is a different matter.