It could be spliced in with jumper wires since the processor itself is the same.
These little ESP32 boards do tend to have the same or similar board-edge pinouts. It’s a question of routing the PCB traces. The processor orientation on the board that produces the shortest and most direct trace runs to the edges is going to be the same for every board of this size with this processor.
This particular ESP32 may not match up with the cyberbrick’s, but that doesn’t mean there isn’t one out there that will… there are a pissload of suppliers making boards in this space.
It might be easier to create new Receiver And Transmitter boards that match the alternate core footprint. Other than level shifters, those boards are pretty much passive and significantly easier to solder.
It is interesting that BL packed a lot of function into those little core boards and they’re priced very low. If it weren’t for this penchant for ‘security’ they’ve embedded in the board it would be universally useful.
Not so much, no. The functionality you get on that board is pretty much the same as what you get on any ESP32 board of the same size. It’s the ESP32 chip that packs all the functionality inside. All the BBL board does is give you an easier way to connect to and use the chip…
These chips support secure FW. Part of their core functionality. They’re targeted at IOT type use cases where you wouldn’t want anyone to be able to load unauthorized FW on it.
Did BBL need to enable those features? No. Except that doing so locks you in to the BBL ecosystem so you need to buy from them even though you can get the exact same MCU cheaper other places…
Maybe I saw it too late, the CyberBrick core board has built-in security features that can protect creators’ JSON configurations from being stolen. If you flash a third-party firmware, this will cause the security feature to fail! And it cannot be recovered!
I must have hit this same broken configuration situation when trying to trouble-shoot my left-spinning-only controller.
I’m guessing mistakenly flashing the bot’s configuration onto the controller is what’s doing it.
I can connect to the board, and flash updated JSON configurations, but it’s reading in the App as a Receiver type, and won’t go back to being a Transmitter. Any attempts to re-configure will fail at the bot to controller pairing stage.
I’m guessing there’s no obvious way to revert and re-flash the firmware. Checking the firmware status in the app just says it’s “up to date”
If you look at the code in rc_main.py, you’ll see that the role (master or slave) is determined by the state of GPIO10. Which, I believe, is hardwired on the shield board. TX would be one way, RX the other. So… I’m not sure how you could not have the right general function if the boards are plugged together properly.
So… I’m not sure how you could not have the right general function if the boards are plugged together properly.
Hmmm, given that I started having issues with that controller sending a continual “turn right” which appeared to be a fault in the Transmitter shield (based on using the other controller to test the pieces individually. The “stuck turning right” behavior followed the shield, not the core or joystick, etc.
Here’s hoping I can get a replacement sooner than the end-of-the-month store restock for general availability.
If you have a meter you can check out the GPIO 10 level. If it’s high (>2.2V) then the core will take on a ‘Master’ role, which is a Remote Transmitter. If the level is low (probably close to 0V) then the core will take on a ‘Slave’ role, ie receiver.
You should be able to measure between GPIO10 and GND easily.
Do this ONLY when the core is plugged into the respective Shield. Although, if you do this without plugging into a shield then you might be able to see if it’s shorted on the Core board.
