Coming Soon: Teensy-LC (low cost Teensy)

Status
Not open for further replies.
Looks good! Might want to include link to the datasheet for it or maybe on your main datasheets page.

Assuming the links on the first page of this thread is correct including: http://cache.freescale.com/files/microcontrollers/doc/ref_manual/KL26P121M48SF4RM.pdf?fasp=1
I believe the UARTs still support half duplex (1 wire mode). I use this when talking to the Dynamixel Servos at 1mbs. That is one of things I want to try out once I get my hands on one of these.

Kurt
 
Oh, and if you're adding links... A link to the forum would be good. People sometimes don't realize what an amazing resource the forum is.
 
I've contacted everyone who has sent me their shipping information. If you are on the first round of beta testers and have not heard from me, please email me directly robin at pjrc dot com

First Round Testers
duff
embedded-creations
Frank B
kriegsman
manitou
onehorse
potatotron
Pensive
MuShoo
syso2342
 
Eight of the ten beta boards shipped out today. They should be delivered before the end of the week. :)

Thanks to everyone who said they wanted to help test and have time to test now.

There are 2 people who have not heard from and I don't have a shipping address for. If I don't hear anything by Wednesday afternoon we will ship them to other people. We really want to move forward with testing!
 
LC manual suggests SPI0 runs at bus clock(24mhz) and SPI1 runs at system clock(48mhz). So does that mean SPI1 can run twice as fast as SPI0. the LC SPI library uses SPI0 (F_BUS).
 
I received my Tracking Code from Robin yesterday. I will let you know when it arrives and then I will give it a testimonial :)
 
I'm sorry not to be helping with first-round testing. I'm literally heading to the other side of the world tomorrow for two weeks.
 
Fantastic Spreadsheet
BTW though Note 6) You say no RTC - the silicon does implement an RTC, however it requires an external clock oscillator to drive RTC_CLKIN/PTC1 - but can't figure out if PTC1 comes out on the Teensy-LC.
 
Thanks neilh20. I'll wait for Paul to chime in on whether the RTC is available (but you would need to provide the crystal, and of course it isn't powered).

Right now, I don't have a column for the interrupt numbers. This morning, I split i2c, spi, serial, can, i2s into separate columns. I don't know what I'll do when the big boy (Teensy 3.1++ or Teensy 4) comes out.
 
See this message regarding my thoughts on the RTC. I feel pretty strongly about promoting realistic expectations. I know pretty much everyone else markets hardware with a lot of hype about every feature, even when there's hidden gotchas. I don't like that.

PTC1 is pin 22, if you really want to give the on-chip RTC a try. A schematic will be posted shortly after the official release, just like all the other Teensy boards. The pinout info can also be found in core_pins.h.

But even if you get the RTC counting time with an external clock, what's going to happen when you lose power?
 
I totally agree, the lack of a VBAT pin makes the Teensy-LC RTC option a lot less attractive as far as keeping absolute time is concerned. However, there are datalogger applications where the absolute time is not as important as logging on a precise interval. With temperature-compensation, you may be able to get sub 5PPM performance out of what I presume would be a oscillator, not a crystal, right? Or, apply a appallingly small RTC and do it all over I2C.

Given the high quality/stability of the crystals that ship with the Teensy MCUs I wonder if an external RTC crystal/oscillator is necessarily needed to allow precise intervals. Can one compensate the 'system clock' the way that the RTC clock registers can be manipulated?
 
Last edited:
In addition to my zoo of motion sensors, Adafruit's displays, nRF24L01+ SPI radio, and nRF8001 bluetooth, I plan to include the M41T62 RTC + environmental sensor in my simple-minded testing.
 
Well if you add a DS3231 real time clock, you also get some i2c storage space, which should help if you use EEprom. Of course it pushes the cost closer to the $19.80 of the Teensy 3.1. Of course you do have to add in the 32.768kHz crystal in the Teensy. 3.1 case, but that is fairly cheap. The only things that come to mind why you might prefer a Teensy LC + RTC over Teensy 3.1 might be the 2nd SPI port, 2nd i2c port accessible without soldering the bottom pads, or the back pin that delivers VIN voltage when A3 is written to.

FWIW, I happened to order a DS3231 RTC today for $4.68 (to replace a RTC for a raspberry pi I seemed to have burned out), which would bring the combined price to 16.33.
 
Last edited:
PAUL!!!

Holy crap do I WANT this board!

I have been looking for a cheap Arduino "like" board. The Teensy 3.1 is awesome, but for $12 HOLY CRAP!

