Teensy-LC Beta Testing

PaulStoffregen said:
I should mention some bad news on beta testing low power. The bootloader chip on these first 10 beta boards remains in full speed mode 100% of the time. I'm going to enable sleep detection, like the Mini54 does on Teensy 3.1, but that feature didn't make these first 10 beta boards.

When posting current measurements, please keep in mind we're doing this beta test in public view. Power benchmarks done now, on these 10 beta test boards, will not be representative of what people will see in the final product.
Click to expand...


thanks for letting me know.
 
Paul, you commented that emulated EEPROM was overwritten with upload. I'm not seeing that with my simple tests. Data seems preserved over power up/down and upload.

emulated EEPROM time (us) to write/read 100 bytes:
teensy 3.1 @96mhz: 115/84
teensy 3.0 @96mhz: 113/89
teensy LC @48mhz: 6309/2535 beta test
 
Last edited:
paul's USB latency test suite on teensy LC (beta) to Ubuntu 14.04 laptop
ref: http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

Code: 
    teensy/USB/latency_test/
      src/teensy/latency_test
      latency_test /dev/ttyACM0
      port /dev/ttyACM0 opened
      waiting for board to be ready:
      .ok
      latency @ 1 bytes: 0.11 ms average, 0.22 maximum
      latency @ 2 bytes: 0.14 ms average, 0.62 maximum
      latency @ 12 bytes: 0.21 ms average, 1.30 maximum
      latency @ 30 bytes: 0.34 ms average, 1.77 maximum
      latency @ 62 bytes: 0.50 ms average, 0.58 maximum
      latency @ 71 bytes: 0.58 ms average, 0.66 maximum
      latency @ 128 bytes: 0.94 ms average, 1.01 maximum  
      latency @ 500 bytes: 3.11 ms average, 3.24 maximum   
      latency @ 1000 bytes: 5.92 ms average, 6.05 maximum
      latency @ 2000 bytes: 11.53 ms average, 13.73 maximum
      latency @ 4000 bytes: 22.69 ms average, 22.80 maximum
      latency @ 8000 bytes: 45.07 ms average, 45.53 maximum

    teensy/USB/USBreadbytes
      receive_test /dev/ttyACM0
      ...
      Bytes per second = 1150616
      Bytes per second = 1150241 
      Bytes per second = 1150902
      Bytes per second = 1151322
      Average bytes per second = 1150290

      USBreadbyte
      receive_test /dev/ttyACM0
      Bytes per second = 550373
      Bytes per second = 551217
      Average bytes per second = 551243
 
manitou said:
Paul, you commented that emulated EEPROM was overwritten with upload. I'm not seeing that with my simple tests. Data seems preserved over power up/down and upload.
Click to expand...

I fixed this just before we shipped the 10 beta boards. Emulated EEPROM data should be preserved now.
 
PaulStoffregen said:
My hope is to switch most of the DMA-based libraries from writing the TCD structure to calling the hardware-neutral functions of DMAChannel.h.
Click to expand...

When I switched SmartMatrix over to using DMAChannel I found the functions you included with DMAChannel didn't cover all the options I'm using, e.g. Minor Loop Offset. I'm not even sure if all the features I use for SmartMatrix are available on the Teensy-LC micro. If you're working on DMAChannel next week maybe you can add some functions. I can't spend too much time on this but maybe I can try to replace as much of the direct TCD changes with DMAChannel library calls and let you know what's still left.
 
Indeed, DMAChannel is intended to be a subset of the functionality. Except for a couple functions, it designed to offer the functionality either board can provide.

Some projects will need the more advanced DMA features only available on Teensy 3.1. DMAChannel.h give you direct access to the TCD registers, but using those locks you out of working on Teensy-LC.

It's entirely possible both chips can offer some functionality that DMAChannel.h doesn't offer yet. I'm very open to adding more stuff, but it really should be only things that either board can do.
 
Just got my Teensy LC tonight. It blinked when hooked up to the USB cable.

Took me a while to realize 1) that I had more than one Arduino installation, and 2) i2c_t3 doesn't work with Teensy LC! I got my MAX21100+LIS3MDL+MS5637 mini breakout board spewing 9 DoF sensor data, quaternions, pressure and temperature to serial output. It runs a little slower since I am using 100 kHz I2C instead of the 400 kHz I usually do with i2c_t3.h but all is working well.

More testing tomorrow...
 
Last edited:
manitou said:
Code: 
    teensy/USB/USBreadbytes
      Average bytes per second = 1150290

      USBreadbyte
      Average bytes per second = 551243
Click to expand...

That's very good news! The USB stack is working efficiently, even with the simpler bus matrix. The CPU-limited speed by processing 1 byte at a time is still pretty good, even though we're on Cortex-M0+ at a lower clock speed. :)

I've been considering reducing the default number of USB buffers, since we have only 8K of RAM in this chip. Fewer buffers might impact USB performance, especially on the "with overhead" benchmark.

If you want to explore the buffers to USB performance trade-off, just edit line 96 in usb_desc.h to change the number of USB buffers. You should see the RAM usage change dramatically when you recompile.

Other stuff is using RAM too. Serail1, Serial2 & Serial3 are getting linked, even when unused. Those are first on my RAM conservation wish list. At least 3 things are causing them to link: calls to available() in yield, calls in the fault handler in mk20dx128.c, and use if the interrupt function. The interrupt is easily fixed with attachInterruptVector, which we didn't have when that code was originally written. I'm not sure how to fix the linking issue, but I know the Arduino guys had this on AVR with serialEvent. It was discussed in detail before a fix was added.
 
