Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 22 FirstFirst ... 3 4 5 6 7 15 ... LastLast
Results 101 to 125 of 550

Thread: Coming Soon: Teensy-LC (low cost Teensy)

  1. #101
    Junior Member
    Join Date
    Jan 2014
    Posts
    19
    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

  2. #102
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Paul View Post
    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, ...
    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.

  3. #103
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    Quote Originally Posted by PaulStoffregen View Post
    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?
    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 by manitou; 01-31-2015 at 12:33 PM.

  4. #104
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,589
    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).

  5. #105
    Administrator Robin's Avatar
    Join Date
    Oct 2012
    Location
    PJRC Global Headquarters
    Posts
    313
    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.

  6. #106
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    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 by manitou; 01-31-2015 at 06:16 PM.

  7. #107
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    562
    I'll put some time in Paul, I'll email by details through. Thanks

    Jon

    edit:mail sent
    Last edited by Pensive; 01-31-2015 at 07:39 PM.

  8. #108
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    562
    I ordered this with 12 pots:

    https://learn.adafruit.com/untztrume...idi-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!!

  9. #109
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,899
    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

  10. #110
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    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...er/mem2mem.pde
    and discussed in the thread:
    https://forum.pjrc.com/threads/18237...emory-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/mic...ote/AN4631.pdf
    Last edited by manitou; 02-03-2015 at 09:07 PM.

  11. #111
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,589
    Quote Originally Posted by manitou View Post
    do you have a LC TODO list? what is working? what you're working on? what needs to be done? triage?
    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.

  12. #112
    Senior Member
    Join Date
    May 2013
    Posts
    130
    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!

  13. #113
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269

    Cool Spreadsheet comparing 3.0, 3.1, and LC

    I just reworked my spreadsheet to compare the Teensy 3.0, 3.1, and LC micro-processors: https://docs.google.com/spreadsheets...gid=1103027528.

  14. #114
    Senior Member
    Join Date
    May 2013
    Posts
    130
    That is a handy spreadsheet indeed!

  15. #115
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,201
    Quote Originally Posted by MichaelMeissner View Post
    I just reworked my spreadsheet to compare the Teensy 3.0, 3.1, and LC micro-processors: https://docs.google.com/spreadsheets...gid=1103027528.
    looking at Paul's core github (eeprom.c), the LC appears to be configured for only 128 bytes of EEPROM.


    #define EEPROM_SIZE 128


    i think it uses the tail end of flash.

  16. #116
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    Ok, I hadn't noticed the EEPROM size is different. Thanks.

  17. #117
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    338
    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?

  18. #118
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    Spreadsheet updated (62K program flash, 2K EEPROM).

  19. #119
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,589
    Quote Originally Posted by MichaelMeissner View Post
    Spreadsheet updated (62K program flash, 2K EEPROM).
    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.

  20. #120
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,589
    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 by PaulStoffregen; 02-01-2015 at 11:37 PM.

  21. #121
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,899
    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.

  22. #122
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    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 by MichaelMeissner; 02-02-2015 at 12:40 AM.

  23. #123
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    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.

  24. #124
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,589
    Quote Originally Posted by MichaelMeissner View Post
    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?
    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.
    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 by PaulStoffregen; 02-02-2015 at 12:51 AM.

  25. #125
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,269
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •