I'm currently in the process of designing a PCB featuring a Master (ESP32) and Slave (ATMEGA1284) setup, communicating via SPI. My primary motivation for this design choice is to expand the available analog inputs, PWM ports, and UART ports. After extensive research, this approach appears to be the most straightforward and cost-effective solution compared to interfacing multiple ICs with the ESP32. Consequently, the Slave will require a basic program to access all peripherals, with potential future updates in mind.
While I've successfully programmed the ATMEGA1284 via ICSP using the Arduino IDE and another Arduino board in the past, I haven't come across an example online matching my current project requirements. However, technically, I see no reason why this wouldn't be feasible, especially considering the ESP32's ample 16MB flash memory.
My query revolves around the possibility of attaching the compiled binary file of the Slave MCU's program to the Master program for storage in the Master MCU's flash memory. Upon startup, the Master Controller would query the Slave regarding its software version. If a mismatch is detected, the Master Controller would then rewrite the Slave program using the binary data stored in its local memory.
Ultimately, I aim to streamline the process of updating both the compiled ESP32 firmware and the ATMEGA1284 program simultaneously, possibly via URL uploads for the ESP32 firmware. This capability would be particularly beneficial for remote nodes where physical access is limited.
I've also contemplated whether the IDE could facilitate a link between the master and slave sketches, though it seems such functionality either doesn't exist or has eluded my search efforts. Any insights or guidance on this matter would be greatly appreciated
An even more cost-effective and straightforward approach is to select a single microcontroller that has the peripherals you need. Since you're making your own PCB, you can through whatever you need on there. My guess is that there will be several controllers in e.g. the STM32F4 line that will meet your needs, and these are generally even programmable with Arduino ('STM32Duino'). Just make sure to pick one with lots of memory, because the STM32Duino core is kind of inefficient. But it works fine.
Alternatively, use an ESP32 module with the number of I/O's you need and use an external ADC for that part. This can be convenient if you need BLE or WiFi.
If you provide a list of what you need in terms of interfaces, perhaps we can offer some additional solutions.
Indeed, technically it's feasible, but the fact that you don't see anyone do it should ring a bell. It's a roundabout way and probably not the most convenient way of handling your project requirements. It sounds like a kludge to me.
In principle it could work; you could interface both MCU's with SPI and as you said, have the ESP32 query the slave for whatever you want to know - over SPI or maybe I2C; IDK how you're going to do the regular interfacing. Then if you see the need to, put the 1284 slave into programming mode and reflash it with whatever data you have on the ESP32. It doesn't really matter where that data comes from; you could store it someplace on the ESP32's SPIFFs for instance.
However, even if you opt for this somewhat oddball twin-head concept, I wonder how much effort you should put in creating an elaborate scheme for updating the 1284's code. If the 1284 is basically just a dumb I/O extender, just develop its firmware, troubleshoot it, test it thoroughly and then leave it as is. I have a system running with a couple of auxiliary controllers and a main unit (which is one of the experiences I base my advice on to not opt for this approach; it doesn't make much sense) and I've never found the need to update the firmware on the slave controllers. They handle fairly simple tasks and once they work, they keep working. If you do find a bug two weeks down the road, fix it and reprogram through a physical SPI header or something. Adding that header to your PCB will be vastly less work than trying to manage a complex setup for updating firmware - which is bound to fail somehow when you actually need it and you'll find yourself digging into the hardware anyway.
Reconsider the plan; it's likely to be a waste of time. (In fact, not just likely - I can guarantee it.)
I completely agree with your point about selecting a single microcontroller that includes the necessary peripherals. I opted for an ESP32 module some time ago due to its integrated Wi-Fi capability, which eliminates the need for additional Wi-Fi design work. Additionally, I already have ESP32 modules on hand ;).
Although the STM32F3 is a good choice, it lacks the Wi-Fi functionality I require.
Honestly, I'm not a fan of the twin-head concept for many reasons. Initially, I considered using multiple SPI ICs to expand my IO requirements, but I quickly realized that this approach would result in four times the number of components to solder at nearly three times the cost of simply adding another MCU. However, in this case, my minimalist mindset outweighs my purist tendencies.
Yes, a long time ago I programmed a Atmega328 with ESP8266 through the Arduino IDE in this way.
I want to remember that was a bit of a faff around to get it going.
Maybe I can adapt that approach.
Thanks for pointing firmata out, I definitely need to spend more time reading through it.
It sounds like something that may have been very useful when did a couple of Raspberry Pi-controlled drones / autonomous robots where the Pi was communicating with an Arduino Pro Mini to drive servo's, motors, monitor batteries / sensors, etc.
I've also been considering the approach of developing the Slave MCU program to function at its lowest level, thoroughly testing and debugging the firmware, and then leaving it as is. That's how I used to handle things in the past. However, I'm trying to plan ahead in case there's a bug, a new idea emerges, or I need to repurpose IO for something else. This way, I can upload a new firmware remotely without needing to be on-site.
Just to give you some context, the first controller will be located 8000km away from where I live, and the individuals on-site aren't proficient in programming MCUs. So, I'll likely need to provide remote support 99% of the time. Fortunately, I'll have a replica with me, performing essentially the same tasks, allowing me to test here. I've anticipated the need for additional functionality in the future, making it impossible for me to test everything before deployment.
Perhaps to simplify everything I should consider implementing a second firmware upload URL on the embedded website and programming the slave through SPI. This should only involve software changes, which I can always add later if necessary. For now, all I need is access to RESET, SCK, MOSI, and MISO to program it. I have also connected SS and PB3 to the Master for communication purposes.
and for completeness: the 1284 has plenty of RAM and can handle a pretty big project. so if that is an option, you can use the esp32 with AT firmware as WiFi adapter with my WiFiEspAT library. my ArduinoOTA library allows for self update of the 1284.
I understand the situation and I might do the same in your case. Although I'd probably try everything in my power to avoid any situation where a firmware update would be necessary, let alone of the 'buried' slave microcontroller.