Doing "quality control" after soldering on headers, ran pin tests on all pins. Did digitalRead with INPUT_PULLUP, digitalWrite, PWM, touch, analogRead, pin ISR. All worked (5v on alternate pin 17).
Confirmed all PWMs at 488 hz at both 48 and 24mhz.
Measured internal pullup pin resistors: 42 to 44Kohms
Tested TX on Serial 1 2 3, also jumpered TX to RX write/read ok

still don't know why MD5 doesn't print (i have !Serial and delay). putting output in a while(1) loop got me output ... but still need to figure out why original code fails to print ... (edit: IDE fixed in 1.21-test4)

The ARM chip does not have a conventional "date code" on it. the entropy guy's database likes to have a date code for the chip. There is a mask code 1N15J

i tried hacking in temp sensor ADC channel (26) in of A0 pin number in array in analog.c, but that didn't seem to work. Has Freescale admitted to not having temp sensor on this chip?

i also tried adding write 1 to TOF in ftm0_isr() in PulsePosition, and using pins 6 and 9 in the loopback example ... but nothing printed ... i may await Paul's magic touch.
 
Last edited:
Thanks. Great testing! :)

manitou said:
i tried hacking in temp sensor ADC channel (26) in of A0 pin number in array in analog.c, but that didn't seem to work. Has Freescale admitted to not having temp sensor on this chip?
Click to expand...

It didn't work when I tried it either. I didn't spend any time investigating. Before pinging Freescale, I'd like to at least give it a good effort.

Edit: let's at least try single ended vs differential mode, both settings for the a/b mux, and try reading the other unused channels with all 4 combinations of mode & ab mux. Let's also make sure the comparator and dac are powered up, just in case. If none of that works, I'll ping Freescale. But functionality-related silicon bugs almost never get fixed, so unless there's some undocumented trick to enable it, if we can't find a way to access it, odds are it's simply not there.
 
Last edited:
PaulStoffregen said:
I ported IRremote. So far, I've only been able to test receiving. IRrecvDump works great with an old Sony remote.

I don't currently have any reasonable way to test sending. Can anyone with an IR LED and some equipment that takes IR remote control look at this?

http://www.pjrc.com/teensy/beta/IRremote_TeensyLC.zip
Click to expand...

I'll add it to my todo list? did you look at output on logic analyzer (40khz carrier with mark/space)? Some IRremote implemetations can work in "loopback" -- aim the IR LED at the sensor. can your LC version do loopback? teensy 3 IRremote couldn't do loopback

i still have an old Sony VCR that I can use to test IR output...
 
teensy LC beta test results:

unconnected SPI with logic analyzer: default SPI clock: 12.5MHz (config as 24000000 or 12000000), analyzer shows 12.5 mhz
configure 8000000, analyzer: 6.25 mhz
configure 4000000,analyzer: 3.846 mhz
...TODO: SPI1 16-bits/DMA/FIFO (Edit: for more SPI results see reply #75 in this thread)
+SPI worked with ds3234 RTC

I2C with 4.7K pullups for I2C EEPROM (write/read works)
30 byte read takes 3384us, analyzer shows I2C CLK at 93.567khz
with TWBR=12 (400khz), 30 byte read 1068 us, analyzer shows 320khz
 
Last edited:
I'm looking at PulsePosition now. It's got a *LOT* of dependency on the K-series hardware! I'll get it working.....

Edit: actually, I might not ever get this working. Seems the TPM timer can't do on-the-fly timer compare reconfiguration. :(

Edit again: I'm working on a workaround......
 
Last edited:
PaulStoffregen said:
I ported IRremote. So far, I've only been able to test receiving. IRrecvDump works great with an old Sony remote.

I don't currently have any reasonable way to test sending. Can anyone with an IR LED and some equipment that takes IR remote control look at this?
Click to expand...

looked at Sony transmit on logic analyzer, looks good. 40khz carrier, sync pulse, plus 12 "bits" with proper encoding 0xA9A
sony.png

(initial compile of Dump demo failed because of variable conflict with RobotIRremote library ? -- I moved that library "out of the way"). Tested IRrecvDUMP with Sony remote, looks good.

OK, IR LED output (pin 16) turns on/off my Sony VCR. I had to get the LED real close to the VCR. your library mods look good to me.:D
 
Last edited:
I'm considering a hack in the IDE, next time I touch the java code.

*in a menacing super-villain voice* .... Arduino Robot libraries, you have inconvenienced me for the LAST time!
 
This evening I got IR Rx and Tx working on a Teensy++2 so when the Teensy-LC arrives I can give it a try.

Pete
 
I was hoping to find a way that completely disregards the Robot libraries when Teensy is selected in the Tools > Boards menu, but leaves the IDE's behavior unchanged with regular Arduino boards are selected, especially the Robot ones!

But that's looking like quite a pain, since the IDE is designed around scanning all those files only at startup and building a single, static list.

However, I do believe I've managed to fix the 2 serial monitor bugs I added in 1.21-test2.

https://github.com/PaulStoffregen/A...mmit/70cbf324fe3b8a0a67724a6fd193e94a32028595
https://github.com/PaulStoffregen/A...mmit/47e37a3ba5d674fd947096a336f82d313bdc7111

This should keep the IDE from locking up when closing the serial monitor with rapid data arriving, and it should restore Serial.print() for the non-serial USB types.

I'm going to take one more quick look at the Robot libs problem, but odds are I'll leave it for another day. We could really use 1.21-test4 now, with all the recent fixed included, and the serial monitor fixed!
 
You must log in or register to reply here.
Back
Top