Python communications with Teensy 4.0?

E

eayars

Member
First post here, please be gentle. ;-)

I've built a SCPI instrument controlled by a Teensy 4.0 for a physics lab course I teach. The Teensy works fine: it controls the apparatus and everything is fine, BUT... I can't communicate with the Teensy through Python because pyvisa can't find the Teensy.

Arduino IDE: interface selection shows COM3 and Teensy4.0.
'*idn?' --> expected response, all SCPI commands work fine and control the apparatus.

python
>>> import pyvisa
>>> rm = pyvisa.ResourceManager()
>>> devices = rm.list_resources()
>>> devices
('ASRL3::INSTR',)

So Python is only seeing COM3, not the Teensy. This may be a problem for the pyvisa forum, but I've used pyvisa for other SCPI instruments without trouble. This is a fresh Win64 box: is there some magic driver installation I need to do on the machine to let it see a Teensy? I don't think that's the answer, because the Arduino IDE sees it. I'm stumped!

Thanks in advance for any help you can offer.
-Eric
 
I don't really understand; if the Teensy is on COM3, and python is seeing COM3, where's the problem?
 
Make sure the IDE isn't holding onto the USB COM3 port.

Have seen IDE 2 not release it even if closed where IDE 1 didn't have that issue. Check TaskMan.

Perhaps build with Dual Serial and use SerialUSB1.begin() and SerialUSB1.print() for the second NEW COM port to talk to python? That would leave the IDE free to SerMon on primary Serial and no issue during uploads with Python holding the port - or not seeing it when it returns.
 
Last edited:
defragster said:
Perhaps build with Dual Serial and use Serial1.begin() and Serial1.print() for the second NEW COM port to talk to python?
Click to expand...
I could be wrong but when using Dual Serial & Triple Serial, shouldn't you be using SerialUSB1.begin()/SerialUSB1.print() & SerialUSB2.begin()/SerialUSB2.print() respectively to send/receive data over those additional virtual serial ports?

Paul
 
PaulS said:
I could be wrong but when using Dual Serial & Triple Serial, shouldn't you be using SerialUSB1.begin()/SerialUSB1.print() & SerialUSB2.begin()/SerialUSB2.print() respectively to send/receive data over those additional virtual serial ports?

Paul
Click to expand...
ABSOLUTELY RIGHT! - sorry, copied from code using both Serial1 and USB1and rushed:

SerialUSB1.begin(115200);
SerialUSB1.print( "\nSerialUSB1: ESP32 SerMon. Disconnect to Program\n" );

and like to copy US1 to USB:
while ( SerialUSB1.available() ) {
char inCH = SerialUSB1.read();
Serial.print( inCH );
 
defragster said:
Make sure the IDE isn't holding onto the USB COM3 port.

Have seen IDE 2 not release it even if closed where IDE 1 didn't have that issue. Check TaskMan.

Perhaps build with Dual Serial and use SerialUSB1.begin() and SerialUSB1.print() for the second NEW COM port to talk to python? That would leave the IDE free to SerMon on primary Serial and no issue during uploads with Python holding the port - or not seeing it when it returns.
Click to expand...
It's not a 'who has the port' conflict: there's the same problem on cold boot when Python tries accessing the Teensy.

My Macbook has no problem: it can see and control the apparatus through pyvisa/SCPI flawlessly. It's just this Windows box that can't see the Teensy for some reason. Obviously the solution is to use Macs for everything, but the classroom has Windows boxes so I need to get it working with that. Still stumped.
 
I'm not sure how double serial solves my problem. I'm building something that should just plug into USB and behave as any other SCPI instrument such as a Keithley meter or Tek 'scope. I can do what I need through serial monitor on the Arduino IDE (although obviously not simultaneously with Python control attempts) I just need it scripted.

This is probably a pyvisa question, I was just hoping someone here had seen this before and knew the answer. Thanks, and I'll post if I find a solution just in case someone else has the same issue.
 
In this case Dual USB was testing a way around an unseen problem.
Some programs may not release it when expected - as IDE 2 seems to do at times.

It is also a useful tool for allowing 'normal' debug USB to run in parallel with allowing an outside second stream from the Teensy.
Also keeps a USB channel open for programming without having to drop the Other access point - in this case Python.

Used it recently to Proxy program an ESP32 on Teensy UART under control of the primary USB while the 2nd USB was then open to upload the code through the Teensy.

Also used it to have the Teensy Write Code Out 2nd USB with a variable number of functions calling functions perhaps 4,000 deep to Fill EEPROM to test the LOCKED Teensy running code from Flash where it was decoded on the fly from Flash to see it work and not much of a speed hit. The code wasn't always generated unless 2nd USB was there - once there it was copy pasted back to a sketch file and rebuilt running the same sketch.

So it offers some cool abilities. This seemed like it could be one ...
 
Last edited:
You must log in or register to reply here.
Back
Top