Finally I seem to have found a path towards my goal to use Mathematica and SystemModeler to apply the "Design by Modelling" methodology with the partly proprietary, partly seemingly unsupported boards. My key request while trying to get support was to get the message across about what I was looking for! Now I have found an entry about "SystemModeler" and "ModelPlug" from Wolfram which relates to the protocol "Firmata". Doing some research I found an article about a collegue "allankliu" who has ported the Firmata software running on Arduino to a board using the LPC801 I think it was. He presented in a very general form the limitations resulting from the fact that Firmdata protocol came out of the "Midi-world" and that it only supported a limited amount of PWMs i.e. He also wrote about that he had to modify code on the PC side. He does not seem to respond as a question was asked early 2014 to which he never responded! So here my questions:
I have spend some time doing a draft research and i have ordered both a RaspBerry Pi B+ to look deeper into how Mathematica and Wolfram Language behave in this environment and to see if I can use such an environment to connect the Raspberry Pi B+ with other boards, specifically the LPCXpresso1769 that i plan to heavily use in my system I want to design by using the methodology of "Design by Modelling". Additionally I have ordered a Teensy 3.1 with the SD & Ethernet I/F to look in more detail into Firmata in an ARM Cortex Mx environment. I have further listened to a YouTube video were I heard about "Datadrop", something I will have to research to learn what it is. Finally i looked into Firmata and basically what I learned without claiming to be right, it is kind of the "Representation Layer" within the OSI 7 Layer Model. The complains I have read in the community and investigating via Google was that due to Firmata coming from a MIDI background it is too limited to really adequately represent the physical external hardware, the specific example was given by addressing the limitations of PWMs it can handle!
So looking into it and thinking about the objective to have a generic efficient way to address any ARM Cortex device from any manufacturer, I thought the the CMSIS library that every licensee of an ARM Cortex Mx has to make available for his instance of an ARM Cortex Mx controller. CMSIS is a common API to use and address any hardware within a microcontroller, all ARM Cortex Mx controllers having the same API from CMSIS available. A smart and efficient way to support effectively any ARM Cortex Mx controller from any manufacturer would be to extract the information about its registers and peripheral using the data available within CMSIS
A library that would generate the proper representation out of the CMSIS supplied by any manufacturer for any of his ARM Cortex Mx controllers of all registers and peripherals with their registers and link it to variables in the SystemModeler and/or Mathematica environment implementing the layer 6 functionality would be a big step forward. The same scheme should made available for the user to add other devices that interact with this controller via digital I/Os or other means of communication like I2C, etcetera. this way there would be a solution that combines the demand to "datadrop" data from the hardware to the PC running Mathematica and/or SystemModeler and a means to identify most of the physically relevant properties of a board.
As to the language for programming, if I would work for Wolfram I would ask myself if this could be the Wolfram language. But so far i have no understanding as to what memory requirements it has on the hardware nor how beneficial or necessary an access to the cloud would be! This is why I have ordered RaspBerry Pi B+. I will also try to understand if a CMSIS compliant RTOS can be used.
Thanks for your valuable response. I will look into this.
I have already posted a few comments on other post I found but I can repeat the answers here.
1.- ModelPlug works with Firmata v2.2 but 2.3 is recommended since it has bugfixes.
2.- ModelPlug is just a library for SystemModeler and it is not the only way of communicating simulation models with the world outside the simulation. Simulation executables generated with SystemModeler can be controlled with a TCP/IP protocol. You can find the information within the SystemModeler help with the title "Communication with Simulation via TCP". For more specific use cases, it is also possible to link your own C/C++ code (containing a specific communication protocol) to a simulation executable. You can find more information in the SystemModeler help with the title "External Functions". For an example on how to do this you can take a look at the ModelPlug C/C++ code which is included with the library.