I think you are really wrong. 
The disadvantage is large programs can be tricky to get working with the limited ability to find and correct errors in a full up system. I'd rather use an old laptop and a "real" program, even one that communicated with microprocessors for data acquisition and control, so you could see what is going on in a more comfortable dev environment.
a7
Ok great, I will consider this and thanks for the information that you have provided 
The disadvantage is large programs can be tricky to get working with the limited ability to find and correct errors in a full up system. Iād rather use an old laptop
My experience has been different.
In my job I needed to perform a lot of testing at a remote location. I've created device controllers using Microchip processors (very similar to an Atmel 328P) and computers using LabView. I am not a software engineer but a hardware design engineer that needed to get testing performed and could write what I needed faster than finding a software engineer to help with the testing software.
While the LabView programs were more involved, the stability issues that came up had nothing to do with LabView but with the basic stability of a PC. Without exception, the microcontroller devices were rock solid while power glitches etc would cause the PC to have issues that needed manual intervention.
Where ever possible I wrote the the processor code without interrupts. If this can be done and I've found the processor boards could run reliability for a multi thousand hour test.
I would suggest, before any platform is identified, the OP create a flow chart of what needs to be done. Usually this will give you a better understanding of the complexity of the project and what the platform requirements are.
I used to use LucidChart (free for small projects) but now I'm starting to use LibreOffice Draw for my flow charts.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.