Coming Soon: Teensy-LC (low cost Teensy)

Status
Not open for further replies.
As i understand - there are no SMT Pads on the bottom at all.
This means a breakout for the USB which works for the 3.1 with spring loaded connectors / pogo pins won't work for the Teensy-LC?

Adding a 5$ adapter to have proper usb is not the nicest option to integrate the teensy in projects which require a solid USB connection.

And what about the separation of VIN and USB Power, is this Option also missing?

THX, J
 
Paul said:
As a special thanks to very active forum contributors and library authors, we're making an early, hand-soldered pre-production run. PJRC will send free Teensy-LC prototypes to these people: ..., Experimentalist, ...
Click to expand...

Hi Paul,

Thank you, that's great.

Happy to wait for a green board and will be glad to help.

looking forward to testing with it

Ex.
 
PaulStoffregen said:
I briefly tried the temp sensor while porting the analogRead() code. I got only zeros and I didn't invest more time into why.

This certainly is something I hope can get worked out next week, when people start getting the boards. But it's also possible the temperature sensor might not actually be supported in this chip?
Click to expand...

So looking at your current version of analog.c, it appears you are not mapping the temp sensor. I was also wondering about adding analogRead(41) for the bandgap ADC channel on all 3 teensy's....

__MKL26Z64__
KINETISL
 
Last edited:
Good news. We got a 10th purple board built, and all 10 passed testing, so a total of 10 will ship on Monday.

I just read this thread, and a few emails. I found 7 definitive requests for the first purple boards:

duff
embedded-creations
Frank B
kriegsman
manitou
onehorse
potatotron

If anyone else *really* wants a purple board for early beta testing, and definitely has time available starting next week, please speak up now. Please, do not worry about shipping costs. If you really do have time and strong interest for beta testing next week, I want to get one of these purple boards into your hands ASAP.

I found 3 more messages indicating available time to test, but perhaps a preference to let the purple boards go to others.

Pensive
MuShoo
syso2342

If I've missed anyone, please speak up now!!

The green pre-production boards should start shipping in a couple weeks (all them hand-soldered by Erin and/or me). Everyone listed on the original post will get either a purple or green board, regardless of beta testing.

Robin will be handling all the shipping details, so I can stay focused on the technical side. If you have a question or concern about shipping, please email Robin directly (robin at pjrc dot com).
 
I've sent messages to the first 7 people on the list asking for shipping info. You can also email me directly - robin at pjrc

Do not worry about the shipping cost, even if you are outside the US. This testing is very important to us and the cost of shipping is well worth it to get these boards to users who are willing to put some effort in to testing this board and giving good feedback.
 
Paul,
do you have a LC TODO list? what is working? what you're working on? what needs to be done? triage?

I think FreqMeasure might need some TLC ... if you don't get to it, I'll poke at it.
FreqCount might be good to go.
 
Last edited:
I'll put some time in Paul, I'll email by details through. Thanks

Jon

edit:mail sent
 
Last edited:
I ordered this with 12 pots:

https://learn.adafruit.com/untztrument-trellis-midi-instrument

Should be here before the end of the week. Reckon it's 1 evening to build and 2 or 3 evenings to code. This should test i2c, all but one analogue, usb_midi, and i'll probably sink a few leds and buttons in and around it to fill up the remainder of the pins.

Teensy-LC will be up to this task easily I'm sure.....excited!! :)
 
Re purple boards

Have plenty of time to test but as per the others unsure of the value of my contribution and on the wrong end of a shipping delay. Unless targeted elsewhere would be working through my assorted display and sensor breakouts verifying no surprises. Also interested in how the power consumption measures up for a potential soil monitoring setup.

GW
 
Re: teensy LC DMA

Here is an untested snippet at using TLC DMA to do memcpy(). The registers aren't yet defined in kinetis.h.

Code: 
#define DMA_SAR0		(*(volatile const void * volatile *)0x40008100)
#define DMA_DAR0		(*(volatile  void * volatile  *)0x40008104)
#define DMA_DSR_BCR0		(*(volatile uint32_t *)0x40008108)
#define DMA_DCR0		(*(volatile uint32_t *)0x4000810C)


#define DMA_DCR_SSIZE(n)       (((n) & 0x3) << 20)
#define DMA_DCR_DSIZE(n)       (((n) & 0x3) << 17)
#define DMA_DCR_START     0x00010000
#define DMA_DCR_SINC     ((uint32_t)1<<22)
#define DMA_DCR_DINC     ((uint32_t)1<<19)
#define DMA_DSR_BCR_DONE     0x01000000
#define DMA_DSR_BCR_BSY      0x02000000


void memcpy32(int *dest, const int *src, unsigned int count)
{
        DMA_SAR0 = src;
        DMA_DAR0 = dest;
        DMA_DSR_BCR0 = count * 4;   // bytes
        DMA_DCR0 = DMA_DCR_SINC | DMA_DCR_DINC | DMA_DCR_START;
        while (!(DMA_DSR_BCR0 & DMA_DSR_BCR_DONE)) /* wait */ ;
}

