PDA

View Full Version : Teensyduino 1.49 Beta #2



Paul
12-10-2019, 11:48 AM
Here is a second beta test for Teensyduino 1.49.


EDIT: links removed, please use 1.49-beta3 (https://forum.pjrc.com/threads/58707-Teensyduino-1-49-Beta-3)


Changes since Teensyduino 1.49-beta1 (https://forum.pjrc.com/threads/58567-Teensyduino-1-49-Beta-1)

Add Teensy 4.0 USB MIDI, Keyboard, Mouse, Joystick
Support for MacOS Catalina
Port WS2812Serial to Teensy 4.0 (KurtE)
AVR register emulation on Teensy 4.0 (KurtE)
Fix serial DMA def on Teensy 4.0 (KurtE)
Improve ADC & XBAR defs on Teensy 4.0 (KurtE)
Improve quadrature encoder defs on Teensy 4.0 (mjs513)
Add Teensy 4.0 USB Touchscreen, not finished... work in progress
Remove serial monitor debug messages on Arduino 1.8.9

mjs513
12-10-2019, 12:25 PM
@Paul

Downloaded and installed Beta2 with no issues whatsoever. Did see all the new USB stuff in the IDE dropdowns.

Out of curiosity I tried to run the keyboard simple example but my PC is having issues with it. Never used the usb stuff before so maybe it is me. Anyway, first run I had SerMon open and I saw the hello wrld displayed in the sermon. My PC then said it created a new Keyboard but then it went all of a sudden it logged me off and the my logon screen displayed and then I was stuck so I just hit restart.

Next run I had notepad open and plugged the T4 in again and again it went even crazier. My web browser pop upped, then the xbox gaming app opened, and then it wanted to install tycommander so I just unplugged the T4 to get control back. Not sure this is the desired behavior.

For reference I am on a Windows 10 x64 machine.

PaulStoffregen
12-10-2019, 03:09 PM
I'll confess... I tested the new USB stuff mostly with Linux and a quick check on Mac, but not Windows. I use Linux as my primary system, and the Macbook Air was set up due to the recent work on MacOS Catalina support.

I did watch the communication with the Beagle 480 protocol analyzer.

Looks like I'll need to get my Windows 10 test machine out later today! Can you tell me exactly which example you ran? Was any other hardware connected to your Teensy 4.0 during the test?

mjs513
12-10-2019, 03:32 PM
I'll confess... I tested the new USB stuff mostly with Linux and a quick check on Mac, but not Windows. I use Linux as my primary system, and the Macbook Air was set up due to the recent work on MacOS Catalina support.

I did watch the communication with the Beagle 480 protocol analyzer.

Looks like I'll need to get my Windows 10 test machine out later today! Can you tell me exactly which example you ran? Was any other hardware connected to your Teensy 4.0 during the test?

Morning again.

Anyway, ran the Simple USB Keyboard Example, simple.ino, under keyboard examples. Nothing else was hooked up to the T4. Was using a the Ultimate T4 breakout board I got off Tindie. Reason - it was handy. It did have a SD card in the its SD Socket.

Also, just in case it might have been the breakout board I tested with one of my breakouts that I have been using with nothing additional on the board. All it does is bring the pins on the T4 out to the headers. It exhibited the exact same behavior.

defragster
12-10-2019, 04:53 PM
Downloaded and installed TD 1.49b2 for some reason this time it gave this on first run - I did not pick "Run":
18414
Looked at properties and it offered 'UNBLOCK', I did not check that and re-ran the download and it completed without issue or prompt from Windows 10.

Re: Clock issue Failure of Micros() at some speeds (https://forum.pjrc.com/threads/58567-Teensyduino-1-49-Beta-1?p=223407&viewfull=1#post223407) - that does repro at 24 MHz. I edited compile to start at 150 MHz and that does work properly - updated in post. Edited code there as it was missing a 0 when asking for 150MHz - it was type 15 MHz.

Accidentally had "USB Serial=S/M/K/J" on other sketch and Windows gave this:18415

Ran the 'Simple.ino' and got 3 things to close and nothing in notepad - T4 with nothing connected: Excel, OneDrive, Browser page to 'Linked In', also TyCommander display page changed.

This "T:\arduino_1.8.10\examples\09.USB\Keyboard\Keyboar dSerial\KeyboardSerial.ino" won't build 'keyboard' or 'Ser + Mouse + Key + Joy'


T:\arduino_1.8.10\arduino-builder -dump-prefs -logger=machine -hardware T:\arduino_1.8.10\hardware -hardware C:\Users\Tim\AppData\Local\Arduino15\packages -hardware T:\tCode\hardware -tools T:\arduino_1.8.10\tools-builder -tools T:\arduino_1.8.10\hardware\tools\avr -tools C:\Users\Tim\AppData\Local\Arduino15\packages -built-in-libraries T:\arduino_1.8.10\libraries -libraries T:\tCode\libraries -fqbn=teensy:avr:teensy40:usb=keyboard,speed=600,op t=o2std,keys=en-us -ide-version=10810 -build-path T:\TEMP\arduino_build_750081 -warnings=more -build-cache T:\TEMP\arduino_cache_493927 -verbose T:\arduino_1.8.10\examples\09.USB\Keyboard\Keyboar dSerial\KeyboardSerial.ino
T:\arduino_1.8.10\arduino-builder -compile -logger=machine -hardware T:\arduino_1.8.10\hardware -hardware C:\Users\Tim\AppData\Local\Arduino15\packages -hardware T:\tCode\hardware -tools T:\arduino_1.8.10\tools-builder -tools T:\arduino_1.8.10\hardware\tools\avr -tools C:\Users\Tim\AppData\Local\Arduino15\packages -built-in-libraries T:\arduino_1.8.10\libraries -libraries T:\tCode\libraries -fqbn=teensy:avr:teensy40:usb=keyboard,speed=600,op t=o2std,keys=en-us -ide-version=10810 -build-path T:\TEMP\arduino_build_750081 -warnings=more -build-cache T:\TEMP\arduino_cache_493927 -verbose T:\arduino_1.8.10\examples\09.USB\Keyboard\Keyboar dSerial\KeyboardSerial.ino
Using board 'teensy40' from platform in folder: T:\arduino_1.8.10\hardware\teensy\avr
Using core 'teensy4' from platform in folder: T:\arduino_1.8.10\hardware\teensy\avr
Detecting libraries used...
"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=149 -DARDUINO=10810 -DF_CPU=600000000 -DUSB_KEYBOARDONLY -DLAYOUT_US_ENGLISH "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\ \teensy4" "T:\\TEMP\\arduino_build_750081\\sketch\\KeyboardSe rial.ino.cpp" -o nul
Alternatives for Keyboard.h: [Keyboard@1.0.2]
ResolveLibrary(Keyboard.h)
-> candidates: [Keyboard@1.0.2]
"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=149 -DARDUINO=10810 -DF_CPU=600000000 -DUSB_KEYBOARDONLY -DLAYOUT_US_ENGLISH "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\ \teensy4" "-IT:\\arduino_1.8.10\\libraries\\Keyboard\\src" "T:\\TEMP\\arduino_build_750081\\sketch\\KeyboardSe rial.ino.cpp" -o nul
Alternatives for HID.h: []
In file included from T:\arduino_1.8.10\examples\09.USB\Keyboard\Keyboar dSerial\KeyboardSerial.ino:22:0:

ResolveLibrary(HID.h)
T:\arduino_1.8.10\libraries\Keyboard\src/Keyboard.h:25:17: fatal error: HID.h: No such file or directory

-> candidates: []
compilation terminated.

Multiple libraries were found for "Keyboard.h"
Used: T:\arduino_1.8.10\libraries\Keyboard
Using library Keyboard at version 1.0.2 in folder: T:\arduino_1.8.10\libraries\Keyboard
Error compiling for board Teensy 4.0.

ETMoody3
12-10-2019, 06:11 PM
Installed on linux mint 19.2 Tina, XFCE desktop, Arduino 1.8.10

USB Midi example " InputRead " works as expected.

USB Keyboard example "Simple"... "all hell" breaks loose. Random applications launched, ' Start menu' opens, volume control activates.

ETMoody3
12-10-2019, 06:21 PM
attached T4 previously flashed with "Keyboard Simple" sketch to windows 10 notebook computer. It rebooted, and failed to acknowledge the built in keyboard. Another reboot corrected this.

A second attempt to connect it with setting opened to devices page... device found, but same results immediately afterward... reboot, locked out of default keyboard device.

vjmuzik
12-10-2019, 06:32 PM
The Catalina one is still using Teensyduino 1.49 beta 1.
18416

radias
12-10-2019, 06:48 PM
Windows 10 Pro 1909 x64 build 18363.476

Trying to run example "Teensy USB_MIDI Buttons"

CPU Speed: "600MHz" (default)
Optimize: "Faster" (default)

USB Type: "MIDI"
Windows builtin MIDI driver: Device driver not started (code 10), "nonpresent device"
Korg USB MIDI driver 1.15.31.2 (recent): Driver loads and starts, exactly one "Note on" gets through, then no communication any more. T4 keeps on running.

USB Type: "Serial + MIDI"
Does not compile. Arduino errors:

Arduino: 1.8.10 (Windows 10), TD: 1.49-beta2, Board: "Teensy 4.0, Serial + MIDI, 600 MHz, Faster, US International"

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:683:13: error: 'CDC_RX_SIZE_480' undeclared here (not in a function)

LSB(CDC_RX_SIZE_480),MSB(CDC_RX_SIZE_480),// wMaxPacketSize

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:64:18: note: in definition of macro 'LSB'

#define LSB(n) ((n) & 255)

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:690:13: error: 'CDC_TX_SIZE_480' undeclared here (not in a function)

LSB(CDC_TX_SIZE_480),MSB(CDC_TX_SIZE_480),// wMaxPacketSize

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:64:18: note: in definition of macro 'LSB'

#define LSB(n) ((n) & 255)

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:1517:13: error: 'CDC_RX_SIZE_12' undeclared here (not in a function)

LSB(CDC_RX_SIZE_12),MSB(CDC_RX_SIZE_12),// wMaxPacketSize

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:64:18: note: in definition of macro 'LSB'

#define LSB(n) ((n) & 255)

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:1524:13: error: 'CDC_TX_SIZE_12' undeclared here (not in a function)

LSB(CDC_TX_SIZE_12),MSB(CDC_TX_SIZE_12),// wMaxPacketSize

^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\us b_desc.c:64:18: note: in definition of macro 'LSB'

#define LSB(n) ((n) & 255)

^

Multiple libraries were found for "Bounce.h"
Used: C:\Program
Error compiling for board Teensy 4.0.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

bicycleguy
12-10-2019, 07:21 PM
The Catalina one is still using Teensyduino 1.49 beta 1.

Well the Arduino window says beta 1, but launches beta 2.
Don't see anything but serial for T4 USB Type.

18417

Installed no other problems on Catalina. I had previously deleted beta1 and cleared all the Arduino related 'Security and Privacy' preferences to give it a good test.

vjmuzik
12-10-2019, 07:29 PM
Teensy Loader does say beta 2, but nothing has been changed in the cores folder like it should be.

neurofun
12-10-2019, 08:07 PM
MacOS 10.13.6

USB Type: "MIDI"
Works in both directions, IN/OUT.

USB Type: "Serial + MIDI"
Does not compile.
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:683:13: error: 'CDC_RX_SIZE_480' undeclared here (not in a function)
LSB(CDC_RX_SIZE_480),MSB(CDC_RX_SIZE_480),// wMaxPacketSize
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:64:18: note: in definition of macro 'LSB'
#define LSB(n) ((n) & 255)
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:690:13: error: 'CDC_TX_SIZE_480' undeclared here (not in a function)
LSB(CDC_TX_SIZE_480),MSB(CDC_TX_SIZE_480),// wMaxPacketSize
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:64:18: note: in definition of macro 'LSB'
#define LSB(n) ((n) & 255)
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:1517:13: error: 'CDC_RX_SIZE_12' undeclared here (not in a function)
LSB(CDC_RX_SIZE_12),MSB(CDC_RX_SIZE_12),// wMaxPacketSize
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:64:18: note: in definition of macro 'LSB'
#define LSB(n) ((n) & 255)
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:1524:13: error: 'CDC_TX_SIZE_12' undeclared here (not in a function)
LSB(CDC_TX_SIZE_12),MSB(CDC_TX_SIZE_12),// wMaxPacketSize
^
/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy4/usb_desc.c:64:18: note: in definition of macro 'LSB'
#define LSB(n) ((n) & 255)
^

vjmuzik
12-10-2019, 08:09 PM
After installing MacOS-X 10.8 to 10.14 over the MacOS Catalina 10.15 app I can confirm the same bug with "Serial + MIDI", but after compiling with normal "MIDI" it seems to work as expected while doing a simple loopback test with seemingly no issues so far. MacOS detects it as it should along with name.c as well and after determining that all of the various midi messages go through and come back as expected I think MIDI is sorted out as long as there are no differences between the T3.6 and T4.0 send and receive functions that would make it work different since I didn't test all of them.

Here's the loopback code if anyone else wants to test it real easy.

void setup() {
}

uint32_t message;

void loop() {
message = usb_midi_read_message();
if(message) {
Serial.print(" Message: ");
Serial.println(message, HEX);
usb_midi_write_packed(message);
}
}

neurofun
12-10-2019, 09:33 PM
MacOS 10.13.6

USB Type: "MIDI"
Works in both directions, IN/OUT.

USB Type: "Serial + MIDI"
Does not compile.

Follow up:
USB Type: "MIDI" seems to act like "Serial + MIDI" since Serial.print() still shows up in serial monitor.

vjmuzik
12-10-2019, 09:45 PM
Follow up:
USB Type: "MIDI" seems to act like "Serial + MIDI" since Serial.print() still shows up in serial monitor.

That is by design, but it’s not Serial being that it won’t work with normal serial monitors since it’s a special HID serial emulation designed for the Teensy monitor. All previous Teensy devices have had the same emulation in the past.

neurofun
12-10-2019, 10:35 PM
That is by design, but it’s not Serial being that it won’t work with normal serial monitors since it’s a special HID serial emulation designed for the Teensy monitor. All previous Teensy devices have had the same emulation in the past.

I was slightly confused when the teensy didn't show up as a usb serial device and the Serial.print() still worked.
It all makes sense now. Thanks for the clarification.

PaulStoffregen
12-10-2019, 11:49 PM
Well the Arduino window says beta 1, but launches beta 2.
Don't see anything but serial for T4 USB Type.

Opps, I messed up the MacOS Catalina build. Fixed it just now and uploaded a fresh file.

The new Teensyduino_MacOS_Catalina.zip (https://www.pjrc.com/teensy/td_149-beta2/Teensyduino_MacOS_Catalina.zip) has shasum e72ba892097e5f849f71706d8b14d2abaea14926.

The original Teensyduino_MacOS_Catalina.zip (https://www.pjrc.com/teensy/td_149-beta2/Teensyduino_MacOS_Catalina.orig.zip) is still on the server with file renamed. It has shasum bf8e3b3b16891131b700cf82b695fd4c8425fe06.

My build process for this Catalina download still involves many manual steps. I skipped automating it, so I could get back to work on the missing USB types. Just now I started the beginning of a script which should help, though it's still need more work to be reasonably well automated like the other builds.

bicycleguy
12-11-2019, 12:55 AM
...Fixed it just now and uploaded a fresh file.

The new Teensyduino_MacOS_Catalina.zip (https://www.pjrc.com/teensy/td_149-beta2/Teensyduino_MacOS_Catalina.zip) has shasum e72ba892097e5f849f71706d8b14d2abaea14926.

Works great! Thanks for the shasum too, clears some of my rev. - dyslexia :)

shawn
12-11-2019, 03:58 PM
I've seen two issues with the Catalina install (running on Mojave):

When I open the search box with cmd-F the first time after a fresh open, and I start typing, the first few characters in my search always go into the editor instead of the search box. This doesn't happen with the regular Arduino 1.8.10 IDE, nor does it happen if I wait a few seconds before typing into the search box. I've seen this with both Beta #1 and Beta #2.
When I try to close a window that has edited content, and I select "Don't Save", I've seen that window never close and I have to quit the app to get it to close. I haven't seen this lately, though. I've only seen this a few times with Beta #1 and not yet with Beta #2.


These issues may very well have nothing to do with Paul's build and instead have to do with OSX or the Arduino code itself. Just thought I'd report anyway. I'm running the very latest 10.14.6 with all the latest updates.

radias
12-11-2019, 04:08 PM
Catalina is so full of bugs, it should be disregarded until the issues are fixed by the costermongers.

vjmuzik
12-11-2019, 05:16 PM
I've seen two issues with the Catalina install (running on Mojave):

When I open the search box with cmd-F the first time after a fresh open, and I start typing, the first few characters in my search always go into the editor instead of the search box. This doesn't happen with the regular Arduino 1.8.10 IDE, nor does it happen if I wait a few seconds before typing into the search box. I've seen this with both Beta #1 and Beta #2.
When I try to close a window that has edited content, and I select "Don't Save", I've seen that window never close and I have to quit the app to get it to close. I haven't seen this lately, though. I've only seen this a few times with Beta #1 and not yet with Beta #2.


These issues may very well have nothing to do with Paul's build and instead have to do with OSX or the Arduino code itself. Just thought I'd report anyway. I'm running the very latest 10.14.6 with all the latest updates.

After running some quick tests I haven't been able to reproduce either of your issues using the latest MacOS Catalina 10.15.2 to any degree of certainty, on the first launch of the IDE when doing cmd-f the search window is a little slow to open by a couple of seconds but after the first open it does launch nearly instantly and doesn't misplace any keystrokes in the wrong window. As far as the second issue I haven't had that happen to me yet, not while using beta 1 or beta 2 so it may just be an issue of running the Catalina app on the older MacOS versions.

PaulStoffregen
12-12-2019, 01:01 PM
USB Keyboard example "Simple"... "all hell" breaks loose.

I committed a fix for this problem.

https://github.com/PaulStoffregen/cores/commit/9026659eaa8ad8df92134f93cb2b8a7af652cf49

Can't say I'm proud of having to add a 30 ns delay. I still don't understand *why* the status word is saying the transfer status is ready before it's actually ready.

PaulStoffregen
12-12-2019, 01:11 PM
USB Type: "Serial + MIDI"
Does not compile.

Opps. Fixed it.

https://github.com/PaulStoffregen/cores/commit/bac5b587f5ee7c91b0498f51f47129dd7d4c77a8

mjs513
12-12-2019, 02:06 PM
I committed a fix for this problem.

https://github.com/PaulStoffregen/cores/commit/9026659eaa8ad8df92134f93cb2b8a7af652cf49

Can't say I'm proud of having to add a 30 ns delay. I still don't understand *why* the status word is saying the transfer status is ready before it's actually ready.

Just downloaded and copied the changed files and gave the "simple.ino" keyboard sketch a try on my Windows10x64 desktop. Looks like the solved the issue with all "hell" breaks loose. Did confirm that it actually prints to what ever window you have active - so be careful :).

PaulStoffregen
12-12-2019, 02:12 PM
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....

mjs513
12-12-2019, 02:24 PM
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

PaulStoffregen
12-13-2019, 09:05 AM
Thanks. I'm looking at all these right now....

cores #397 (https://github.com/PaulStoffregen/cores/pull/397) - merged just now

cores #385 (https://github.com/PaulStoffregen/cores/pull/385) - was merged in October

spi #50 (https://github.com/PaulStoffregen/SPI/pull/50) - merged just now

spi #55 (https://github.com/PaulStoffregen/SPI/pull/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 (https://github.com/PaulStoffregen/cores/pull/395) - breaks PWM phase sync timing of updates, as I explained in a comment

wire #18 (https://github.com/PaulStoffregen/Wire/pull/18) - altering I2C timing is too high risk for this late in 1.49 testing

defragster
12-13-2019, 09:37 AM
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.

PaulStoffregen
12-13-2019, 10:16 AM
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?

defragster
12-13-2019, 10:37 AM

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.

PaulStoffregen
12-13-2019, 10:43 AM
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.

defragster
12-13-2019, 10:52 AM
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?

mjs513
12-13-2019, 12:11 PM
Thanks. I'm looking at all these right now....

cores #397 (https://github.com/PaulStoffregen/cores/pull/397) - merged just now

cores #385 (https://github.com/PaulStoffregen/cores/pull/385) - was merged in October

spi #50 (https://github.com/PaulStoffregen/SPI/pull/50) - merged just now

spi #55 (https://github.com/PaulStoffregen/SPI/pull/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 (https://github.com/PaulStoffregen/cores/pull/395) - breaks PWM phase sync timing of updates, as I explained in a comment

wire #18 (https://github.com/PaulStoffregen/Wire/pull/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 (https://github.com/PaulStoffregen/Wire/pull/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.

KurtE
12-13-2019, 12:21 PM
@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.

mborgerson
12-13-2019, 06:36 PM
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.

defragster
12-14-2019, 09:55 AM
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:

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 (https://github.com/greiman/SdFat-beta)?} - gave compile errors - easier to //comment those features to start than try to resolve and even then I'm out of cycles for today.

PaulStoffregen
12-15-2019, 12:14 PM
As for wire #18 (https://github.com/PaulStoffregen/Wire/pull/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

mjs513
12-15-2019, 12:36 PM
@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:

// 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:

// 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?

PaulStoffregen
12-15-2019, 12:41 PM
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?

mjs513
12-15-2019, 12:44 PM
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.

mjs513
12-15-2019, 01:57 PM
…….

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.

mjs513
12-15-2019, 02:30 PM
@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:

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.

PaulStoffregen
12-15-2019, 03:33 PM
Before I just revert to the old code, could you give this a try?



#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?

mjs513
12-15-2019, 04:20 PM
Changing DSE to 4 seems to work better, I would go with this minor update to what you have.:


#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.

PaulStoffregen
12-15-2019, 09:30 PM
I would go with this minor update to what you have.

Ok, done.

https://github.com/PaulStoffregen/Wire/commit/5f58cb703ba025076a1775321ae8d2e74063329f