Arduino IDE direct to different MCU in SAM3X family?

Hardware Arduino Due
1

Hello all. I'm a hardware designer and I'm considering making a board that would include one of the Atmel processors similar to the SAM3X, but I'd rather not use the actual SAM3X processor presently on the standard Due board. The application of the new board doesn't require so many I/O's or memory, so the SAM3X is overkill both in board space and cost for this project. I would like the board to be directly compatible with the present and future versions of Arduino IDE so that present Arduino users and students can easily program and control the new board.

I am not very familiar with the specifics of the Atmel SAM3 family (I am much more experienced using STM32 processors with the Keil toolchain), but I'm considering processors that could be scaled down from the SAM3X in terms of either smaller pin package and smaller memory size, and possibly even different max operating frequency options.

So the real question is, if I build the USB interface to say, the SAM3A4C processor, which does the same 84 MHz as the SAM3X, but it is in the 100 pin package and only has 256k (vs. 512k) of flash and only 64k of ram (vs. 96k), and I attempt to compile and load a sketch directly from the present Arduino IDE, will it just be happy to compile and program the part, or will I get a string of errors?

I expect if the sketch was going to take up more memory than what was available on the part there would certainly be a problem or if the code references pins or peripherals not present on the smaller part, but if I reference only peripherals and pins they both share in common, would we be okay?

The second question is, if I do get a string of errors (perfect world?) how deep of an edit is required to tell the Arduino IDE to be happy with the new part? And furthermore, if something is edited to make the IDE play nicely with the new part, will it then conversely throw a fit if the user then tries to later use his/her IDE to program up a standard Due board?

I did some digging on this and found this blog post, which comments that the new IDE may be able to support lots of new processors. I'd think it would easily support other processors immediately in the SAM3 family, but I don't know if it does as of today, or when the support may be added in the future such that a novice / student user can easily select the new processors, etc.

So in the end the question boils down to whether or not I can make the present IDE seamlessly play nicely with different SAM3 processors. If not, then I'm just going to have to build the full scale SAM3X onto the board.

Much appreciate any guidance. Thanks!

-K

2

You raise an interesting question, I was also considering use of Arduino IDE for different CPUs.

So in the end the question boils down to whether or not I can make the present IDE seamlessly play nicely with different SAM3 processors.

As you used the word "seamlessly", the easy short answer is no. :slight_smile: Only chips from the same family are likely to be that similar, even there they may be significant differences. In order to create a smooth experience for the user, the platform has to be carefully designed with portability in mind, and the user and any third-party library writers very careful not to bypass the APIs and access peripherals directly. For small microcontrollers most people don't want to take that route, and tend to code specifically for their target chip.

For a limited subset, and for your own use, you should be able to create the required drivers to run your project on different chips but there is going to be a lot of porting involved, and ongoing effort for any additional library you want to use.

I would suggest the best bet to retain the most compatibility with Arduino IDE is with the SAM3X4C, but I haven't looked into specifics. If you want go outside of Arduino, then I would look closely at building a framework on something like ChibiOS.

I was going to suggest that someone might produce a "Due module", like the Arduino Micro, but just looking at the Due there is not a lot of opportunity for size reduction.