Teensyduino 1.49 Beta #2

Status
Not open for further replies.
I'm going to package up 1.49-beta3 soon.

Now's the time to remind me of stuff I've forgotten to test or merge....

Just off the top of the head think there were a few open PRs in the Core for T4: #385, 395 and 397.
For Wire: PR #18 still open

See you merged in the ST7735_t3 PR - Thank you :)

For SPI: PR #55 is still open. Not sure if FrankB's PR #50 is overtaken by events.

I am sure @KurtE and @defragster can add to this list
 
Thanks. I'm looking at all these right now....

cores #397 - merged just now

cores #385 - was merged in October

spi #50 - merged just now

spi #55 - this makes me a little nervous so close to a release, but merging it now.

Some of these I'm leaving for later, probably 1.50.

cores #395 - breaks PWM phase sync timing of updates, as I explained in a comment

wire #18 - altering I2C timing is too high risk for this late in 1.49 testing
 
My comment on #395 notes that behavior now is that without 'some' change the behavior is problematic at best - there is a cusp where what would be expected to be HIGH value results in 'zero'. That PULL used prior code flow - makes sense it isn't perfect with time sync, but the expected value is presented - versus 0 instead of full value.

For #18 and related speed change - that worked well on SSD1306 to get near 3 MHz - testing was some weeks back - can't speak to other changes or devices that may fail on losing lesser clocks - but it gave a good perf bump to SSD1306 and the ones I have ran reliably with mjs513 speed edit. mjs513 and KurtE did testing on the noted BN0 thing they bought for clock stretch and it seemed to hit a critical pin change as I read the posts they left.

Indeed the #385 pre-setup() hooks change was taken for 1.48.

Only other thing on my post #2 list was the clock anomaly at certain speeds( 24 & 150 observed ) . Makes the millis() clock look bad - and may affect SDIO or other clocks as well. But unless there is time to see an obvious correction, best to not try fudging it in haste as progressive clock changes can make it run right when needed.
 
That PULL used prior code flow - makes sense it isn't perfect with time sync, but the expected value is presented - versus 0 instead of full value.

Yes, that's the way it was done on Teensy 3.x, because it was done that way on Teensy 2, because Arduino does it that way. But just because we've always done it that way doesn't mean we should.

The bad waveforms which result for the 0 and 2^resolution cases have been on my low priority bug list for many years. I'll probably never go back and fix it on those older boards, but starting with Teensy 4 my goal is to have all analogWrite() updates use proper PWM timing.


behavior now is that without 'some' change the behavior is problematic at best - there is a cusp where what would be expected to be HIGH value results in 'zero'

I did some tests just now. I was only able to reproduce the problem on the pins controlled by the Quad Timers. I've committed a fix.

https://github.com/PaulStoffregen/cores/commit/1be006032e8ad38a6a74f714b4859cbad5913d24

Are there other cases where this happens?
 

I did some tests just now. I was only able to reproduce the problem on the pins controlled by the Quad Timers. I've committed a fix.

https://github.com/PaulStoffregen/cores/commit/1be006032e8ad38a6a74f714b4859cbad5913d24

Are there other cases where this happens?

Wasn't trying to justify bad behavior 'just because' - only that as posted/tested it was erratic. ... TODO maybe came in handy?

I can't say about other pins/cases - only tested the noted on the post/thread. If you can say which pins are on Quad Timers or off I will test further with that fix in place. Maybe something fun for the ADC_Lite.

Other than those notes - don't recall having seen anything reported not working that seemed like it should be working.
 
There are 3 cases:

Pins 10-15, 18, 19 use the quad timers.

Pins 0, 1, 24, 25 use the flexpwm timer extra (X) output.

All the other PWM pins use flexpwm timer normal (A, B) outputs.
 
There are 3 cases:

Pins 10-15, 18, 19 use the quad timers.

Pins 0, 1, 24, 25 use the flexpwm timer extra (X) output.

All the other PWM pins use flexpwm timer normal (A, B) outputs.

Thx, I'll look to set value out and read them in groups with the 6 Analog/non-PWM {16,17,20,21, 26,27} pins and cycle value up and down when at some measurable freq with the ADCLite. If I read right {26,27} are only adc2, but the other 4 both adc 1&2?
 
