Anyone interested in "Dual" ATMEGA2560/other boards GPIO Craze? Or other Boards?

[ThePeoplesLab]

Hello all! I am currently in development of a whole host of  a "Custom" Line of Arduino boards. I Have a few Ideas in the pipeworks with some pretesting but are there anyone that would be interested in "Dual" Arduino Boards? Ones that I am currently designing are Dual MEGA2560, connected over I2C (One layout with 2 "standard" Uno Shield headers, another focusing Over 100 GPIO pins in a smaller Area). Also working on a ATSAMD21 in conjunction with a MEGA260 as well.) Is there any combinations i have yet to say that someone would be interested in? Also are there any other board ideas that people have and would like come to fruition through them at me I have too much free time Coupled with the ambition to start up a Makerspace based in USA, Springfield Missouri. Any ideas or general warnings or tips are welcome!

                                                                                                                                                                                                                                                                                                                                            - T    Tavian             
    P.S If anyone is interested I will have a Theoretical Pin out diagram available for the Dual MEGA boards Shield friendly and "compact" footprints in a week or two should there be some interest.

[Rerouter]

Don't hold interest in it, But I have to ask, Why I2C?, literally the slowest interlink on the device, You have an SPI peripheral you could bump up to CLK/2, or equally a USART operating in a synchronous mode again at CLK/2

As a start, is there a reason you chose the Mega2560?, the Due which didn't really take off had 103 GPIO on its raw chip (but was still my favorite before I began spinning my own dev boards) and the price of 2x 2560's is pretty much on par with a Due, (ATSAM3X8e)

[ThePeoplesLab]

I chose I2C  as a proof of concept because I have limited software experience and what experience I have was at a Robotics Startup for a month and we used I2c over multiple 2560s and a Nividia Jetson. though I might as well Learn a bit and use what you suggested as I am not incredibly familiar with Communication interlinks and haven't done the research on them yet. Also I overlooked the Due as well because I didn't look at the raw chip I just saw the same layout as the 2560 on the arduino branded board. I feel 206 GPIO pins would be a challenge to use XD. But Also feel that a Dual 2560 would still be useful because the ATSAM3x8e Isn't GPIO 5v Friendly. And 103/206 Bidirectional Logic 3.3/5v converters would be pretty bulky :p though you definitely gave me something to think on thank you!           -T

[MrW0lf]

Just my 2 cents... My bg is high level programmer so I'm really too lazy to deep dive into MCU stuff, optimize things at machine code level etc. Originally I had trouble with Unos because I needed several processes doing different time critical things at same time. Ended up using several Micro boards. Later did some stuff on Due because it was much faster and this worked around process response time issues. However Due has some other drawbacks (compatibility) and is bulky. So from that perspective I sort of see point to having "multicore" Arduino that is compatible with all regular libraries in much more compact format than Due.

[sokoloff]

As a learning exercise (how to make it work, how to make a PCB, how to write software libraries, etc.), this is an interesting project.

As a business endeavor, it's overwhelmingly likely to bomb. Why?
Because there are already faster and even dual core boards/modules on the market for just a couple bucks. (ESP32 and perhaps others.)

[JPortici]

aside the "WHY the 2560", how do you propose to handle the programming and the debugging of the two cores simultaneously?
Well, debugging is a strong word, as you have only a software trace through UART..

This is the main reason I (and many other people) prefer a single gigantic higher performance MCU instead of two smaller MCUs.
This until cheap and easy to use multicore MCUs came out, such as the LPC54000 (which i prefer over the older multicore LPCs.. newer peripherals.) or the dsPIC33CH series

Anyway, if i were in your shoes i'd ditch I2C immediately. For inter-mcu communication I would use a high speed full duplex UART channel (maybe with CTS/RTR signals) or SPI. With UART you could implement a protocol for master-slave communication or have two independent unidirectional links.
If you have a desire instead of making 3-4-n cores boards in the future i would instead design the thing to use CANbus: each core would have a set of IDs such as 0xn00 to 0x0nFE for core n data broadcasting among all the cores and reserve ID 0xnFF to implement point-to-point communication as per ISO 15765-2. CAN introduces a bit of overhead but it's easier to scale

It's surely a fun project for learning and experimenting the concept of multi-MCU systems and the problems that arise in these situations..
If i were you i would take a look at multi-core MCUs like the two families i mentioned before, to see how they solved (internally) the problems of master,slave,intercommunication,resource sharing

[ajb]

