It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

 

It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

I don't know. It kind of sounds like doing the same work twice. I suppose it would depend on the debugging tools that you have available with the other processor.

 

It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

I think that it's a very bad idea.

 

It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

IMO, only if working within the same architectural uC family. But if you are going to implement on another "Arduino" fully supported board, I think it is OK to start prototyping ideas until you procure the needed Arduino board.

Remember, Arduino is a unique ecosystem and compatibility is strongly associated with the "specific Arduino core" code; usually hosted on GitHub.

Ray

 

Agree with @RayB
If you're using the same processor as in the Arduino, then it's a good idea.
Otherwise, it isn't, as all the peripherals will be different, and you will end up doing the job twice.

 

”Arduino” is a very imprecise and confusing term. There are Arduino development boards, made by Arduino or cloned by others but there is also the Arduino IDE and ecosystem. Many completely non-“Arduino” MCUs and development boards are compatible with the latter thanks to both the previously mentioned cores that describe the MCU, as well as board definitions ar that provide specific translations of pins and peripherals so the compiler can make sense of them.

Then there are the libraries. Many of the libraries are architecture agnostic, some support many architectures as people contribute the code to do it, and some are narrowly focused. But, in any case, if you use the libraries then porting your code to some other environment might become impractically complex.

The question I have is “why?”. Why would you want to develop something either with a different MCU then you would be suing (assuming you are not going to use the Atmel or other “officially supported“ options, and, why would you want to use the Arduino IDE whose main advantage is the availability of a broad array of libraries and example code—all for the supported MCU/development board option you can choose from the boards list?

Could you explain what it is you are planning to do? I mean, whaat is this project and what is the ultimate target MCU? Your question is confusing possi ly because you don’t know better or because you have something in mind that makes some sense but you didn’t say. It’s very hard to be helpful with such an open-ended question.

 

It depends. Forth has been used to quickly mock up models of software systems, sometimes to be re-written in a more widely recognized language. Forth has the advantage of easy to use to express ideas and actions. If Arduino is a very easy platform for you to use, go ahead and use it to mock up and experiment with your ideas. After that you can move it, for example, to a $2 microcontroller if you were careful to keep resource limitations in mind.

It is much like I rough out magazine articles in html then transfer to word for submission.

 

It depends. Forth has been used to quickly mock up models of software systems, sometimes to be re-written in a more widely recognized language. Forth has the advantage of easy to use to express ideas and actions. If Arduino is a very easy platform for you to use, go ahead and use it to mock up and experiment with your ideas. After that you can move it, for example, to a $2 microcontroller if you were careful to keep resource limitations in mind.

It is much like I rough out magazine articles in html then transfer to word for submission.

Yes, but if he uses libraries he will be in for a huge mess in porting. I am not sure why he needs to move to a different MCU and development platform. If he can write what he wants in the Arduino IDE then he can use the code directly by using the same MCU, be can much more easily clear away the board definition than port the libraries.

 

Changing microcontrollers is hugely time consuming. I have just moved software from a 64-pin NXP LPC1517 to a Renesas RA4M1, both of which are 32-bit ARMs with the same instruction set, and both have the same set of peripherals but the peripheral control registers all are different.
It has taken months.

 

Changing microcontrollers is hugely time consuming. I have just moved software from a 64-pin NXP LPC1517 to a Renesas RA4M1, both of which are 32-bit ARMs with the same instruction set, and both have the same set of peripherals but the peripheral control registers all are different.
It has taken months.

Sounds... tedious.

 

I was amazed just how different two A to D converters could possibly be.
I you don’t use a lot of peripherals it is less of a problem, but I have used A to D, I2C, SPI, CAN, RTC and two different sorts of timers.

 

It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

Actually, it's a good idea to flow-chart your code before implementing it in any MCU or PCU.

 

It is a good idea to make a code in an Arduino first before to implement in another microcontoller?

That sounds like unnecessary extra work to me. The only time it would make sense is if you're migrating an existing application to a different microcontroller.

 

Actually, it's a good idea to flow-chart your code before implementing it in any MCU or PCU.

I very rarely make flow charts, except when I work with others as a team. What I always do though, is write in plain and simple language every step (and why) of what the code is supposed to do.

 

Actually, it's a good idea to flow-chart your code before implementing it in any MCU or PCU.

The first time I did NOT in more than 15 years, it was in my (almost finished) current project. Thanks to that I made the stupid mistake of calling an obstructive online delay in the middle of the main loop. Had to debug to know why.

For me writing code is just clerical work.

 

If you only have experience and are familiar with Arduino then it is a good idea to accomplish whether your thought is right or wrong in Arduino, otherwise, you don't have to spend double the time to do the same thing.

 

the arduino api
https://www.arduino.cc/reference/en/
is fairly similar across different cores ( for different microcontrollers), there are many of them.
this is an advantage. i.e. it may be possible for the same code to run on different microcontrollers.
The trouble is, the moment you used a feature specific to the microcontroller, e.g. access a register, all that is lost, and the code will most likely run only on the specific microcontroller. The arduino api is 'rather limited' in some aspects, it can do 'many things', but not 'all things'.

And it is rather likely for various reasons of performance, specific features or otherwise that you use codes specific to a core for a particular microcontroller or even sensor - end of 'portability'.
Some of the very common ones are like using DMA (arduino don't use it), specific features of the on chip ADC e.g. for STM32, using STM32 specific codes is the only way to fully use the ADC in ways that is impossible in the Arduino api.
e.g. in stm32duino
https://www.stm32duino.com/
https://github.com/stm32duino/Arduino_Core_STM32
if you are hard core enough to use both ADC with DMA, this is the only way if you want to do things like make an oscilloscope out of it or a fast DAQ out of it, the moment you do that you are off tracked from the Arduino API and specific to STM32.
The code is no longer portable, but you can use that feature that is specific to the microcontroller -which is possibly not achievable say on a different microcontroller or is different on another microcontroller.
STM32s can do pretty fast DMA, some of these videos has become 'famous', they are features of stm32 microcontrollers and various ARM based microcontrollers. They (the ARM microcontrollers) probably run many of the electronics gadgets / devices all around us. DMA on one chip won't work the same way on a different chip, and this can be even true for different series from the same manufacturer e.g. stm32 f1xx and f4xx has different DMA hardware.

but that those features are specific to specific microcontrollers, not 'across the board'.

 

The OP did not mention what advantage could expect to get from that stunt. In my opinion, none plus a nice waste of time.

 

Wonder if the OP is ever going to come back , may be answer some of the questions weve asked,

 

I very rarely make flow charts, except when I work with others as a team. What I always do though, is write in plain and simple language every step (and why) of what the code is supposed to do.

That is, in and of itself a form of a 'flow-chart'. It is a logic methodology that works for you. Flow-charts should be done by newer coders- it gives them a road-map that they can 'run' on paper and test scenarios and check their logic. More seasoned/veteran coders use flow-charting less because they have usually learned 'tried and true' methods to code defensively- like always niling pointers after use, and so forth.

I still use flow-charts for complex algorithms, or any production algorithm as a form of 'formal documentation' of it. Flow-charts are invaluable if you have to go back later, for example, to see how two or three interrupt driven algorithms work together to perform a task, or you have massage data in a way that is simply not obvious in code, an comments aren't enough, where other documentation is necessary.

I know, as an example, when I was doing 6DoF simulation code for not just creating the environments, but for the drawing engine as well, that I was so deep in my mind into the data and how things worked to shave of micro and nanoseconds of time, touch every pixel only once, prediction algorithms, etc, that the only way to even understand what I'd done years later was to have flow-charts and lots of other documentation.

Flow-charting is an underutilized and underappreciated tool that would solve so many 'bad code' problems of today if the coders were disciplined and made an effort to benefit from such tried and true tools.