TELEZ Teensy realtime, Raspberry fileserver, PARTICLE cloud connection


Active member
Somebody may find this interesting. There are significant shifts in play with large companies' attitudes toward proprietary hardware and software methods. The user community is demanding open hardware and software. According to the risk model, confidence is derived from wide use as well as direct testing. The idea of the relationship and integrity of the application as it relates to the entire system is also a significant issue for these people as it relates to system life cycles and preservation of system methods with technology improvement. The other issue is that system development is based on current system requirements and methods (traceability). EXXON and Lockheed (along with more than 100 large companies) are fore-runners in these thoughts. I have been in discussion regarding strategies for that open effort. Challenges in the adoption of that perspective remain; these challenges exist chiefly around commercial value models. Regulatory issues for an open system developed environment also represent a significant challenge. Quality testing is still required and code control is still mandatory. Reuse, while maintaining integrity is the user's objective as always.

I do not pretend that the system described int the attachment is suitable for anything but development at this point. The fact remains that several 100 million people are trained in this environment from schools and that level of comfort and ad hoc testing provides a basis for acceptance. Training verification is part of what that group is looking to address as well. Leverage of what the the users and developers already know is a good thing; even if that only helps facilitate learning and deployment Those things, combined with the fact that open source community remains relevant after 20 years of development is significant. The opengroup community regulary develops and uses defacto standards. This is the backdrop I look at when I consider the shift to a distributed cloud model for SOME types of information.

I feel that the IoT effort is needing to rearrange what is important; eventually, what it does will be more important than the novelty of connection path and data availability and security. There are things required in the internet backbone or segmentation that need to happen. Perhaps a newconcept for TCP/IP is required. For now, the idea of a corporate cloud is a good one. If they can get to a distributed cloud model so much the better.

In all likely-hood, things will move toward a Java virtual machine or some similar hardware abstraction for control processors,and that the controls vendors will morph into tool providers for migration assistance to a common set of control object definitions much like S88 and S95. The architecture is the important thing, and that what I show there is running with a JVM as compiled with a toolset capable of control object execution. Control vendors will likely want to provide intellectual property preservation by offering products that allow users to move from the legacy object to the new set of JVM objects compatible with open hardware. Our challenges are in how to apply this to our benefit. I hope this helps.


  • portfolioIoT36.pdf
    378.2 KB · Views: 282
Last edited:
Hello Paul,

You are to be deeply thanked for your Teensy concept. The communication forum you have is excellent. The TEENSY platform is exceptional.

I run the Teensyduino environment on Raspbian, and I apply it to chemical process problems. I also have the PARTICLE dev and po-utils on the Raspbian setup for a *really integrated* IDE. What I am working on creating a space where new engineers can express their ideas in an environment they most likely already know. I am working toward is the setup of a micro cloud access point, maybe even a distributed cloud.. The Teensy is setup as a scanning environment for real-time events, and the calculations for controller response. The PARTICLE has latency and priority issues (they interfere with real-time performance) but has instant cloud connectivity. I offload the cloud issues to the PARTICLE. I have set up the PARTICLE as an SPI slave to the TEENSY to make TEENSY data efficiently available to the PARTICLE/Raspbian. File services and configuration are also part of the TELEZ cluster in the RASPBIAN node....

I took past implementation concepts from some major industrial controls vendors and implemented them in TEENSY.

for batch sequential control you might find this interesting orientation.

for accepted control languages of implementation on traditional commercial controllers

There are large libraries of control "objects" that are available for implemented in Teensyduino These libraries are mostly originally written in C/C++ but the vendors don't offer that implementation. Instead the commercialize them by putting them into their "products" that use the IEC 61131 languages to drive a cross compiler that puts them back through the C routines for executables on their control processors....A bit convoluted but profitable for them. The problem is that they try to fight over market share at the expense of the customer.

I have done a few dozen of the control object constructs in C++ that are most useful for what I do. I can use the Teensy or the PARTICLE use those vendor specific protocols for work in conjunction with the legacy controllers.

I have found that your Teensy scans the entire application of a Bioreactor in milliseconds...and makes the information available to the PARTICLE and to visualization in a graphic terminal. The PARTICLE slave notifies the Teensy of a pending need for communication with a flag pin so that the Teensy is free-running independent of the PARTICLE. Presently, the Teensy has TCP/IP connectivity to industrial HMI/PLC products with Ethernet industrial protocols (SNAP7 and MODBUS). I hope to find or get someone to implement a graphical environment for the RPI . I am looking to pick a cloud capable graphic visualization path for mobile devices too.

For now,I am implementing my in the C/C++ .

I am looking to speed up my translation of what I know using something like...

Industry is looking to commoditize hardware/software so that end users are not held hostage by commercial vendors. They hope to achieve this by an "open" definition of objects. The problem with the effort is that they are anything but OPEN. The users want a pluggable process controller enviroment....TELEZ is consistent with some typical hardware clustering approaches, and includes a cloud access point. I set up the pinout geometry of that board specifically to be pluggable. I have also setup a library of boards consistent with the NANO and MEGA/DUE form factors......but TELEZ hass the cloud..

Once again,

KUDOS to you. the TEENSY has juice.. I appreciate you taking time to reach out.