I'm getting sensor data from 4 ASDXACX100PAAA5s, I am feeding them 3.3V from a Teensy 4.1 instead of their rated 5V but the sensors are still operating. The serial monitor stops after less than 5 seconds of run time. I have tested this with multiple programs which read from the sensors. Is there a problem with my code or is there something wrong with my computer? Here is the 1st program:
#define SysValve 1
#include <Wire.h>
#include <SparkFun_MicroPressure.h>
SparkFun_MicroPressure mpr(-1, -1, 0, 55);
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
Wire.begin();
mpr.begin();
}
void loop() {
// put your main code here, to run repeatedly:
//float I2CRead = mpr.readPressure();
//Serial.print("I2C PSI:");
//Serial.println(I2CRead);
Serial.print("Analog Reading:");
Serial.println(analogRead(A0));
}
Here is the 2nd program:
#define Address 0x70 //Setup to connect to the Sparkfun MicroPressure sensors
#include <Wire.h>
//#include <SparkFun_MicroPressure.h>
//SparkFun_MicroPressure mpr(-1, -1, 0, 35);
//void TCA9548A(uint8_t bus) { //Setup for Adafruit Multiplexer
// Wire.beginTransmission(0x70);
// Wire.write(1 << bus);
// Wire.endTransmission();
//}
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels
#define OLED_RESET 4 // Reset pin # (or -1 if sharing Arduino reset pin)
#define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128x64, 0x3C for 128x32
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
#define ValvePin 2
void setup() {
// put your setup code here, to run once:
Serial.begin(4800);
Wire.begin();
//mpr.begin();
//TCA9548A(2);
// mpr.begin();
pinMode(ValvePin, OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
//TCA9548A(2);
//float I2CPressure = mpr.readPressure();
//Serial.print("I2C PSI:");
//Serial.println(I2CPressure);
int Read1=analogRead(A0);
int Read2=analogRead(A1); //Sensor readings
int Read3=analogRead(A2);
int Read4=analogRead(A3);
display.clearDisplay(); //Display setup
display.setTextSize(1);
display.setTextColor(SSD1306_WHITE);
display.setCursor(0,0);
display.print("Sensor1: "); //Displaying sensor readings:
display.println(Read1);
display.print("Sensor2: ");
display.println(Read2);
display.print("Sensor3: ");
display.println(Read3);
display.print("Sensor4: ");
display.println(Read4);
display.display();
//Serial.println(" ");
//delay(500);
digitalWrite(ValvePin, HIGH);
//delay(1000);
digitalWrite(ValvePin, LOW);
}
A Teensy 4.1 has a 480MBit/sec USB connection. If, (in your first program) you write out data without any delay you will probably overload the serial monitor. To check try to add a delay(1) in loop of your first program.
Raising the delay to 5 fixed it for that program, I kept hearing the Windows disconnect sound every few seconds but that seems to have fixed it.
The 2nd program is continuing to have the same problem, even with a delay of 20. Is there anything else that could be the problem?
I looked to see if the Teensy was resetting itself due to Teensyduino screwing up but I don't see the reset light coming back on when I hear the disconnect sound.
(CORRECTION) Every increment of 5 increases the time the Serial Monitor can run by 1 minute. This timer can be reset by disconnecting and reconnecting the Teensy from its power as long as the disconnect happens before the Serial Monitor stops working. Once the Serial Monitor stops working you must reload the program onto the Teensy.
Just to make sure: You do use the latest version of Teensyduino (1.54) right? There were a lot of bug fixes in this version.
Overloading the serial monitor is a PC thing only. It will not influence the Teensy side at all and will not cause a disconnect of the Teensy.
The continuous disconnects you observe might be due to some power supply issue. I had a similar issue when I tried to run a few servos from the 5V pin. Would be helpful if you post a schematic of your circuit.
The only other reason for a disconnect I know of is a severe bug in your code which might cause a processor exception. TD1.54 also improved on that and provides a crash report. You can try to add
void setup()
{
while (!Serial) {}
if (CrashReport)
{
Serial.print(CrashReport); // Once called any crash data is cleared
}
// your code...
}
In case of a crash teensyduino will reset the processer after about 8s and print out a crash report. E.g.:
CrashReport:
A problem occurred at (system time) 0:0:1
Code was executing from address 0x9C
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x0 (nullptr)
Check code at 0x9C - very likely a bug!
Run "addr2line -e mysketch.ino.elf 0x9C" for filename & line number.
Temperature inside the chip was 36.78 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected
I downloaded Teensyduino less than 2 weeks ago so I should have the latest version. I don't know what happens to the Teensy but it seems to stop the program to the point where it won't restart when I unplug and replug the Teensy into my computer. Instead, I need to completely reload the program.
Could the power problem be solved by using a power supply to power the Teensy instead of using a USB cable?
Usually using the 5V from USB for the Teensy only and supplying the rest of the hardware with its own supply is working just fine but maybe your Hub has issues.
Anyway, at least to find out the underlying problem I'd supply the Teensy which its own supply. Don't forget to cut the VIN trace to separate the USB power from your supply.
You can still use the USB connection for data, but the board needs to be powered via VIN (3.6 - 5.5V) after cutting. Don't cut too deep, this is a 6 layer board, thus the layers are quite thin!
No, if you simply remove the USB cable and power it via VIN you do not need to cut the trace. But then you obviously can't communicate with the board ?
Remark: I sometimes forget to cut the trace and accidentally power it from both sides (USB and external supply) until now nothing broke. But, of course, I do not recommend to do it this way