void memset32(int *dest, int val, unsigned int count)
{
        DMA_SAR0 = &val;
        DMA_DAR0 = dest;
        DMA_DSR_BCR0 = count * 4;   // bytes
        DMA_DCR0 =  DMA_DCR_DINC | DMA_DCR_START;
        while (!(DMA_DSR_BCR0 & DMA_DSR_BCR_DONE)) /* wait */ ;
}

This is based on teensy 3 sketch defined at
https://github.com/manitou48/teensy3/blob/master/mem2mem.pde
and discussed in the thread:
https://forum.pjrc.com/threads/18237-teensy-3-0-memory-to-memory-DMA-help
where there was speed up on teensy 3.0 but not(?) on teensy 3.1

will test on LC "real soon now"

freescale readings: DMA on KINETIS L series
http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4631.pdf
 
Last edited:
manitou said:
do you have a LC TODO list? what is working? what you're working on? what needs to be done? triage?
Click to expand...

Yes, I do. It's been changing pretty rapidly as I test stuff and fix bugs, and also as I find more stuff to test.

I'll post it on a thread dedicated to the beta testing, on Monday or Tuesday morning.
 
I just came up with an addition for our large (medical simulation) project that would be nice to use the LC version for (since it needs to connect to the other teensies using i2c but also with an extender chip that uses i2c as well (and I want to make it very modular) so using a through hole teensy module with two i2c ports would be very convenient as the 3.1 uses the SMD pads for the second i2c port of course!
 
Yes, the top 2K of flash is reserved for EEPROM emulation.

I've edited the original post. Michael, maybe the spreadsheet should mention 62K flash?
 
MichaelMeissner said:
Spreadsheet updated (62K program flash, 2K EEPROM).
Click to expand...

It's actually only 128 bytes of emulated EEPROM.

EEPROM emulation uses wear leveling over a bigger chunk of lower endurance, block-erase Flash to emulate a much smaller amount of higher endurance, byte-erase EEPROM. The amount of flash memory consumed by the emulation is 2K, resulting in 128 bytes of emulated EEPROM.
 
On Teensy 3.1, the 2K of EEPROM is also emulated, but the wear leveling and emulation algorithms are all implemented in hardware. That hardware includes a dedicated 2K block of RAM, and a dedicated 32K block of flash. Reads and writes complete in a single bus cycle, but after a write it becomes "busy" for some time while the hardware completes the wear leveling writing and management of the flash.

On Teensy-LC, none of that hardware exists, so I had to build it all in software. My software is much slower than the all-hardware approach! Because there's no dedicated flash block, code execution stalls for about 8 microseconds during the actual write operation. The whole flash memory on Teensy-LC is only twice the size of Teensy 3.1's dedicated flash for EEPROM emulation. The dedicated RAM section, which Freescale calls "FlexRAM", is 25% the size of Teensy-LC's entire memory.

When you think about it... the hardware in Teensy 3.1 is really pretty amazing!
 
Last edited:
Having just been for a poke through the EEPROM files is there a correct way to access the eeprom_write_word and eeprom_write_dword functions?

My thought would be adding entries EEPROM.CPP but checking if I missed a some other place they were being declared. I'm assuming real programers just go straight to the calls in cores/EEPROM but not quite sure if I'm up for that yet.
 
Hmmm, I had designed an EEPROM structure to hold various things between boots, and it is 88 bytes. When I set this up with the ATtiny85's 512 byte EEPROM structure, 88 bytes wasn't that bad. It will need to be trimmed somewhat. Now, I set this up sort of as the possible things I might want to preserve, but at present, the only thing I depend on is a random number seed.

Given how expensive it is to write to EEPROM, I wish the EEPROM libraries had an interface to read/byte a chunk of bytes, rather than byte at a time.

Yep, the 3.1 hardware is amazing. I must admit, to $8 difference may sway me to use Teensy 3.1's instead of the LC, given the unaligned storage issues and small/expensive EEPROM area.
 
Last edited:
Now, I haven't looked into the M0 (or arm at all), but it may make sense to have some sort of trap handler to catch segfaults on unaligned read/writes. The trouble is what to do in a trap handler? Perhaps call a user specified function so the user can appropriately flash LED 13, write to the USB serial line, etc.
 
MichaelMeissner said:
it may make sense to have some sort of trap handler to catch segfaults on unaligned read/writes. The trouble is what to do in a trap handler?
Click to expand...

It's already in there. See fault_isr() in mk20dx128.c starting on line 53.

Actually sending the stack dump out Serial1 is disabled by default. If you want to see it, you'll need to edit the code to enable it.

Perhaps call a user specified function so the user can appropriately flash LED 13, write to the USB serial line, etc.
Click to expand...

Calling anything unknown while in fault mode is risky. Another fault while already in fault mode puts the CPU into a special "hard lockup" mode.

It's really desirable to keep running the USB polling while in fault mode, so you can easily upload new code from Arduino. Otherwise, you'd have to manually press the button on Teensy. Yeah, that's pretty horrible... but speaking from experience of porting and testing so much code, I really like not having to manually press the pushbutton!
 
Last edited:
Agreed, I've debugged enough compilers code on raw machines and occasionally brought code up to new machines (debugging user code with an OS debugger was 'interesting') that I know the challenges. I was just wondering out loud if we could do anything when a fault occurs.
 
Status
Not open for further replies.
Back
Top