I really wanted a cheap, small device for lighting control and 3d printer filament maker control. Wow!

When can I buy this?!
 
Well if you add a DS3231 real time clock, you also get some i2c storage space

The DS1307 and DS3231 are fine RTC solutions for the $5 you might pay on Amazon, but a bit too big for my taste. I made the I2C M41T62 RTC board so small it can ride piggy back on the Teensy (3.x or LC) such that you might not even know it's there. Plus it has a pressure sensor and supercap power backup as well as the 64 kByte or 256 kByte of EEPROM for logging, just like the EEPROM usually added to the DS3231 boards. The M41T62 RTC board is more expensive, but it is more capable and pleasantly, appallingly small.
 
onehorse, what do think about making some spi-flash & spi-(f)ram boards ? escpecially the ram could be interesting for the LC
+ LC has 2x SPI
 
making some spi-flash & spi-(f)ram board

Yes, I have looked at this. ST makes a 256 kByte SPI EEPROM similar to the 256 kByte I2C EEPROM I have already been using. It would be relatively easy to make a small board with 512 kByte of EEPROM that uses an SPI interface (I like the simplicity and robustness of EEPROM). Sort of the analog of this board. But it would likely be a little wider since the SPI port near the non-USB end of the Teensy 3.x/LC is 3 pins wide. Is 512 kByte enough to interest many people? Do you have another memory chip that you would prefer that would fit on an equally small board?

Just took a look at FRAM, it is max 2 Mbit just like ST's EEPROM but about four times as expensive!

But this looks interesting!
 
Last edited:
Hi All

I have worked with the KL26 on the Freescale FRDM-KL26Z boards so prepared a project for the Teensy LC for when the HW is available.

Some notes:
1. Would it not be better to use a KL26Z128 on the board since the 64k Flash and 8k Ram are quite tight; I needed to skimp on RAM to use USB CDC and 3 UARTs by allocating much reduced buffer space to normal. 16k is quite comfortable but 8k may be below the cut-off threshold for some work. The part with double the memory is otherwise identical and costs 30c more (if the quantities are high).
2. I see much discussion about the RTC. I never really understood the RTC in the KL parts because it really needs a low power 32kHz oscillator in combination with the very low power modes to be a real RTC. The following discusses the KL RTC in some more general details: http://www.utasker.com/kinetis/KL_RTC.html
3. I don't find a circuit diagram so quessed at some pinouts for the moment.
4. This is what I based the configuration on : http://www.utasker.com/kinetis/FRDM-KL26Z.html, mixed with http://www.utasker.com/kinetis/TEENSY_3.1.html so it supports Tx DMA on the UARTs and the low leakage modes (see also http://www.utasker.com/kinetis/LLWU.html)
5. The Teensy LC stuff has been prepared here: http://www.utasker.com/kinetis/TEENSY_LC.html
The (provisonal) binaries may work but most probably need at least some pin configuration changes. The code has been proven on the KL26 (on Freescale Freedom and Tower boards) and simulated on the Teensy LC board/processor type.
I'll tweek once the ciruit diagram is published and test once production starts.

Regards

Mark

http://www.utasker.com/index.html
 
Hi

I have attached memcpy code from the uTasker project below (there is also memset which is very similar) which is suitable for the KL26.
It can be used generally since it will work out the alignment of input and output buffer and optimised 32 bit copies where possible. This means that it doesn't have to be used only specially for 32 bit copies but can be use instead of the library routine.

Beware that you should add protection in your code for the following case - if an interrupt arrives which calls the the routine while the whie() is in progress it will cause the DMA operation to fail and the code to hang (crash). In the uTasker code this is accomplished by checking the DMA_DCR content and falling back to general memcpy() loop code if needed.

Note that there is also a define for the DMA channel used since there are only 4 in the KL26 and these will be moved around between various peripherals etc. DMA_MEMCPY_CHANNEL defines which one is used for the library operations.

