ESP32 Proffieboard

Proffieboards
1

Since ST-micro doesn’t show any sign of getting their house in order, it might be time to consider the alternatives.

One particularly tempting alternative is ESP32, due to its built-in wifi and bluetooth. This thread will chronicle the trials and tribulations of porting ProffieOS, figuring out if the hardware will actually do what I want, designing a a board and, if everything works out well: launching it. (I can feel your excitement right now, but hold on, this process takes months, and may fail at any moment…)

5 Likes
2

Ok, so let’s start with an idea: Imagine a proffieboard with no USB connector!
Instead, we would program it wirelessly and also upload fonts wirelessly. If done correctly, there would never be a need for opening your saber to access the board.

But what about charging you say?

I think we should just embrace charging through the pogo pin PCB. (Or whatever else you’re using to connect to the blade.) All the normal options, like charge ports, replaceable batteries and separate USB charge PCBs will of course also work.

IF the new board has some sort of deep sleep (which ESP32 does) and we charge through the pogo pin PCB, then there is no need for charge ports, which would reduce the wiring needed quite a bit.

3 Likes
3

Would it still need an as card?

4

Ok, first problem:

The ESP32 bootloader mode doesn’t actually let you upload programs using WIFI or Bluetooth. In fact, it doesn’t even support USB, only serial uploads. The standard way people work around this is to use a USB-to-serial chip and wire up RTS and DTS to the boot and reset buttons so that we can get the board into bootloader mode by changing some settings on the serial port.

Of course, if we don’t have a USB port, that won’t work very well…

My idea is to have a secondary bootloader on the ESP32 board. This bootloader would support wireless uploads. (Which might be easier said than done, but more about that later.)

The secondary bootloader will need a button or something to trigger it. There will also need to be a way to trigger the built -in bootloader, so that means more pins are used up to control how the board boots unfortunately.

Originally I was thinking that since the bluetooth is builtin, we might not need to have pads for the serial port on the board, however, in order to make it possible to use the built-in bootloader, the serial port must still be accessible somehow.

1 Like
5

Not sure yet.

6

So I spent an hour making ProffieOS compile on ESP32, but without audio, motion and ws2811 support, which takes more work. However, something is crashing, so now I have to figure out how to set up a debugger.

Looks like debugging on ESP32 is pretty similar to debugging on stm32l433, except it uses JTAG instead of SWD. JTAG requires four pins instead of two.
So, in addition to RX, TX, and BOOT, we now have TDO, TDI, TCK and TMS. For the most part it’s just me that does any debugging, but for me it’s very important to have these available somehow.

On the V3 board, I put some pads on the bottom of the board and used pogo pins to access them. This works, but still takes up a fair amount of space. Also, most ESP32 processors don’t have that many IO pins, with 7 pins already consumed, I’m not actually sure if there is enough left or not. A proffieboard needs at least 22 gpio pins, but ideally it should have 35!

As if that isn’t enough, ESP32 has four strapping pins (BOOT being one of them) which has to be left alone at boot time, or it will try to do something different while booting.

I’m considering something like a PFC cable for all of these pins that most people won’t need. That still takes up quite a bit of space on the board though. :frowning:

1 Like
7

Wireless programming is going to be kind of tricky to get it to work the way I would want it to…

What I would want is ideally:

  • super simple
  • always works
  • secureish (so you can’t reprogram someone elses saber remotely)
  • no need to open the saber to reprogram

I’m not sure I can have all of these though.
My first idea was to make it so that if you hold the power button while the saber is booting, then it goes into bootloader mode. I’m not sure how that would work if you don’t have a kill switch or kill key though. I mean, I could put a reset button on the board itself, but then you have to open the saber to program it…

The next issue is that wifi is not a point-to-point protocol, and really the only way to establish a connection between a computer and the esp32 is to have the esp32 know how to connect to the local wifi, which means it has to know the ssid and password to use. Once it’s connected we can use zeroconf or some other kind of broadcast to find out the right IP, and then we can talk to it.

