PDA

View Full Version : Coming Soon: Teensy-LC (low cost Teensy)



Pages : 1 [2] 3

Robin
02-19-2015, 09:02 PM
Isn't that on the USPS side Robin? I can also see my Teensies 3.1 have departed from the US yesterday. Will try to see if that also works within NL.
Update: nope, doesn't work in NL yet. Guess we should have just have stayed German territory after all in 1945 ;)

It really varies by country. There have been improvements all around. The US is able to provide more info as it receives it from other countries. Many countries have improved their tracking by using the customs label bar code as a tracking number. More complete tracking info can sometimes be found on the USPS web site, the postal web site for the destination country, or the customs web site for the destination country.

jakorten
02-19-2015, 09:07 PM
Dutch postal service isn't very reliable anymore, I have had very strange situations with packages from China (one time they said customs (read: their own customs department) could not read my address since the package was severely damaged, the next week when I called they said they had returned it to China. Another week after that I got the very same package with a well readable address and no damage at all). Fortunately they seem to be better in handling envelopes with Teensies :) at least... until now.

christoph
02-19-2015, 09:08 PM
I'm a scientific coworker in thermodynamics/fluid dynamics, teaching is part of the job and I really enjoy it.

jakorten
02-19-2015, 09:10 PM
I see, I work in a "Fachhochschule" (university of applied sciences) two days in a Nursing school and the rest in the Computer Science department, try to link healthcare and technology (thus using teensies for CPR training etc).

Very convenient that the LC has two easy accessible i2c ports, one to connect to the rest of the system, and one to connect to a bunch of sensors (we make a modular system), hope that helps in improving CPR / nursing performance in the near future.

christoph
02-21-2015, 11:36 AM
Yay! My board just arrived!

jakorten
02-21-2015, 08:52 PM
So how does it hold up to your expectations?!

christoph
02-21-2015, 09:05 PM
So far it's working well, I'm just struggling with my code a bit.

The board just works:

plug it in for the first time -> blinky
write own blinky sketch and hit download -> loader works fine
even more blinky without problems


DmaSpi seems to working fine. When I'm sure that it actually does work fine I'll push it to github.

defragster
02-22-2015, 10:26 AM
I'm not sure what 5V is at issue - VIN is declared as (3.7 to 5.5 volts) on Pinout card - this Technical Specifications table on product page (screen snip above) shows:
Digital I/O 27
Voltage Output 3.3V + one 5V
Current Output 5mA + four 20mA
Voltage Input 3.3V Only

Product page (http://www.pjrc.com/teensy/teensyLC.html)

Pinout detail (http://www.pjrc.com/teensy/teensylc_front_pinout.png)

Note: I don't think this was the issue but misreading this part of the pinout card might not say "VIN output on pin #"'17 @5V' but rather wrongly suggest 17 pins usable at 5V
3595

PaulStoffregen
02-22-2015, 02:15 PM
Maybe the pinout card should say something like "17 @VIN Voltage"? That's kinda long, but maybe "Voltage" could be a smaller font and squeeze underneath?

Near the end of next week I need to finalize the card and get them printed, so we'll have cards when Teensy-LC releases in March. I'm open to ideas. Just speak up now, since the card design gets finalized in a matter of days....

KurtE
02-22-2015, 02:29 PM
As I mentioned back in posts #238 and #241, I think CS pins may need to marked for which buss. Also some alternative pins maybe should be included as well...

jakorten
02-22-2015, 03:18 PM
Maybe the pinout card should say something like "17 @VIN Voltage"? That's kinda long, but maybe "Voltage" could be a smaller font and squeeze underneath?

Near the end of next week I need to finalize the card and get them printed, so we'll have cards when Teensy-LC releases in March. I'm open to ideas. Just speak up now, since the card design gets finalized in a matter of days....


About that, although I know it might be a bit cumbersome for processing, but wouldn't it be a good idea to get selection option that says "include card" on checkout in your store. I like the cards, even have some taped above my working place, but I consider it a loss that I have a whole stack of them now (environment etc. and it would be a shame to just put such a beautiful cards in the waste bin).

Nantonos
02-22-2015, 03:23 PM
Maybe the pinout card should say something like "17 @VIN Voltage"? That's kinda long, but maybe "Voltage" could be a smaller font and squeeze underneath?

That does seem clearer. Its a boosted copy of pin17. Maybe it should be labelled differently, with an explanation in a callout box.

Edit: the rear photo posted earlier (https://forum.pjrc.com/threads/27624-Coming-Soon-Teensy-LC-%28low-cost-Teensy%29?p=64305&viewfull=1#post64305) shows that pin labelled on the silkscreen as 17-5V. Also the DAC pin as 26-DAC. Does that mean that on the LC the DAC pin can be used as a digital I/O pin as well as analog input A12 and DAC out?


Near the end of next week I need to finalize the card and get them printed, so we'll have cards when Teensy-LC releases in March. I'm open to ideas. Just speak up now, since the card design gets finalized in a matter of days....
I was going to revise the card I made to include higher resolution front photo and also a card for the back (showing the inner pins). However, I don't have clean photos of green board teensyLC and I don't have a board to photograph myself. There were some higher resolution front and back photos posted earlier, but those were purple boards and would need some straightening and background knockout to be useable.

MichaelMeissner
02-22-2015, 03:28 PM
I was updating my microprocessor cross-reference spreadsheet (https://docs.google.com/spreadsheets/d/1LSi0c17iqtvpKuNSYksMG306_FpWdJcniSRR6aGNNYQ/edit?usp=sharing), and I did not recall seeing what the maximum limit of micro-amps you can draw from the 3.3v pins. For reference, I have the limits for the Teensy 3.0 at 155mA and the 3.1 at 185mA, with a suggestion that using 100mA is a safe design rule for the Teensy 3.0. What is the appropriate value for the LC?

Nantonos
02-22-2015, 03:32 PM
Also on the subject of pinout cards, there have been several postings over the last few months where people misread the rear pinout card to mean that the outer pins were different top to bottom (and were confused because surely they will join together if you solder pins to them). Having lines going from the labels to the inner pins (and pads, for Teensy 3.0/3.1) would seem to aboid that confusion.

defragster
02-22-2015, 07:37 PM
It should get it's own color cue? Is p17 5v input tolerant - or just output VIN only? My thought was to invert logic order as in: "Vin out p17". Since the label item isn't near the pin #17 - the context isn't there like the other labels.

stevech
02-22-2015, 07:37 PM
I find the term @5V confusing due to the ampersand.

MichaelMeissner
02-22-2015, 08:13 PM
defragster: The pin on the back on the LC where Vbat used to be on the 3.0/3.1 is an output only pin (i.e. there is a one way MOSFET between the pin 17/A3 and the back pin). If you want to read from it, you need to hook up the connection the pin 17/A3 directly. That means it is not 5v tolerant. Paul answered this a few pages ago.

The intent is to allow you hook up a single low powered servo or a ws2812b (neopixel) directly to the pin without needing to use a level converter. You would then hook up the remaining 2 wires on the servo/ws2812b to the ground and the VIN pin (not the 3.3v pin that is next to the back pin), Thus the control is done through A3 in the source, and neopixel/servo gets its power from the VIN pin. It would have been more convenient if the back power pin was also VIN and not 3.3v (so you could hook the servo/ws2812b directly to the 3 adjacent pins), but it itsn't that hard to run a wire from Vin.

<edit>
You probably don't want to run a high power LED from this pin, as the pin can only deliver 8mA of power.

defragster
02-22-2015, 08:54 PM
I did know Output Only from scanning so sort of a rhetorical ? just showing how much it takes to describe - there are two pin #17's and one is very special and 5 characters comes up short

@Paul: Odd too that 17/A3 is 20mA and 5Vp17 is 8mA - electrically sensible - but so many details. Question how much current does it take to drive that p17 Mosfet? If you take 3.3v@20mA off 17/A3 is there any chance the Mosfet won't properly fire 5V off p17?

MM: thanks as I read that I didn't look at the pinout to visualize 2 pin 17's.

[edit]: @addressing in forum - pardon my generally untrained etiquette

MichaelMeissner
02-22-2015, 08:59 PM
Defragster, those questions are better addressed to Paul, and not to me.... :cool:

PaulStoffregen
02-23-2015, 08:15 AM
Ok, let's see if I can get all of today's questions answered in just 1 post....


I think CS pins may need to marked for which buss.

Yes. Since there aren't 5 logically different hardware-controlled CS pins, maybe just "CS0" and "CS1" will work?

I'll be working on the final card design later this week. Hopefully there'll be time to post a couple draft copies for feedback.



wouldn't it be a good idea to get selection option that says "include card" on checkout in your store.

Right now, messing with anything on the website is the last thing I should be doing. Eventually it needs a huge amount of work, but that should happen some time when a new product isn't about to release.

Customizing stuff is something we're not set up to do. I've often considered setting up a way to order different pins & sockets soldered, with a few days lead time. But logistically, it really makes things much more complex. We do pretty well with shipping orders quickly, but only because we try to keep everything as simple as possible.

If you *really* want to not get a card included, you can mention that in the "additional instructions" box. Some people do exactly that when ordering 10 or so.



Also the DAC pin as 26-DAC. Does that mean that on the LC the DAC pin can be used as a digital I/O pin as well as analog input A12 and DAC out?

Yes, on Teensy-LC the DAC pin can also work as digital I/O or an analog input.

On Teensy 3.1, the DAC pin can be an analog input, but not digital I/O.




I was going to revise the card I made to include higher resolution front photo and also a card for the back (showing the inner pins). However, I don't have clean photos of green board teensyLC and I don't have a board to photograph myself.

I'll update the web page soon, with a better photo of the green board.



.... with a suggestion that using 100mA is a safe design rule for the Teensy 3.0. What is the appropriate value for the LC?

For now, I believe recommending 100 mA is still probably best. Teensy-LC will use less power than Teensy 3.1, and the on-chip regulator has similar specs, so in theory a little more current could be available.

For initial release next month, I'd prefer to keep things conservative, specs-wise.



Having lines going from the labels to the inner pins (and pads, for Teensy 3.0/3.1) would seem to aboid that confusion.

Oh, the Teensy 3.1 printed card was updated months ago, but it seems the reference page on the website has the older version of the card.



I find the term @5V confusing due to the ampersand.

What specifically would be more clear?



I did know Output Only from scanning so sort of a rhetorical ? just showing how much it takes to describe - there are two pin #17's and one is very special and 5 characters comes up short


Yeah, with any sort of reference card, or pretty much any type of graphic intended to convey technical details, there's a trade-off between expressing accurate details versus maintaining overall simplicity that allows the most important features to be seen easily. I'm afraid there are no perfect answers, only (somewhat) reasonably compromises.



Question how much current does it take to drive that p17 Mosfet?

It's a CMOS logic chip, not just a mosfet. Internally, it's made of many mosfet transistors inside the chip, but functionally it's a logic gate chip, not a mosfet transistor.

Like all such logic chips, the input current is minimal. The input is a very low capacitance, under 10 pF, not anything like the large capacitance of a single high-power mosfet transistor. Like all capacitive inputs, some current is needed during the rising and falling edges to switch the logic state, but with such a low capacitance, it's really not worth much concern. To maintain a steady logic state on a capacitive input requires no current at all.

For all practical purposes, the buffer doesn't "use up" any significant portion of the 20 mA current the main chip can provide on pin 17.

defragster
02-23-2015, 09:55 AM
It should get it's own color cue? Is p17 5v [3.3v] input tolerant? My thought was to invert word order as in: "Vin out p17". [edited]

Paul: Thanks. How about a Grey color Digital loop/ring around the label on the end p17 description - vertically for more room?

3617

Re: voltage on p17 - in the case it was confused for the input A3/17 pin? Like my 'current drive' question - if it can't be expected to be a problem then special warning isn't needed.

Nantonos
02-23-2015, 11:08 AM
I find the term @5V confusing due to the ampersand.

I was trying to convey "this is a copy of pin 17, but at 5 volts". Except, in few characters.

mxxx
02-23-2015, 12:05 PM
I find the term @5V confusing due to the ampersand.


me too. not sure much is won by trying to find a as-short-as-possible but ultimately cryptic label.

as long as there aren't that many special cases, i'd suggest marking the pin as somehow special, using a different color and some sort of familiar typographical device, eg. an asterisk '*' or obelisk '†'. a more verbose description could then be included in some legend/footnote.

christoph
02-23-2015, 12:09 PM
While I was working on DmaSpi I noticed that the chip seems to get pretty warm, so I placed my breadboard in front of our IR camera

3618

And the result:

3619

The chip is doing some graphics and sending data to an OLED display (you can see the display on the right). This is without any detailed knowledge about the emissivity of the chip's surface, which will be less than 1. Therefore the chip's surface temperature is probably above 60 C. I don't have pictures of the 3.x boards, but they didn't seem to get this warm.

PaulStoffregen
02-23-2015, 12:24 PM
Something is not right! It shouldn't warm up significantly.

manitou
02-23-2015, 12:26 PM
wow. i've used multimeter temp sensor and LC's internal temp sensor to measure chip temp just doing i++ and prints, and I measure about 32C. do you have a thermometer? (or you could see what LC"s internal temp sensor reports -- some assembly required)

christoph
02-23-2015, 12:33 PM
Maybe that explains the odd graphics problems I'm seeing....

christoph
02-23-2015, 12:35 PM
I could read the internal temp sensor and also attach a thermocouple. Using the camera was just the quickest way, and it doesn't get out of its cage too often... I don't have much spare time at the moment.

PaulStoffregen
02-23-2015, 12:57 PM
If you disconnect all the wires and just run a LED blink, does it still get hot?

christoph
02-23-2015, 02:00 PM
Two variants of LED blinking:

Using delay(): cold to the touch

void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
}
void loop()
{
delay(500);
digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN));
}

Using elapsedMillis(): cold to the touch

void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
}
void loop()
{
static elapsedMillis timer;
if (timer >= 500)
{
timer = 0;
digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN));
}
}

Continuous SPI transfers: cold to the touch

#include <SPI.h>
void setup()
{
SPI.begin();
SPI.beginTransaction(SPISettings(12000000, MSBFIRST, SPI_MODE3));
}
void loop()
{
SPI.transfer(0xFF); DOUT connected to DIN
}

