Teensy 4.0 & 4.1
Re: Teensy 4.0 & 4.1
Yes. That's still strange. What I will do is writing a little test script that dumps the values of all internal clocks. Maybe that gives a hint about what is changing. The speed change between -182 and -183 is repeatable forth and back with today's builds.
Re: Teensy 4.0 & 4.1
Did several more builds from 1.15-177 up to 1.16-13. All give about 2620 pystones/second and all hex files are 728.9 KB. Also 1.15-182 and -183 were not exception: identical result.
I'm beginning to doubt if I followed the proper procedure. Before a new build I (only) issue a "git reset <7-digit-code>" and then start the build (preceded by make clean).
BTW: Where can I find the figure for code size?
I'm beginning to doubt if I followed the proper procedure. Before a new build I (only) issue a "git reset <7-digit-code>" and then start the build (preceded by make clean).
BTW: Where can I find the figure for code size?
Re: Teensy 4.0 & 4.1
Generally i do the same:
git checkout <hash-value>
make clean
make BOARD=TEENSY40 -j5 deploy
The code size is reported at the end of the build. It is a table like this:
I made several attempts to find a reason, but no luck. The clock settings are always identical, and the memory settings as well. It looks like a random choice, as if it depends on some data randomly set in RAM.
The hash code for build 182 is a40e1473d, the one for 183 is bbdc98f72
git checkout <hash-value>
make clean
make BOARD=TEENSY40 -j5 deploy
The code size is reported at the end of the build. It is a table like this:
Code: Select all
Memory region Used Size Region Size %age Used
m_flash_config: 512 B 4 KB 12.50%
m_ivt: 48 B 4 KB 1.17%
m_interrupts: 1 KB 1 KB 100.00%
m_text: 193084 B 1027 KB 18.36%
m_vfs: 0 GB 1008 KB 0.00%
m_reserved: 0 GB 4 KB 0.00%
m_itcm: 1964 B 128 KB 1.50%
m_dtcm: 42160 B 128 KB 32.17%
m_ocrm: 0 GB 768 KB 0.00%
text data bss dec hex filename
196632 256 40112 237000 39dc8 build-TEENSY40/firmware.elf
The hash code for build 182 is a40e1473d, the one for 183 is bbdc98f72
Re: Teensy 4.0 & 4.1
I am almost sure that the differences we see are related to the Python dynamic memory management. I ran another test which was provided a while ago by @pythoncoder, which just does arithmetic and a little bit of looping. There, the numbers are consistent over all versions. That matches my observation when using the port, that there is no noticeable difference over the various versions. Peter's test script:
Note: For versions before 1..15-183 you have to comment the decorator. Support for that came with 1.15-183.
And some results:
Some earlier results with ESP32 and PybD-SF6
:
Code: Select all
import time
import machine
def pi(places=100):
# 3 + 3*(1/24) + 3*(1/24)*(9/80) + 3*(1/24)*(9/80)*(25/168)
# The numerators 1, 9, 25, ... are given by (2x + 1) ^ 2
# The denominators 24, 80, 168 are given by (16x^2 -24x + 8)
extra = 8
one = 10 ** (places+extra)
t, c, n, na, d, da = 3*one, 3*one, 1, 0, 0, 24
while t > 1:
n, na, d, da = n+na, na+8, d+da, da+32
t = t * n // d
c += t
return c // (10 ** extra)
def pi_test(n=5000):
t1=time.ticks_ms()
t=pi(n)
t2=time.ticks_ms()
print('Pi test: ', time.ticks_diff(t2,t1)/1000, 's')
def pass_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
pass
t2=time.ticks_ms()
print('Pass test: ', time.ticks_diff(t2,t1)/1000, 's')
@micropython.native
def passn_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
pass
t2=time.ticks_ms()
print('Pass test native: ', time.ticks_diff(t2,t1)/1000, 's')
def add_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
sum = a + b
t2=time.ticks_ms()
print('Add test: ', time.ticks_diff(t2,t1)/1000, 's')
@micropython.native
def addn_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
sum = a + b
t2=time.ticks_ms()
print('Add test native: ', time.ticks_diff(t2,t1)/1000, 's')
def mul_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
sum = a * b
t2=time.ticks_ms()
print('Mul test: ', time.ticks_diff(t2,t1)/1000, 's')
def div_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
sum = a / b
t2=time.ticks_ms()
print('Div test: ', time.ticks_diff(t2,t1)/1000, 's')
def idiv_test(n=1000000, a = 1234, b = 5678):
t1=time.ticks_ms()
sum = 0
for i in range(n):
sum = b // a
t2=time.ticks_ms()
print('iDiv test: ', time.ticks_diff(t2,t1)/1000, 's')
print('Speed test')
try:
print('System freq: {:.1f} MHz'.format(machine.freq()[0]/1000000))
except:
print('System freq: {:.1f} MHz'.format(machine.freq()/1000000))
pass_test()
passn_test()
add_test()
add_test(1000000, 1234.1, 5678.1)
addn_test()
addn_test(1000000, 1234.1, 5678.1)
mul_test()
mul_test(1000000, 1234.1, 5678.1)
div_test()
div_test(1000000, 5678.1, 1234.1)
idiv_test()
pi_test()
And some results:
Code: Select all
MicroPython v1.16-19-g8b1d75b8d on 2021-06-23
System freq: 600.0 MHz
Pass test: 0.443 s
Pass test native: 0.215 s
Add test: 0.641 s
Add test: 1.367 s
Add test native: 0.277 s
Add test native: 1.219 s
Mul test: 0.693 s
Mul test: 1.377 s
Div test: 1.369 s
Div test: 1.443 s
iDiv test: 0.677 s
Pi test: 2.211 s
MicroPython v1.15-182-ga40e1473d on 2021-06-23
System freq: 0.0 MHz
Pass test: 0.447 s
Add test: 0.64 s
Add test: 1.363 s
Mul test: 0.697 s
Mul test: 1.373 s
Div test: 1.189 s
Div test: 1.439 s
iDiv test: 0.675 s
Pi test: 2.017 s
MicroPython v1.15-183-gbbdc98f72 on 2021-06-23
System freq: 600.0 MHz
Pass test: 0.447 s
Pass test native: 0.221 s
Add test: 0.64 s
Add test: 1.366 s
Add test native: 0.286 s
Add test native: 0.907 s
Mul test: 0.697 s
Mul test: 1.384 s
Div test: 1.201 s
Div test: 1.447 s
iDiv test: 0.675 s
Pi test: 2.124 s
Code: Select all
Runtest, ESP32 with spiram
Speed test
System freq: 240.0 MHz
Add test: 3.514 s
Mul test: 3.703 s
Div test: 7.758 s
Pi test: 16.149 s
Runtest, ESP32 without spiram, firmware with spiram support
Speed test
System freq: 240.0 MHz
Add test: 3.225 s
Mul test: 3.418 s
Div test: 4.599 s
Pi test: 11.29 s
Runtest, ESP32 without spiram, firmware without spiram support
Speed test
System freq: 240.0 MHz
Add test: 3.064 s
Mul test: 3.255 s
Div test: 4.368 s
Pi test: 9.005 s
MicroPython v1.9.4-793-gaba83e66-dirty on 2019-02-05; ESP32 module with ESP32
Runtest, ESP32 without spiram, firmware without spiram support
Speed test
System freq: 240.0 MHz
Add test: 2.625 s
Mul test: 2.809 s
Div test: 15.874 s
Pi test: 8.354 s
PyBoard D SF6.
MicroPython v1.16-13-gc99e4995f on 2021-06-23
Speed test
System freq: 192.0 MHz
Pass test: 1.089 s
Pass test native: 0.6680000000000001 s
Add test: 1.704 s
Add test: 4.248 s
Add test native: 0.893 s
Add test native: 2.933 s
Mul test: 1.881 s
Mul test: 4.258 s
Div test: 3.562 s
Div test: 4.46 s
iDiv test: 1.818 s
Pi test: 7.073 s
Re: Teensy 4.0 & 4.1
I've run Peter's script and see generally comparable figures with yours, but also some significant(?) differences.
Below 2 runs, the second with a one of my 'fast' firmware versions (4200 pystones)
Below 2 runs, the second with a one of my 'fast' firmware versions (4200 pystones)
- Pi test is always around 3.5 with me, even with the fast firmware
- Add test native is mostly 0.9, but I saw also 1.7 and 3.5 (with the same firmware).
Code: Select all
MicroPython v1.16-13-gc99e4995f-dirty on 2021-06-24; Teensy 4.0 with MIMXRT1062DVJ6A
Speed test
System freq: 600.0 MHz
Pass test: 0.44 s
Pass test native: 0.34 s
Add test: 0.636 s
Add test: 1.386 s
Add test native: 0.276 s
Add test native: 3.508 s
Mul test: 0.694 s
Mul test: 1.409 s
Div test: 1.966 s
Div test: 1.454 s
iDiv test: 0.673 s
Pi test: 3.699 s
MicroPython v1.15-216-g95048129b on 2021-06-18; Teensy 4.0 with MIMXRT1062DVJ6A
Speed test
System freq: 600.0 MHz
Pass test: 0.443 s
Pass test native: 0.215 s
Add test: 0.637 s
Add test: 1.797 s
Add test native: 0.277 s
Add test native: 0.902 s
Mul test: 0.694 s
Mul test: 1.81 s
Div test: 1.699 s
Div test: 1.504 s
iDiv test: 1.075 s
Pi test: 3.431 s
Re: Teensy 4.0 & 4.1
The ST7789 TFT display works fine and much faster with the new hardware SPI!
I'm looking forward to support VfsFat to be able to drive an SD card!
I'm looking forward to support VfsFat to be able to drive an SD card!
Re: Teensy 4.0 & 4.1
SDCard support is still under construction. You can use it with SoftSPI and the Python driver. But for that, FAT support has to be included.
Re: Teensy 4.0 & 4.1
Here is a firmware package that includes the FAT support. You can use that with SPI to connect a SD card. It also support a regular SD card at the SD card pins on the bottom side. But that is still under development.
https://hidrive.ionos.com/lnk/P4CAiRPM Teensy 4.0
https://hidrive.ionos.com/lnk/n4CgCMDd Teensy 4.1
https://hidrive.ionos.com/lnk/P4CAiRPM Teensy 4.0
https://hidrive.ionos.com/lnk/n4CgCMDd Teensy 4.1
Re: Teensy 4.0 & 4.1
I noticed the addition of hardware I2C, great!
I did some elementary tests with a board which uses 2 I2C interfaces (with a.o. tcs34725 and tsl2591). All works fine!
However I noticed an issue with I2C.init(). A change of freq (what else could be changed with hardware-I2C?) shows:
Similarly with PyBoard:
In both cases dir(machine.I2C) shows the presence of 'init'. So what is the reason for this?
With SoftI2C (with the Teensy 4.0) another issue with init():
I did some elementary tests with a board which uses 2 I2C interfaces (with a.o. tcs34725 and tsl2591). All works fine!
However I noticed an issue with I2C.init(). A change of freq (what else could be changed with hardware-I2C?) shows:
Code: Select all
MicroPython v1.16-92-g98c570302-dirty on 2021-07-15; Teensy 4.0 with MIMXRT1062DVJ6A
Type "help()" for more information.
>>> from machine import I2C
>>> bus = I2C(0)
>>> bus.init(freq=100000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: I2C operation not supported
Code: Select all
MicroPython v1.16-92-g98c570302-dirty on 2021-07-15; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> from machine import I2C
>>> bus=I2C(1)
>>> bus.init(100000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: I2C operation not supported
With SoftI2C (with the Teensy 4.0) another issue with init():
Code: Select all
MicroPython v1.16-92-g98c570302-dirty on 2021-07-15; Teensy 4.0 with MIMXRT1062DVJ6A
Type "help()" for more information.
>>> from machine import SoftI2C, Pin
>>> bus=SoftI2C(scl=Pin("A2"), sda=Pin("A3"))
>>> bus.init(freq=100000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'scl' argument required
{/code]
Why is 'scl' (and probably 'sda') a required argument?
Re: Teensy 4.0 & 4.1
Both Hardware and Software I2c share the same dictionary. The hardware i2c has no init() method, that's why you get that message. You can simply instantiate the I2c again for a frequency change. That is not an expensive operation. I was thinking of implementing a separate init() method, but followed the example of other ports not to do that.
The softI2C code is not touched with the new hardware I2C. So whatever you notice now, must have been there before. Looking into the code, it's the same code used for soft_i2c_new and soft_i2c_init. That's why sda and sdl are told to be mandatory. But that should apply to all ports.
The softI2C code is not touched with the new hardware I2C. So whatever you notice now, must have been there before. Looking into the code, it's the same code used for soft_i2c_new and soft_i2c_init. That's why sda and sdl are told to be mandatory. But that should apply to all ports.