Finally note that the memset() library routines from some compile chains (eg. IAR) will easily out-perform a DMA based solution (they load a group of registers with the the value to be written and use a Cortex instruction that writes the group to memory over and over again - this is about 3x faster!!

Regards

Mark

http://www.utasker.com/kinetis.html

Code:
extern void *memcpy(void *ptrTo, const void *ptrFrom, size_t Size)
{
    register unsigned char *ptr = (unsigned char *)ptrTo;
    register unsigned char *buffer = (unsigned char *)ptrFrom;

    if (Size >= SMALLEST_DMA_COPY) {                                     // if large enough to be worthwhile 
        KINETIS_DMA *ptrDMA = (KINETIS_DMA *)DMA_BLOCK;
        ptrDMA += DMA_MEMCPY_CHANNEL;
        if (ptrDMA->DMA_DCR == 0) {                                      // if not already in use
            unsigned long ulTransfer;
            while (((unsigned long)buffer) & 0x3) {                      // move to a long word boundary for source
                *ptr++ = *buffer++;
                Size--;
            }
            ptrDMA->DMA_DSR_BCR = DMA_DSR_BCR_DONE;                      // clear the DONE flag and clear errors etc.
            if (((unsigned long)ptr & 0x3) != 0) {                       // if the destination is not also long word aligned
                if ((unsigned long)ptr & 0x1) {                          // not short word aligned
                    ulTransfer = Size;
                    ptrDMA->DMA_DCR = (DMA_DCR_DINC | DMA_DCR_SINC | DMA_DCR_D_REQ | DMA_DCR_DSIZE_8 | DMA_DCR_SSIZE_8 | DMA_DCR_DMOD_OFF | DMA_DCR_SMOD_OFF); // set mode and protect from interrupts that could use the function in the process
                }
                else {
                    ulTransfer = (Size & ~0x1);                          // ensure length is suitable for short words
                    ptrDMA->DMA_DCR = (DMA_DCR_DINC | DMA_DCR_SINC | DMA_DCR_D_REQ | DMA_DCR_DSIZE_16 | DMA_DCR_SSIZE_16 | DMA_DCR_DMOD_OFF | DMA_DCR_SMOD_OFF); // set mode and protect from interrupts that could use the function in the process
                }
            }
            else {
                ptrDMA->DMA_DCR = (DMA_DCR_DINC | DMA_DCR_SINC | DMA_DCR_D_REQ | DMA_DCR_DSIZE_32 | DMA_DCR_SSIZE_32 | DMA_DCR_DMOD_OFF | DMA_DCR_SMOD_OFF); // set mode and protect from interrupts that could use the function in the process
                ulTransfer = (Size & ~0x3);                              // ensure length is suitable for long words
            }
            ptrDMA->DMA_SAR = (unsigned long)buffer;                     // set address of sourse
            ptrDMA->DMA_DAR = (unsigned long)ptr;                        // set address of destination
            ptrDMA->DMA_DSR_BCR = (ulTransfer & DMA_DSR_BCR_BCR_MASK);   // set transfer count (don't set DMA_DSR_BCR_DONE at the same time otherwise BCR is reset)
            ptrDMA->DMA_DCR |= (DMA_DCR_START);                          // start DMA transfer
            ptr += ulTransfer;                                           // move the destination pointer to beyond the transfer
            buffer += ulTransfer;                                        // move the source pointer to beyond the transfer
            Size -= ulTransfer;                                          // bytes remaining

            while ((ptrDMA->DMA_DSR_BCR & DMA_DSR_BCR_DONE) == 0) {} // wait until completed

            while (Size--) {                                             // complete any remaining bytes
                *ptr++ = *buffer++;
            }

            ptrDMA->DMA_DCR = 0;                                         // free the DMA channel for further use
            return ptrTo;                                                // return pointer to original buffer according to memcpy() declaration
        }
    }
    // Normal memcpy() solution
    //
    while (Size--) {
        *ptr++ = *buffer++;                                              // copy from input buffer to output buffer
    }
    return ptrTo;                                                        // return pointer to original buffer according to memcpy() declaration
}
 
I've done a small amount of tinkering with the KL26 series, and I'm very curious about the Teensy LC. I'm mainly wondering if the other chip, which I presume is a Nuvoton ARM of some kind, is powered off of the KL26's internal regulator? That would really impact the lowest possible sleep current you could achieve for the whole board. The L series chips are pretty well regarded as being very good for lower power designs so it will be interesting to see how the LC performs overall.
 
1. Would it not be better to use a KL26Z128 on the board since the 64k Flash and 8k Ram are quite tight;

Choices and trade-offs had to be made to keep the cost low. If the bigger chip had been only pennies more, I would have used it. The chip and all other hardware stuff is fixed and will not be changed.

Right now, Teensyduino is burning about 10K flash and 2K ram, based on code that was designed for Teensy 3.0 & 3.1. I'm pretty sure I'll manage to cut that roughly in half by release next month.
 
Status
Not open for further replies.
Back
Top