Teensy 4.0 First Beta Test
- Thread starter PaulStoffregen
- Start date
- Status
Kurt, buffer problem...
If I use
Code:
Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
Code:
Hello world
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
Yes, I thought that.. there is nothing to cache, DMAMEMORY is accessed one time. It will be the same for most, if not all DMA operations I think.
Caching makes sense if that memory is used for other purposes, too. Like a displaybuffer if you read+write the buffer, too. But then there must be a mechanism to sync the cache with the ram - Pauls cache-functions (great btw) can do that. The question is, when is it faster to use NOCACHE or to use the functions? I think the answer is: It depends..
maybe some things are faster with the functions, others with NOCACHE or WRITETHROUGH (<- need again extra care if reading is desired..). With very large buffers we have to take into account, that otherwise useful cache-contents can get lost. For example if a font is stored in PROGMEM.
Last edited:
KurtE
Senior Member+
Looks like time for some more testing...
Right now playing with Dynamixel servos. hooked up to Serial1 through a Robotis Open RS485 expansion board (also does TTL). It has the hardware setup for
TX, RX, Direction pin, plus +3.3v and 5v...
Did some initial editing of my BioloidSerial library to work with it, currently only with Direction pin, will try later with setting Serial port into half duplex mode...
Part of it appears to be working but my library is not picking up the responses... Need to debug, to see where the issue might be...
Looks like the data should be there. Looking at LA output.
Top line is the DXL buss that the servos see and respond. Line 2 is pin 0 which should be the RX pin, I receive the data back on. Line 3 is TX pin, where the commands go out and Line 4 is the direction pin output which is driven by Serial1...
Again maybe just problem with my library... First off see if I am receiving anything... Note: I hacked up my test app, to use Serial2 for the Serial inputs and outputs instead of Serial so I could use commands... And that appears to be working fine.
EDIT: Timeout issue in the library. When the library was originally written it was for AVR 8 bit boards running at 16mhz and timeouts were done by timeout loops.
When I added support for t3.x I just changed the timeout value... But that was not caught in the #ifdef for t3.x and even if it did, would not be high enough...
Probably time to break down and use a timeout using something like an elpasedmillis...
Right now playing with Dynamixel servos. hooked up to Serial1 through a Robotis Open RS485 expansion board (also does TTL). It has the hardware setup for
TX, RX, Direction pin, plus +3.3v and 5v...
Did some initial editing of my BioloidSerial library to work with it, currently only with Direction pin, will try later with setting Serial port into half duplex mode...
Part of it appears to be working but my library is not picking up the responses... Need to debug, to see where the issue might be...
Looks like the data should be there. Looking at LA output.
Top line is the DXL buss that the servos see and respond. Line 2 is pin 0 which should be the RX pin, I receive the data back on. Line 3 is TX pin, where the commands go out and Line 4 is the direction pin output which is driven by Serial1...
Again maybe just problem with my library... First off see if I am receiving anything... Note: I hacked up my test app, to use Serial2 for the Serial inputs and outputs instead of Serial so I could use commands... And that appears to be working fine.
EDIT: Timeout issue in the library. When the library was originally written it was for AVR 8 bit boards running at 16mhz and timeouts were done by timeout loops.
When I added support for t3.x I just changed the timeout value... But that was not caught in the #ifdef for t3.x and even if it did, would not be high enough...
Probably time to break down and use a timeout using something like an elpasedmillis...
Last edited:
defragster
Senior Member+
Hooked Servo into my Combo app - the IR Receiver is triggering it seems from Servo noise - with no IR Tx buttons on remote pressed.
Mike can you put a servo with your IR receiver? Do you see odd behavior? For Demo I was going to tie buttons to Servo pos ++ and --, but IR reception is compromised getting 0xF's instead of normal button code. Is there a timer conflict on the select pins or system wide?
Mike can you put a servo with your IR receiver? Do you see odd behavior? For Demo I was going to tie buttons to Servo pos ++ and --, but IR reception is compromised getting 0xF's instead of normal button code. Is there a timer conflict on the select pins or system wide?
mjs513
Senior Member+
Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while
UPDATE:
Ok, just tested it and yeah, am seeing strange things. The servo movement seems a little more jerkier than before and the IR reading are mostly FF's or random numbers unlike in individual tests. Same effect if you are using Servo or PWMServo libraries. For ref here is the sketch:
Code:
/*
* IRremote: IRrecvDemo - demonstrates receiving IR codes with IRrecv
* An IR detector/demodulator must be connected to the input RECV_PIN.
* Version 0.1 July, 2009
* Copyright 2009 Ken Shirriff
* http://arcfn.com
*/
#include <IRremote.h>
int RECV_PIN = 11;
IRrecv irrecv(RECV_PIN);
decode_results results;
//#include <PWMServo.h>
#include <Servo.h>
//PWMServo myservo;
Servo myservo; // create servo object to control a servo
// twelve servo objects can be created on most boards
int pos = 0; // variable to store the servo position
void setup()
{
Serial.begin(9600);
// In case the interrupt driver crashes on setup, give a clue
// to the user what's going on.
Serial.println("Enabling IRin");
irrecv.enableIRIn(); // Start the receiver
Serial.println("Enabled IRin");
myservo.attach(9, 544, 2000); // attaches the servo on pin 9 to the servo object
myservo.write(0);
Serial.printf("Angle Read %d\r\n", myservo.read());
delay(5000);
}
void loop() {
for(pos = 0; pos <= 180; pos += 1) // goes from 0 degrees to 180 degrees
{ // in steps of 1 degree
myservo.write(pos); // tell servo to go to position in variable 'pos'
delay(15); // waits 15ms for the servo to reach the position
if (irrecv.decode(&results)) {
Serial.println(results.value, HEX);
irrecv.resume(); // Receive the next value
}
}
delay(100);
for(pos = 180; pos>=0; pos-=1) // goes from 180 degrees to 0 degrees
{
myservo.write(pos); // tell servo to go to position in variable 'pos'
delay(15); // waits 15ms for the servo to reach the position
}
delay(1000);
}
Last edited:
Clock is on pin 14. Hm.. Does someone know if it is possible to use pin14 for spi-clck? I have not looked at the pin-configurations so far.
Edit: Err. wrong,the board does that
all good with sclk.Edit: Sd2Card.cpp needs some love and edits. Adding the #defines __IMXRT* to some other files needed.
Last edited:
defragster
Senior Member+
Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while
Just remember Servo VCC is 5V
- I started Servo with pin #8 and moved to #2 for control - LedControl LED's are now 3/4/5. I see #22 and #23 are also open if it is a timer conflict. Even just SWEEP example with IR powered shows flicker on yellow Rcv LED.
mjs513
Senior Member+
Yeah had servo on 3.3v
. Probably pulled too much power. Anyway:1. No yellow lite flashing while servo moving for me. Using 11 for IR sensor and 9 for servo.
2. Still seeing a lot of FF's but at least the code is the same when it does the reading. If you just hold the button down it just gives ff's.
3. Now the servo is on 5v its running a lot smoother
manitou
Senior Member+
FYI,
new T4 beta arrives (#27) to swap out with my impaired unit. New beta unit uploads properly. Only differences I expect are MAC address in fuses and drift in crystals
Measured with GPS PPS and GPT timer clocked by either 24mhz or 32khz crystals.
https://github.com/manitou48/teensy4/blob/master/gpsgpt.ino
other MCU crystals https://github.com/manitou48/crystals/blob/master/crystals.txt
new T4 beta arrives (#27) to swap out with my impaired unit. New beta unit uploads properly.
Only differences I expect are MAC address in fuses and drift in crystals
Code:
crystal drift (ppm)
24MHz 32KHz
T4beta1 -3.2 -4.7 1052
T4beta1-2 -4.1 -4.3
T4beta2 1 -6 1062
T4beta2-2 -11 10 1062
T4-1 -11 -3 1062
T4-2 -10 -5
T4.0-1 -23 -0.5
T4.0-2 -26 -2.5
T4.1 -7 -2
T4.1-1 -11 -5.5
T4.1-2 -12 -3
T4.1-3 -10 1
EVK -14 -54 1052
EVKB -6 -52
NXP1062 -9 9
T4mm -45 -6 sparkfun T4 micromodhttps://github.com/manitou48/teensy4/blob/master/gpsgpt.ino
other MCU crystals https://github.com/manitou48/crystals/blob/master/crystals.txt
Last edited:
mjs513
Senior Member+
Frank: Yep - no argument here. Typically I power them from separate 5v, if I have a bunch of them. For one its never been on issue when I am on my desktop.
Tim: could be the timers, check irrecv.cpp around line 167 and irrecvint.h.
EDIT: Playing around with the lag and tolerance numbers and watching the data carefully, think the issue is if you hold the button even a fraction too long you get a false read. If I tapped it real quick I would get single reads and no ff's but if too slow to release would get the actual readings plus a ff's sometime multiple. Timing probably but have to search where - need a debouce function
Last edited:
defragster
Senior Member+
Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while
UPDATE:
Ok, just tested it and yeah, am seeing strange things. The servo movement seems a little more jerkier than before and the IR reading are mostly FF's or random numbers unlike in individual tests. Same effect if you are using Servo or PWMServo libraries. For ref here is the sketch:
Good sketch - thanks for testing Mike- you see what I saw and with your sketch I see what you saw - except I clearly have flickers small and bigger on IR Yellow Rcv indicate LED - even with the IR LED covered. And Sermon shows phantom IR reads unless servo power removed.
Not running nut powered are my OLED ssd1306 and LedControl 8 digit and they are showing affects on the images they are holding from last run. The multiplexed LED are pulsing and a flicker scan is pulsing the OLED as the servo cycles.
PROBLEM: GND ISSUE. That Servo is pulling Gnd across breadboard. Move GND wire from open BBoard area to GND pin row - or touch USB plug and all is well. Even on the end of the wire from GND row to (-)RAIL and it show noise.
With better GND the IR receive is not throwing 0xF's like it was before!
My setup it two long BBoard together with T_4 and T_3.1 ( debug ) and T_3.6 on same hub from PC (now 5V 2.5A POWERED)- so common GND to each Teensy and from each to BBD rails. Also pulled GND from T4 end pin to far (-)Rail - common to T_3.6 - No flicker there and the Servo is moving 10° on pressing the IR Remote control buttons.
>> Gotta get to mailbox - my phone says PJRC delivered.
manitou
Senior Member+
SPI DMA
My first cut at simple SPI DMA on T4, transmit only. Checked SPI clocks on scope. Data rate is close to SPI CCR clock rate.
https://github.com/manitou48/teensy4/blob/master/spidma.ino
SPI is still running, need to fix that. Add Rx DMA, try 16 and 32 bit frame size, though the clock doesn't have gaps that i can see.
At 25.1 MHz waveform is a little distorted, Vpp 2.74v. At max speed, 37.7 MHz, waveform distorted, Vpp 2v. I haven't tested with a SPI device.
EDIT: github update, simple DMA TX, polling, and SPI stops properly. also added spidma2.ino with DMA TX and RX, polling, jumper MOSI to MISO for error check.
My first cut at simple SPI DMA on T4, transmit only. Checked SPI clocks on scope. Data rate is close to SPI CCR clock rate.
https://github.com/manitou48/teensy4/blob/master/spidma.ino
Code:
SPI CLOCK 4000000 CCR freq 4.0 MHz
tx 1024 samples 1990 us 4.1 mbs scope clock 3.97 mhz
SPI CLOCK 8000000 CCR freq 7.5 MHz
tx 1024 samples 1080 us 7.6 mbs scope 7.57 mhz
SPI CLOCK 16000000 CCR freq 15.1 MHz
tx 1024 samples 570 us 14.4 mbs scope 14.9mhz
SPI CLOCK 30000000 CCR freq 25.1 MHz
tx 1024 samples 370 us 22.1 mbs ? scope 25 mhz Vpp 2.74 v
SPI CLOCK 40000000 CCR freq 37.7 MHz
tx 1024 samples 260 us 31.5 mbs scope 37.9 Vpp 2vAt 25.1 MHz waveform is a little distorted, Vpp 2.74v. At max speed, 37.7 MHz, waveform distorted, Vpp 2v. I haven't tested with a SPI device.
EDIT: github update, simple DMA TX, polling, and SPI stops properly. also added spidma2.ino with DMA TX and RX, polling, jumper MOSI to MISO for error check.
Last edited:
defragster
Senior Member+
servos can need a lot of power.. more than usb allows. be careful
Can confirm it was GND across BreadBoard. I do have 3 Teensy and the stuff on - inline cheap power meter says 4.88V and 0.17-0.23 Amp total - running this micro servo shows it might be peaking at 0.33A total. Plugging hub power back in goes to 5.03V and 0.00A from PC.
Now disconnected that for moving to the impressive looking breakout from PJRC - on plexiglass with rubber feet.
mjs513
Senior Member+
Tim: Glad you found the problem. My ground line runs are as long as yours I don't think. Don't use the T3.2 for debug any more unless I am testing something specific. Everything goes to serial. My GND connections are typically all close to the GND pin of the T4. Maybe an a couple inches.
Nice work Frank. Looked at it a while ago, you have more patience than I do
PaulStoffregen
Well-known member
Looks like you got the later beta boards, where we were much closer with the capacitors. Earlier ones (number under 22) probably have much more error, since we were still learning which capacitors to use (and NXP's specs and examples were of little help).
PaulStoffregen
Well-known member
I've seen something like this a few times, usually after many hours of use (Linux, 64 bit). I believe there may be a bug lingering in teensy_ports, or perhaps in the Arduino IDE discovery manager code I added to talk to teensy_ports. Restarting Arduino always seems to fix it.
defragster
Senior Member+
KurtE said:
That was a typo - yes wString.cpp was copied and just confirmed that with Stream.cpp copied to T4 the other posted sketch works.
Problem was not getting a CLEAN build - adding that file didn't trigger - even though I did a board change with the way it now TEMPS per Board. Did a Close IDE after Stream.cpp copy build failed - then restarting built fine and runs.
Soldered pins to Audio board - I had a Vol Pot and Mic I put on too and it is working.
defragster
Senior Member+
I've posted on seeing this as well - most specifically in my cases where the T4 got into odd state perhaps from interrupted startup - or quickly returning and interrupted. [ Both of my 'panics' Frank's T4 OFF testing and the mA measure going down to 300 Mhz ] - and also perhaps background upload to T_3.x's with TyComm when TT_Loader was active. In my case 'Windows' - assumed it might be the MSFT USB code misleading T_ports. Planned to look for recurrence when new T4 USB arrives.
defragster
Senior Member+
Genuine PJRC supplied [picked up as spare parts and actually found them first place I looked] - with Filler disk for Mic : pjrc.com/store/microphone.html
And 25K Pot : pjrc.com/store/pot_thumb_25k.html {need to check pin 15 there }
Decided to skip adding Flash so as not to ruin it just in case
Last edited:
- Status