So it must be my display (or the wiring), but it should (by far) not draw more than the allowed 100 mA.

Edit: Had a look at the datasheet: the display draws about 30 mA when the whole area is turned on. When the teensy LC chip got hot I supplied the display from the teensy's 3.3V regulator. Now I have it on 5V and the LC does not get hot. The display has its own on-board regulator, but it is said to have a 3..5V input range. So all was within the specifications I had.

PaulStoffregen
02-23-2015, 03:45 PM
22 more of the early boards are shipping today. These are the ones with green solder mask with gold plating, the same PCB material that will be used for the final products. This leaves only a few early boards left, and I believe those are cases where Robin doesn't have info.

I had originally planned ship these 22 last Monday. The release of Arduino 1.6.0 on Feb 9th pretty much set all my plans back by 1 week. On the plus side, 1.21-beta6 is looking really good.

These 22 are the first boards that will be able to upgrade their bootloader. The earlier ones (purple and green with tin plating) can not upgrade. At this point, the main need for the upgrade before the full Teensy-LC release will be adding low power support.

If anyone who got one of those first round *really* wants to play with low power modes within the next 3 weeks, please contact Robin directly by email and we'll arrange to send you another board. These are hand soldered by Erin, so please only request a 2nd board if you really do plan to do something with the low power modes before we fully release Teensy-LC next month.

Edit: here's a high-res photo:

3624
(click for full size)

duff
02-23-2015, 03:58 PM
Yay, I was waiting for this, sweet! I'll contact Robin now.

manitou
02-24-2015, 10:39 AM
The display has its own on-board regulator, but it is said to have a 3..5V input range. So all was within the specifications I had.
Did you get a chance to measure how much current your setup was drawing? Which OLED ?

christoph
02-24-2015, 11:01 AM
Did you get a chance to measure how much current your setup was drawing? Which OLED ?

Adafruit's SSD1351 1,5" OLED: http://www.adafruit.com/product/1431

I'll try to remember measuring the current later today... <- fail.

manitou
02-24-2015, 05:32 PM
I'll try to remember measuring the current later today...

I did a quick temperature check using LC internal chip temp sensor and various resistive loads on 3.3v pin.

15ma 33C
31ma 35C
54ma 38C
84ma 40C

nothing too hot.

mxxx
02-25-2015, 08:28 AM
quick question re beta testing -- I've replied to Robin's email with my address about 2 weeks ago, but I've heard nothing since. does one/do we get a notification when the board is shipped?

(not complaining, just wondering ... )

Frank B
02-26-2015, 07:25 PM
The LC is quite robust. I connected by mistake a 5 volt I2C ( with 4k7 pullup to 5V) display ...
It worked for hours (and is still living... :-).

But please do not try this !
According to the datasheet , the max IO pin input voltage is VDD + 0.3 Volt

MichaelMeissner
02-26-2015, 07:51 PM
Mxx: I gave Robin my address some time ago. I did not get advance notification of the LC being shipped, and it arrived at my work address yesterday (I work just west of Boston).

Robin
02-26-2015, 08:01 PM
Recently I sent out a batch of Teensy-LC beta boards, but I got distracted and didn't get the shipping notices out. Sorry about that. Some people can expect a pleasant surprise in the mail. :)

Pensive
02-26-2015, 08:07 PM
The LC is quite robust. I connected by mistake a 5 volt I2C ( with 4k7 pullup to 5V) display ...
It worked for hours (and is still living... :-).

But please do not try this !
According to the datasheet , the max IO pin input voltage is VDD + 0.3 Volt

I've also overloaded 8 of the analogue pins @ 5v for extended periods (up to an hour at a time, sometimes more). Back in the land of 3.3v now - They still seem to work ok, one of them is fluctuating a bit but otherwise they work great :)

JBeale
02-26-2015, 09:02 PM
Thanks for including me in the beta; the LC board arrived today!
36833684

defragster
02-26-2015, 09:33 PM
Paul: Not sure if you finished the cheater card - but since you wrote "17-5V" on the silkscreen - you might stick with that on the card in some fashion.

JBeale
02-26-2015, 10:06 PM
How do I get started with my Beta LC board?

I'm on Win7_64 with Arduino 1.6.0 and Teensyduino 1.21-beta6, Teensy Loader 1.21-beta6.
When I plug Teensy LC in, no serial port appears and pushing the load button on the board does nothing.
The board voltage is OK: +5V USB and +3.3V appear as expected on the board pins.

When I plug an old Teensy 3.0 into the same USB cable, Win7 says "installing device driver software..." and then it shows up as a "Teensy USB Serial" device with a COMxx number and it can be programmed and works as expected. So the USB cable, the PC and the software install seems OK.

UPDATE: holding down the button, releasing it, then pressing again gives me "Installing device driver..." and then "Device driver software was not successfully installed. Unidentified Device X device unplugged"

stevech
02-26-2015, 10:14 PM
load a blinky example for the LC into the IDE. Compile and tell IDE to push download the result of the compile/build. Shouldn't need to push button on Teensy unless code it was last downloaded crashes.
I think they ship LCs with a blinky already installed, But put your own in with different blink timing.

May need to use older IDE - 1.6 is all still beta.

duff
02-26-2015, 10:22 PM
I have been using 1.6.0 for a while now and it works as expected with the LC, just some IDE bugs but all the TeensyLC sketches and libraries I've used work as advertised.

JBeale
02-26-2015, 10:24 PM
I rebooted my laptop, opened the IDE, connected Teensy LC. The LC board looks dead (nothing blinking), Windows sees no serial port or device, and the IDE says no serial ports available. I think many people would conclude it's broken at that point. I select Teensy LC in the IDE and click the "checkmark" button to compile (but not load) "Blink". Suddenly, Windows loads a device driver, COM20 appears, and now blink is loaded on the board and working. So it works, maybe that is the way it is supposed to work, but I don't remember it working this way before? Or maybe it did and I forgot, or maybe my other (non-beta) Teensy 2, 3.0, 3.1 boards had something preloaded already. Anyway, onwards...

defragster
02-26-2015, 11:06 PM
At the end of TeensyDuino Install it says (in some fashion): CLICK COMPILE ONLY the first time. I've not seen other commentary on that event - but I've done it and not seen an issue with the Beta on v3.1's. Somehow it forces the first compile of the CORE or something that makes the system work though.

bperrybap
02-27-2015, 06:33 AM
Paul,
Teensy-LC is now working with openGLCD on the GLCD test bed.

It worked "out of the box", with the latest code; however, because the board
was unknown, the library uses defaults, and the default pins are different pinout
from what Teensy 3 and 3.1 used with the GLCD test bed.

I've added support for this board to use the same pinout as the Teensy 3 and 3.1 since they
are digital pin pinout compatible.

I have a question and need a bit of help in one area.

Currently I went back to use a h/w level shifter.
My question is can the Teensy-LC use the 10k series resistors to simply
limit the back current when connecting 5v outputs to the Teensy 3v input pins like on Teensy 3.0 or will it require a real level shifter?

Also, the nanosecond delay code you gave me doesn't work on the processor used on the Teensy-LC
so the code is slowed down because it has to use Arduino API functions for its delays which
are considerably longer than necessary.

This is the code that breaks:

static __inline__ void /* exactly 4 cycles/loop, max 2**32 loops */
_delay_loop_2_x( uint32_t __n )
{ /* cycles per loop */
__asm__ volatile ( /* __n..one zero */
"L_%=__delay_loop_2_x:" "\n\t"
"subs %0, #1" "\n\t"
// "nop" "\n\t"
"bne L_%=__delay_loop_2_x" "\n"
: "+r" (__n) :
);
}

The assembler complains with this error
Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

I don't know gcc/gas arm syntax or I'd fix it myself.

--- bill

Constantin
02-27-2015, 11:20 AM
Just got mine! Very nice soldering work. Now it's time to reciprocate the favor with some testing. BTW, are you transitioning to a new bootloader chip just for the Teensy? This one seems smaller than the mini 54 I remember on the Teensy 3.x series.