I don't see the advantage of using more than one MCU unless they need to be physically separate.  Hardware and programming wise it'd be easier to use a single higher pin count MCU.  That typically also means getting into a much more powerful device as a bonus.  Plenty of Cortex M-4s and M-7s in 208-pin QFPs.  That gets you something like 150+ GPIOs, USB, ethernet, etc, and the horsepower to actually use it all--even a single core part is going to get you 200+ MIPS at 32 bits vs 2x20MIPS at 8 bits, not to mention sophisticated DMA, optional FPU, etc.

The downside is bringing the Arduino library infrastructure to such a part, if it's not already in place, is not going to be trivial.  Honestly, working out Arduino ports for some of the existing cheap ARM dev boards is probably a more worthwhile pursuit.

[JPortici]

That's true, but once you sort the system architecture you can benefit from having multiple cores.. If you use a lot of interrupts or context switching for tasks that do not have to communicate between each other you can find out that a big beefy MCU still isn't enough.
Case in point, i did a prototype with a dsPIC33EP512MU814 which until very recently was the beefiest of dsPICs (tons of peripherals,with dual can and usb, 144pin 70MIPS, 16bit) and at 70% of implemented functionality it was starting to struggle.
The PIC32MK and ARM that ticked all the boxes (and were available at the time) didn't do a better job, they were almost on par despite the much higher advertised MIPS.
Now the dsPIC33CH is out, having an improved core (straight out faster, three times faster hardware division, reduced context switch latency) and being dual core, the workload can be shared between cores which means less time is wasted between contex switching because the switching happens less often so i don't even have to go full throttle to have 100% functionality. being dual core i don't have to solve the problem of programming or to set up fast communication busses and i can debug both cores at the same time (with 2 debuggers of course)
The icing on the cake is that it's cheaper than all the other options.

I still think this project can be an interesting one

[ThePeoplesLab]

aside the "WHY the 2560", how do you propose to handle the programming and the debugging of the two cores simultaneously?
Well, debugging is a strong word, as you have only a software trace through UART..

This is the main reason I (and many other people) prefer a single gigantic higher performance MCU instead of two smaller MCUs.
This until cheap and easy to use multicore MCUs came out, such as the LPC54000 (which i prefer over the older multicore LPCs.. newer peripherals.) or the dsPIC33CH series

Anyway, if i were in your shoes i'd ditch I2C immediately. For inter-mcu communication I would use a high speed full duplex UART channel (maybe with CTS/RTR signals) or SPI. With UART you could implement a protocol for master-slave communication or have two independent unidirectional links.
If you have a desire instead of making 3-4-n cores boards in the future i would instead design the thing to use CANbus: each core would have a set of IDs such as 0xn00 to 0x0nFE for core n data broadcasting among all the cores and reserve ID 0xnFF to implement point-to-point communication as per ISO 15765-2. CAN introduces a bit of overhead but it's easier to scale

It's surely a fun project for learning and experimenting the concept of multi-MCU systems and the problems that arise in these situations..
If i were you i would take a look at multi-core MCUs like the two families i mentioned before, to see how they solved (internally) the problems of master,slave,intercommunication,resource sharing

First off JPortici (and any others that read this) I apologize for any Grammar or Just bad English Its been an overnighter working on this project     I Jump around alot and have many questions.  Thank You though for your advice!
                                                                                                       -T


I mainly chose the 2560 because of my familiarity with it and the 5V tolerance and the 100 surface mount pins to solder instead of over 190 for some Mic mentioned here. ( working in a garage for now though boards will be through JLC probably).Yes after some research it may not be the most powerful or practical idea to use but it does seem a good solution for ~100 5V tolerant GPIOs with only 2 "cores"

  Also I will absolutely take your advice ditching I2C for a main inter-mcu communication as it is slow and the MEGA only has one I2C bus using that as a sole inter-mcu communication would cause problems if using 2 sensors with the same address(with I believe should be an expected feature from a dual Mega board), though Probably run it though a Header Bridge or a DIP switch package on Prototype boards Just to have there or not (I have limited software knowledge so far but i am definitely learning with these Projects)

After doing some research I would definitely involve a serial communication, SPI seems very straight forward tough seems slow as its only a send and reply communication, but another downside to SPI would be the sacrificing of pins 53 to 50 pins for each controller for the SPI bus. I did some research on UART connections it was a little much to wrap around but does seem like the "standard" and makes the most sense to use after researching. Though I couldn't find any documentation of CTS/RTC with "arduino to arduino" communication just a few people bodging routers to be hacked with Unos. (If you know of a good page for that I would gladly look into it more.) with each Mega there are 4 RX/TX pairs though all are on the "uno shield" layout which could (possibly?) cause some problems with some shields though through another Pin Header Jumper Or Dip switch it could be made to switch between the pairs 1-3 leaving Pair0 for the USB programming. But still enough to have Master-slave or 2 independent unidirectional links as you stated.

 The Canbus does seem interesting to use though would need 4 canbus ics to get working. also would using this as a MAIN form of communication on intensive core to core communication projects hang up the SPI bus not allowing it to be used for other SPI sensors or peripherals or is it in most cases able to be swapped back and forth between an lcd for example with no problem?