Now, blutetooth on the other hand is a point-to-point protocol, and it comes in two flavors; BLE and old-fashioned bluetooth. Old-fashioned bluetooth has the Serial Port Profile, which would be nice, because it could show up as a port on the computer, which could be selected in Arduino and programmed. However, only some of the Esp32 chips support old-fashioned bluetooth, and those chips don’t have enough pins to work well for a proffieboard.

The last candidate is BLE. BLE is weird, but it’s low enough energy that we might be able to keep it on most or all of the time, which is cool. BLE is a slow, but, maybe I can set it up so that we send the SSID and password for the wifi over BLE. Then we use wifi from there.

None of this is great though. If you type in the wrong password, how will you know?
What if you’re away from home and trying to program the board in a location that doesn’t have wifi? There are a million things that could go wrong, and identifying and fixing them might not be easy. Also, this only works if the computer has a bluetooth adapter, which is not always true for desktop computers.

An alternative would be to have the esp32 act as an access point, and you connect to it to talk to it. Again, this might not work for desktops, and some computers and phones don’t like it when you connect to an access point that has no internet access. Also, it can be tricky to convince a computer to be connected to two different access points, so in most cases it means that you loose internet access while connected to the esp32 access point.

It would also be possible to do it the other way around; have the computer act as an access point and have the esp32 connect to it. Most computers nowadays have an internet sharing mode where they can be both an access point while also being connected to a separate access point, but activating that is generally done through some control panel option which is not particularly simple, and I don’t know if it’s even possible to have a script running from inside arduino activate it. (It probably requires admin access.)

Ok, so far none of these options are simple, reliable and always works. :frowning:
Maybe cables are better…

1 Like
8

One possibility would be to use the SD card as a way to program the board.
Basically, every time the board boots up, it would check the SD card, and if there is a file with a certain name. (Let’s say “boot.bin”) it would compare that file with the program in it’s memory. If it doesn’t match, it would load boot.bin into memory before running the user program. The idea here is that ProffieOS should have a way to access the files on the SD card remotely, and if we have that, we could just store the file, then reboot when we want to reprogram, and if something is screwed up, it’s always possible to take out the SD card and put a new boot.bin on there that way. Also, users might need to do this the first time they program the board. Doing it this way also makes it less likely that the programming will fail. If the transfer is not completed, boot.bin would be ignored, and if the programming is interrupted while transferring boot.bin to internal memory, then it would notice that next reboot and just redo it.

PS: if you made it this far in the thread; congratulations :slight_smile:

6 Likes
9

Sounds like a really cool alternative! While I don’t have the electronics knowledge to grasp the details of it all, I think I can still follow it.

Besides the ESP32 CPU chip, what other alternatives do you have in mind?

10

Two questions:

  1. is there such a thing as a gpio extender? Say a small daughter board that communicates with the main cpu via i2c or canbus or something, and which can add additional gpio pins?

  2. I forgot the second question.

  3. oh right! How about a programming blade plug? Maybe with a USB port or sd card slot in it?

11

Also, slightly off topic, but how do nordic’s Processors like their nrf5340 compare? I believe that one has like 48 gpio.

Edit: mouser currently has almost 6000 in stock. About $10 a piece.

12

This would be very popular with the “other” crowds.

2 Likes
13

