Multiple Teensy Architecture Questions

Status
Not open for further replies.

Chevelle

Active member
First I want to say how impressed I am with the Teensy line. They are terrific products and I am having a ball using them.

I am starting a more ambitious project that has several asynchronous functions in it and I don't feel that one uC will be able to handle everything without timing issues. My plan is to off load these separate functions to LCs or 3.1/2s and have the whole system be controlled by a 3.5/6. Eventually, I may spin a custom board for this system. That board won't have some of the functions that are build into the Teensy. For example, there won't be SD cards or a USB connector for each uC.

I have two basic questions.

PROGRAMMING:
I have been doing all the programming through the USB connector. What is needed and what is the process for programming directly through the program pin?

CONTROL ARCHITECTURE:
The 3.5/6 has to communicate with the LCs and the 3.1/2s. What architecture would you recommend? CAN?

Thanks for your help and suggestions.
 
PROGRAMMING:
I have been doing all the programming through the USB connector. What is needed and what is the process for programming directly through the program pin?

Nothing :) - It is not possible. The program pin does the same as pressing the button. Programming is possible with USB only.
https://www.pjrc.com/teensy/schematic.html

CONTROL ARCHITECTURE:
The 3.5/6 has to communicate with the LCs and the 3.1/2s. What architecture would you recommend? CAN?

Thanks for your help and suggestions.
I'd just use serial. Keep it simple.
 
I have two basic questions.

PROGRAMMING:
I have been doing all the programming through the USB connector. What is needed and what is the process for programming directly through the program pin?

There is no other way. That's at the same time an advantage for the customer who doesn't see a single byte of flash memory wasted for a boot loader and it's PJRC's business model: You get everything for free, code, schematics, support, and much more, but you must go through the MKL02 chip with their magic secret sauce firmware (only available from them) to load your code via USB into the Teensy. You might even produce your own PCBs with nude/virgin Kinetis MCUs, but you'll have to buy and to use an according number of pre-programmed MKL02s from PJRC.

CONTROL ARCHITECTURE:
The 3.5/6 has to communicate with the LCs and the 3.1/2s. What architecture would you recommend? CAN?

Thanks for your help and suggestions.

Depends on different factors: If you remain on one single PCB/short wiring and with less than 5 nodes, SPI with up to 30MHz might be the inter-uP communication offering the highest bandwidth and efficiency. CAN is interesting when you have more nodes, but it is slower and has, like I2C or SMBus, more overhead for addressing in the transmit protocol. Using hardware handshake, high speed UART could also be an option for point to point communication. But you'd really have to reveal more of your technical specifications and requirements to get an appropriate answer.
 
Hey, great responses. Don't mean to be cryptic but just wanted to keep the post down to a readable level. Here's more information....

There are four main sub-functions.

TEMP MONITORING:
Probably will use a LTC2986 that handles all types of temp sensors and can communicate SPI to the main uC.

TEMP CONTROL:
I need to control two small peltier devices. Will most likely go with the MAX1968/9 or TEC5V4A-D from Analog Technologies. Depending on that decision, this function may or may not need a dedicated uC like a 3.1/2.

PNEUMATIC CONTROL:
This will either be the control of two piezo pumps or a fine precision motor lead screw or both. If the piezo pumps are being used, I will use a uC to generate the pump pulses. If not, then I may be able to get away with a dedicated motor controller and not need the uC.

OPTICAL DETECTION:
This is the most complicated sub-function. I need to drive at least 5 LEDS with constant current and read 5 (possibly 10) detectors. The main uC will give instructions to this uC and it will perform a complete acquisition sequence that will include turning on and off the required LEDs and taking a set number of 16-bit reads from the detectors. The read rate will be 100k samples/second or faster. The 16-bit read values will be stored locally and passed back to the main uC when the sequence is complete.

So for the prototype, I'll just use bought Teensys. I may even make a board that incorporates the full modules. If this goes to the next level, I can use the same uC devices and go with a complete custom embedded design at that point.

So that just leaves the inter-uP communications. From your post Theremingenieur, SPI is the fastest. I will definitely have less than 5 nodes. The optical detection part will need to be on another PCB. The electronics needs to be in very close proximity to the detectors for low noise considerations but the cable will be short, 5-10cm at most.

Again, thanks for your help.
 
Looks like one single Teensy 3.6 should be able to handle everything in one MCU:
- The temp stuff seems to be trivial, there is always thermal inertia in sensors and heaters, so that you don't need to run more than 10 or 20 actuation loops per second.
- If you can drive your pumps or motor for pneumatic control with PWM or similar servo mechanisms , the Teensy's integrated Flex timers can handle that in autonomous mode without eating much CPU cycles.
- Remains the optical detection stuff which let me estimate a 20 to 25% CPU load for a Teensy 3.6 from your specifications if mindfully programmed.

Summary : IMHO, you seem to be overthinking and overcomplicating things. I'd start with one T3.6 and the optical detection, then, after this works and is optimized, add the pneumatic control in the same way, and find at the end that there is enough headroom to do the temp stuff. You might find out in this process that some of the ready to use libraries are written more for Arduino compatibility and easy use for amateurs than to be optimized, so it could happen that you have to strip them down and/or rewrite the one or the other function to be optimized for your MCU and use case.
 
So we contracted a design outfit to design the first generation of the system. They used one uC although not as capable as the one in the 3.5/6. (Just one of their many mistakes.) The performance was unreliable and in large part to timing issues. I do not want to make that mistake again. This is not a cost issue. I would much rather have far too much processing power with lots of idle time than to repeat their past mistake.

Part of the poor performance before was because they didn't even use purpose designed devices. (For example, they used the uC to create the stepper motor microstep pulses that went to the pump in that system. That included the timing for ramping up and down. As you point out, the temperature control didn't need to be fast but it was a PID loop so there was some sophistication to it.

That being said, I agree with you in general. The Linear Devices component for temperature measurement will require little attention by the uC. The dedicated peltier controllers will also off load the 3.5/6. However, the piezo pumps cannot be just driven by the on-board PWM outputs. They have very particular pulse requirements. The fluidic process must be very precise, whether it is done by the piezo pump or mechanically as we are considering. Even with all of that, with a more efficient design that the old system, one uC may be able to perform all of these functions.

The optical bits are the most critical part of the system. The read times for each channel are only 1ms long. I would like at least 100 ADC reads during that period. The entire read sequence for all channels is 1-2 seconds. There is a lot going on so I don't have any problem dedicating a uC for this purpose.
 
Status
Not open for further replies.
Back
Top