PDA

View Full Version : Teensyduino 1.50 Released



Paul
02-01-2020, 01:55 AM
Teensyduino 1.50 has been released.

(https://www.pjrc.com/teensy/td_download.html)https://www.pjrc.com/teensy/td_download.html

This is a detailed list of the changes since 1.49:



Support for Arduino 1.8.11
Fix soft reboot on Teensy 4.0
Fix 1 GHz in Tools > CPU Speed
Fix IntervalTimer minimum on Teensy 4.0 (KurtE)
Add defines for ethernet and PLLs
Add defines ARDUINO_TEENSY## for each board
Fix Printable.h with WiFiNANA lib on Teensy 4.0 (MichaelMeissner)
Minor fix to defines (Frank B)
Update ADC & ST7735_t3 libraries


The last 3 items on this list were added after 1.50-beta1.

duff
02-01-2020, 02:30 AM
Downloaded Arduino 1.8.11 twice and ran it with no problems then downloaded and installed this Teensyduino and when I opened Arduino it crashes with this error every time now for both Arduino's I downloaded:


Process: Arduino [5606]
Path: /private/var/folders/*/Arduino.app/Contents/MacOS/Arduino
Identifier: cc.arduino.Arduino
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Arduino [5606]
User ID: 501


Date/Time: 2020-01-31 19:25:38.962 -0800
OS Version: Mac OS X 10.13.6 (17G10021)
Report Version: 12
Anonymous UUID: A9BE6FF8-36FF-1512-5289-45EAC01D4BA7


Sleep/Wake UUID: ECC6EA37-12E9-482C-8A4F-CBB0E5789FE3


Time Awake Since Boot: 830000 seconds
Time Since Wake: 7800 seconds


System Integrity Protection: enabled


Notes: Translocated Process


Crashed Thread: 0


Exception Type: EXC_CRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY


Termination Reason: Namespace CODESIGNING, Code 0x1


kernel messages:


VM Regions Near 0 (cr2):
-->
__TEXT 0000000108d07000-0000000108d0c000 [ 20K] r-x/r-x SM=COW S []


Thread 0 Crashed:
0 ??? 0x0000000111f5119c _dyld_start + 0


Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x00007ffee6ef8b18
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x0000000111f5119c rfl: 0x0000000000000200 cr2: 0x0000000000000000

Logical CPU: 0
Error Code: 0x00000000
Trap Number: 0




Binary Images:
0x108d07000 - 0x108d0bfff +??? (???) <2AE2040B-3408-3208-B101-5825B8F425F0> (null)
0x111f50000 - 0x111f9aadf +??? (551.5) <ACC6AC7F-EAD9-340E-B2A8-AD26FE5B387B> (null)


External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 74590183
thread_create: 0
thread_set_state: 0


VM Region Summary:
ReadOnly portion of Libraries: Total=452K resident=0K(0%) swapped_out_or_unallocated=452K(100%)
Writable regions: Total=8404K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8404K(100%)

VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
STACK GUARD 56.0M 2
Stack 8192K 2
__DATA 228K 4
__LINKEDIT 132K 3
__TEXT 320K 3
shared memory 8K 3
=========== ======= =======
TOTAL 64.7M 11


Model: MacBookPro9,2, BootROM 228.0.0.0.0, 2 processors, Intel Core i7, 2.9 GHz, 8 GB, SMC 2.2f44
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (7.21.190.20.1a4)
Bluetooth: Version 6.0.7f16, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: CT500MX500SSD1, 500.11 GB
Serial ATA Device: MATSHITADVD-R UJ-8A8
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: FaceTime HD Camera (Built-in)
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: Hub
USB Device: Apple Internal Keyboard / Trackpad
USB Device: IR Receiver
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: USB 3.0 Bus
Thunderbolt Bus: MacBook Pro, Apple Inc., 25.1

neurofun
02-01-2020, 03:28 AM
Downloaded Arduino 1.8.11 twice and ran it with no problems then downloaded and installed this Teensyduino and when I opened Arduino it crashes with this error every time now for both Arduino's I downloaded:

MacBookPro8,2 OS X 10.13.6 (16G29)
iMac12,2 OS X 10.13.6 (17G10021)

Arduino 1.8.11 & TD1.50 is running fine on both systems.

duff
02-01-2020, 05:30 AM
I get this error if I try from Terminal:
LSOpenURLsWithRole() failed with error -10810 for the file /Users/duff/Downloads/Arduino.app.

PaulStoffregen
02-01-2020, 08:10 AM
I get this error if I try from Terminal:

Does 1.50-beta1 work, or also crash?

https://forum.pjrc.com/threads/59297-Teensyduino-1-50-Beta-1

I ran 1.50 here several times on my Macbook Air with Catalina 10.15.3. Started up properly every time. Compiler and uploads programs without error.

Can you try downloading the 1.50 ZIP file without extracting? In Safari, control-click and select Download Linked File. Then in terminal, run "shasum Teensyduino_MacOS_Catalina.zip". If the ZIP file is intact, it should print this:


091ebac53174a5929d09a877bcc1ba4f83fba38e Teensyduino_MacOS_Catalina.zip

mjs513
02-01-2020, 11:13 AM
Just downloaded and installed 1.50 and IDE 1.8.11 with no problems on a Win10x64 PC. Ran a test sketch using ST7735 library that I was working on ran with no issues.

Just a couple of observations with the latest release:
1. Not seeing multiple libraries but think that was corrected already can't remember anymore since I learned to ignore that message.
2. Teensy 4 now identified: Using board 'teensy40' along with "-DARDUINO_TEENSY40".
3. Compiles a lot faster on recompiles - did not it is now saying its using precompiled binaries.

KurtE
02-01-2020, 12:34 PM
Installed on Windows 10 and on MAC Catalina with latest updates and it appears to run on both. Did not try to program Teensy yet on MAC, but the compiled Blink for T4 and it went all the way to Teensy app...

On Windows, programmed T4 with sketch for RA8875... So far so good. As mentioned, not getting all of those duplicated messages with 1.8.11, but that was release note. I have not verified if I still get them when they are valid.

PaulStoffregen
02-01-2020, 12:43 PM
Thanks for testing.

Yup, Arduino fixed the bugs. I'm going to drop support for Arduino 1.8.10 in the next Teensyduino release.

neurofun
02-01-2020, 01:28 PM
MacBookPro8,2 OS X 10.13.6 (16G29)
iMac12,2 OS X 10.13.6 (17G10021)

Arduino 1.8.11 & TD1.50 is running fine on both systems.

I spoke too soon. After shutting down both macs and have a good night sleep, today arduino crashes on startup on both systems.

Process: Arduino [917]
Path: /Applications/Arduino.app/Contents/MacOS/Arduino
Identifier: cc.arduino.Arduino
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Arduino [917]
User ID: 502

Date/Time: 2020-02-01 15:14:03.529 +0100
OS Version: Mac OS X 10.13.6 (17G10021)
Report Version: 12
Anonymous UUID: 37A0F961-1C41-3A43-6AF6-9378166121D0


Time Awake Since Boot: 550 seconds

System Integrity Protection: enabled

Crashed Thread: 0

Exception Type: EXC_CRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace CODESIGNING, Code 0x1

kernel messages:

VM Regions Near 0 (cr2):
-->
__TEXT 000000010e9cd000-000000010e9d2000 [ 20K] r-x/r-x SM=COW } []

Thread 0 Crashed:
0 ??? 0x0000000113eb819c _dyld_start + 0

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x00007ffee1232c30
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x0000000113eb819c rfl: 0x0000000000000200 cr2: 0x0000000000000000

Logical CPU: 0
Error Code: 0x00000000
Trap Number: 0


Binary Images:
0x10e9cd000 - 0x10e9d1fff +??? (???) <2AE2040B-3408-3208-B101-5825B8F425F0> (null)
0x113eb7000 - 0x113f01adf +??? (551.5) <ACC6AC7F-EAD9-340E-B2A8-AD26FE5B387B> (null)

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 37212
thread_create: 0
thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=452K resident=0K(0%) swapped_out_or_unallocated=452K(100%)
Writable regions: Total=8404K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8404K(100%)

VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
STACK GUARD 56.0M 2
Stack 8192K 2
__DATA 228K 4
__LINKEDIT 132K 3
__TEXT 320K 3
shared memory 8K 3
=========== ======= =======
TOTAL 64.7M 11

Model: iMac12,2, BootROM IM121.004D.B00, 4 processors, Intel Core i5, 3,1 GHz, 24 GB, SMC 1.72f5
Graphics: AMD Radeon HD 6970M, AMD Radeon HD 6970M, PCIe
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020
Memory Module: BANK 0/DIMM1, 8 GB, DDR3, 1333 MHz, 0x0198, 0x393955353432382D3031382E4130304C4620
Memory Module: BANK 1/DIMM1, 8 GB, DDR3, 1333 MHz, 0x0198, 0x393955353432382D3031382E4130304C4620
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x9A), Atheros 9380: 4.0.74.0-P2P
Bluetooth: Version 6.0.7f16, 3 services, 18 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: WDC WD30EFRX-68EUZN0, 3 TB
Serial ATA Device: Samsung SSD 860 EVO 1TB, 1 TB
Serial ATA Device: OPTIARC DVD RW AD-5690H
USB Device: USB 2.0 Bus
USB Device: FaceTime HD Camera (Built-in)
USB Device: Hub
USB Device: Keyboard Hub
USB Device: USB-PS/2 Optical Mouse
USB Device: Apple Keyboard
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: IR Receiver
USB Device: Internal Memory Card Reader
Thunderbolt Bus: iMac, Apple Inc., 25.1

neurofun
02-01-2020, 01:47 PM
I spoke too soon. After shutting down both macs and have a good night sleep, today arduino crashes on startup on both systems.

Same behaviour with 1.50-beta1.

KurtE
02-01-2020, 02:19 PM
@nerufun - For what it is worth, I am running macOS Catalina 10.15.3 on Macbook Pro (Retina, 15 inch, early 2013), I shutdown the MAC and restarted and still runs.

I am guessing you are running with the older MAC Installer version as it looks like you are running 10.13... ?

PaulStoffregen
02-01-2020, 03:10 PM
Maybe these Mac crashes are from the Java JRE?

Can you try running 1.49? Does it work on your Mac?

Does a plain 1.8.11 from Arduino's website run or crash on your Mac?

duff
02-01-2020, 05:10 PM
So I did finally got Teensyduino 1.5.0 to install correctly. For some reason my machine which is old (2012) and running Mac 10.13.4 Quarantines the Arduino ide when I download it. I checked with this command:


duff$ xattr /Users/duff/Downloads/Arduino.app
com.apple.quarantine

Now I can open and run Arduino ide fine before installing Teensyduino even though it is Quarantined. So to get Teensyduino to install and not have the Arduino crash I ran this command before installing:


duff$ sudo xattr -r -d com.apple.quarantine /Users/duff/Downloads/Arduino.app

I not sure if this matters but when I downloaded and ran the Ardiono Pro Ide it really screwed with the Java version of Arduino. I would get errors that the board files where corrupted and had to be reinstalled and other things I can't remember now.

I downloaded the Catilna Teensyduino and ran and got what looks like the right hash sum?:


duff$ shasum Teensyduino_MacOS_Catalina.zip
091ebac53174a5929d09a877bcc1ba4f83fba38e Teensyduino_MacOS_Catalina.zip

neurofun
02-01-2020, 05:45 PM
Maybe these Mac crashes are from the Java JRE?

Can you try running 1.49? Does it work on your Mac?
1.49 runs fine with arduino 1.8.10 as does 1.50.
But cannot install 1.49 on arduino 1.8.11 which I think is normal since arduino 1.8.11 is only supported by td1.50.


Does a plain 1.8.11 from Arduino's website run or crash on your Mac?
Plain 1.8.11 does not crash. After a reboot of the mac it still works fine.

After installing TD1.50 it still doesn't crash. I can compile & upload.
After quitting and restarting arduino, no crash and I can still compile & upload.
After logout & login from finder, no crash and I can still compile & upload.
After rebooting the mac, adruino crashes immediately upon start.

iMac 2011 osx10.13.6

PaulStoffregen
02-01-2020, 06:45 PM
iMac 2011 osx10.13.6

Can you run the Catalina 10.15 version on 10.13.6? Does it crash also?

Maybe it's time to just completely retire the installer from MacOS?

duff
02-01-2020, 07:24 PM
Can you run the Catalina 10.15 version on 10.13.6? Does it crash also?

Maybe it's time to just completely retire the installer from MacOS?

Yes it does work on my 10.13.4 Mac with no crashes that I saw.

khoih-prog
02-01-2020, 07:36 PM
Just installed TD 1.50 and tested with T4 on Ubuntu 18.04.1 LTS x64 with Arduino IDE 1.8.11. No problem so far with compiling, uploading and running T4 with
1. ESP8266 shield
2. Ethernet shield
3. HardwareSerial <-> USB (/dev/ttyACM0) <-> socat
to provide communications and connect to Blynk / Internet.

PaulStoffregen
02-01-2020, 07:40 PM
I tested the Catalina version (https://www.pjrc.com/teensy/td_150/Teensyduino_MacOS_Catalina.zip) on 10.12.6. Works fine.

Sadly, I don't have any macs older than 10.12 (Sierra) but newer than 10.7 (Lion) testing, so I don't know how far back it works. It definitely does not work on 10.7. If anyone reading this has an old Mac running 10.8 to 10.11, please please please run the Catalina build and let me know if it works or fails on those older MacOS systems.

I'm going to update the webpage now to at least say "10.12 to 10.15" for the new all-in-one copy.

neurofun
02-01-2020, 07:42 PM
Can you run the Catalina 10.15 version on 10.13.6? Does it crash also?

Maybe it's time to just completely retire the installer from MacOS?
The Catalina 10.15 version runs without crashing, also after a system reboot.
I can compile but not upload.

Opening Teensy Loader...
Unable find Teensy Loader. (p) Is the Teensy Loader application running?

neurofun
02-01-2020, 08:03 PM
Previous post was referring to iMac12,2 OS X 10.13.6 (17G10021)

different system, different result:
MacBookPro8,2 OS X 10.13.6 (16G29)
The Catalina 10.15 version runs without crashing, also after a system reboot.
I can compile & upload.

PaulStoffregen
02-01-2020, 08:05 PM
Unable find Teensy Loader. (p) Is the Teensy Loader application running?

Does the small Teensy Loader window appear?

In other words, trying to understand whether the problem is that is can't run Teensy Loader at all, or if you are getting the Teensy Loader window on your desktop, but then Arduino can't communicate with it.

If the Teensy Loader window does appear, does its bottom status bar change filenames as you compile different programs in Arduino?

neurofun
02-01-2020, 08:35 PM
Does the small Teensy Loader window appear?

No, the Teensy Loader window does not appear.
There is no process "Teensy" visible in the Activity Monitor.

PaulStoffregen
02-01-2020, 08:38 PM
No, the Teensy Loader window does not appear.

Could run Applications > Utilities > Console, then click Verify in Arduino? Do any errors get logged in the console application?

neurofun
02-01-2020, 08:48 PM
Could run Applications > Utilities > Console, then click Verify in Arduino? Do any errors get logged in the console application?
No errors in the console.

neurofun
02-02-2020, 12:24 AM
iMac12,2 OS X 10.13.6 (17G10021)

Catalina 10.15 version -> show package content -> double click Teensy.app
result:
18927

PaulStoffregen
02-02-2020, 01:05 AM
I have no idea why your Mac is saying Teensy Loader requires 10.14. It doesn't (or shouldn't).

I ran it this way just now on 10.12.6. Here's a screenshot.

18928

At least 2 people on Twitter have confirmed it ran on their old Macs with 10.10 Yosemite. One specifically said uploading code to a Teensy 3.2 worked.

https://twitter.com/bikerglen/status/1223766258723639296

https://twitter.com/Dithermaster/status/1223777431099793408

neurofun
02-02-2020, 02:28 AM
I have no idea why your Mac is saying Teensy Loader requires 10.14. It doesn't (or shouldn't).
I have no idea either.
But I fixed the problem by copying Teensy.app 1.50 installed in Arduino 1.8.10 to Teensyduino Catalina 10.15 version.

PaulStoffregen
02-02-2020, 02:44 AM
But I fixed the problem by copying Teensy.app 1.50 installed in Arduino 1.8.10 to Teensyduino Catalina 10.15 version.

Now that's *really* confusing. They've built from same code base using the same Mac (running 10.14 Mojave).

neurofun
02-02-2020, 03:42 AM
Now that's *really* confusing. They've built from same code base using the same Mac (running 10.14 Mojave).

Do not want to add to the confusion but did a get info on both files and there are some differences.
file size
creation date
enable app nap option

18930

I consider for myself this problem fixed but if you want to get to the bottom of this I will gladly help troubleshooting.
Sadly my HighSierra installer is corrupted and cannot test on a clean OS install.

Frank B
02-02-2020, 10:59 AM
Because I was bored, because I put my debugger idea ad-acta and I had to wait for something else, I played with the compiler again - this time
GCC9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]


GCC 5.4.1:
Coremark with -O2: 2313.57
Coremark with -O2 -fgcse-after-reload -finline-functions : 2344.67
Coremark with -O3: 2476.88

GCC 9.2.1:
Coremark with -O2: 2433.48
Coremark with -O2 -fgcse-after-reload -finline-functions : 2474.23
Coremark with -O3: 2399.04

-O2 is faster, and -fgcse-after-reload -finline-functions gives a little more speed.
Performance-wise GCC 9.2.1 still does not make much sense (if you choose the right flags - which depend on the version), and there is a regression with -O3.
Otherwise I couldn't find problems with 9.2.1 and it may have some bugs fixed.

luni
02-02-2020, 11:45 AM
I can confirm the compatibility with the core libs. I'm using GCC 9 as default for a couple of weeks now. Didn't notice any issues so far.

Advantages I found:

It is more strict (standard conform) on pointer conversions (it actually found some 'bugs' in my code which GCC 5.4 didn't complain about)
It also has a working objDump for the M7. The list files generated by GCC 5.4 are often not readable.
Compiler output (errors/warnings) is more nicely formatted

PDOS
02-02-2020, 12:20 PM
I am pleased to say that Teensyduino 1.50 and Arduino 1.8.11 with Teensy 4.0 work nicely on my Ubuntu 19.10. Software reboot works too.

duff
02-05-2020, 12:57 AM
So it looks like I have the same problem that @neurofun has with the Catalina version. When I try to open the Teensy.app it says it needs 10.14:
18956
18955
Got it to work when I copied the 1.50 Teensy.app from another Arduino install I did. I'll try to download the Catalina version again now.

edit: Teensy.app is still is X out:(

towe
02-05-2020, 12:03 PM
Admin-less installation on Windows 10 64-bit over Arduino IDE 1.8.11 worked fine.

The bug with the supposedly required admin rights - probably for installing USB drivers on obsolete Windows versions - is still there though.

glasspusher
02-08-2020, 03:52 PM
Chiming in here, first time in a while. Teensyduino 1.50 on a macbook pro running 10.15.3 working fine so far.

Frank B
02-09-2020, 03:49 PM
https://www.pjrc.com/teensy/td_libs_LedControl.html which is part of teensyduino uses shiftout(), which is too fast on T4.

I want to fix it - what is better ?

a) add own slow _shiftOut for T4 to the library
b) rewrite it to use SPI - which limits the usable pins
c) patch Teensyduino and insert the delay to the Core-shiftOut()?

What do you want?



void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
uint8_t mask;
const int dly = 10;
for (mask=0x80; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
delayNanoseconds(dly);
digitalWrite(clockPin, HIGH);
delayNanoseconds(dly);
digitalWrite(clockPin, LOW);
delayNanoseconds(dly);
}
}


Edit: I would vote vor c) to keep Arduino-compatibility.
In LedControl, it happens for >= 396MHz - my display uses a MAX7219.
Might be that other chips are even slower..

defragster
02-09-2020, 05:02 PM
@Frank - what about alternate F_CPU_ACTUAL timings? Does the same delay work at 24 and 800 MHz?

Frank B
02-09-2020, 05:06 PM
well, the time is independent from f_cpu, so, the f_cpu should'nt matter (but I have tested up to 960MHz ;-) . (..and I hope the laws of nature have taken T4 into account)

defragster
02-09-2020, 05:10 PM
well, the time is independent from f_cpu, so, even the speed should'nt matter (but I have tested up to 960MHz ;-) . (..and I hope the laws of nature have taken T4 into account)

Indeed the time is fixed - but the bus timing changes for the write speed?

Frank B
02-09-2020, 05:15 PM
The only issue I see that it is a little slower - but that's the intention.
For my max7219 it works without the delays if f_cpu is < 396MHz. So of course one could add a bunch of #ifdefs - would that be better?
I don't think so. I'd think we have to increase the delays someday and we will find chips (ATMEL? with "shiftIn()" ) where my added delay is too small.

the bus-mhz does not matter that much here..

defragster
02-09-2020, 05:36 PM
With T4 having runtime changeable F_CPU an #ifdef would not be perfect - adding a runtime conditional would be time consuming too.

Thought a test of that code at 24 and 800 MHz would quickly show if the delay ended up being too much or too little since the problem comes from the speed of the T4. Assuming a T_3.6 at 256 MHZ doesn't have this trouble?

Frank B
02-09-2020, 05:42 PM
The delay is (almost) the same for 24 and 800Mhz (it will be a bit more with 24MHz due to the nature of the waiting loop).. But I understand your point - digitalWrite is slower with 24MHz. Edit: Adding an if-statement would slow it down even more, maybe
Is that an issue? It would be an issue if it was slower than 8-Bit Arduino. I don't think, it is.. anyway, I have no hardware to compare both.

I've not tried 3.6 - can do that in the next days (don't want to rip my hw now)

defragster
02-09-2020, 05:45 PM
The delay is (almost) the same for 24 and 800Mhz (it will be a bit more with 24MHz due to the nature of the waiting loop).. But I understand your point - digitalWrite is slower with 24MHz.
Is that an issue? It would be an issue if it was slower than 8-Bit Arduino. I don't think, it is.. anyway, I have no hardware to compare both.

Opps - I thought you had hardware in front of you testing it to see it run to observe and select the delay time in action.

Frank B
02-09-2020, 06:04 PM
Opps - I thought you had hardware in front of you testing it to see it run to observe and select the delay time in action.

No i have no ATMEL-Arduino. I should buy some, some day..
Shiftout is just too fast for the display ( "too fast" is definitely NOT compatible with ATMEL-Arduino.. ) - it does not work.

Just try it - the display are sold for 1.- EUR at ebay.
Edit: Datasheet says, it is good for 10MHz. I doubt Atmel-Arduino can reach that.taken the usual overclocking-possibility into account it's much more.

We could make it like this, perhaps:


if f_cpu_actual > XY //<-dunno...
for (mask=0x80; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, HIGH);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, LOW);
delayNanoseconds(shiftOutDly );
}
else
same without delays..

Frank B
02-09-2020, 06:32 PM
@defragster:
What do you think?


static const int shiftOutDly = 10;
static const int maxSpeedBeforeDelay = 300e6;

void shiftOut_lsbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
uint8_t mask;
if (F_CPU_ACTUAL > maxSpeedBeforeDelay)
for (mask = 0x01; mask; mask <<= 1) {
digitalWrite(dataPin, value & mask);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, HIGH);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, LOW);
delayNanoseconds(shiftOutDly );
}
else
for (mask = 0x01; mask; mask <<= 1) {
digitalWrite(dataPin, value & mask);
digitalWrite(clockPin, HIGH);
digitalWrite(clockPin, LOW);
}
}

void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
uint8_t mask;
if (F_CPU_ACTUAL > maxSpeedBeforeDelay)
for (mask = 0x80; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, HIGH);
delayNanoseconds(shiftOutDly );
digitalWrite(clockPin, LOW);
delayNanoseconds(shiftOutDly );
}
else
for (mask = 0x01; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
digitalWrite(clockPin, HIGH);
digitalWrite(clockPin, LOW);
}
}

Frank B
02-09-2020, 07:42 PM
Assuming a T_3.6 at 256 MHZ doesn't have this trouble?
Tested this - works wonderful.

defragster
02-09-2020, 08:00 PM
Both F_CPU_ACTUAL and delayNanoseconds are new for T_4 and only #ifdef __1062__

But that seems reasonable to test with. Though not sure how close delayNanoseconds(10) is to accurate for that low value?

I wrote a test delayCycles() on T4 and min execution wasn't good until about 20 cycles - and then it went in groups of 4 cycles. That seems to agree with 10 and 3 ns request below?

Check my math/code but I get:

100 ns cycles == 71
100 ns time == 118.333333

and ::


10 ns cycles == 18
10 ns time == 30.000000

and:

3 ns cycles == 19
3 ns time == 31.666667

with::


uint32_t yy = ARM_DWT_CYCCNT;
#define iWait 10
delayNanoseconds(iWait);
yy = ARM_DWT_CYCCNT-yy;
Serial.print(iWait);
Serial.print(" ns cycles == ");
Serial.println(yy);
double xx=yy*1000000 ;
xx = xx/(double)F_CPU_ACTUAL;
Serial.print(iWait);
Serial.print(" ns time == ");
Serial.printf("%f\n",xx*1000);

Frank B
02-09-2020, 08:02 PM
Both F_CPU_ACTUAL and delayNanoseconds are new for T_4 and only #ifdef __1062__
Sure - it's in the T4 core...


But that seems reasonable to test with. Though not sure how close delayNanoseconds(10) is to accurate for that low value?

Don't know, is not important and does not matter - 10 is the lowest value that works. It's not the goal to get a reproducable timing. (SPI would be better, then) It should just shift out the data. But not too fast.
As said - we may have to increase this value even more. Depends on the receiving chips.

defragster
02-09-2020, 08:08 PM
Good it works! I thought you had hardware to test on Teensy, I wasn't worried about ATMEL.

Wasn't sure if this was for generic lib change or for your purposes when #ifdef would be needed.

Frank B
02-09-2020, 08:09 PM
I have hardware to test on teensy. But I have no Atmel*.
shiftOut is in the core and is part of arduino-compatibility! (digital.c)


*By the way, I really do not care if it works on the Atmel or other Arduinos. But it should'nt be slower than Atmel - thank you for pointing out 24MHz...!

Frank B
02-10-2020, 08:07 AM
I will connect the scope this evening.
The speed on atmega or such can't be much higher than 4MHz I think.
Maybe we should limit it to 10MHz?
Or less??

The mentioned library does not work now on T4 so we need a solution.

Frank B
02-10-2020, 08:34 PM
Ok.. managed to kill the display.. lol, no idea, how :)
I will stop bothering you and put this on pause until i have a replacement for the display.

KurtE
02-10-2020, 09:30 PM
Hi @Frank, sorry to hear about your display...


FyI I ran the LCDemo7Segement on A T2... (Don't have many of these) This one was part of my XV Lidar Controller V1.2 of GetSurreal.com...

The only thing I did was to connect it up to Logic Analyzer...

You can see the pulse widths/spacing hopefully in this one:
19017

This is part of an output of 4 16 bit outputs... There is a gap of about 22us between the words...

And this repeats maybe every .25 seconds...

Frank B
02-10-2020, 09:54 PM
I'm using a 8 digit 7-segment display.
it worked with this replacement for shiftout up to 960Mhz:


static const int maxSpeed = 10000000ULL; //10 MHz
static const int maxSpeedBeforeDelay = 392000000ULL; //max F_CPU_ACTUAL before doing delays (measured for 10MHz, -O2)

void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
uint32_t mask;

if (F_CPU_ACTUAL > maxSpeedBeforeDelay) {
uint32_t cycles = (F_CPU_ACTUAL / 3 / maxSpeed);
uint32_t t = ARM_DWT_CYCCNT;

for (mask = 0x80; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
do {;} while(ARM_DWT_CYCCNT - t < cycles);
t += cycles;

digitalWrite(clockPin, HIGH);
do {;} while(ARM_DWT_CYCCNT - t < cycles);
t += cycles;

digitalWrite(clockPin, LOW);
do {;} while(ARM_DWT_CYCCNT - t < cycles);
t += cycles;
}
}
else
for (mask = 0x80; mask; mask >>= 1) {
digitalWrite(dataPin, value & mask);
digitalWrite(clockPin, HIGH);
digitalWrite(clockPin, LOW);
}
}

The numbers can be optimized somewhat, maybe.
Goal is to reach the maxSpeed as close as possible (but not higher) for every f_cpu_actual.
Note, it is a 1/3 - 2/3 cycle (25%/75%) - not sure how to come 50/50 closer. But it was OK for the MAX7219.

Edit: It takes the data at the rising edge of clk - but i noticed, the data-bit needs to be set some time before. (Datasheet says 25ns)
But we should'nt optimize for THAT chip... on the other hand, the MAX should work...

feel free to play with it :)

good night.

Edit: For better code see pullrequest in the next post.

Frank B
02-12-2020, 06:30 PM
Got the new displays.

so, finally:
https://github.com/PaulStoffregen/cores/pull/433/files

Its now nearly 50% clock ratio.
Runs fine for every F_CPU_ACTUAL.

LachAus
02-13-2020, 02:46 AM
For what it's worth, https://www.pjrc.com/teensy/td_download.html is displaying some older 1.49 information:

Teensyduino 1.49 supports Arduino versions 1.8.5 and 1.8.7 and 1.8.8 and 1.8.9 and 1.8.10 and 1.8.11.
Future versions of Teensyduino will drop support for Arduino 1.8.7 and 1.8.8 and 1.8.10

Bryan42
02-16-2020, 07:43 PM
Just tried using V 1.50 of Teensyduino with Arduino 1.8.11 on an old Raspberry Pi Model 3B (not plus), which I use from time for time for testing my Teensy project on. (I compile and develop mostly on Windows). Anyway, I haven't used any Raspberry Pi's in a while and especially not this old box, but what a failure!

First, it seems Arduino.1.8.11 and a fresh copy of the latest Raspbian Buster OS (I think released a few days ago) do not get along at all. The IDE is super slow, basically unusable. Then after installing the Teensyduino 1.50 to the machine and launching the IDE with a previously compiled Teensy program running on a Teensy 3.2, that dumps sensor data (several numbers per line) to the serial monitor repeatedly in a 100 uSec loop (or as fast as the serial I/O can keep up). This type of thing runs fine in Windows 10, but on this old Raspberry Pi 3B, it filled a page or two of the Serial Monitor and then locked up, forcing a reboot. Same thing when dumping said data to the Serial Plotter.

So I erased the SD card on the Pi and installed fresh copy of the latest Raspbian Buster OS and tried Arduino.1.8.10 with Teensyduino.1.50. Now my Teensy program can dump lots of data to the Serial Monitor/Plotter just fine. So clearly there are serious issues with Teensy 1.50/Arduino 1.8.11 on a Raspberry Pi 3B.

I haven't tried this on newer Raspberry Pi boxes (3B+ and 4) nor with the Teensy Beta 1.51/Arduino.1.8.12. Is Arduino 1.8.11 well-known to being problematic on Raspberry Pi's and is everyone moving quickly away from it?

PaulStoffregen
02-16-2020, 08:01 PM
Is Arduino 1.8.11 well-known to being problematic on Raspberry Pi's and is everyone moving quickly away from it?

Yes, seems so. Arduino 1.8.11 uses AdoptOpenJDK Java, which causes trouble on some systems.

Arduino 1.8.12 was recently released, reverting back to Oracle Java. Please give 1.8.12 a try, using Teensyduino 1.51-beta1.

https://forum.pjrc.com/threads/59566-Teensyduino-1-51-Beta-1

Bryan42
02-16-2020, 08:56 PM
Yes, seems so. Arduino 1.8.11 uses AdoptOpenJDK Java, which causes trouble on some systems.

Arduino 1.8.12 was recently released, reverting back to Oracle Java. Please give 1.8.12 a try, using Teensyduino 1.51-beta1.

https://forum.pjrc.com/threads/59566-Teensyduino-1-51-Beta-1

Will do. Thanks for the fast response.

Bryan42
02-16-2020, 09:59 PM
Have confirmed with a quick test that the Arduino 1.8.12 and Teensyduino 1.51beta combination works fine for my Teensy 3.2 application on a Raspberry Pi 3B.