I love this discussion! I’ve been thinking about the ESP32 since that old thread (Crazy idea of the day: ANOTHER proffieboard - #22 by profezzorn). That and the RP2040.

No USB charging port

Yes! Charging through blade connector should be the norm. No need for USB for charging, and you can easily add one later if you want (just solder a USB connector to the charging pins).

Wireless firwmare upload

This would be really cool, but seems hard. Doesn’t this limit you to 1/2 the flash space? (Since you need 1/2 the flash space to store the new firmware before updating).

ESP32 I think has support for arduinoOTA? But you need to get the first OTA firmware on there, so chicken-and-egg problem (solved by SD-card uploading?).

Use case: end user - in this case, I’d want the proffie to be the AP, I connect to “proffie-wifi” with my phone, and upload the firmware by browser / captive portal. I’m less sure how this would work by bluetooth… would we need a custom app to do that? Not as supported as wifi is?

Use case: developer - here it’d be nice to have the proffie connect as a normal wifi client (infrastructure mode) so I can repeatedly upload from dev-machine. But in this case it’s fine to have ssid/password saved, since I’d only be doing active development at home.

BTW, I’ve usually seen a mix of AP and Infrastructure modes… The proffie boots up. If it has an SSDI/password saved, then it connects to that wifi. If it doesn’t (or it can’t connect), then it falls back to AP mode automatically. And you can connect to AP mode to upload firmware or save the ssid/password. Best of both worlds.

SD card upload

Yes! For end-users this would be really nice and simple. Grab SD card, copy the file, reinsert card and turn on saber. Not great for iterative development, but that’s ok.

I also love the idea of only doing SD-based uploads, but allow transferring boot.bin to SD over wifi. Again, best of both worlds (plus no need to waste 1/2 the flash space for wifi OTA?).

no need to open the saber to reprogram

That would be nice, for sure. I’d be just as happy with opening the saber when I need to update and hitting the “update” button (or holding down something while I power on), seems like a fairly small/simple step for an infrequent action.

I would not want the saber reprogrammable by default all the time. Maybe if I’m doing iterative dev at home, but otherwise no. Just too hackable/vulnerable.

helping out…

I don’t have a ton of time, but I wouldn’t mind helping if there’s something simple I could do. I have an esp32, motion, sound, etc.

14

Almost any CPU can work as an GPIO expander, but there are a lot of problems with doing it this way, like more power draw and board space…

No you didn’t

Not entirely out of the question, but tricky without adding more pins to the blade connector.

Well, they don’t have wifi, and they are not dual-core. Other than that, I’m not quite sure yet.

I’m not sure it will be, because it wouldn’t be a text file you edit. Instead you would run arduino, compile, then copy the output to the SD card.

No, that’s only the OTA-with-fallback solution. In my case I’m planning to have a small “factory” partition which would have the bootloader. The rest would be available for the sketch.

Even if it was only half the flash memory, ESP32 modules tends to come with 256 times more memory than a Proffieboard, so it would still be fine…

I’m not sure what ArduinoOTA is, but if it’s what I think it is, then it just uses the ESP32 ota method, which basically puts the bootloader and the application together. This makes sense if you’re making a long-running application that needs to be able to update itself from the internet, but it does’t make so much sense for programming through arduino. In that case I think it would be much better to have a way to boot the board into bootloader mode, then you can upload the program.

This could definitely work, but of course, it’s more work and more complications.

15

A few more ideas for how to go into bootloader mode:

  1. I could make it so that it only goes into bootloader mode if you hold power while:
    1a. powering up
    1b. reseting the board
    1c. connecting a blade plug charger (I might need a new circuit to detect this.)
  2. I could use the always-on-processor on the ESP32 chip to detect when someone holds the power button for a long time and put it into bootloader when that happens. Unfortunately I think there are reasonable use cases for holding the button for a long time, so it might not be reasonable to do.
  3. I could abandon the whole “don’t need to open the saber” and require people to push a button on the board to go into bootloader mode.

I think I like (1) the best.

16

nordic processors with bluetooth and RP2040 mostly.
I’m open to other suggestions.

17

Do you have the code in a branch yet? Just curious (I actually started one for esp32 way back, but only got like 10 lines in)

18

no, the code is only on my machine at home so far.

19

Could the bladeid pin be used?

If one were willing to have a fancier (read: more of a pain in the butt to build) blade holder, one might be able to add some horizontal pogo pins around the inner cylinder of the blade holder that would act as the needed additional pins. For a normal blade they wouldn’t be used, but for a programming/charging blade plug they could be. Maybe something like this or this.

20

blade id is the same as the data pin
blade detect is separate, but goes to the same ring as + or -