Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 51 to 75 of 119

Thread: K64 Beta Test :: Teensy 3.5

  1. #51
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,195
    Quote Originally Posted by KurtE View Post
    Found the problem. DMA channel for SPI0 was improperly set in header file.

    Fixed: Pull request https://github.com/PaulStoffregen/cores/pull/170
    yep, i just saw that in k64 ref table 3-27

    After editing kinetish.h, DmaSpi example works with SPI0 on K64


    How do I test with SPI1, i tried replacing DMASPI0 with DMASPI1 (jumpered 0 to 1), src and dest don't match? non-DMA works with SPI1

    EDIT: SPI1 and DMASPI1 with 0 to 1 works on K66

    K64 DMA MUX table shows
    16 SPI1 Transmit or Receive
    17 SPI2 Transmit or Receive
    that doesn't seem hopeful.
    Last edited by manitou; 09-04-2016 at 07:08 PM.

  2. #52
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by defragster View Post
    Tim, i have a display that does not work anymore. It was in my drawer. Last time i used it - some weeks ago - it was working. When i tried it today, it was white too.. I took a new one, and this worked instantly.

  3. #53
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Hi defragster and Frank. As I mentioned I have had some of the cheaper ILI9341 displays not work unless I hooked up Reset. I know the PJRC version you need to either wire the pin up to 3.3v or you need to drive it by an IO pin, as it does not have an internal PU like the Adafruit one does. I also had an issue when I wired one up when I forgot to put the resister in, in between power and the backlight pin.

    Manitou: I will also play some with the SPI1 and 2 as well. Yep see the same table. So looks like the header file needs to change, plus maybe changes to dmaspi. Or maybe define constants for both
    DMAMUX_SOURCE_SPI2_RX and DMAMUX_SOURCE_SPI2_TX that both have same value likewise for SPI1...

    I have defined:
    Code:
    #define DMAMUX_SOURCE_SPI0_RX		14
    #define DMAMUX_SOURCE_SPI0_TX		15
    #define DMAMUX_SOURCE_SPI1_RX		16
    #define DMAMUX_SOURCE_SPI1_TX		16
    #define DMAMUX_SOURCE_SPI2_RX		17
    #define DMAMUX_SOURCE_SPI2_TX		17
    Built like you mentioned and tried with SPI1/DMASPI1... Has lots of failures:
    Code:
    Hi!
    Buffers are prepared
    Time for non-DMA transfer: 234us
    src and dest match
    
    Press a key to continue
    
    DmaSpi::begin() : DmaSpi::start() : state_ = eStopped
    DmaSpi::beginNextTransfer: no pending transfer
    Transfer @ 0x2001fee8
    Testing src -> dest, single transfer
    --------------------------------------------------
    Transfer @ 0x2001ff20
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      real sink
      real source
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001fee8
      state = eRunning
    DmaSpi::beginNextTransfer: no pending transfer
    Finished DMA transfer
    src and dest don't match
     src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
    dest: 0x63 0x63 0x63 0x63 0x63 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
    ==================================================
    
    
    Testing src -> discard, single transfer
    --------------------------------------------------
    Transfer @ 0x2001ff3c
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      dummy sink
      real source
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001fee8
      state = eRunning
    DmaSpi::beginNextTransfer: no pending transfer
    Finished DMA transfer
    last discarded value is 0x2f
    That appears to be wrong, it should be src[DMASIZE-1] which is 0x63
    ==================================================
    
    
    Testing 0xFF dummy data -> dest, single transfer
    --------------------------------------------------
    Transfer @ 0x2001ff58
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      real sink
      dummy source
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001fee8
      state = eRunning
    DmaSpi::beginNextTransfer: no pending transfer
    Finished DMA transfer
    src and dest don't match
     src: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 
    dest: 0x30 0x31 0x31 0x31 0x31 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 
    ==================================================
    
    
    Testing multiple queued transfers
    --------------------------------------------------
    Transfer @ 0x2001ff74
    Transfer @ 0x2001ff04
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      real sink
      real source
    DmaSpi::registerTransfer(0x2001ff04)
      DmaSpi::addTransferToQueue() : queueing transfer
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001fee8
      state = eRunning
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001ff04
      this was the last in the queue
      real sink
      real source
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001ff04
      state = eRunning
    DmaSpi::beginNextTransfer: no pending transfer
    Finished DMA transfer
    Finished DMA transfer1
    src and dest don't match
     src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
    dest: 0xff 0xff 0xff 0xff 0xff 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
    src and dest don't match
     src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
    dest: 0x30 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 0x2f 
    ==================================================
    
    
    Testing pause and restart
    --------------------------------------------------
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      real sink
      real source
    DmaSpi::registerTransfer(0x2001ff04)
      DmaSpi::addTransferToQueue() : queueing transfer
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001fee8
      state = eStopping
    Time until stopped: 492 us
    Finished DMA transfer
    DMA SPI appears to have stopped (this is good)
    restarting
    DmaSpi::start() : state_ = eStopped
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001ff04
      this was the last in the queue
      real sink
      real source
    DmaSpi::rxIsr_()
      finishCurrentTransfer() @ 0x2001ff04
      state = eRunning
    DmaSpi::beginNextTransfer: no pending transfer
    Finished DMA transfer1
    src and dest don't match
     src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
    dest: 0x30 0x31 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
    src and dest don't match
     src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
    dest: 0x30 0x31 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
    ==================================================
    
    
    Testing src -> dest, with chip select object
    --------------------------------------------------
    Transfer @ 0x2001ff90
    DmaSpi::registerTransfer(0x2001fee8)
      DmaSpi::addTransferToQueue() : queueing transfer
      starting transfer
    DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
      this was the last in the queue
      real sink
      real source
    Last edited by KurtE; 09-02-2016 at 08:15 PM.

  4. #54
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by KurtE View Post
    Hi defragster and Frank. As I mentioned I have had some of the cheaper ILI9341 displays not work unless I hooked up Reset.
    Hi Kurt, no, this display is broken.
    The board I use connects reset to a teensy-pin, and the display is from the same batch (or, at least i bought them together) . I can't tell how this happended, and it i know that it worked last time i used it.

  5. #55
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,700
    Frank - I had one go white just after I got it from PJRC - Robin replaced it ASAP. With nothing to lose I was going to use the SD portion and I jumpered the J1 per those directions and after that the display came back to life! Worth a try if you have that same style display as on the PJRC store with that jumper.

    In the case of this 2.8" display it works on two T_3.6's, and a new 2.2" acts the same. Given the above posts I'm pretty sure I have a failing wire or connector - it got packed twice on my recent trip and there was enough pressure to bend over some of the jumper wire ends in the headers on the soldered Proto board.

    Kurt - I have reset to 3.3V. I was going to run power direct to my LED and then jumper that to the VCC end connect to use my 8 connector plug.
    Last edited by defragster; 09-02-2016 at 09:23 PM.

  6. #56
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    TIM: That closing J1 helped (?!?)- the display works now... thanks
    Is that a voltage-regulator near J1 ? Maybe it is broken.

  7. #57
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,700
    AWESOME - I shared my findings 2-3 times to others that 'saw white' and never got feedback that anyone else tried it at all.

    I'll go solder that J1 on mine first - perhaps there is some factor causing that to work intermittently?

    Voltage-regulator sounds like what I heard before with regard to that part that J1 bypasses.

    Paul/Robin - did you consider moving this thread to Announcements from General Discussion for better visibility?

  8. #58
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,700
    TYQT IS WORKING !!!!!!!! Both T_3.5 and T_3.6 !!!!
    Current newest is TyQt-0.7.5-204-g33f592f-...

    Update: I posted on the TYQT thread images showing multi devices, and I stopped using the HUB below.

    Other Note: Something is still messing with the (long used) powered USB HUB - it may be tired - but it keeps going offline, mostly using TYQT RESET feature? Maybe it isn't responsive enough for the USB/HID/Program loop and is confusing something - then it is removed from the system and the HUB pilot light goes out. It is even weirder when TeensyDuino is active - it tried to program on reset - FLASH gets WIPED - then hub goes offline and the device is empty. I saw this on my Laptop before - but the hub didn't go away, now on my desktop it is. Tried with a T_3.1 and it really went weird - I had USBView running and that terminated . . . asking Koromix.

    I soldered J1 on the 2.8" and 2.2" ILI9341 - still nothing but white on T_3.5 but works well on T_3.6 . . . ? Though on handling and swapping the plug in board one more time back to 2.2" - the T_3.6 is a bit touchy - but either works or at least tries. It does show some failure of solid electrical connections.

    I'll get back to wiring up the KurtE SD display adapter and diagnose this later as I know the 2.2" display works.
    Last edited by defragster; 09-05-2016 at 09:49 PM.

  9. #59
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    DMASPI - For now I am punting on SPI1 and SPI2. I am not sure if there is an answer that will work here.

    I did some searching and found things like: http://cache.freescale.com/files/sof...QXTWRK64RN.pdf
    Which states:
    Because the DMA TX channel and DMA RX channel for SPI1 and SPI2 are the same, SPI1 and SPI2 do not use the DMA driver
    And from: https://community.nxp.com/thread/330972
    Described issue with the same DMA for TX and RX channel is caused by hardware configuration directly on chip.

    Unfortunately there isn’t any workaround except don’t use DMA for SPI1 and SPI2 and potentially complete rework of SPI driver and linking change (currently it is not on TO-DO list).

  10. #60
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    I tested some things with pre-production 3.5 and 3.6 and must say that they work great.
    I could not find any problems that weren't mentioned already.

  11. #61
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,195
    I assume snooze will need some K64 mods. I tried duff's K66 mods at https://github.com/duff2013/Snooze_V6_Beta and got the sleep example to work on K66, but example doesn't compile on K64.
    Last edited by manitou; 09-04-2016 at 07:05 PM.

  12. #62
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by manitou View Post
    I assume snooze will need some K64 mods. I haven't tried duff's K66 mods at https://github.com/duff2013/Snooze_V6_Beta
    I have never used snooze, but thought I would download the V6 stuff and see if it builds and the like. And at least some of the Examples will probably need a little TLC.

    Example I tried to build sleep_all_wakups, it builds fine for 3.6, but fails on 3.5, in this case probably because the 3.5 does not have any touch pins...
    Code:
    
    Build options changed, rebuilding all
    In file included from C:\Users\Kurt\Documents\Arduino\libraries\Snooze/Snooze.h:38:0,
    
                     from C:\Users\Kurt\Documents\Arduino\libraries\Snooze\examples\sleep\sleep_all_wakeups\sleep_all_wakeups.ino:9:
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeTouch.h: In constructor 'SnoozeTouch::SnoozeTouch()':
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeTouch.h:73:5: error: expected identifier before '{' token
    
         {
    
         ^
    
    In file included from C:\Users\Kurt\Documents\Arduino\libraries\Snooze/Snooze.h:39:0,
    
                     from C:\Users\Kurt\Documents\Arduino\libraries\Snooze\examples\sleep\sleep_all_wakeups\sleep_all_wakeups.ino:9:
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h: In constructor 'SnoozeCompare::SnoozeCompare()':
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:53:13: warning: 'SnoozeCompare::SIM_SCGC4_clock_active' will be initialized after [-Wreorder]
    
         bool    SIM_SCGC4_clock_active;
    
                 ^
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:47:13: warning:   'uint8_t SnoozeCompare::CR0' [-Wreorder]
    
         uint8_t CR0;
    
                 ^
    
    C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:62:5: warning:   when initialized here [-Wreorder]
    
         SnoozeCompare( void )  :
    
         ^
    
    sleep_all_wakeups: In function 'void setup()':
    sleep_all_wakeups:87: error: 'class SnoozeTouch' has no member named 'pinMode'
         touch.pinMode(0, touchRead(0) + 250); // pin, threshold
    
               ^
    
    Multiple libraries were found for "Snooze.h"
     Used: C:\Users\Kurt\Documents\Arduino\libraries\Snooze
     Not used: C:\arduino-1.6.11\hardware\teensy\avr\libraries\Snooze
    'class SnoozeTouch' has no member named 'pinMode'
    Note: I cloned the beta into C:\Users\Kurt\Documents\Arduino\libraries\Snooze

    The line that the system showed the error for:
    Code:
        touch.pinMode(0, touchRead(0) + 250); // pin, threshold

  13. #63
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Did some Analog testing. Using the test program I posted in other thread. So far so good. That is I tested the pins out of the Table in my test program:
    uint8_t analog_pins[] = {A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12
    , A13, A14, A15, A16
    , A17, A18, A19, A20, A21, A22, A23, A24, 44, 45,

    And so far it found all of the Analog pins.
    Note: A23 and A24 code relies on my pull request: https://github.com/PaulStoffregen/cores/pull/167
    Currently using the simple version which just added another case, not the version that which used a full populate lookup table.

    Next, I may try reading the one out of the pins that are used for USB Host on T3.6

  14. #64
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by KurtE View Post
    Next, I may try reading the one out of the pins that are used for USB Host on T3.6
    For the fun of it I did create a new fork based on the other fork, that add A25 and A26 on the Teensy 3.5. They use the D+ and D- pins the 5 pin connector that is used on the T3.6 for USB host.

    These pins are Analog only so I would assume NOT +5v tolerant.

    https://github.com/KurtE/cores/tree/...so-Add-A25-A26

    They are on pin J1 which is ADC0_DP1 and K1 which is ADC1_DP1

    Tested by again adding them to my Analog test program. Might be good if someone else also tested it...

    Again not sure how many would be interested, but it does add two more Analog pins that you don't need to surface mount...

    Paul: I have not done any testing on the Are the +5v and GND pins connected up to the other three pins. Wondering are they connected to Other GND +5v pins or are they connected up to other IO pins on the K64/K66. Example: on K66 pin K2 is USB1_VSS. If so K2 on K64 is ADC0_DM0/ADC1_DM3

    Thanks
    Kurt

  15. #65
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by KurtE View Post
    Paul: I have not done any testing on the Are the +5v and GND pins connected up to the other three pins. Wondering are they connected to Other GND +5v pins or are they connected up to other IO pins on the K64/K66. Example: on K66 pin K2 is USB1_VSS. If so K2 on K64 is ADC0_DM0/ADC1_DM3
    First step I did was to hook up Logic Pro 8 to all 5 pins and turned on both digital and analog reads of the 5 pins.
    I Know from before D+ and D- are hooked up to IO pins.

    But again not sure of other
    What I am seeing is: +5v pin is showing voltages somewhere in the range .025 to .031...
    The two ones marked G are very much close to 0 (likewise one on another GND pin). +- .0001

    Now maybe experiment, a little bit. Want to make sure I don't short anything out!

  16. #66
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,700
    Kurt - not sure if I'm following. But you are on K64 looking at the internal USB connector 5 pin holes? Those that on K66 give the 'T3.6 for USB host'?
    If that is where you are the GND are (I assume) on the GND plane, the 5V and D+ and D- are floating with those components left off the K64 PCB.
    Or have you gone upstream to where the empty component pads get their signal?

  17. #67
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Hi Defragster:

    Yes looking at internal USB connections.

    First pass looked at D+ and D- pins as these do connect up to pins J1/K1 (USB1_DM and USB1_DP) on the K66 and on K64 these are ADC0_DP1 and ADC1_DP1. At first I thought that they may not be connected, but if you look at posting #23, that the pins were connected, the missing part is actually an ESD device but that the pins are connected in an internal layer...

    So far that works fine. As I mentioned I pushed up a fork that has these defined as IO pins.

    Then it made me wonder what are the other three pins connected to.

    Example: G pin are they directly connected to other GND pins? Or maybe is one or more of them connected to an IO pin on the K66, like the one marked USB1_VSS? My Ohm meter measured a few ohms between ground and these pins. USB1_VSS is on pin K2 on K66, which K2 pin on K64 is: ADC1_DM1. So this morning I tried defining this as an analog input. So far I don't think this is connected to any of these pins and/or some other stuff is on these pins as well as I get a constant value...

    Hope that makes sense.

  18. #68
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,700
    Good, I assumed - you looked more closely - I saw post 23 - my electronics understanding assumed the ESD was fed through - not already connected internally with ESD to bleed off D+/D-.

    Makes sense - carry on Have you tried the GND checks on beta1 Proto board - at least there the MCU pins are exposed to look for GND connect pins? Maybe even see the traces on the underside of not on ground plane?

  19. #69
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,574
    I've been working with the ADC0_DP1 and ADC1_DP1. Earlier I saw "strange" problems, but until now I assumed it was something wrong with my code.

    It's looking like the K64 has a hardware bug with ADC1_DP1 when used in single ended mode. It seems to work, but the range is inverted. Zero volts reads 1023 (with analogRead default 10 bit config) and 3.3V reads zero.

    On the connections, K66 pin USB1_VSS (K64 pin ADC1_DM1) is shorted directly to GND. So are the 2 ground pins on the USB host port.

  20. #70
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,195
    Quote Originally Posted by manitou View Post
    I re-ran the tests, and the K66 numbers were actually a little lower at higher frequencies. i updated the table. Not sure why K64 is consuming more power. Measured with multimeter and hacked USB cable.
    In post #11, k64 seems to be consuming more power than K66?? loop() with delay(5000); runs at 53.6 ma. Anyone else confirm this? Another data point is loading the BigNumber library Factorials example. if the monitor is not activated (spinning on !Serial), k64 consumes 46.1 ma. once monitor is activated, 58.1ma.

    Here are some power numbers incrementally adding Ether things to the k64:
    Code:
          blank sketch 53.7 ma  
          ether shield  89 ma (no LEDs)
          +e cable     140.3 ma  LEDs
          load etherraw  141.6 ma
          monitor on   159.6 ma

  21. #71
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by PaulStoffregen View Post
    I've been working with the ADC0_DP1 and ADC1_DP1. Earlier I saw "strange" problems, but until now I assumed it was something wrong with my code.

    It's looking like the K64 has a hardware bug with ADC1_DP1 when used in single ended mode. It seems to work, but the range is inverted. Zero volts reads 1023 (with analogRead default 10 bit config) and 3.3V reads zero.

    On the connections, K66 pin USB1_VSS (K64 pin ADC1_DM1) is shorted directly to GND. So are the 2 ground pins on the USB host port.
    Thanks Paul,

    Good to know. I tried doing an Analog read on ADC1_DM1 and it was a constant value so assumed probably not viable.

    So the question that probably only you can answer is does it make sense to add ADC0_DP1 and ADC1_DP1 as "A" pins, knowing one of them is inverted. Will update my version of it be based of current code...

    EDIT: Looks like you added those pins as part of the last code delta :
    Last edited by KurtE; 09-05-2016 at 03:23 PM.

  22. #72
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,574
    I added them both in the code.

    The bigger question is whether to print A26 on the pinout card....

  23. #73
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,574
    D'oh, it was just a mistake in my test circuit. Looks like A26 does work properly.

  24. #74
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by PaulStoffregen View Post
    D'oh, it was just a mistake in my test circuit. Looks like A26 does work properly.
    Great! Looks like time to download next beta version and start testing again

  25. #75
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Decided to do some I2C testing and see if my SSD1306 would work on the T3.5... I know it has been done before, but I hacked up
    a version of the Adafruilt_SSD1306 library that I replaced the including of Wire.h with i2c_t3.h. I also then added an optional parameter at the end of the I2C constructor with a reference to which I2C object to use. I did some rudimentary testing For Wire, Wire1, and Wire2 on the T3.5 (using default pins for each).

    I uploaded the changed library, maybe should create new Library like SSD1306_I2C_T3, and rip out spi stuff... As there already is a good SPI version...
    I only updated the 128x64 I2C display example and I selected the non standard I2C address for device (at least by Adafruit) as that is what my display has. Also changed reset pin to 6 as to not conflict with Wire2.

    Again I pushed these changes up to new branch
    https://github.com/KurtE/Adafruit_SSD1306/tree/I2C_T3

Posting Permissions

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