Thanks. I'm looking at all these right now....

cores #397 - merged just now

cores #385 - was merged in October

spi #50 - merged just now

spi #55 - this makes me a little nervous so close to a release, but merging it now.

Some of these I'm leaving for later, probably 1.50.

cores #395 - breaks PWM phase sync timing of updates, as I explained in a comment

wire #18 - altering I2C timing is too high risk for this late in 1.49 testing


Thanks Paul. Glad the list helped. As for SPI #55 (was just going through the major pieces to check what was still open for you on the T4 that maybe should get into 1.49), doesn't seem to be affecting anything with SPI without it in.

As for wire #18 the I2C timings is a small part of the change. The major piece is the fix for the BNO080 sensor. After we did that I found it was also needed for the Garmin Lidar Lite V3 or 4, forget now which didn't work without the fix. Been running with both since we put the PR in. If you are uncomfortable with the I2C timing with testing the changes can you leave that part out and only put in the clock stretching and clear FIFO. As @defragster stated we tested the changes so far on the SSD1306, the BNO080, BNO055, Lidar Lite's, MLX900640 as well as on the MPU-9250.
 
@paulStoffregen and @mjs513 - Yes the Wire change fixed an issue where for BN0055 we cleared the fifos if we entered a new start condition and the fifo had data in it...

This busted some devices/libraries that rely on repeat starts... Like the BNO080, which reads something like 2 bytes in to get the size and then does another read to read in the buffer.
 
Just tested the 1.49 Beta#2 with a data logger program I'm working on. I tested the Beta to see how it would affect data file upload speeds, and the improvements were significant.

Test setup:
Teensy 4.0 at 600MHz with attached SD Micro card running SDFat 2.0 on 8GB card formatted as FAT32
I tested data file upload speeds with an 80MB data file generated by the data logger program. I also tested raw USB upload speed sending from a constant buffer without file reads.
Data is uploaded in 4KB blocks with ACK handshaking by the host program running in WIN10 Home 64-bit with latest updates.

TeensyDuino 1.48 File Upload: 6.8MB/S Buffer Upload: 7.16MB/s
TeensyDuino 1.4B#2 File Upload: 11.8MB/S Buffer Upload: 26MB/s

The 26MB/s buffer upload overstresses my host, generating some errors. The file uploads seem reliable and did not require changes to either the data logger program or my host program.

The improved upload speeds are much appreciated, since at max speed, the data logger stores 8 channels of float32 data at 20,000 samples per second. I save float32 data because the channels are run through a 4-pole IIR lowpass filter before being saved. The collection rate is near the max 175KSPS of the LTC1867L ADC converter in the logger.
 
Thx, I'll look to set value out and read them in groups with the 6 Analog/non-PWM {16,17,20,21, 26,27} pins and cycle value up and down when at some measurable freq with the ADCLite. If I read right {26,27} are only adc2, but the other 4 both adc 1&2?

I got as far as updating libraries and putting this in the ADC_Lite example by KurtE:
Code:
const uint8_t ADC0_pins[] = {16,17,20};
const uint8_t ADC1_pins[] = {21,26,27};
#define COUNT_PINS_PER_ADC  sizeof(ADC0_pins)

const int interval_period = 20; // us

Runs without reporting fail - though data untested/viewed. Much faster than 20 us on the timer and ADC0 fails read ready in the timer_isr. And swapping the last two pin elements in the ADC arrays { 20 and 27 } indeed fails since #27 can't be read on ADC0.

For some reason the SDFat {beta SdFat Version 2?} - gave compile errors - easier to //comment those features to start than try to resolve and even then I'm out of cycles for today.
 
As for wire #18 the I2C timings is a small part of the change. The major piece is the fix for the BNO080 sensor.

@paulStoffregen and @mjs513 - Yes the Wire change fixed an issue where for BN0055 we cleared the fifos if we entered a new start condition and the fifo had data in it...

This busted some devices/libraries that rely on repeat starts... Like the BNO080, which reads something like 2 bytes in to get the size and then does another read to read in the buffer.

Is this enough?

https://github.com/PaulStoffregen/Wire/commit/6c9fec1699297e0b8b71609b42a94b4a53a2043d
 
