Yes, but I thought the whole point of DFU is that I wouldn’t need a sperate programmer, I thought the point was to be able to just use USB. Am I misunderstanding?
Only because I thought that would be a fun project and would make future projects easier. I’ll add RP2040 to the list to see if it will fit the bill, I’m striking out on finding chips with USB, I didn’t realize the shortage was this bad.
Not at all! I love all the info, but I’ve played around with lots of dev boards that I’ve had to program with JTAG or USART and that’s what I’m trying to avoid. I think being able to plug in a board I’ve made into the computer and be able to use it directly like that would be a huge win for me.
Gotcha - unless you find a source with a bootloader installed, I think you need at least a first-time SWD / SPI or similar programming interface before you can use the USB DFU mode. If you don’t plan on doing anything too memory-intensive you could try a SAMD11 (in stock at Digikey) but I don’t know how keen you are for an ICE programmer to get a USB DFU bootloader onto it.
There is a whisper that a new line of AVRs will come with native USB, but again I doubt that would be the main programming interface from the factory - it’ll still likely be UPDI. The other think to note about the new ATtiny and ATMEGA / AVR chips is that they do have the option of a UART bootloader, like the ATMEGA328Ps etc, so you could put a USB-serial adapter chip onboard. I realise things like the CH340G may also be hard to source in the simpler packages (that don’t need external crystal etc) but worth considering to widen you choice of chips if you don’t want to shell out for a programmer and just use UPDI to burn a UART bootloader.
I don’t know but you could perhaps use an ST Link to get an ST part up and running DFU for a cheaper entry, tooling-wise. From a quick look on Digikey, may of the available parts are STM32 L and G series. I think ST are trying to move people away from the F series, so learning L and G parts could be a good move. But I don’t know how much is out there on the bootloader/firmware front. I wouldn’t want to encourage you to go this route for you to get bogged down in drivers and registers, despite having fully assembled boards in your hands!
Another suggestion fora USB-native microcontroller is the ESP32-S2. It might sound a little weird, since they are mostly known for cheap WiFi, but the price/value on them is favorable enough that we’ve been using them for projects that don’t need wireless, and just don’t add the wireless components. They are actually available: https://mou.sr/3leiehI
They have a hardware USB bootloader, so no extra tools are needed.
A second suggestion if you are looking for low-cost development tools, is to use OpenOCD (https://openocd.org/) to convert a spare Raspberry Pi into a JTAG programmer/debugger- it can use the pins on the RPi to generate JTAG signals, so you only need some jumper wires to connect to your target project and get started.
It looks to me that some of the STM32 devices do come with a bootloader installed that allows reprogramming the flash through the USB DFU interface, I thought it was more common than it is. I have been looking through each datasheet at the Boot Modes section and some of them mention DFU but those are all the ones that are out of stock (like STM32F042x4 – https://www.st.com/resource/en/datasheet/stm32f042k6.pdf)
I’d be happy to look at some elements of this as I currently have two challenges:
I need some dedicated buttons next to my keyboard to make debugging across the various IDEs I use simpler - so I just press the button in front of me rather than try to remember the keypress or wave the mouse around the toolbar.
Eliminating the USB to serial from a PCB would be useful given that all the bits are there in something like the SAMD21. Inconjunction with that it would be super useful to be able to do some sort of firmware update with either a USB stick, SD card or, at worst, a small device that has an MCU + some sort of memory to plug in - at which point I could revert to SWD but if it’s done over serial a small OLED could also capture diagnostic data & or be used as a settings interface.
The Raspberry Pi PicoProbe config works well as an SWD programmer & OpenOCD programmer but I’ve not tried it on anything else. Alex Taradov’s Free-DAP looks excellent value (he sells them on Tindie for ~$15).
Generally I’m keen to keep life simple and I find the ATmega4808 as a SOIC does that nicely for me, I can wrap my head around the clock configuration, it’s got the useful extras like the CCL & Events and if the clients wants to co-develop the firmware, I can make it be an Arduino for which there are instructions on making a UPDI programmer from a Nano. Otherwise the SNAP debugger works nicely with Microchip(Atmel) Studio.
ATMEGA4808 (same series as ATMEGA4809, 3208, 1609 etc etc - good code and peripheral compatibility between them all, as well as ATtiny 0 and 1 series). I’m sure it wouldn’t have lasted long but didn’t want you getting lost in searching for 4080
Huh, thanks… I didn’t even notice since the search engines magically “fixed” it for me while searching, but it didn’t magically fix it in my hand written notes.
It doesn’t look like those parts can do what I want with USB, but they might come in to play for other side projects.
Like a game of Chinese Whispers! Seems it was a quote issue as I can’t see an edit on my post …
The ATmega4809 is its big brother, internals are the same but more pins. Generally I don’t find a use for all those pins and making a couple of boards on the bench with the human-pick-n-place is so much easier with SOIC.
I think I’ve landed on the ESP32-S2 for my first run at this one, it seemed like the STM32 and ESP32 had the highest chance of success but availability of an ideal STM32 is low.
Since I’ll get WiFi and a temperature sensor basically for free I might as well feature creep this project into a data logger to log temperatures in different parts of the house. I’ll add a rechargeable battery and experiment with how long I can run it from a battery.
I’ve played around with ESP32 dev boards through USART interfaces so I’m familiar with the ESP-IDF build environment and how to get the basics going, but the native USB is the new part I want to focus on for this experiment, so I’ll have to figure that out as I go.
Right, I’ve used vim and cmake so far, but I’ll want debugging too so I’ll add that to the list.
I went off on a little tangent with this project, I started off creating the symbol for the ESP32 and spent some time fiddling with what information I wanted in my symbol, I based it on a combination of a few that I’ve seen that I liked.
Then when I placed it in the schematic I got distracted by the page layout and wondered how one goes about putting a logo on their schematic which lead me down a path of bitmap2component → s-expression polygons → svg → Inkscape → svg2shenzhen → childhood inspiration…
In the end, I spent way to much time on it, but it was a lot of fun. This is what I came up with.
If you return to this symbol, you may want to add some more indication of special pin considerations. I can see you have IO0/BOOT0 labelled but there are also a few other considerations around “strapping” at boot. On the original ESP32 IO10 needed special care and from the ESP32 S2 datasheet it looks like IO45 and IO46 have this function. There may be other titbits to add? Anyway, I didn’t want you to get derailed, just wanted to say I find it helpful to warn myself about special pin considerations in the part symbol.
That’s a great point, I was struggling with how much to include with all the pin functions and not having something like RTC_GPIO14, GPIO14, TOUCH14, ADC2_CH3, FSPIWP, FSPIDQS for one pin.
The strapping pins (IO0, IO45 and IO46) have a whole page of info with a table of combinations, I’m not sure what to show in the symbol to indicate that, but I think it’s a great idea. Do you have any examples on what would be a good indicator for that?
Which is a good plan, seeing how many pin functions can be reassigned IIRC.
I don’t have a good strategy other than to make it something that will jog your memory when you see it. Perhaps have an ASCII scheme of symbols that mean something to you, such as an asterisk for boot-related pins, maybe another symbol for the main peripherals you’ll likely use.
Looking at the module datasheet, maybe put something in to remind you not to leave EN floating? Maybe the ^ symbol? Also, I don’t know if you have a footprint yet for this module but you may want to number the GND pin(s)/pad(s) so the symbol matches up with the footprint.
There are also these notes in the pinout, which may be worth representing somehow:
IO18 on the module is pulled up to VDD33 through a 10 kΩ resistor. For details, please refer to Figure 5 and Figure 6.
IO26 is used by the embedded PSRAM on the ESP32-S2-MINI-1-N4R2 and ESP32-S2-MINI-1U-N4R2 modules, and cannot be used for other purposes.
Thanks for the input @smerrett79, I really like the idea of having that info there right in the symbol. I fiddled around with it a bit and came up with this:
The GND pins and pads are all numbered, they all match up with the symbol, all of the GND pins exist in the same location in the symbol so I can connect them all together easily
Great, that looks more useful already. Please ignore if this input is taking things too far but I’ll offer it in case it’s welcome:
KiCad has some conventions when it comes to parts that the project would include in its “built-in” libraries. First one that comes to mind is using background fill for the part box. S3.3 Symbol outline and fill requirements - Library Conventions | KiCad EDA I think the fill colour disappears (to white) if you export a black and white version of the schematic in pdf, so it shouldn’t impact readability if printed on paper, for example.
The second one is that they place power pins top and bottom, and put port/GPIO pins in memory order, rather than where they leave the package physically. S4.2 Pins should be grouped by function - Library Conventions | KiCad EDA I find this latter aspect frustrating when assigning pin roles in my schematic capture so I often ignore it when making my own parts. But just letting you know.
As I said, please ignore those considerations but I thought I’d highlight them while we’re talking about symbol creation.
I would also point out that I think the note about IO26 only applies to the N4R2 version (has the PSRAM and the N4 doesn’t?), and I didn’t want you to feel limited on that pin if you were using the N4 version (although the small price difference and perhaps better availability may make you want to plan not to use IO26 so you don’t have to worry about which version you can get your hands on).
I note something that is interesting to me about the ESP32 S2 MINI 1 schematics, which is that they have a filter on their 3V3 power input but apparently not on their VDDA analogue power input.
. It’s similar on the original WROOM modules too, so I wonder why they do that. I would have thought you want the analogue supply to be more filtered than the main supply. But I’m sure they know what they’re doing!