PaulStoffregen
02-27-2015, 12:36 PM
The assembler complains with this error
Error: instruction not supported in Thumb16 mode -- `subs r3,#1'


Try "sub" instead of "subs".

Really, the assembler should accept "subs", since the status bits are always updated. But this looks like a quick in the assembler.

But you'll need a #ifdef, to use "sub" on Teensy-LC and "subs" on the others. Yeah, it's messy.

duff
02-27-2015, 03:23 PM
Try "sub" instead of "subs".

Really, the assembler should accept "subs", since the status bits are always updated. But this looks like a quick in the assembler.

But you'll need a #ifdef, to use "sub" on Teensy-LC and "subs" on the others. Yeah, it's messy.


I found that if you look at the disassembly of the asm for delayMicroseconds it uses 'subs' :confused:



00000472 <L_10_delayMicroseconds>:
472: 3b01 subs r3, #1
474: d1fd bne.n 472 <L_10_delayMicroseconds>
476: 4770 bx lr
478: 00027100 .word 0x00027100


I had some issues with this and other instructions that try to set flags for inline assembly.



The assembler complains with this error
Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

I don't know gcc/gas arm syntax or I'd fix it myself.

You can use asm (".syntax unified"); before the subs instruction and then asm (".syntax divided"); after it and it will compile so something like this would compile:

static __inline__ void /* exactly 4 cycles/loop, max 2**32 loops */
_delay_loop_2_x( uint32_t __n )
{ /* cycles per loop */
__asm__ volatile ( /* __n..one zero */
"L_%=__delay_loop_2_x:" "\n\t"
".syntax unified" "\n\t"
"subs %0, #1" "\n\t"
".syntax divided" "\n\t"
// "nop" "\n\t"
"bne L_%=__delay_loop_2_x" "\n"
: "+r" (__n) :
);
}


the disassembly looks good to me:

00000476 <L_19__delay_loop_2_x>:
476: 3b01 subs r3, #1
478: d1fd bne.n 476 <L_19__delay_loop_2_x>
47a: 4770 bx lr
47c: 00002710 .word 0x00002710

PaulStoffregen
02-27-2015, 05:13 PM
I found that if you look at the disassembly of the asm for delayMicroseconds it uses 'subs' :confused:


Yes, it's absolutely terrible.

But that's the way the toolchain is, where you have to write "sub" which really means "subs" (it does in fact update the status bits) and gets disassembled as "subs".

bperrybap
02-27-2015, 06:22 PM
Yes, it's absolutely terrible.

But that's the way the toolchain is, where you have to write "sub" which really means "subs" (it does in fact update the status bits) and gets disassembled as "subs".

WOW. That sucks. Seems like a tool bug to me, since the assembler and the disassembler don't agree on the mnemonics.
I can't imagine the amount of time wasted spent trying to figure that one out.

That fixed it.
Is there a better define rather than using the processor define of __MKL26Z64__ to indicate that "thumb" mode
is being used and "sub" must be used instead of "subs"
i.e. I'd like to test a define that works on any ARM processor using thumb mode vs just this specific one to put this
code to bed vs having to fix it later in the future.

--- bill

MichaelMeissner
02-27-2015, 06:28 PM
I believe in the full ARM instruction set there is both SUB (does not set condition code fields) and SUBS (does set condition code fields). However in thumb16, there is only SUB and it sets the condition code fields always. The GCC compiler defines __thumb__ and __thumb2__, depending on which thumb instruction set is used.

bperrybap
02-27-2015, 06:30 PM
Have some questions on pin i/o.
Maybe this isn't the best thread for this, but I'll start off here.

Currently openGLCD jumps through lots of hoops to try to do the fastest
pin i/o as possible. On the AVR that drops down to direct port i/o and can
even do multi bit nibbles or even byte i/o when possible.
On the Teensy arm processors, it uses digitalReadFast()/digitalWriteFast() which
are a bit faster than digitalRead()/digitalWrite() but no where near
as fast as the raw port i/o on the AVR even thought the AVR overall is a
significantly slower processor.

So the first question is:
Is there a better form of pin i/o available on the teensy arm based products?

The second question is:
Is there way other than having to check for CORE_TEENSY and then the processor types
to detect when digitalReadFast()/digitalWrite() exists?
i.e. on other platforms those are implemented as macros so I can simply check for
their existence but on Teensy they are implemented directly as inline functions so you
can't check for their existence.


--- bill

PaulStoffregen
02-27-2015, 06:30 PM
I can't imagine the amount of time wasted spent trying to figure that one out.


Just a few minutes, actually, the first time I hit this while porting delayMicroseconds().

I'm pretty familiar with the ARM Cortex-M (thumb2) assembly language. ;)

bperrybap
02-27-2015, 06:36 PM
I believe in the full ARM instruction set there is both SUB (does not set condition code fields) and SUBS (does set condition code fields). However in thumb16, there is only SUB and it sets the condition code fields always. The GCC compiler defines __thumb__ and __thumb2__, depending on which thumb instruction set is used.

So it looks like __thumb__ is the defined when using thumb16 where "subs" can't be used.
Thanks.

Another question, out of curiosity, is thumb16 a locked in mode for a given processor or is something that
can change depending on how the code is compiled through command line or optimization options?
--- bill

MichaelMeissner
02-27-2015, 07:03 PM
I don't really know the arm all that well, but I believe it depends. Some processors are ARM-only, some are Thumb-only, and some can have ARM/thumb code in the same context, and use a mode context swap instruction to switch between the two.

bperrybap
02-27-2015, 07:07 PM
I don't really know the arm all that well, but I believe it depends. Some processors are ARM-only, some are Thumb-only, and some can have ARM/thumb code in the same context, and use a mode context swap instruction to switch between the two.
Great so using the __thumb__ define is definitely the way to go vs using a processor define.

Thanks again.

--- bill

bperrybap
02-27-2015, 07:09 PM
One thing I still need to get resolved is can the LC 3v pin inputs tolerate a 5v output when fed through a 10k series resistor
like the Teensy 3 could?

PaulStoffregen
02-27-2015, 07:11 PM
All Cortex-M chips are thumb instructions only. If you ever try switch to ARM state, the processor goes to fault mode.

Cortex-M0+ supports only the v6m instructions. Cortex-M3 and Cortex-M4 support the much larger v7m instruction set, and M4 adds the special DSP instructions.

I too would like to know if there's a reliable set of gcc built-in defines to distinguish between all these cases.

PaulStoffregen
02-27-2015, 07:14 PM
One thing I still need to get resolved is can the LC 3v pin inputs tolerate a 5v output when fed through a 10k series resistor like the Teensy 3 could?

Yes, it can.

As with Teensy 3.0, the caveat is the total injected current on all pins must always be less than the current consumption of the entire chip. Rarely is this an issue while the chip is running, but you have to be careful if using the very low power modes.

bperrybap
02-27-2015, 08:11 PM
All Cortex-M chips are thumb instructions only. If you ever try switch to ARM state, the processor goes to fault mode.

Cortex-M0+ supports only the v6m instructions. Cortex-M3 and Cortex-M4 support the much larger v7m instruction set, and M4 adds the special DSP instructions.

I too would like to know if there's a reliable set of gcc built-in defines to distinguish between all these cases.

Just as a followup, __thumb__ is defined when building for Teensy 3.0 and for Teensy LC so that define isn't the magic bullet.
--- bill

PaulStoffregen
02-27-2015, 08:30 PM
My headers define KINETISK and KINETISL. That's hardly as authoritative as a gcc builtin, but so far I've been going with those.

bperrybap
02-27-2015, 08:45 PM
Just ran into a strange issue in the 1.21-beta6 on the 1.6 IDE
There seems to be an issue with the error output when building for teensy boards.
I see this when a #error is encountered.
If I build for uno, I can see what I expect and the useful information like the file, line number, and error message is at the bottom
of the red output. When I build for any teensy board the output is truncated and I am not getting the error information.

I tossed a #error into a header file and this is what I get when building for Teensy++/Teensy 3.0 or Teensy LC: (all teensy boards)


Arduino: 1.6.0 (Linux), TD: 1.21-beta6, Board: "Teensy 3.0, Serial, 96 MHz (overclock), US English"

Build options changed, rebuilding all
Using library openGLCD in folder: /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD (legacy)

/media/DataPartition/2B-Organized/devel/avr/arduino/arduino-1.6.0-bap/hardware/tools/arm/bin/arm-none-eabi-g++ -c -g -Os -Wall -ffunction-sections -fdata-sections -MMD -nostdlib -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -D__MK20DX128__ -DTEENSYDUINO=121 -DARDUINO=10600 -DF_CPU=96000000 -DARDUINO_ARCH_AVR -DUSB_SERIAL -DLAYOUT_US_ENGLISH -I/media/DataPartition/2B-Organized/devel/avr/arduino/arduino-1.6.0-bap/hardware/teensy/avr/cores/teensy3 -I/media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD /tmp/build1859051540936981105.tmp/GLCDdiags.cpp -o /tmp/build1859051540936981105.tmp/GLCDdiags.cpp.o
In file included from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd_Device.h:36:0,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/gText.h:36,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd.h:41,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/openGLCD.h:5,
from GLCDdiags.pde:45:
Error compiling.

And this is what I get when building with the exact same IDE but for UNO:


Arduino: 1.6.0 (Linux), TD: 1.21-beta6, Board: "Arduino Uno"

Build options changed, rebuilding all
Using library openGLCD in folder: /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD (legacy)

/media/DataPartition/2B-Organized/devel/avr/arduino/arduino-1.6.0-bap/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10600 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/media/DataPartition/2B-Organized/devel/avr/arduino/arduino-1.6.0-bap/hardware/arduino/avr/cores/arduino -I/media/DataPartition/2B-Organized/devel/avr/arduino/arduino-1.6.0-bap/hardware/arduino/avr/variants/standard -I/media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD /tmp/build1859051540936981105.tmp/GLCDdiags.cpp -o /tmp/build1859051540936981105.tmp/GLCDdiags.cpp.o
In file included from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd_Device.h:36:0,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/gText.h:36,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd.h:41,
from /media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/openGLCD.h:5,
from GLCDdiags.pde:45:
/media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd_io.h:1:2: error: #error XXX
#error XXX
^
In file included from GLCDdiags.pde:47:0:
/media/UbuntuRoot/home/bill/Arduino/Arduino-AVR/libraries/openGLCD/include/glcd_io.h:1:2: error: #error XXX
#error XXX
^



There must be some sort of output error parsing that is different for Teensy that is dropping the information.
It is pretty important information so obviously it needs some tweaking.



--- bill

duff
02-27-2015, 09:11 PM
Just ran into a strange issue in the 1.21-beta6 on the 1.6 IDE


https://forum.pjrc.com/threads/27867-Arduino-1-6-0-compiler-does-not-output-error-messages

bperrybap
02-27-2015, 09:29 PM
Yes, it can.

As with Teensy 3.0, the caveat is the total injected current on all pins must always be less than the current consumption of the entire chip. Rarely is this an issue while the chip is running, but you have to be careful if using the very low power modes.

Something is different with the LC vs the 3.
I tried using 10k series resistors instead of the level shifter and the LC
doesn't seem to be a able to reliably read the 5v signal levels which
ends up putting trash on the display.
I don't believe it is a timing issue as the Teensy 3.0 works even when clocking at 96Mhz and I've also forced the LC
to use the much slower Arduino delayMicroseconds() call which should give much longer than needed delays.

If I turn off all data reads, and use the write cache, then it works fine with the LC so the issue is definitely
on the read side.

I've also tried dropping back to standard digitalRead()/digitalWrite() instead of the "fast" versions
and no difference.

I'll hook up a logic analyzer and report back but I'm not expecting an issue with the delays.
I don't have a scope so I can't look for analog type corruption on the signals.

Any ideas?

--- bill

manitou
02-28-2015, 02:05 PM
Something is different with the LC vs the 3.
I tried using 10k series resistors instead of the level shifter and the LC
doesn't seem to be a able to reliably read the 5v signal levels which
ends up putting trash on the display.

--- bill

tell me more. are you using INPUT_PULLUP on teensy side? how fast is input signal changing? what is source of 5v signal?

PaulStoffregen
03-02-2015, 09:20 AM
Here is a first draft for the front side of the reference card.

3747

christoph
03-02-2015, 09:38 AM
Why are the labels for pins 5, 16, 17 and 21 bold?

There is hardly any difference in the colors for digital pins and serial ports - maybe make it more prominent?

Constantin
03-02-2015, 09:48 AM
That's likely an oversight.

manitou
03-02-2015, 10:33 AM
Here is a first draft for the front side of the reference card.


On 3.* cards, pin between Vin and 3.3v was marked as AGND

and shouldn't A12/DAC be 26 not 17?

the red dots for 20ma pins was nice addition as per Nantonos draft, though I guess your bold for 5,16,17,21 conveys that info (steganography)

MichaelMeissner
03-02-2015, 11:55 AM
Just to be sure are both digital pins 3 and 21 alternates for RX1 and digital pins 4 and 5 alternates for TX1?

manitou
03-02-2015, 01:11 PM
Just to be sure are both digital pins 3 and 21 alternates for RX1 and digital pins 4 and 5 alternates for TX1?

i think that is right according to this earlier attachment
https://forum.pjrc.com/attachment.php?attachmentid=3552&d=1424103301

KurtE
03-02-2015, 02:25 PM
There are probably a few other alternate pins that potentially could be marked. Example CS on pin 2?

Also my built table could be wrong, but wondering about PWM on pin 21?

3748

manitou
03-02-2015, 02:45 PM
Also my built table could be wrong, but wondering about PWM on pin 21?



based on core_pins.h, i think your table is spot on, though you need to color pin 22 PWM (TPM0_CH0)



#define CORE_PIN0_CONFIG PORTB_PCR16
#define CORE_PIN1_CONFIG PORTB_PCR17
#define CORE_PIN2_CONFIG PORTD_PCR0
#define CORE_PIN3_CONFIG PORTA_PCR1
#define CORE_PIN4_CONFIG PORTA_PCR2
#define CORE_PIN5_CONFIG PORTD_PCR7
#define CORE_PIN6_CONFIG PORTD_PCR4
#define CORE_PIN7_CONFIG PORTD_PCR2
#define CORE_PIN8_CONFIG PORTD_PCR3
#define CORE_PIN9_CONFIG PORTC_PCR3
#define CORE_PIN10_CONFIG PORTC_PCR4
#define CORE_PIN11_CONFIG PORTC_PCR6
#define CORE_PIN12_CONFIG PORTC_PCR7
#define CORE_PIN13_CONFIG PORTC_PCR5
#define CORE_PIN14_CONFIG PORTD_PCR1
#define CORE_PIN15_CONFIG PORTC_PCR0
#define CORE_PIN16_CONFIG PORTB_PCR0
#define CORE_PIN17_CONFIG PORTB_PCR1
#define CORE_PIN18_CONFIG PORTB_PCR3
#define CORE_PIN19_CONFIG PORTB_PCR2
#define CORE_PIN20_CONFIG PORTD_PCR5
#define CORE_PIN21_CONFIG PORTD_PCR6
#define CORE_PIN22_CONFIG PORTC_PCR1
#define CORE_PIN23_CONFIG PORTC_PCR2
#define CORE_PIN24_CONFIG PORTE_PCR20
#define CORE_PIN25_CONFIG PORTE_PCR21
#define CORE_PIN26_CONFIG PORTE_PCR30

manitou
03-02-2015, 02:51 PM
but wondering about PWM on pin 21?



I agree pin 21 is NOT PWM , but 20 is PWM. here are channel assignments

#define FTM0_CH0_PIN 22
#define FTM0_CH1_PIN 23
#define FTM0_CH2_PIN 9
#define FTM0_CH3_PIN 10
#define FTM0_CH4_PIN 6
#define FTM0_CH5_PIN 20
#define FTM1_CH0_PIN 16
#define FTM1_CH1_PIN 17
#define FTM2_CH0_PIN 3
#define FTM2_CH1_PIN 4

PaulStoffregen
03-02-2015, 05:01 PM
Yes, good catch. Pin 21 was mislabled. The PWM was meant to be on pin 20. The DAC pin also has a copy-n-paste error of "17".

I'm planning to use much otherwise empty space on the back side to specify the per-pin current and interrupts. I hope to have a first draft tonight or early tomorrow.

PaulStoffregen
03-02-2015, 05:06 PM
Another draft.

3749

KurtE
03-02-2015, 05:21 PM
Is there any significance to the pin numbers that look like they are bold?

PaulStoffregen
03-02-2015, 05:26 PM
Yes, those are the 4 pins capable of 20 mA output.

manitou
03-02-2015, 05:40 PM
On 3.* cards, pin between Vin and 3.3v was marked as AGND

and shouldn't A12/DAC be 26 not 17?

the red dots for 20ma pins was nice addition as per Nantonos draft, though I guess your bold for 5,16,17,21 conveys that info (steganography)


what about AGND ?

PaulStoffregen
03-02-2015, 05:55 PM
On Teensy-LC, it's just normal GND. There's no inductors or other stuff like on Teensy 3.1.

PaulStoffregen
03-02-2015, 10:28 PM
Here's a first draft of the card's back side:

3750

manitou
03-02-2015, 10:41 PM
your pin table in the first posting of this thread shows INT on pin 2, your card does not ...

#define CORE_INT2_PIN 2

otherwise, your back side looks fine.:(

PaulStoffregen
03-02-2015, 11:30 PM
Opps, I missed that one. Here's an update.

3751

stevech
03-03-2015, 03:29 AM
Out of context, this gets a smiley :)


...
otherwise, your back side looks fine.

defragster
03-03-2015, 05:13 AM
Nice part of the product.

This could make pin 17 on back harder to misinterpret, and the same has room on the front as well.
3754

This arrangement would show fewer top row color jumps
3755

manitou
03-03-2015, 10:55 AM
you could add your new card images to http://www.pjrc.com/teensy/teensyLC.html

PaulStoffregen
03-03-2015, 11:12 AM
This arrangement would show fewer top row color jumps


Yes, that is a bit cleaner. I'll look at modifying the card now.

PaulStoffregen
03-03-2015, 11:42 AM
Ok, this is probably the last draft before the first cards get printed.

3758 3757

Nantonos
03-03-2015, 11:49 AM
Yes, those are the 4 pins capable of 20 mA output.
It needs to say that somewhere, though.
Edit ok it says so on the back of the card. Looks good.

PaulStoffregen
03-03-2015, 11:50 AM
Current specs are on the back side.

PWard
03-03-2015, 12:57 PM
Congrats Paul!

I preordered a couple on general principles. The Teensy is just so darned versatile though, and it handles project feature creep perfectly.

MichaelMeissner
03-03-2015, 01:17 PM
Looking at the card reminded me of something when I last went to my electronics toy-stores that both sell Teensy 3.1 (You-do-it in Needham, MA, and Microcenter in Cambridge, MA). In both of these stores, they have a wall of various bits and pieces, and several microprocessors (Sparkfun red boards, Adafruit Trinkets/Gemmas, Digisparks, Raspberry Pis, etc.). Interestingly, both stores have very few Arduino branded boards, though various clones.

The card mentions the http://www.pjrc.com/teensy link on the front and the http://www.pjrc.com/help link on the back, which is great (and more than some of the vendors list). But if you go to the teensy site, it dives straight into pictures of the Teensy boards with pin layouts, etc. And then it goes into older products that may be near their end of life.

It strikes me that it doesn't help users who are coming to Teensy fresh, and have not been programming Arduinos and other processors for years if you started with the basics of what you can do with the processor, giving links to a few examples (blink, neopixel, etc.).

Now, I realize you've been running full tilt getting LC out the door, and having Arduino 1.6.0 dropped on top of you, but it may make sense to revisit the main page to make it more friendly to newcomers when you get a chance to breathe. And even for non-newcomers, it may be useful to put in links for things like octows2811, audio shield, etc. I know there have been several attempts at making things more friendly, including https://forum.pjrc.com/threads/25395-Teensy-Quick-Reference-Code-Examples-Tips-and-Tricks, but I'm not sure what can be done.

KurtE
03-03-2015, 01:28 PM
I am not sure if it maters, but my spreadsheet I posted print out of, I think, pins 24, 25 on back also can be used for TX1, RX1?

PaulStoffregen
03-03-2015, 01:45 PM
Yes, they can. Maybe on the next rev of the card, I'll cram more stuff into that part.

Those lines with arrows are a problem though. Maybe there's a better way to show this?

It's going into this print shop today, so we'll have cards next week. Any more edits will need to go onto the next printing.

defragster
03-03-2015, 07:42 PM
I can't wait to get my cards in the mail! - with the LC pair I felt compelled to order. Cool color alignment :) - I thought the box idea was better. Maybe I'll hook up the one LC for a serial debug terminal with a ILI9341 screen and add in the tiny_scope code.

PaulStoffregen
03-03-2015, 09:34 PM
I should confess, this first batch of cards will be "digital press", which lacks the color quality of "offset press" printing we normally use.

The reason is digital press printing is fast, only a couple days (and they offset same day service for an extra fee). The last thing I want is to be waiting on printed cards when boards are ready next week.

Future batches will be done with the higher quality offset press printing.

bperrybap
03-04-2015, 04:19 AM
tell me more. are you using INPUT_PULLUP on teensy side? how fast is input signal changing? what is source of 5v signal?

The 5v signal is from a ks0108 GLCD.
Depending on what is happening the 8 GLCD data pins can be inputs or outputs.

I hooked up the analyzer and my h/w delays are the same for both Teensy 3.0 vs Teensy LC.
Typical delays are between 140ns and 500ns depending on the type of operation.
(actual delays are a little bit longer due to what is possible given the CPU clock and instruction cycles)
Those values are defined by the ks0108 spec.

I have tried both INPUT and INPUT_PULLUP with no change.
The current code self adjusts for various environments (AVR, PIC32, ARM) and has been
working for several years.

With Teensy 3.0 it can reliably read the 5v inputs when 10k series resistors are used on the GLCD data lines.
Teensy LC has issues with the 10k series resistors but works fine when the 8 data lines are properly level shifted
using a TI TXB0108 level shifter.

Because it reliably works when a real level shifter is used, I'm tending to rule out a s/w issue.

I don't have a scope so I can't look to see if there is any sort of ringing or slew rate issues
on the signals.

Not sure what the difference is between the internal i/o pin h/w on the Teensy 3.0 vs the Teensy LC but
they don't appear to working the same in this case.


I was hoping to be able to cheat on the 5v input mapping on the Teensy LC the same as what
could be done on the Teensy 3.0

I'm kind out of ideas on what to look at or try next.
Anybody got any ideas?

I guess it might be useful to look at the datasheet for the part
to compare the i/o specs to the part used on the Teensy 3.0

Anybody got pointers to the two datasheets?


--- bill

manitou
03-04-2015, 01:45 PM
Anybody got pointers to the two datasheets?

--- bill

here are datasheets
http://www.pjrc.com/teensy/K20P64M50SF0.pdf

http://cache.freescale.com/files/microcontrollers/doc/data_sheet/KL26P64M48SF5.pdf?fasp=1

I have observed, internal pullups on LC are around 43K, but only 32K on teensy 3 (your mileage may vary).
if your logic requires pullups you might use external 2.2k pullups to reduce RC time (a scope would be handy).
I guess you could also try 5k series resistor and hopefully not stress the teensy (though lacking EE credentials, I shouldn't dispense electrical tips)

Constantin
03-04-2015, 02:03 PM
I guess you could also try 5k series resistor and hopefully not stress the teensy (though lacking EE credentials, I shouldn't dispense electrical tips)

Wouldn't the 2.2k resistors stress the Teensy more than 5k resistors? FWIW, I have used 2.2k resistors happily with the Teensy 3 series (I2C and so on)

manitou
03-04-2015, 02:17 PM
Wouldn't the 2.2k resistors stress the Teensy more than 5k resistors? FWIW, I have used 2.2k resistors happily with the Teensy 3 series (I2C and so on)

The 5k resistor is in series with 5v. I intended the 2.2k pullup to pull to 3.3v. If the logic is like I2C where pullups are required, then it would seem the series resistor woudldn't be required, because the device is only pulling the line low. I suspect the 5v device is actively driving the pin to 5v, so INPUT_PULLUP is probably not required...

stevech
03-04-2015, 03:38 PM
A series resistor in a GPIO input line is not a good thing.. Simple math can tell you if the input signal, after the resistor, can achieve a logic 0. Or worse, the voltage for a logical 0 hovers near the threshold.

bperrybap
03-04-2015, 05:33 PM
Just getting ready to look at the datasheet for the LC.
To stop the guessing, pullups are not needed.
The LCD drives the data signal lines both ways (+5/GND) when the data lines are outputs.
(technically it isn't 5v but the voltage on the USB since everything is powered from USB
so it is a tad lower than 5v)

I'll write some special test code that will allow me to take voltage measurements
on the signals with a voltmeter so I can at lest see the static input voltage levels
(before and after the series resistor)
and compare them between Teensy 3.0 and Teensy LC to see if there is any
difference external to the chips.

If I don't see anything obvious in the datasheet or after doing some math,
it may be time to borrow a scope or it may be a good excuse just go buy a digital scope.
I always like new toys :)

--- bill

PaulStoffregen
03-04-2015, 07:06 PM
Teensy-LC will begin shipping on March 12.

That's 2 days later than the estimated release date, originally published almost a month ago.

jakorten
03-04-2015, 08:30 PM
Good to hear that Paul, looking forward to them!

bperrybap
03-04-2015, 10:58 PM
ok, tracking my 5v pin read/write issue down a bit more.
writes to the GLCD are working as expected.
The issue is occasionally pin reads don't read the expected level correctly.
It isn't random and is very repeatable which is actually great.
It appears that the pin read issues track back to two pins and primarily one pin.
The two pins are digital pins 16 and 17 with most of the issues occurring on digital pin 17.

I did notice that those two pins are special and pin 17 has some sort of level shifter on it that goes to another hole.
is there any sort of special s/w handling that has to be done on these pins?

Is there a schematic for the Teensy LC so I can look at the loading on digital pin 17 by the level converter?

I'm off to write some special code to freeze right in the middle of a failed read so I can look at the actual
voltages on all the signal lines and see what is happening.

--- bill

GremlinWrangler
03-04-2015, 11:12 PM
@bperrybap

Pin 17 is the 5V drive and has a level converter package on it that will probably have a tendency to pull high or low. Rather than trying to freeze the LCD writes would suggest using resistors to pull it and an adjacent pin high and low and see if there is any difference in steady state voltages. Unfortunately it's possible that while the level converter should have a high steady state input impedance it may be delaying the response from the LCD drive circuit that will only how up with a oscilloscope and feeding it a pulse train at the LCD data rate.

bperrybap
03-04-2015, 11:24 PM
I know about the level converter, which is why I'd like to see a schematic
to see what type of load it puts on the ARM pin.
I've increased h/w timing delays to the millisecond range with no changes so I don't think there is any sort
of slew rate issue for the signal nor any type of realtime signal disturbance as the signals are stable
on the input pins for several milliseconds before the ARM is reading the pin state.

In the absence of a further information or a schematic,
I think freezing the code is good thing to do right now.
I want to get a voltage reading for all the signals, while the LCD is driving the data bus as I've never done this yet.
I'll look at both sides of the series resistor to see where the voltages are and compare pin 17 to the others.

Since it is so predictable I can add special code to freeze the code where the arm has seen incorrect data
and then look at the voltages on the signals to see what is going on.
I think it will be useful to see the what the voltages are vs what the ARM is "seeing"
when the LCD is driving the bus.

PaulStoffregen
03-04-2015, 11:46 PM
No schematic yet, probably won't be ready for another week or two.

The logic level converter is a SN74LV1T125 chip with high impedance input, with only a few pF capacitance. It is NOT a mosfet transistor with pullup resistors.

bperrybap
03-05-2015, 01:05 AM
Ok, so I trapped the bad read.
The data on the pins was correct when everything was stopped.
The highs were 4.88 volts and the lows were 0 on both sides of the resistors.
I'm definitely beyond the digital world.
The code normally tells the LCD to drive the data bus then goes to read it
around 320ns later.
It works with the Teensy 3.0 when using 10k serial resistors.
It doesn't work with the Teensy LC.
It works when the delay is increased to 150us so there is some sort of
AC type issue involved.

A delay of that long is not really usable as it is severe impact to performance.

Anyway the only thing I can try now is to use a smaller resistor to see if that improves things.

I'm still not sure why this is an issue for Teensy LC and not for Teensy 3.0
When I looked at the datasheet the AC characteristics looked the same
so I'm not sure what is happening.
This is where a scope would come in handy.

-- bill

PaulStoffregen
03-12-2015, 11:09 PM
Teensy-LC is officially released!! :)

All Teensy-LC pre-orders (without pins) were shipped today. The few orders with pins, placed within the last 48 hours, will ship tomorrow.

Plenty of Teensy-LC boards are in stock.

A final Teensyduino 1.21 release will be made within the next day or two, for official non-beta Teensy-LC software support.

KurtE
03-12-2015, 11:12 PM
Teensy-LC is officially released!! :)

Congrats! For the fun of it I ordered a couple of them to play with which shipped today :) Not sure yet what I will use them for, but will find something!

Constantin
03-12-2015, 11:29 PM
Congratulations! I can't tell you how much rather I'd be at home testing the LC than traveling the country for the month of March. Visits to manufacturers are great fun but being away from home isn't.

duff
03-13-2015, 12:21 AM
I've updated the Snooze (https://github.com/duff2013/Snooze) v5 low power library and now it works pretty well with the LC. I also updated the examples to reflect the differences between Teensy 3.x and LC. Let me know if you encounter any problems.

MichaelMeissner
03-13-2015, 04:41 AM
Congratulations. I do hope after 1.21 ships, that you take some time to recharge your batteries, and such.

MickMad
03-13-2015, 06:06 AM
Teensy-LC is officially released!! :)

All Teensy-LC pre-orders (without pins) were shipped today. The few orders with pins, placed within the last 48 hours, will ship tomorrow.

Plenty of Teensy-LC boards are in stock.

A final Teensyduino 1.21 release will be made within the next day or two, for official non-beta Teensy-LC software support.

Sweet, congrats Paul!

I'm really sorry that I haven't been helpful during the beta test phase but I still have to receive my beta boards...

jakorten
03-13-2015, 06:40 AM
Saw that mine were shipped yesterday, looking forward to them Paul! Already got a bunch of pogo pins for one of them (to make it a test device for my applications).

Pensive
03-13-2015, 09:30 PM
Great news! My beta testing didn't feel much like beta testing at all, most of the problems were Micro$ofts fault :) so I'm sure you will have great success with this product.

At the price, It largely makes more sense to use a teensy-LC instead of multiplexer breakout boards whether analog or digital. I was hoping to finish my Teenstrument completely before the LC release, to have the first finished open source LC based project but I've been on holiday for the past week and frankly, no, im not sorry!! =D

I'll keep cracking on anyway and get it finished.

Time for a holiday for Paul now...

Jerware
03-17-2015, 03:54 AM
Stupid question: what pin has the 74LV1T125 connected? Is it digital pin 17 (i.e 17/A3/SDA0/PWM) or the one at the bottom of the board between 12 and 3.3V? They're both labeled 17. The store page says, "A 74LV1T125 buffer is connected to pin 17, with the increased output voltage available on another pin."

GremlinWrangler
03-17-2015, 04:05 AM
the one labelled as just '17' is the raw I/O from the IC at 3.3V. The one on the end between 12 and 3.3V is an output only at Vin (5V if running from USB) from the level converter.

Jerware
03-17-2015, 04:06 AM
the one labelled as just '17' is the raw I/O from the IC at 3.3V. The one on the end between 12 and 3.3V is an output only at Vin (5V if running from USB) from the level converter.

Brilliant! Thank you.

bperrybap
03-17-2015, 04:46 AM
The silk screen on the bottom of my PCB for that pin says "17-5V"

dougm
03-17-2015, 08:01 PM
Got my TeensyLC's in the mail yesterday!

Is there an update the Arduino environment and/or to the loader application to support them?

12:51:32: HID/win32: vid:045E pid:076C ver:0083
12:51:32: HID/win32: vid:16C0 pid:0478 ver:0102
12:51:32: HID/win32: usage_page:FF9C, usage:0020
12:51:32: Device came online, code_size = 65536
12:51:32: Board is: Unknown board, version 1.02
12:51:32: File "Blink.cpp.hex". 10616 bytes, 16% used
12:51:32: File "Blink.cpp.hex". 10616 bytes, 16% used
12:51:32: elf size appears to be 262144
12:51:32: elf binary data matches hex file
12:51:32: Code size from .elf file = 262144
12:51:32: Incompatible file, showing warning dialog
12:51:32: HID/win32: HidD_GetPreparsedData ok, device still online :-)
12:58:35: Verbose Info event

Thanks,

DougM

defragster
03-17-2015, 08:58 PM
from PJRC https://www.pjrc.com/teensy/td_download.html and select LC for board type

stevech
03-17-2015, 11:46 PM
On that web page is
Windows Serial (installer)

What is this software?

Thanks in advance

GremlinWrangler
03-18-2015, 12:03 AM
That should be the installer for the serial driver, so if you are setting up a machine to talk to a Teensy in a finished product you don't need the full Arduno+Teensyduino install.

stevech
03-18-2015, 01:33 AM
Thanks. A note of explanation on that web page would help.

MickMad
03-18-2015, 09:59 AM
Hey, I finally got my Teensy LC Beta board! I can't wait to test it :) (I'm at work now so no blinky test for now)

I already have a project based on the Pro Trinket that will surely benefit from an hw upgrade to the Teensy LC ;)

MichaelMeissner
03-18-2015, 11:57 AM
I see Adafruit now lists the Teensy-LC: https://www.adafruit.com/product/2419 though they are sold out at the moment.

<edit>
Well Adafruit got some stock later in the day. However, given Adafruit's $2.30 higher price tag and their generally higher shipping costs, if I were just ordering LC's and nothing else, I would go with PJRC, but if I needed one ASAP, I would go with Adafruit, due to the fact I'm in New England and New York is a lot closer than Oregon.

What Adafruit does bring to the table is a wider audience for Teensys.

BTW, the link on Adafruit for the LC points to this thread. The link for the Teensy 3.1 points to the more general page: http://www.pjrc.com/teensy/index.html, which does need to add the LC, now that it has been announced.

Frank B
03-18-2015, 09:44 PM
Wow, exp-tech in germany already lists it - 88 in stock at the moment.
12,50

PaulStoffregen
03-18-2015, 10:06 PM
Yup. Over the next several days, Teensy-LC should appear at several more distributors. :)

Frank B
03-18-2015, 10:40 PM
hehe, the intel edison is sold at -11% in the same shop.
Das Board wird verramscht. <- sorry don't know how to translate this, perhaps "(clearance) sale" ?

Constantin
03-18-2015, 11:07 PM
Verramscht = Flogged or sold at a loss.

Awesome re: the Teensy LC. I do have a question re: the bootloader chip, however. Will it go on sale alongside the LC boards?
Or, alternatively, can the current edition of the Minitan54 be used to program an LC as well?

PaulStoffregen
03-19-2015, 12:07 AM
I do have a question re: the bootloader chip, however. Will it go on sale alongside the LC boards?


Yes, we will start selling a pre-programmed chip for making DIY boards based on the Teensy-LC design.

You can expect this in about 2 to 3 months. It requires building up a special test fixture with a ZIF socket. I do have the socket here, but so far no significant work has begun on building that hardware.

I'm currently working on the Arduino library dependency issue, and then I have a long list of "small" issues and documentation updates planned, before I start on that chip programmer hardware.



can the current edition of the Minitan54 be used to program an LC as well?

No. The Mini54 only implements Teensy 3.0 and 3.1.

PaulStoffregen
03-19-2015, 12:10 AM
hehe, the intel edison is sold at -11% in the same shop.


Wow, I'm surprised they're discounting so quickly. I've heard a few bad stories, but also a lot of positive hype. Hard to know if people are really using them....

Maybe Intel's planning a new version and the distributors know to sell off their stock ASAP?

Nantonos
03-19-2015, 11:11 AM
I see Adafruit now lists the Teensy-LC: https://www.adafruit.com/product/2419 though they are sold out at the moment.

<edit>
Well Adafruit got some stock later in the day. However, given Adafruit's $2.30 higher price tag and their generally higher shipping costs, if I were just ordering LC's and nothing else, I would go with PJRC, but if I needed one ASAP, I would go with Adafruit, do to the fact I'm in New England and New York is a lot closer than Oregon.


I see Floris in the Netherlands has LC at 14.50 (http://floris.cc/shop/en/teensy/1335-teensy-lc.html) (compared to 23.50 for 3.1 (http://floris.cc/shop/en/teensy/953-teensy-31.html)). Meanwhile Snootlab in France doesn't have them yet. (http://snootlab.com/lang-en/43-pjrc-teensy)

squeeek
03-19-2015, 12:02 PM
Meanwhile Snootlab in France doesn't have them yet. (http://snootlab.com/lang-en/43-pjrc-teensy)
I was at their monthly meeting last week and they said they had a lot of work, but that it was in their intention to get some. It might just take "some" time ^^

KurtE
03-19-2015, 01:38 PM
Wow, I'm surprised they're discounting so quickly. I've heard a few bad stories, but also a lot of positive hype. Hard to know if people are really using them....

Maybe Intel's planning a new version and the distributors know to sell off their stock ASAP?
I know that I have mixed feelings about them. Trossen Robotics is using one in a soon to be released robot. Some things nice, some things not so nice. Also working with Intel is not nearly as nice as working with PJRC! Example (https://communities.intel.com/thread/61554) Someone asked about using Arduino 1.6.1 and got the typical Intel answer. You can download the current stuff from (1.5.3 based) xxx, we will post when something else is released... :rolleyes:

PaulStoffregen
03-19-2015, 03:19 PM
LOL. Keeping up with every Arduino release is much harder than it looks!

MichaelMeissner
03-19-2015, 04:29 PM
And doing in the context of a large corporation has its own set of challenges :cool:

Markus_L811
03-19-2015, 08:43 PM
Yeah may off-topic but, the guys from Arduino split in half (arduino.cc the known one, and arduino.org the new one). so there are now 2 IDE's again! Paul what are you do?

Nantonos
03-19-2015, 08:48 PM
I was at their monthly meeting last week and they said they had a lot of work, but that it was in their intention to get some. It might just take "some" time ^^

Oh I'm sure they will have them eventually (and their price for 3.1 is lower than Floris). Not a criticism, just saying they don't have them yet.

Nantonos
03-19-2015, 08:51 PM
Yeah may off-topic but, the guys from Arduino split in half (arduino.cc the known one, and arduino.org the new one). so there are now 2 IDE's again! Paul what are you do?

Arduino.cc has Arduino 1.0.6 and Arduino 1.6.1. This new Arduino srl has 1.0.6.2 and 1.5.8.3. Teensyduino 1.21 works with Arduino 1.0.5, 1.0.6, 1.6.0 and 1.6.1. So it already seems clear what Paul is doing.

PaulStoffregen
03-19-2015, 09:16 PM
arduino.cc the known one, and arduino.org the new one). so there are now 2 IDE's again! Paul what are you do?

My position is Arduino.cc is the real Arduino. Please continue this conversation on this thread:

https://forum.pjrc.com/threads/27873-Arduino-org/page2

See my reply on #35 on that thread for more detail. Please try to keep the Arduino controversy discussion on that thread.

PaulStoffregen
03-19-2015, 10:33 PM
Sparkfun has added Teensy-LC.

https://www.sparkfun.com/products/13305

defragster
03-20-2015, 05:58 AM
I hit the SparkFun page linked and they show the LC "•Using the RTC" and link it to the http://www.pjrc.com/teensy/td_libs_Time.html#teensy3

Only user comments so far are debating that LC Feature and the 'crystal shown as added there' - 'oops no its not . . .'

Sparkfun has 195 in stock - Adafruit $1 more and out of stock.

uTasker
03-21-2015, 12:08 AM
Hi All

There is a simulation of the Teensy LC here: http://www.utasker.com/kinetis/TEENSY_LC.html

It can be downloaded and executed without any installation (see screen shot at the link) and then by hovering the cursor over the board pins the connection to the processor (pin number, possible pin functions and presently selected function) is show.

I am wondering whether there will be a circuit diagram made available (like the GIF for the Teensy 3.1) since I didn't find anything, but could put this together based on the pin connection defines in the code.

Regards

Mark

Constantin
03-21-2015, 12:18 AM
I think I am done coming up with the eagle pin connections for the LC and the boot loader chip. I will post those shortly.

johnmickle
03-21-2015, 03:14 PM
Hi Paul, Glad to know that. It's really a good news. I am waiting for the production run.

Thanks. :)

jakorten
03-21-2015, 03:31 PM
Looking forward to the package with my LC's.

lsnyman
03-24-2015, 06:36 PM
I rebooted my laptop, opened the IDE, connected Teensy LC. The LC board looks dead (nothing blinking), Windows sees no serial port or device, and the IDE says no serial ports available. I think many people would conclude it's broken at that point. I select Teensy LC in the IDE and click the "checkmark" button to compile (but not load) "Blink". Suddenly, Windows loads a device driver, COM20 appears, and now blink is loaded on the board and working. So it works, maybe that is the way it is supposed to work, but I don't remember it working this way before? Or maybe it did and I forgot, or maybe my other (non-beta) Teensy 2, 3.0, 3.1 boards had something preloaded already. Anyway, onwards...

I am having an issue with this also. Firstly, my Teensy 3.1 works fine, Uploading a sketch automatically reboots the board and all works well so I presume the Teensyloader is correctly configured, although I have now re-installed 3 times.
With the Teensy LC, at first I get a Serial port # and select this in the IDE. I click the verify and nothing happens. Then I click upload and it goes through the opload, but at the end it says the following
Opening Teensy Loader...
Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
At this point the COM port # dissapears from my device manager and pressing the button on Teensy LC does nothing.
The only way I can get the COM port to re-appear is to disconnect any connect to a different physical USB socket. Repeat procedure does exactly the same thing again. I have 2 LC boards and both do the same thing.
I am using Windows 8.1, Arduino 1.6.1
Something seems different between Teensy 3.1 and LC.
Any help appreciated.

xxxajk
03-24-2015, 06:38 PM
Try plugging it in while holding the programming button.

jakorten
03-24-2015, 06:39 PM
Or maybe shorting the program to GND.

lsnyman
03-24-2015, 06:53 PM
Tried both of those suggestions. No change.
Pressing the button on LC causes the Serial port to disappear and also kills the flashing LED. Shorting PROGRAM to GND restores the flashing LED but still serial port doesnt appear. Only moving to a new USB will again show a COM port.

jakorten
03-24-2015, 06:55 PM
There might be a short! So check your wires etc.

lsnyman
03-24-2015, 06:57 PM
Used 2 different USB cables, also the Teensy 3.1 works without issues.

lsnyman
03-24-2015, 08:07 PM
As an update, Teensy LC shows up in device manager as Teensy USB Serial (COM10). If I press the reset button, it disappears and shows up under Human Interface Devices as USB Input Device. This is where it stays no matter what I do, until I move the cable to a different USB socket or uninstall the USB Input device. I am at a loss at this stage.

neslekkim
03-24-2015, 08:11 PM
Looking forward to the package with my LC's.

Got mine today! :)

PaulStoffregen
03-24-2015, 08:51 PM
As an update, Teensy LC shows up in device manager as Teensy USB Serial (COM10). If I press the reset button, it disappears and shows up under Human Interface Devices as USB Input Device. This is where it stays no matter what I do

Sounds like it's working perfectly.

The button is NOT for reset. It's to put Teensy into programming mode, where it appears as a HID device with ID 16c0:0478.

More info is here:

http://www.pjrc.com/teensy/troubleshoot.html

lsnyman
03-24-2015, 09:31 PM
Thanks Paul.
According to that info it is acting normal as regards the button and LED, however it will not program. Loading the Blink Sketch on both the Teensy 3.1 and Teensy LC give the following verbose results.
Teensy LC - a long string of the same messages.
16:23:41: file changed
16:23:46: remote connection opened
16:23:46: remote cmd: "comment: Teensyduino 1.21 - WINDOWS"
16:23:46: remote cmd: "dir:C:\Users\Leon\AppData\Local\Temp\build54745990 74920242015.tmp\"
16:23:46: remote cmd: "file:Blink.cpp.hex"
16:23:46: File "Blink.cpp.hex". 10076 bytes, 4% used
16:23:46: remote cmd: "status"
16:23:46: status data sent
16:23:46: remote connection closed
16:23:46: remote connection opened
16:23:50: status data sent
16:23:50: remote cmd: "status"
16:23:50: status data sent
16:23:50: remote cmd: "status"
16:23:50: status data sent
16:23:50: remote cmd: "status"
16:23:50: status data sent
16:23:50: remote cmd: "status"
16:23:50: status data sent
16:23:51: remote cmd: "status"
16:23:51: status data sent
16:23:51: remote cmd: "status"
16:23:51: status data sent
16:23:51: remote cmd: "status"
16:23:51: status data sent
16:23:51: remote connection closed

Teensy 3.1
16:22:47: file changed
16:22:47: File "Blink.cpp.hex". 12200 bytes, 5% used
16:22:47: remote connection opened
16:22:47: remote cmd: "comment: Teensyduino 1.21 - WINDOWS"
16:22:47: remote cmd: "dir:C:\Users\Leon\AppData\Local\Temp\build54745990 74920242015.tmp\"
16:22:47: remote cmd: "file:Blink.cpp.hex"
16:22:47: File "Blink.cpp.hex". 12200 bytes, 5% used
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote connection closed
16:22:47: remote connection opened
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:47: remote cmd: "status"
16:22:47: status data sent
16:22:48: Device came online, code_size = 262144
16:22:48: Board is: Teensy 3.1 (MK20DX256), version 1.03
16:22:48: File "Blink.cpp.hex". 12200 bytes, 5% used
16:22:48: File "Blink.cpp.hex". 12200 bytes, 5% used
16:22:48: elf size appears to be 262144
16:22:48: elf binary data matches hex file
16:22:48: Code size from .elf file = 262144
16:22:48: begin operation
16:22:48: flash, block=0, bs=1024, auto=1
16:22:48: flash, block=1, bs=1024, auto=1
16:22:48: flash, block=2, bs=1024, auto=1
16:22:48: flash, block=3, bs=1024, auto=1
16:22:48: HID/win32: waiting for device
16:22:48: HID/win32: waiting for device
16:22:48: HID/win32: waiting for device
16:22:48: HID/win32: waiting for device
16:22:48: remote cmd: "status"
16:22:48: status data sent
16:22:48: remote connection closed
16:22:48: flash, block=4, bs=1024, auto=1
16:22:48: HID/win32: waiting for device
16:22:48: flash, block=5, bs=1024, auto=1
16:22:48: flash, block=6, bs=1024, auto=1
16:22:48: HID/win32: waiting for device
16:22:48: flash, block=7, bs=1024, auto=1
16:22:48: flash, block=8, bs=1024, auto=1
16:22:48: flash, block=9, bs=1024, auto=1
16:22:48: HID/win32: waiting for device
16:22:48: flash, block=10, bs=1024, auto=1
16:22:48: flash, block=11, bs=1024, auto=1
16:22:48: HID/win32: waiting for device
16:22:48: sending reboot
16:22:48: begin wait_until_offline
16:22:48: offline, waited 3
16:22:48: end operation
16:22:48: redraw timer set, image 14 to show for 1200 ms
16:22:49: redraw, image 9

lsnyman
03-24-2015, 09:44 PM
Ok More info.
Connect Teensy LC - COM port 10 appears LED flashes 1Sec ON 1Sec OFF
Press button on Teensy - LED stops flashing
Upload Blink with new flash rate
Nothing happens - Press button nothing happens
Disconnect Teensy LC and reconnect - Nothing happens - No Com Port shows.
Press button - Nothing happens
Move USB to new socket - Com Port 10 Shows up
Teensy flashes at old rate 1Sec ON, 1Sec OFF
Press Button - Teensy Loader shows reset and programming
LED Flashes at new rate 3Sec ON, 1 Sec OFF.

Dont know if that helps
Again, Teensy 3.1 works without issues.

MarshallTaylor
03-26-2015, 05:04 PM
Hey Paul,

What's the plan with AltSoftSerial and the LC?

I'm working on a teensy3.1 to XBee adapter board(at sparkfun) and have the option to connect software serial lines to the radio, but I don't know where they'll go!
Do you have any plans to make AltSoftSerial compatible with the LC?
Do you know what pins are to be mapped for TX and RX?

Thanks,
Marshall

PaulStoffregen
03-26-2015, 05:15 PM
Do you have any plans to make AltSoftSerial compatible with the LC?


Yes, but it's a low priority.

Do you really need a 4th serial port?

defragster
03-26-2015, 05:32 PM
Isnyman: It looks to have properly worked in the end. Scanning the early part that I'm wondering if TeensyDuino was running at first? With 'Press button on Teensy - LED stops flashing' you took the USB offline and into program mode and unless TeensyDuino was active it would stay that way and the rest may nearly make sense** - putting on new port would restart the Teensy to Run with USB active, and then active TeensyDuino did its job.

**I see you are on Windows - like I am - and it doesn't always set up USB right on new devices, especially if it is busy associating/updating drivers. Early on I was getting a 'ghost' com port that wouldn't work to connect or view output, that hasn't recurred lately.

I just put my LC on and using my own blink code (with Serial print) followed your steps and it worked - though did generate the event noted below, maybe confusion because I also had a 3.1 connected. I repeated with that off and it worked.

10:20:06: File "T_InterruptBlink.cpp.hex". 10688 bytes, 4% used
10:20:06: reboot too soon timer still running, oh no!
10:20:06: remote cmd: "status"

MarshallTaylor
03-26-2015, 06:24 PM
Do you really need a 4th serial port?
Interesting assumption.


The low priority part is all I need. If it was in the pipeline I would wait on my design, but I'll release describing the LC as HW UART only.

Thanks for the quick reply!

Nantonos
03-26-2015, 07:17 PM
I'm working on a teensy3.1 to XBee adapter board(at sparkfun) and have the option to connect software serial lines to the radio, but I don't know where they'll go!


If you are reading a guide that assumes an Arduino-branded board, then most of them (apart from Due and Leonardo) have only one hardware serial port. Furthermore, they tie that up to the USB with a serial-to-USB converter. So, most Arduino boards require you to use software emulation for all your serial duties.

So for Teensy boards, the question is not "can software serial work" but "are there free hardware serial lines I can use". To which the answer is yes, there are three of them.

MichaelMeissner
03-26-2015, 07:27 PM
If memory serves the Leonardo only has one serial port (Serial1, attached to 0/1). Like the Teensy, the USB connection is independent of the hardware serial port, while on an Uno, there is a secondary chip that watches the hardware serial port and converts it to USB. The Due and Mega have 4 serial ports (Serial0 attached to 0/1, Serial1 uses 18/19, Serial2 uses 16/17, Serial3 uses 14/15).

PaulStoffregen
03-26-2015, 09:04 PM
Many sketches and even some libraries published for normal Arduino boards have SoftwareSerial hard-coded into them, based on the assumption there aren't any extra serial ports.

Teensy LC and 3.x have a fake SoftwareSerial library which simply uses the real hardware serial, when you specify the pins to be 0 & 1 or 9 & 10 or 7 & 8. That lets you use such program by only editing the pin numbers, which is usually very easy.

sumotoy
03-28-2015, 12:02 PM
I just tried Teensy LC as "Flight Sim Controls" via USB and doesn't work. It compile ok and driver update correctly but there's no communication with XPlane. The same code works on Teensy 3.1.
UPDATE
I've maded some more testings and looks like Teensy LC doesn't receive any data from XPlane plugin (apart FlightSim.isEnabled()), I've sended some command to XPlane plugin and it reacts but nothing received by Teensy LC. I will look more deeply into this later.
Teensy 3.1 works perfect in both directions, same exact code.

PaulStoffregen
04-03-2015, 10:37 PM
Here's a fix. Copy this file to hardware/teensy/avr/cores/teensy3. It should fix the flightsim troubles on Teensy-LC.

Please let me know how this works for you?

raflyer
04-04-2015, 01:24 AM
That fixed it! Thank so much.

jakorten
04-05-2015, 06:44 PM
What library to use with the LC and Wire? I used the i2c_t3 but no support for Teensy LC yet.

nox771
04-05-2015, 08:37 PM
What library to use with the LC and Wire? I used the i2c_t3 but no support for Teensy LC yet.

Sorry for that, I'm working on it. I'm trying to get it out soon, hopefully a day or two. The Wire library that comes with Teensyduino has LC support (I'm not sure about the 2nd bus though).

PaulStoffregen
04-05-2015, 11:48 PM
Yup, the ordinary Wire library works on Teensy-LC, but it doesn't support the 2nd port and it has far fewer features than i2c_t3. It only provides the basic level of Arduino functionality.

Later this coming week, I'm planning to really look into the Wire library, using that troublesome Lidar module. It's been sitting here collecting dust for a couple weeks while I've been scrambling to keep up with the rapid Arduino releases. I have no intention to turn Wire into the larger feature set of i2c_t3, but at the very least I do intend to support Wire1 and implement setClock, setSDA and setCLK, and do some sort of timeout or other way to recover from misbehaving I2C devices.

sumotoy
04-06-2015, 12:05 AM
Here's a fix. Copy this file to hardware/teensy/avr/cores/teensy3. It should fix the flightsim troubles on Teensy-LC.

Please let me know how this works for you?

Confirmed, thanks Paul!

jakorten
04-06-2015, 09:24 AM
Good to hear that guys. At this point indeed the second bus is most important for me indeed. I have hooked a analog port multiplexer to the second i2c (all SMD so not easy to connect it to the primary port).

mcsarge
04-17-2015, 05:38 PM
In the code of the Wire library you are using, there is a comment that external pull ups must be used. Will the newer or updated library resolve that? I have a Teensy 2.0 and it works fine with the internal pull ups. I realize these are different processors. Also, there is a version of the Wire library out there that includes a twi library that has additional code to prevent I2C lockups, it is called WSWire. Do we need to do that with the TeensyLC? Maybe the new processor also does not have this lock-up problem?

Matt



Yup, the ordinary Wire library works on Teensy-LC, but it doesn't support the 2nd port and it has far fewer features than i2c_t3. It only provides the basic level of Arduino functionality.

Later this coming week, I'm planning to really look into the Wire library, using that troublesome Lidar module. It's been sitting here collecting dust for a couple weeks while I've been scrambling to keep up with the rapid Arduino releases. I have no intention to turn Wire into the larger feature set of i2c_t3, but at the very least I do intend to support Wire1 and implement setClock, setSDA and setCLK, and do some sort of timeout or other way to recover from misbehaving I2C devices.

MichaelMeissner
04-17-2015, 05:54 PM
In the code of the Wire library you are using, there is a comment that external pull ups must be used. Will the newer or updated library resolve that?
I believe the answer regarding pullups is it is not something the library can work around. The ARM processors used in the Teensy 3.0/3.1/LC just do not have the right hardware that the library can enable internal pull-ups and have them work correctly for i2c.

mcsarge
04-17-2015, 06:06 PM
Yes, that seems reasonable. My application uses very few pins. Do you think it could be possible to connect two unused pins to each of the I2C connections needing pull up and set the pull ups on those unused pins to true? I am really trying to limit the number of components used and even getting rid of 2 resistors is a help.


I believe the answer regarding pullups is it is not something the library can work around. The ARM processors used in the Teensy 3.0/3.1/LC just do not have the right hardware that the library can enable internal pull-ups and have them work correctly for i2c.

bperrybap
04-17-2015, 06:31 PM
I have a Teensy 2.0 and it works fine with the internal pull ups

Even on the AVR, while it may "work" with the internal pullups for certain device configurations, it is out of spec and doesn't always work.
The internal pullups are simply too weak.
Consider yourself lucky if it works for your situation without the external pullups.

--- bill

mcsarge
04-17-2015, 06:41 PM
Thanks, that is good information. I bet it works because I am doing I2C from one Atmel chip to another. I guess I will be prepared to wire up a couple of pull-ups since I will be going from an Atmel to the ARM Cortex-M0+.

Matt

nox771
04-17-2015, 06:55 PM
Yes, that seems reasonable. My application uses very few pins. Do you think it could be possible to connect two unused pins to each of the I2C connections needing pull up and set the pull ups on those unused pins to true? I am really trying to limit the number of components used and even getting rid of 2 resistors is a help.

This is an interesting solution, especially if you have a lot of unused pins. The internal pullups are weak for I2C, but they might work for a 100k rate. However if you parallel a few pins together (with others configured as INPUT_PULLUP) you might get something approaching a reasonable pullup value. It's worth a try if you can do it.

stevech
04-17-2015, 07:08 PM
lower resistance pullup improves noise immunity. Like 4.7K, depending on wire length. Pay attention to a good common ground wire too.

mcsarge
04-17-2015, 07:10 PM
Very interesting information all, thanks it is a huge help.

I found this posting that shows the effects of different pull ups on I2C communications, very good article. http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors



lower resistance pullup improves noise immunity. Like 4.7K, depending on wire length. Pay attention to a good common ground wire too.

stevech
04-17-2015, 08:00 PM
The weak internal pull-ups in MCUs, say, 40K, don't bring much benefit to improving the rise time as you see on that dsscircuits.com web page. Unless the device is battery powered and there's a lot usage of the I2C, then I'd go with 1.5K or so.
The length of and capacitance of the wiring you use has a big affect.

mcsarge
04-17-2015, 08:09 PM
The device I am constructing will receive data in slave mode over I2C then send the data using serial out a bluetooth serial module continuously. It will be battery powered but only needs to be able to run for an hour or so per charge of a moderately large LiPo battery. It should be plenty of power so the 1.5K should work well. I am going to hook my O'Scope up and check the rise times just to make sure all is OK.


The weak internal pull-ups in MCUs, say, 40K, don't bring much benefit to improving the rise time as you see on that dsscircuits.com web page. Unless the device is battery powered and there's a lot usage of the I2C, then I'd go with 1.5K or so.
The length of and capacitance of the wiring you use has a big affect.

mcsarge
04-18-2015, 01:14 PM
OK Guys, Last night I went ahead and hooked up my O-Scope to the I2C lines, and I found that the internal pull ups were really rounding off those wave forms. So I grabbed a couple of 1.5K resistors, turned off the internal pull ups and wired them in, and like magic, the wave forms squared off nicely. So, thanks bperrybap, it was as you explained, "working" but certainly not very clean.

This may also fix my problem where the i2C gets into a locked up state, the poor performance on the bus may be causing it, so I will test that as well going forward.

Thanks to you all!

Matt

stevech
04-19-2015, 01:05 AM
on the 'scope, pay attention to how close to 0 volts the signals go. There's less margin for error in a logic 0 than a logic 1, in terms of voltage.

Experimentalist
04-27-2015, 10:11 PM
Can anyone post a link to the latest Teensy-LC pinout front and back graphics? All credits to Nantonos (https://forum.pjrc.com/members/97-Nantonos)

Robin
04-27-2015, 10:12 PM
Can anyone post a link to the latest Teensy-LC pinout front and back graphics? All credits to Nantonos (https://forum.pjrc.com/members/97-Nantonos)

http://www.pjrc.com/teensy/pinout.html

Experimentalist
04-27-2015, 10:15 PM
http://www.pjrc.com/teensy/pinout.html

That was quick!

uTasker
04-27-2015, 11:02 PM
Hi All

Just an idea to make a "really cheap" version in case this would be of interest in the future.

The Teensy LC uses the KL26Z64 which costs $1.50 in quantity but needs the Mini54tan for loading code and a crystal for the USB to be reliable.

The KL27Z64 costs $1.52 in the same quantity but has two additional features that save overall component costs:
1 - it doesn't need a crystal since it has an internal 48MHz clock which supports synchronisation to a USB host and so allows crystal-less USB device operation
2 - It has an internal loader that allows programming it via USB, UART, I2C or SPI and so doesn't require a Mini54tan

I have seen this board using it http://www.coffeebrain.org/blog/distribucion-de-pines-capuccino-kl27/

Of course the USB protocol (HID based) for loading is not the same but it could certainly be supported with a modification in the Teensy Loader application.
There may be other (slight) differences to consider but may be worth checking out.

Regards

Mark

Robin
04-27-2015, 11:07 PM
Hi All

Just an idea to make a "really cheap" version in case this would be of interest in the future.

The Teensy LC uses the KL26Z64 which costs $1.50 in quantity but needs the Mini54tan for loading code and a crystal for the USB to be reliable.



Actually, The Teensy-LC does not use the MINI54TAN chip. It uses the MKL02Z32VFG4. The schematic can be found at:
http://www.pjrc.com/teensy/schematic.html

Nantonos
04-28-2015, 12:47 AM
Can anyone post a link to the latest Teensy-LC pinout front and back graphics? All credits to Nantonos (https://forum.pjrc.com/members/97-Nantonos)
Hey, I just threw together a quick and dirty one during beta testing. The final reference card was done properly by PJRC.

mcsarge
04-30-2015, 03:16 AM
OK Guys, Last night I went ahead and hooked up my O-Scope to the I2C lines, and I found that the internal pull ups were really rounding off those wave forms. So I grabbed a couple of 1.5K resistors, turned off the internal pull ups and wired them in, and like magic, the wave forms squared off nicely. So, thanks bperrybap, it was as you explained, "working" but certainly not very clean.

This may also fix my problem where the i2C gets into a locked up state, the poor performance on the bus may be causing it, so I will test that as well going forward.

Thanks to you all!

Matt

So, I wired up my TeensyLC to be a slave, and I can not get it to receive any data. I have external pull ups and am using pins 18 & 19 for the I2C. Am I missing something? I have gotten this setup to work with the Teensy2.0 and the Trinket from Adafruit.

I can see on my scope that the master is sending out the data, the TeensyLC just does not seem to be receiving it.

Matt

PaulStoffregen
04-30-2015, 04:20 AM
I can see on my scope that the master is sending out the data, the TeensyLC just does not seem to be receiving it.


I tested this with both pairs of master/slave examples in the Wire library. Both worked great.

Are you using different code? I could investigate if you post (hopefully small, but complete) code for both sides and a photo of how you've actually wired them up. If you post something for me to test, please use two Teensy boards. I don't have any Adafruit Trinkets.

mcsarge
04-30-2015, 11:06 AM
I tested this with both pairs of master/slave examples in the Wire library. Both worked great.

Are you using different code? I could investigate if you post (hopefully small, but complete) code for both sides and a photo of how you've actually wired them up. If you post something for me to test, please use two Teensy boards. I don't have any Adafruit Trinkets.

Paul,

I am using Pins 18 and 19 with external pull up resistors of 1.5k for the I2C in the same configuration I used to receive the data using the Teensy2.0 (running at 3V3). I will take a picture tonight to show. Unfortunately, I am trying to interface to a purchased device so I do not have control over that device. Through research I know that the device I am connecting to is AVR based and is acting as a Master on the I2C and transmitting data to all slaves on the bus. The program below is almost exactly what I have for the Teensy2.0, but for the 2.0 I am using the WSWire library, because it includes code to prevent the I2C lockup that can sometimes happen. Even without the lockup code, I would expect to get some of the data before the bus locks up, but I get zero calls to the receiveEvent routine.

Here is the program I am using:



#include <Wire.h>

int ledPin = 13;//on TeensyLC
int mindex = 0;
int packetsRxed = 0;
unsigned long lastPacketRxedTime = 0L;
unsigned long now = 0L;
int buffer[32];
boolean dataAvailable = false;

//Define hardware serial port #1 on the TeensyLC as btModule
#define btModule Serial1


//////////////UTILITY/////////////////////////

boolean ledOn(){
return digitalRead(ledPin);
}

void toggleLED(){
digitalWrite(ledPin,!ledOn());
}


//////////////SETUP/////////////////////////

void setup()
{
//Serial.begin(19200); // start serial for output
btModule.begin(19200);

pinMode(ledPin, OUTPUT);
digitalWrite(ledPin,HIGH); //start LED as ON.

//Blink the LED 2 times and leave on...
//The LED starts as ON, so you get ON, OFF, ON, OFF, steady ON
for (int i=0; i <2 ; i++){
delay(250);
toggleLED(); //off
delay(250);
toggleLED(); //on
}

//Serial.println("Starting");

Wire.begin(0x00); // get general call
Wire.onReceive(receiveEvent); // register event
lastPacketRxedTime = millis();//initialize the led toggle timer
}


//////////////LOOP/////////////////////////
void loop()
{
delay(5);
now = millis();

//Blinking LED means data is being received, steady ON means no data
//has been received for awhile.
//
//Toggle the LED after 10 packets have been received OR
//more than 1 second has gone by and there is a new packet received. This keeps
//the LED blinking even if the data is coming in slowly...
if ((packetsRxed > 10) || (dataAvailable & ((now - lastPacketRxedTime) > 1000L))){
toggleLED();
packetsRxed = 0;
}

//if it has been 3 seconds since the last packet was received and there is
//not new data coming in and the LED is off,
//turn the led back on to show we are still alive
if (((now - lastPacketRxedTime) > 3000L) && !ledOn() && !dataAvailable){
toggleLED();
}

if (dataAvailable) {
dataAvailable = false;

//Serial.print(mindex);
//Serial.print(":");

//write it to the Bluetooth SPP (and Serial port for debugging)...
for (int i=0; i<mindex; i++){
btModule.write(buffer[i]);

//Serial.print(buffer[i],HEX);
//Serial.print(':');
}
//Serial.println("[EOM]");
}
}

//////////////EVENT/////////////////////////

// function that executes whenever data is received from master
// this function is registered as an event, see setup()
// Get the data and get out of this routine. Set a flag to
// transmit the data on the main loop.
//
void receiveEvent(int howMany){
if (howMany < 1) // Sanity-check
return;
if (howMany > 32) // Also insane number
return;

packetsRxed++;
int i = 0;
while(Wire.available())
buffer[i++] = Wire.read(); // receive bytes

//leave mindex alone for as long as possible...
mindex = i;
dataAvailable = true;
}

PaulStoffregen
04-30-2015, 11:53 AM
Is there any code available I could run on a Teensy 2.0, so when I connect it to a Teensy-LC running this code, I can reproduce the lockup?

Actually, before that... have you tried 1.23-beta1 yet?

https://forum.pjrc.com/threads/28499-Teensyduino-1-23-Beta-1-Available

Quite a bit of work was done to the Wire library to prevent lockups with using the Lidar Lite, which does all sorts of wrong I2C stuff. Maybe 1.23-beta1 will solve the problems you're seeing? It's easy to try.

mcsarge
04-30-2015, 12:14 PM
Is there any code available I could run on a Teensy 2.0, so when I connect it to a Teensy-LC running this code, I can reproduce the lockup?

Actually, before that... have you tried 1.23-beta1 yet?

https://forum.pjrc.com/threads/28499-Teensyduino-1-23-Beta-1-Available

Quite a bit of work was done to the Wire library to prevent lockups with using the Lidar Lite, which does all sorts of wrong I2C stuff. Maybe 1.23-beta1 will solve the problems you're seeing? It's easy to try.

I do not have the Beta, I will try it. Should I switch to the i2c_t3 library?

Matt

PaulStoffregen
04-30-2015, 01:29 PM
That'd be worth a try too.

If the lockups still happen with 1.23-beta1, please try to give me some way to reproduce the problem.

mcsarge
04-30-2015, 01:52 PM
That'd be worth a try too.

If the lockups still happen with 1.23-beta1, please try to give me some way to reproduce the problem.

I loaded up the new Beta, and there is no difference. I took a snapshot of the display of the o-scope, maybe that will help?

I will try to create a transmitter with the Teensy2.0 to see if I can make it repeatable for you, but that will take a day or so.

Matt4177

nox771
04-30-2015, 02:59 PM
I loaded up the new Beta, and there is no difference. I took a snapshot of the display of the o-scope, maybe that will help?

I will try to create a transmitter with the Teensy2.0 to see if I can make it repeatable for you, but that will take a day or so.

Matt4177

You are trying to setup a Slave device to respond to a General Call request? Is that right?

GC requires special settings (GCAEN set in I2Cx_C2). I don't think GC is supported in the current libraries. I've never tested it out anyway. It may be as simple as enabling that bit. If not you'll need to wait for someone to dig into the code and figure out how to support it (IIRC, GC has specific protocol format).

You can try enabling that bit in your setup code:

Wire.begin(0x??); // pick a "real" Slave address, not 0x00
I2C0_C2 |= I2C_C2_GCAEN; // set GC addr enable


See if you get anywhere with that.

mcsarge
04-30-2015, 04:20 PM
You are trying to setup a Slave device to respond to a General Call request? Is that right?

GC requires special settings (GCAEN set in I2Cx_C2). I don't think GC is supported in the current libraries. I've never tested it out anyway. It may be as simple as enabling that bit. If not you'll need to wait for someone to dig into the code and figure out how to support it (IIRC, GC has specific protocol format).

You can try enabling that bit in your setup code:

Wire.begin(0x??); // pick a "real" Slave address, not 0x00
I2C0_C2 |= I2C_C2_GCAEN; // set GC addr enable


See if you get anywhere with that.

Indeed, I am trying to receive data sent out as a general call on the bus.

I have looked over the code in the Wire library and the twi, and it appears that the AVR implementation will utilize an address of 0x0 as a general call. If I understand what you are saying, that not the case with the Cortex and it's implementation. I have looked over the code in the Teensy areas and I do not see a spot where that bit is set anywhere, so this may be the answer, but I have to wait to test until tonight.

Matt

PaulStoffregen
04-30-2015, 06:10 PM
Oh, I had no idea you were trying to use general call addressing! That probably doesn't work.

If you have any test code on the Teensy 2.0 side, I'll give it a try here and see if I can improve the code in the Teensy-LC side.

mcsarge
05-01-2015, 12:40 AM
Well,

I tried setting the GC bit in the register and that does not seem to work. Does anyone have the information sheet for doing IC2 on the MKL26Z64? I think that the library is just not letting the master know there is a slave on the bus interested in the data being sent.

Matt

nox771
05-01-2015, 05:05 AM
Well,

I tried setting the GC bit in the register and that does not seem to work. Does anyone have the information sheet for doing IC2 on the MKL26Z64? I think that the library is just not letting the master know there is a slave on the bus interested in the data being sent.

Matt

I just did a test, enabling the GCAEN bit in C2 made a Slave respond to address 0x00. I also verified that bit specifically enables 0x00 address even when A1 and RA are both non-zero.

Attached is example code (using i2c_t3 example sketches). The Master code is the provided example with target Slave address set to 0x00, and the Slave code is the provided Slave-range example with GCAEN bit set as noted above.

4179

If you load the sketches into two T3 (or LC) devices (external pullups required), and put a serial monitor on the Slave, then touching pin12 to GND on the Master device will send a burst of traffic to address 0x00, and the Slave will dump it's output to the monitor.

I get the following:

WRITE to Slave 0x0 at MemAddr: 0 Data: 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224
WRITE to Slave 0x0 at MemAddr: 32 Data: 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192
WRITE to Slave 0x0 at MemAddr: 64 Data: 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160
WRITE to Slave 0x0 at MemAddr: 96 Data: 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128
WRITE to Slave 0x0 at MemAddr: 128 Data: 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96
WRITE to Slave 0x0 at MemAddr: 160 Data: 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64
WRITE to Slave 0x0 at MemAddr: 192 Data: 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
WRITE to Slave 0x0 at MemAddr: 224 Data: 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
READ from Slave 0x0 at MemAddr: 0
READ from Slave 0x0 at MemAddr: 32
READ from Slave 0x0 at MemAddr: 64
READ from Slave 0x0 at MemAddr: 96
READ from Slave 0x0 at MemAddr: 128
READ from Slave 0x0 at MemAddr: 160
READ from Slave 0x0 at MemAddr: 192
READ from Slave 0x0 at MemAddr: 224


This appears to be working fine, perhaps there is something else wrong.

mcsarge
05-01-2015, 11:30 AM
Wow,

Thanks for this! After I made my post, I actually created a master that transmitted my data to the slave and I found, as you did, that setting the bit did work to receive the general call.

When I connect it to the real device, however, it still does not work. I beleive the real device must be behaving badly and locking up the slave. I say this because I have to use the WSWire library on the Teensy 2.0 to get it to receive correctly. The WSWire includes code to reset the slave when it appears that the device is locked in a state.

I will try to make the same mods to the Wire lib that Paul supplies for the TeensyLC and see if that works.

Also thanks for the example code using i2c_t3, I will switch to that first to make sure using that does not solve the problem.

Again, many thanks!

Matt

PaulStoffregen
05-01-2015, 11:53 AM
What is this real device that behaves badly? It's a commercial product which I could buy online somewhere?

mcsarge
05-01-2015, 02:17 PM
What is this real device that behaves badly? It's a commercial product which I could buy online somewhere?

It is the Spectra (http://hitecrcd.com/products/aircraft-radios-receivers-and-accessories/2.4ghz-aircraft-receivers-modules/spectra-2.4ghz-transmitter-module/product)module from Hitec. It is part of the 2.4 GHz RC Airplane radio control system that they sell. It is all AVR based, and involves a module that plugs into the back of an RC Radio and a receiver that sits in the aircraft. The "Receiver" is actually a transmitter too, transmitting telemetry back to the Spectra Module in your radio. The telemetry data include data bout the battery level and a bunch of data collected using additional sensors and things in the aircraft (if you purchase them). The Spectra module has a port that allows you to receive this telemetry data over I2C and that is what I am reading.

Here is a post I made about using the Teensy 2.0 and a Bluetooth SPP module to get at the data and send it on to my App running on an Android device, it includes some pictures too. http://mcsarge.blogspot.com/2015/04/spectra-module-to-bluetooth-link-for-rc.html

Matt

mcsarge
05-01-2015, 06:02 PM
Wow,

Thanks for this! After I made my post, I actually created a master that transmitted my data to the slave and I found, as you did, that setting the bit did work to receive the general call.

When I connect it to the real device, however, it still does not work. I beleive the real device must be behaving badly and locking up the slave. I say this because I have to use the WSWire library on the Teensy 2.0 to get it to receive correctly. The WSWire includes code to reset the slave when it appears that the device is locked in a state.

I will try to make the same mods to the Wire lib that Paul supplies for the TeensyLC and see if that works.

Also thanks for the example code using i2c_t3, I will switch to that first to make sure using that does not solve the problem.

Again, many thanks!

Matt

Well,

I looked at the code and it appears that the code for the Teensy does not use the twi code and that makes sense really. But I think it will take me some time to figure out where a similar lock up is happening in the TeensyLC code, if it is happening. I will post more if I am able to figure it out.

Matt

mcsarge
05-05-2015, 03:16 PM
All,

Is it possible that this library is not working because it does not handle "repeated starts"? I know that this is sometimes an issue. I can not seem to figure out why it is not working, and it looks like I will have to give up using the Teensy LC for this project, though it appears to be the best in price and performance.

Any additional help would be appreciated.

Matt

PaulStoffregen
05-05-2015, 04:21 PM
It does support repeated start.

nox771
05-05-2015, 04:27 PM
All,

Is it possible that this library is not working because it does not handle "repeated starts"? I know that this is sometimes an issue. I can not seem to figure out why it is not working, and it looks like I will have to give up using the Teensy LC for this project, though it appears to be the best in price and performance.

Any additional help would be appreciated.
Matt

There is not much to go on. Nobody has the device you are working with, so you'll need to post some I2C traffic.

mcsarge
05-05-2015, 07:03 PM
There is not much to go on. Nobody has the device you are working with, so you'll need to post some I2C traffic.

What is the best way to collect that traffic? I have a Bus Pirate, would that work?

Matt

nox771
05-05-2015, 07:57 PM
What is the best way to collect that traffic? I have a Bus Pirate, would that work?

Matt

Anything that can describe what's going on with the traffic. Scope shots, logic analyzer, bus pirate, all those should give some idea of the traffic. Specifically something showing traffic that is working correctly versus whatever the LC is doing (eg. does the part ACK the GC call, if so does the following traffic also get ACK'd). Logic analyzer is probably best if you have one. Bus pirate might obscure issues with timing or traffic it doesn't understand, not sure. Better than nothing though.

mcsarge
05-05-2015, 08:22 PM
Anything that can describe what's going on with the traffic. Scope shots, logic analyzer, bus pirate, all those should give some idea of the traffic. Specifically something showing traffic that is working correctly versus whatever the LC is doing (eg. does the part ACK the GC call, if so does the following traffic also get ACK'd). Logic analyzer is probably best if you have one. Bus pirate might obscure issues with timing or traffic it doesn't understand, not sure. Better than nothing though.

I have the Diligent O'Scope and Logic Analyzer so I will fire that up and see if I can get a copy of what happens when working correctly and not so correctly. I can say that when the LC is hooked up I can see the master sending out the GC, and the LC looks like it is responding, but then nothing happens after that.

I will get a o'scope display of it running correctly later tonight and will try to get a logic analyzer working on it too.

4218

mcsarge
05-06-2015, 03:46 AM
OK, I have some pictures:

Simple setup: Teensy 2.0 with 1.5K external pull up resistors on pin D0 and D1 with those connected to the device. Successfully reading data sent by the master:
4222

Similar setup with the external pull ups on pins 18 and 19 of the TeensyLC; Not reading data (I also tried 5.1K pullups and got the same results):
4223

This setup is using the Teensy 2.0 as a master, sending out simulated data to the Teensy LC, same pull up resistors:
4224

Here is the data that the Teensy 2.0 is receiving: First number is length, then each byte is printed with a ":" between and an [EOM] for end of message.


21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]

mcsarge
05-06-2015, 04:14 AM
I was also able to get the Logic Analyzer working for the data coming to the Teensy 2.0. Here is a shot of that screen when receiving a packet.

4225

nox771
05-06-2015, 05:39 AM
Similar setup with the external pull ups on pins 18 and 19 of the TeensyLC; Not reading data (I also tried 5.1K pullups and got the same results):
4223


On plot2 I noticed a couple things. Assuming the Master is trying to drive identical signals as that in plot1, the LC appears to be slightly stretching the clock (plot1 byte transfer is ~58us, versus ~74us on plot2). That in itself is a little curious, but the Master seems to handle it.

But my guess is that somehow the Master device is thinking it lost arbitration. The reason I'm thinking this is due to how it terminates the signal in plot2. Even though an ACK bit is given by the LC, both SDA and SCL just jump high in a somewhat uncoordinated manner. This might be it trying to release the bus to the other apparent Master. It is certainly not a STOP signal as would be the case with a NAK.

It might be the large pulse between clocks 8 and 9 which is not evident in plot1. Maybe it doesn't like the SDA handover to the Slave. I don't see any apparent problem with the signaling, it appears to follow spec, but maybe the glitch is large and fast enough to cause some unseen problem.

An idea might be to try and suppress the glitch between clocks 8 and 9 by slowing the SDA line down. Maybe try a slower pullup on SDA only. Say 10k or 15k on SDA and 1.5k on SCL. Just a guess.

-------------
The clocks are somewhat odd, plot 1 looks closer to 200kHz, and plots 2/3 look closer to 100kHz. It's not clock stretching (typically only on 9th clock). I'm not sure why the Master would have inconsistent SCL.

mcsarge
05-06-2015, 04:15 PM
On plot2 I noticed a couple things. Assuming the Master is trying to drive identical signals as that in plot1, the LC appears to be slightly stretching the clock (plot1 byte transfer is ~58us, versus ~74us on plot2). That in itself is a little curious, but the Master seems to handle it.

But my guess is that somehow the Master device is thinking it lost arbitration. The reason I'm thinking this is due to how it terminates the signal in plot2. Even though an ACK bit is given by the LC, both SDA and SCL just jump high in a somewhat uncoordinated manner. This might be it trying to release the bus to the other apparent Master. It is certainly not a STOP signal as would be the case with a NAK.

It might be the large pulse between clocks 8 and 9 which is not evident in plot1. Maybe it doesn't like the SDA handover to the Slave. I don't see any apparent problem with the signaling, it appears to follow spec, but maybe the glitch is large and fast enough to cause some unseen problem.

An idea might be to try and suppress the glitch between clocks 8 and 9 by slowing the SDA line down. Maybe try a slower pullup on SDA only. Say 10k or 15k on SDA and 1.5k on SCL. Just a guess.

-------------
The clocks are somewhat odd, plot 1 looks closer to 200kHz, and plots 2/3 look closer to 100kHz. It's not clock stretching (typically only on 9th clock). I'm not sure why the Master would have inconsistent SCL.

When I look at picture 1 and 2, I see that in pic 1 there are 9 SCK pulses before the SDA goes high, in pic 2, there are 8 pulses before it goes high. Is there some kind of 7bit addressing thing going on that the master is not using or something?

Matt

mcsarge
05-06-2015, 04:20 PM
Here are the picture labeled:

Teensy 2.0 (Successful)
4227

Teensy LC (Unsuccessful)
4228

nox771
05-06-2015, 10:17 PM
It depends on the Master/Slave SDA timing. The SDA direction changes twice, once before the 9th clock (as in plot2, it is so Slave can ACK), and once after (as in plot3, so Master resumes control). In either of those places a glitch can happen on SDA, it is very common. It is not a bug, per spec SDA can change as much as it wants when the SCL is low. Why the Master device doesn't like it isn't clear.

mcsarge
05-07-2015, 02:07 AM
It depends on the Master/Slave SDA timing. The SDA direction changes twice, once before the 9th clock (as in plot2, it is so Slave can ACK), and once after (as in plot3, so Master resumes control). In either of those places a glitch can happen on SDA, it is very common. It is not a bug, per spec SDA can change as much as it wants when the SCL is low. Why the Master device doesn't like it isn't clear.

OK, I will try with the large resistor on SDA as you suggest, but I probably can not do it until Sunday night. Going to see my daughter get her graduate degree from Clemson on Friday! Thanks very much for all the help, I really appreciate it!

Matt

mcsarge
05-07-2015, 02:39 AM
OK, I will try with the large resistor on SDA as you suggest, but I probably can not do it until Sunday night. Going to see my daughter get her graduate degree from Clemson on Friday! Thanks very much for all the help, I really appreciate it!

Matt

I have it working!

I tried the larger 10K resistor and that did not seem to change anything. I figured I would try the i2c_t3 library and after I converted my code to use that, it started working!

Thanks again for all the help across the board, I do not think I would have stuck with it if it wasn't for nox771 and Paul, many thanks!

Matt

Here is the trace of it receiving the data.
4232

cheshire
05-08-2015, 06:26 AM
Hey all,
I've done a quick search over the thread, but was unable to find any info:
Can the Teensy-LC do the HID Joy/Mouse/KB emulation like it's older siblings?

And now for a suggestion: When you do these things, you might want to do an update to let all your kickstarters from previous projects know you are doing something new and cool! I managed to miss both the 3.1 AND this for ages simply because I didn't think to check :-)

(I use my Teensy 3.0 as a 15 Pin Joystick emulator for an old pair of CH Flight foot pedals. Currently expanding it to do whole buch of custom keystrokes to aid in playing OOLITE)

John "Cheshire" Parker

PaulStoffregen
05-08-2015, 02:27 PM
Can the Teensy-LC do the HID Joy/Mouse/KB emulation like it's older siblings?


Yes, it can do all the same USB features as Teensy 3.0 & 3.1.



And now for a suggestion: When you do these things, you might want to do an update to let all your kickstarters from previous projects know you are doing something new and cool!


Yeah, that's a good point. I really haven't looked at Kickstarter over the last year or two.

cheshire
05-09-2015, 03:26 AM
Yes, it can do all the same USB features as Teensy 3.0 & 3.1.



Yeah, that's a good point. I really haven't looked at Kickstarter over the last year or two.


W00t! That's excellent! (I figured they would)

Bwahaha! Those are cheap enough I can use them as "disposable" for some of my projects.

Next payday I'll have to place an order.

neilh20
08-03-2015, 08:05 PM
Hi
I need to be able to define an accurate Reference voltage for an LC, I'm still working out if its 2.5V or it could be 1.0V - whats the recommended way of doing it.
I've done a search on this thread for using the AREF pin, and I couldn't find anything/
https://forum.pjrc.com/threads/28380-DC-signal-generator-using-the-DAC

Looking at a 3.1 posting it suggested connecting a LM336 to Aref with enough current to over-ride the internal 480ohm R connecting to VDD - does that still hold?
thanks

PaulStoffregen
08-04-2015, 01:05 PM
Teensy-LC doesn't have the 470 ohm resistor, so you'd need both a LM336 and a resistor.

neilh20
08-04-2015, 02:32 PM
Hello Paul
Thanks for the quick response. Can you explain or give a diagram of how the KL26Z VREFH is connected to the AREF pin. Its likely to be about 2.4V. Thanks.
I'm promoting the TeensyLC in specific-conductance probe, which for the analog front-end measurements requires good analog stability and traceability to a temperature stabilized voltage reference.
https://makerspace.com/u/neilh20/projects/specific-conductance-probe

PaulStoffregen
08-04-2015, 02:38 PM
Thanks for the quick response. Can you explain or give a diagram of how the KL26Z VREFH is connected to the AREF pin.

The schematic?

http://www.pjrc.com/teensy/schematic_lc.gif

neilh20
08-04-2015, 03:27 PM
Ok many thanks. That makes it simple to connect to VREFH. :)

ghjmaui
10-13-2015, 08:52 PM
Hello Paul-
Brand new here, and still trying to grasp all the capabilities of the different versions. You have an excellent table for the Teensy LC in this thread, but nothing comparable for 3.1 and 3.2. I can extract most of it from the "3.2 & 3.1 New Features" technical specs, but nothing about INTs and Output sourcing current for the different pins. It took me a while to infer that any pins on the 3.1 and 3.2 can be interrupt enabled by reading posts, but nothing documented. If there are tables out there that I haven't found, please hold my hand and guide me. Thanks.

MichaelMeissner
10-13-2015, 09:07 PM
Ghjmaui: I put together this table for my own uses that tries to list the various differences between the 4 ARM Teensys (I also have the pinouts of various other processors as separate sheets in the document): https://docs.google.com/spreadsheets/d/1LSi0c17iqtvpKuNSYksMG306_FpWdJcniSRR6aGNNYQ/edit?usp=sharing

PaulStoffregen
10-14-2015, 09:51 AM
Yes, there's a tremendous number of details which add up to a ton of information to communicate.

When we add a high-end Teensy++ 3.x, I'll probably make a big table comparing all the options. But it's difficult to make a huge table that shows everything and is still easy to read and understand at a quick glance.

wb8nbs
12-24-2015, 09:49 PM
Is there any way to add an external reset button to an LC? Pressing the program button hangs the sketch, is that normal? I'm resorting to power cycling the board which seems crude.

PaulStoffregen
12-24-2015, 09:58 PM
The button on Teensy LC (and all Teensy boards) is for entering programming mode. It's *not* a reset button for restarting your program!

xxxajk
12-25-2015, 02:24 AM
*YOU* can add a reset button. There should be a pad on the bottom. Just have your switch connected to it and GND. GND resets it.

MichaelMeissner
12-25-2015, 02:48 AM
*YOU* can add a reset button. There should be a pad on the bottom. Just have your switch connected to it and GND. GND resets it.

The LC does not have a pad on the bottom for reset. Only the 3.1 and 3.2 have such a pad (and it is in a different location between the two). The only pads underneath the LC are the D-/D+ for USB, and the VUSB/VIN connection pad.

xxxajk
12-25-2015, 03:05 AM
Unless you hack it, yes, this is true.

mcsarge
01-04-2016, 04:15 PM
Maybe this was covered, but I can not seem to find the correct information.

I would like to use the Adafruit Trinket LiPo Back pack on my LC. It has a 3 connections - GND, Bat and Vin. It automatically switches from battery power to USB power when the USB on the trinket is plugged in. Would it be possible to do the same with the LC? I see that we have the 5V from the USB available, would connecting the other two pins to ground and Vin work?

I guess the real question is can I power the LC from a 3.7V batter using the Vin pin? It reads 3.7-5.5V, while the Vbat pin on the Teensy allows 3.3-16V.

MichaelMeissner
01-04-2016, 04:28 PM
The Adafruit Trinket Pro LiPo backpack won't fit directly on the LC, you would have to wire the 3 pins and place the backpack elsewhere. You would have to cut the trace between VIN and VUSB like you would have to for the 3.0/3.1/3.2 (https://forum.pjrc.com/threads/19228-confused-again-Cutting-VIN-from-VUSB-Teensy-3-0?p=44024#post44024).

If you haven't bought the backpack, you might want to look into onehorse's custom board for the 3.0/3.1/3.2/LC. He has two boards, the original one would change smaller batteries, and his newer board charges larger batteries:

New: https://www.tindie.com/products/onehorse/stbc08-high-current-lipo-battery-charger/ (charges batteries at 300mAh, 500mAh, or 800mAh);
Original: https://www.tindie.com/products/onehorse/lipo-battery-charger-add-on-for-teensy-31/ (charges batteries at 100mAh).

mcsarge
01-04-2016, 06:12 PM
Beautiful,

Thanks, I have not yet ordered the backpack, but onehorse's boards may be the answer.

One followup - if I power the LC from a 3.7V battery connected to Vin and do not pug a USB in, should it startup and run correctly? I know if I want to have the USB and the batter in at the same time, I need to cut the trace. Then if I need to reprogram the LC, I need to keep the battery plugged in while I connect the USB.

Matt

onehorse
01-04-2016, 06:26 PM
You can power the Teensy from a 3.7 LiPo battery. With the LiPo battery charger soldered to the Teensy, even without the battery, the Teensy can be programmed from just the USB cable since the USB provides power to the charger chip, which supplies 4.2 V to Vin even in the absence of a battery. You'll get at most 100 mA this way but enough to program the Teensy.

mcsarge
01-04-2016, 07:00 PM
Beauty - I am thinking of just using a battery connected to my board directly for now, which a user would have to unplug and charge separately, but adding the option of getting one of your boards to have a simple charge system all included.

MajorTom
01-21-2016, 06:36 PM
Is the Teensy LC compatible with the Teensy "Audio Adaptor Board" (http://www.pjrc.com/store/teensy3_audio.html) ?

Pensive
01-21-2016, 07:00 PM
No it isn't - sorry. That may change but right now - no.

MajorTom
01-21-2016, 07:12 PM
wow, thanks for the fast answer. Can I make it compatible, or is this an absolutely no :)