@PaulStoffregen - @KurtE

The only other thing that was part of @KurtE's changes that had nothing to do with the I2C speed changes was also a change for the pad configs for SDA and SCL:

Is:
Code:
// Setup SDA register
	*(portControlRegister(hardware.sda_pins[sda_pin_index_].pin)) |= IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3);
…
	// setup SCL register
	*(portControlRegister(hardware.scl_pins[scl_pin_index_].pin)) |= IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3);

In @KurtE's change it should be:
Code:
// Setup SDA register
	*(portControlRegister(hardware.sda_pins[sda_pin_index_].pin)) = IOMUXC_PAD_ODE |IOMUXC_PAD_SRE |  IOMUXC_PAD_DSE(5)| IOMUXC_PAD_SPEED(1);
…
	// setup SCL register
	*(portControlRegister(hardware.scl_pins[scl_pin_index_].pin)) = IOMUXC_PAD_ODE |IOMUXC_PAD_SRE |  IOMUXC_PAD_DSE(5)| IOMUXC_PAD_SPEED(1);


With the I2C clock changes is there any other tests you would like to see done to confirm the changes work or to identify potential issues?
 
I committed a hybrid of the pin config change. I want to preserve the weak pullups, like on Teensy 2.0 and most Arduino boards.

https://github.com/PaulStoffregen/Wire/commit/f52060abe313362817ca9c731f9ed96a56244848


With the I2C clock changes is there any other tests you would like to see done to confirm the changes work or to identify potential issues?

Yes. I'm packaging up 1.49-beta3 now. Should have it uploaded in ~15 minutes. Just waiting on Raspberry Pi build and Apple notarization.

Really hoping you can check if that BNO080 sensor works with 1.49-beta3?
 
I committed a hybrid of the pin config change. I want to preserve the weak pullups, like on Teensy 2.0 and most Arduino boards.

https://github.com/PaulStoffregen/Wire/commit/f52060abe313362817ca9c731f9ed96a56244848




Yes. I'm packaging up 1.49-beta3 now. Should have it uploaded in ~15 minutes. Just waiting on Raspberry Pi build and Apple notarization.

Really hoping you can check if that BNO080 sensor works with 1.49-beta3?

Thanks - looking forward to the changes. Then you better get some sleep.
 
…….

Really hoping you can check if that BNO080 sensor works with 1.49-beta3?

Just posted on the Beta3 thread. It does work but having issues. Initially sketch starts at 400mhz. It wouldn't work. So I changed it to 100Mhz and it would run the sketches tested. I then changed back to 400mhz and it would then run fine without an issue. Strange problem. Cause: may need additional pullups. Have to change my set up so I can add additional pullups or change pad config as a quick and dirty test.
 
@PaulStoffregen

The issue seems to resolve itself with using the pin configs in the BNO080 Wire PR. It also seems to be working properly with the original pin config in the Wire library before the "hybrid change". In other words:
Code:
THIS
*(portControlRegister(hardware.sda_pins[sda_pin_index_].pin)) = IOMUXC_PAD_ODE |IOMUXC_PAD_SRE |  IOMUXC_PAD_DSE(5)| IOMUXC_PAD_SPEED(1);

OR THIS
*(portControlRegister(hardware.sda_pins[sda_pin_index_].pin)) |= IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3);
work.
 
Before I just revert to the old code, could you give this a try?

Code:
#define PINCONFIG (IOMUXC_PAD_ODE | IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(5) | IOMUXC_PAD_SPEED(1) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3))

Or maybe lower numbers for IOMUXC_PAD_DSE?
 
Changing DSE to 4 seems to work better, I would go with this minor update to what you have.:

Code:
#define PINCONFIG (IOMUXC_PAD_ODE | IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(4) | IOMUXC_PAD_SPEED(1) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3))

I did try it at DSE=5 and DSE=3 and after about 3-4 consecutive uploads of sketches (same or different) it would hang and would have to turn off and then back on or hit the upload button on the T4 and reload and it would start up again. It does happen with the old code as well but there are more consecutive uploads between it hanging the BNO080. Now this could be me since I was the time between uploads was only a few seconds.
 
Status
Not open for further replies.
Back
Top