Could you please clarify what you meant with "If you have a desire instead of making 3-4-n cores boards in the future i would instead design the thing to use CANbus"   did you mean like 3 or 4 chips on the same board?     

  My first choice I have for Programming would be separate USBs and USB to serial ics allowing serial access to both boards at the same time  I have only glanced at the 2 MCU families you stated but will do more research soon!

Thank you again    -T

[JPortici]

Yeah, i meant 3,4 or more chips on the same board..
My point being: You could design this to be for two MCUs only or you could design it to be further expandable by adding even more cores.

[xani]

Honestly I wouldn't bother with second MCU and i2c just to add few more GPIOs, 4094 (and its parallel-in/serial out equivalent) will do the job just as well and it is cheap and trivial to control.

IMO adding additional MCU to handle I/O is only worth if you want to make it into "I/O coprocessor", where the secondary processor(s) can handle some operations on its own, like say probing ADC input every x cycles and sending output periodically to main CPU, or having option to say trigger an interrupt when ADC passes some value.

[martinjaymckee]

This is an interesting learning project.  I don't have much interest in it as a product though.  The reason for that is that I (like many people) don't see much of an advantage in having two tightly coupled AVR cores.  Honestly, "tightly coupled" might be stretching it.  SPI would be plenty fast (simply design the protocol between them to take advantage of the duplex nature of the interface).  It forces you to have a master processor and a slave.  UART would be quite fast too and it allows for a symmetric connection (which I'd like in something like this were I doing it).  It's really going to be a bear to program though.  Unless you do something fancy, it'll need two USB connection during development.

Having said that though, I often design "multi-processor" systems.  I have a robot that is going to use a raspberry pi as the main controller, an ARM as a communication hub, another as a sensor processor, each of the motors has a separate motor controller with a processor, etc.  In the end, it will have over ten different processor cores.  Where this differs from the Dual ATMega2560 idea, however, is that each of these processors is dedicated to a specific task.  the motor controllers have a processor that focuses on controlling the PWM; temperature, voltage and current feedback signals; quadrature encoder feedback; and so forth.  By splitting the design into separate processors, the design can be built up one section at a time.  It can be designed, built, coded and debugged without having any affect on any other part.  For personal projects, I like this process.

So I guess I'm on the side of "this is a great learning project but not something I see as making a good product."  Multiple processors will always be more expensive than one large processor.  There are some advantages that I see however.  It will be 5v compatible.  It would give an interesting board to test inter-processor communication.  It could be leveraged in a true main-/co-processor arrangement.  Good luck with the project!  Sounds like fun!

Cheers,
Martin Jay McKee

[ajb]

Case in point, i did a prototype with a dsPIC33EP512MU814 which until very recently was the beefiest of dsPICs (tons of peripherals,with dual can and usb, 144pin 70MIPS, 16bit) and at 70% of implemented functionality it was starting to struggle.

Sure, eventually you can outgrow any MCU.  But you're talking about going from one 70MIPS part to two 70MIPS part.  The OP is talking about sticking two 16MIPS parts together, and I'm saying there are tons of options that start at like 50MIPs in a single device go allllll the way up from there.  STM32H7 will get you 800DMIPS with 200 pins and 2MB flash if you want, and has way more interesting peripheral features than an ATMega.  Or there's the RT1050 family that does 1200MIPS, but that's arguably edging out of MCU territory.  I'll grant that an M7 is going to be a different beast to program than an AVR, but there are some significant advantages.  I suspect that bringing Arduino support to parts like that (or the more popular M4s, maybe) would be a pretty popular effort, though not a small one. 

I also 100% support people using what they're comfortable with, so I'm not at all trying to shit on the OP.  I just am skeptical about the commercial viability for the practical reasons I mentioned, as well as the fact that anyone bringing an Arduino board into the world right now is competing against the dirt cheap clones, which is going to make it really really difficult to do anything commercial.  So the question isn't really whether or not a dual Arduino Mega board is useful or appealing, the question is whether it makes sense to build such a thing when you can get two Mega clones for $12/ea shipped and just stick 'em together.  If this is a personal project for the OP that they want to work on and share, then that's great.  I just would hate to see anyone sink much effort into an arduino product that has basically zero chance of ever making any money.