Forum Rule: Always post complete source code & details to reproduce any issue!
Page 76 of 81 FirstFirst ... 26 66 74 75 76 77 78 ... LastLast
Results 1,876 to 1,900 of 2017

Thread: Teensy 4.0 First Beta Test

  1. #1876
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,182
    @Frank - Not sure what you are asking? I believe currently the beginTransaction/endTransaction does not currently setup anything distinctive. Only if you wish for it to maybe turn on an LED if it looks like you have a mismatch does it actually define and use inTransaction (#define SPI_TRANSACTION_MISMATCH_LED)

    So I don't know any way to detect if you are logically in a transaction or not. As you know in libraries like ili9341_t3, we mainly use it to hopefully make sure we have the right settings, when we are doing anything to output to SPI...

    If this is for ili9488 display? I was playing with one... Have not dealt with DMA yet as this display required 3 times as much memory as ILI9341 and current beta board does not have enough...

    Thought about maybe trying a reduced memory (reduced color mode), where I think we only output a byte per pixel, but not sure how well that would work.

  2. #1877
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,506
    I'm about the make the final pinout changes for the 1062 chip. Here's a final call for feedback....


    First, pins I'm considering removing:

    1: Pins 30-31 on the bottom side. This means giving up Serial8, for only 7 serial (plus FlexIO). I want to reserve these 2 pins (and 13 others not currently used) for FlexSPI2, so far likely to remove these 2 signals.

    2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.


    Pins I'm considering adding:

    1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.

    2: EMC_36+EMC_37 for CANFD. These give access to 2 channels of GPT1 timer, plus 2 XBAR inputs.

    3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.


    Pins I'm considering moving:

    1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.

    2: swap pins 5<->33. This would allow I2S2 to both transmit & receive on the outside pins. Unanswered question so far: to codec chips work on I2S2 if connected to I2S1's MCLK?

  3. #1878
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,052
    No comments on updated pin layout

  4. #1879
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,182
    @Paul,

    I know it is difficult to please everyone with so few pins available and so many things that everyone would like those pins to do.

    Personally I am sort of sad to lose a 2nd SPI port, especially since I have never used CAN. But I understand that there are a lot of others that do.

    One argument I remember from before is you can create an SPI object using FlexIO pins, which I have done, as part of the library: https://github.com/KurtE/FlexIO_t4
    Again wonder if parts of this should make it into the mainline...

    Problem is, we are finally starting to see a few more libraries, where you maybe can pass in a pointer to which SPI object to use as a way to be able to use different SPI objects without having to change libraries. The problem is that we are passing in pointer (or reference) to the SPIClass library.

    Not easy for these to support both types of SPI objects as we have simple non-virtual functions that do the majority of the work, like transfer(byte):
    Code:
    uint8_t transfer(uint8_t data) {
    		// TODO: check for space in fifo?
    		port().TDR = data;
    		while (1) {
    			uint32_t fifo = (port().FSR >> 16) & 0x1F;
    			if (fifo > 0) return port().RDR;
    		}
    	}
    Which is directly using the SPI registers...
    Obviously there are ways to solve this, like make all of these functions virtual, and have the Flex version be a sub-class. Or you could have the SPI library be hacked up, where if it is not SPI object it uses different code for each of these functions...

  5. #1880
    Senior Member
    Join Date
    Feb 2013
    Posts
    552
    Quote Originally Posted by PaulStoffregen View Post
    Here's a final call for feedback....
    fwiw, it's more questions rather than feedback:

    Quote Originally Posted by PaulStoffregen View Post
    First, pins I'm considering removing: [...]
    2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.
    is/will be FlexSPI2 as, say, capable as a/the second SPI port? (sorry if this was discussed previously in this thread, it's grown a bit unwieldy). lack of a second SPI port was (to me at any rate) one of the main bottlenecks of T3.2, so me too would be sad to see this go ... but i suppose like pretty much everything else that's a matter of idiosyncratic taste/needs.


    Quote Originally Posted by PaulStoffregen View Post

    Pins I'm considering moving:

    1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.
    if that's easy to do ... i'd suspect though the number of people profiting from this will be fairly small (i can't be sure, of course, but my hunch would be that pins 7/8 more typically would be used as DOUT/DIN, not RX/TX, ie if the concern is using T.4 as a drop-in replacement for existing hardware)

  6. #1881
    Junior Member
    Join Date
    Feb 2019
    Posts
    3
    Quote Originally Posted by PaulStoffregen View Post
    Me too. Sadly, this is the largest one we could buy in a 6 sq mm package. The next largest package is 12 sq mm, and the smallest package that goes up to substantially higher capacity is 40 sq mm.

    After 4.0 is released, I'm considering making a larger (and more expensive) board using this same processor, but with one of those bigger flash chips, an audio codec chip, and probably an ethernet phy chip, and some way to break out more of the I/O pins.
    On this larger board, will the debug pins be available to the developer?

  7. #1882
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,419
    Quote Originally Posted by PaulStoffregen View Post
    Here's a final call for feedback....

    1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.
    I have no use for CAN in any flavour - and normally, in Europe if you even try to connect anything to that bus in your car, the insurance doesn't pay if you're involved in an accident.
    Other uses: Hm.. still, have not needed that.

    Quote Originally Posted by PaulStoffregen View Post
    3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.
    Why not?


    Do we need that many SERIALx? So far I haven't read of any user that needed all.
    Sorry, but you asked for feedback

  8. #1883
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    494
    Quote Originally Posted by PaulStoffregen View Post
    I'm about the make the final pinout changes for the 1062 chip. Here's a final call for feedback....


    First, pins I'm considering removing:

    1: Pins 30-31 on the bottom side. This means giving up Serial8, for only 7 serial (plus FlexIO). I want to reserve these 2 pins (and 13 others not currently used) for FlexSPI2, so far likely to remove these 2 signals.

    2: Pins 26-27 on the bottom side. This means giving up signals for a 2nd SPI port.


    Pins I'm considering adding:

    1: AD_B0_14+AD_B0_15 for CANFD. These both come with analog inputs, plus 1 XBAR input.

    2: EMC_36+EMC_37 for CANFD. These give access to 2 channels of GPT1 timer, plus 2 XBAR inputs.

    3: AD_B1_04+AD_B1_05: These have analog inputs, but not much else - but they would allow 8 continuous bits for the AD_B1 port. Whether that's useful is debatable since the GPIO registers only support 32 bit access.


    Pins I'm considering moving:

    1: pin 6->7, pin 7->8, pin 8->6. This would put Serial3 on the same pins whee it is on Teensy 3.x.

    2: swap pins 5<->33. This would allow I2S2 to both transmit & receive on the outside pins. Unanswered question so far: to codec chips work on I2S2 if connected to I2S1's MCLK?
    I really like these changes. CAN-FD is something that I'm interested in using for the higher data rate transfers compared with CAN and I'm happy to have the UART bumped over to match Teensy 3.x - some of my breakout boards use that port.

  9. #1884
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,954
    sacrificing an SPI port for the CANFD ain’t that bad, who here doesn’t know how to share the SPI bus?, unless you’d want to communicate between 2 devices at same time... I would assume that the initial boards would be a base model like a 3.2 and the t3.5/3.6 form factor later on with more pins/pads available.

  10. #1885
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,506
    Quote Originally Posted by KurtE View Post
    I know it is difficult to please everyone with so few pins available and so many things that everyone would like those pins to do.
    Yes, so much this!

    Since last summer, I've juggled so many combinations of pin decisions. This will be the very last time, and then everything we do with the 106X chips going forward will have to support this decision (or make painful sacrifices).


    At this moment, I'm feeling like we should probably keep the 2 pins for the other SPI port, but something has to go for CANFD and that's going to be Serial8. I have indeed heard from some people who are really looking forward to 8 real serial ports. They're going to have to settle for FlexIO to get beyond 7. CANFD is just too important to leave out.

    This means CANFD is going to end up on bottom-side pins. Not ideal for the most capable CAN port, but I don't see much alternative without sacrificing really important features already on the outside pins.

    Keeping the 2nd SPI port means having no contiguous set of 8 pins on any port.


    On a future larger format board, if FlexSPI2 is used (a pretty big if), it's really most useful for connecting a memory chip. Using FlexSPI as for ordinary SPI devices would be awkward, though you could set up its LUTs in some way to accomplish that. But FlexSPI is really optimized for connecting memory chips rather than ordinary SPI peripheral chips.

    I'm not prepared to talk about long-term plans for debug at this time.

  11. #1886
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,663
    Quote Originally Posted by PaulStoffregen View Post
    Yes, so much this!

    Since last summer, I've juggled so many combinations of pin decisions. This will be the very last time, and then everything we do with the 106X chips going forward will have to support this decision (or make painful sacrifices).


    At this moment, I'm feeling like we should probably keep the 2 pins for the other SPI port, but something has to go for CANFD and that's going to be Serial8. I have indeed heard from some people who are really looking forward to 8 real serial ports. They're going to have to settle for FlexIO to get beyond 7. CANFD is just too important to leave out.

    This means CANFD is going to end up on bottom-side pins. Not ideal for the most capable CAN port, but I don't see much alternative without sacrificing really important features already on the outside pins.

    Keeping the 2nd SPI port means having no contiguous set of 8 pins on any port.


    On a future larger format board, if FlexSPI2 is used (a pretty big if), it's really most useful for connecting a memory chip. Using FlexSPI as for ordinary SPI devices would be awkward, though you could set up its LUTs in some way to accomplish that. But FlexSPI is really optimized for connecting memory chips rather than ordinary SPI peripheral chips.

    I'm not prepared to talk about long-term plans for debug at this time.
    Just my two cents here, while not ideal to put CANFD on the bottom side and giving up serial8 its probably the best option for this size board. Would not like to give up the second SPI port either. To be honest I have never had need for 8 serial ports but that is just me. I think I have an idea why you want that though but if for future T4's its possible maybe you could recover Serial 8.

  12. #1887
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,182
    Thanks @Paul, and for what it is worth, again I have code in the library: https://github.com/KurtE/FlexIO_t4
    Where you can define a few more Serial ports if you really need them. They may not work as fully as a real hardware Serial port, but was able to do stuff with them.

  13. #1888
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,506
    My hope is to eventually have FlexIO serial ports implemented in the SoftwareSerial library. I guess the question there is how realistic is implementing on transmit on a different FlexIO than receive?

    After the switch to RT1062, we'll have 3 FlexIO modules which cover all the outside pins, except 0 & 1 which are normally used for Serial1.

  14. #1889
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,807
    RE:Pin ReMap >> If only T_3.0 had been rounded up to an even 1.5"

    Are the SD pads on the bottom going to work out to be usable? [socket mountable - card accessible - enough power - current/noise interference] ? Would that area repurpose better to keep 2nd SPI and Serial8 and gain CANFD.

    Moving pins for Serial3 to be 'home' sounds like fun - Was it mjs513 noting that some time back.

  15. #1890
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,182
    I think the code in my library will already handle it (FlexIO for SoftwareSerial). I don't think there is any common need between the RX and Tx, they both require a timer and shifter and my underlying code tries to figure out which ones are free. My SPI code tries to get two on the same FlexIO module and for DMA to work they have to be on two different DMA sources. Only two channels per FLEX Io object...

    Note: I have not implemented everything, only most of the basics.

  16. #1891
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    494

  17. #1892
    Hi there. Has Teensy 4.0 First Beta Test already done? Has it been released?

  18. #1893
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,277
    Quote Originally Posted by nicfaust View Post
    Hi there. Has Teensy 4.0 First Beta Test already done? Has it been released?
    Beta test is ongoing. Not yet released, see https://www.pjrc.com/teensy/

  19. #1894
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,419

    Ili9488

    I played a bit with the ILI9488 Display.

    With max SPI-Speed (around 66MHz - the ili9341 accepts a bit more), the max fullscreen-refresh rate I got is ~15.3Hz (65ms) :-(


    Is this enough for a flicker-free display (let's say a movie)?

    - The max refresh-rate of the display itself is ~90Hz (ILI9341: 119Hz)
    - it does not support 16BIT colors - it wants 18 Bit (3 bytes with two LSBs= 0)
    - way more pixels

    - so, we have to transfer 320*480*3 bytes, = 450 KB!! for a full screen.
    - we can save only 3 of such images in the flash.

    Because of the high memory-usage, I'm currently working on a 256-color library.
    It uses a CLUT (or some CLUTs) to translate 8BIT Palette-color to RGB.
    To improve the speed, for every line it stores the minimal-x and maximal-x used pixel-coordinates if a fullscreen-update is triggered it checks these values and transfers only the pixels in between.
    It is still possible to display fullRGB-pictures with sending the RGB-data to the display directly - without using the memorybuffer.

    Thoughts? Is there any need for this 256-color "mode"? Does it make sense? I'm not sure..

    I'm not very satisfied.. fullscreen-applications (like console-emulators, or T64) may flicker because of the slow refresh-rate, if the whole display changes its content - which is quite often the case, for example whith scrolling.

    What do you think...is 15Hz enough??

    (p.s. and even that only with dirty tricks like IPG-CLOCK = CPU-CLOCK / 2 - without that, its ~10Hz)
    Last edited by Frank B; 03-07-2019 at 07:01 PM.

  20. #1895
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,182
    Quote Originally Posted by Frank B View Post
    I played a bit with the ILI9488 Display.
    ...
    Because of the high memory-usage, I'm currently working on a 256-color library.
    It uses a CLUT (or some CLUTs) to translate 8BIT Palette-color to RGB.
    To improve the speed, for every line it stores the minimal-x and maximal-x used pixel-coordinates if a fullscreen-update is triggered it checks these values and transfers only the pixels in between.
    It is still possible to display fullRGB-pictures with sending the RGB-data to the display directly - without using the memorybuffer.

    Thoughts? Is there any need for this 256-color "mode"? Does it make sense? I'm not sure..

    I'm not very satisfied.. fullscreen-applications (like console-emulators, or T64) may flicker because of the slow refresh-rate, if the whole display changes its content - which is quite often the case, for example whith scrolling.

    What do you think...is 15Hz enough??
    Hi Frank, I also wondered about a 256 color mode as well, but was not sure if the display has the ability to set what the 256 colors are (i.e. in the displays lookup table).

    Or if there was some ability with DMA to be able to do a DMA from your logical frame buffer, through a color table to then to the display?

    Now if you could go directly to the display in 256 color mode, should both reduce the memory requirements it should also speed up the drawing of the display... Where the in memory look up table would only reduce memory requirements.

  21. #1896
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,419
    The LUT is on the teensy-side, and it's only there to reduce the memory requirements. The SPI Interface supports 18 Bits ( physically 24Bits) only ( or 8 colors only) , so I think there is no other way. A short,fast function translates this to RGB, for the current line, short before DMA for that line starts.

  22. #1897
    Junior Member
    Join Date
    Nov 2017
    Posts
    14
    @Frank B
    I don't think 15 fps is going to be good for video, at least 25-30 fps is needed for persistence of vision or it's going to look choppy. For game and computer emulators, 50-60 fps is needed or it's just going to look like the games / demos are dropping frames. I guess the 256 color mode is a good idea to allow double buffering without clobbering memory.

  23. #1898
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,807
    This data sheet for the ILI9488
    shows "5.2.34. Interface Pixel Format (3Ah) " that suggests there is a command to set display to '16 bits/pixel'. Not sure if this conflicts with or overrides hardware wiring of the device? That would go to the 565 color scheme used for the ILI9341

    <edit>: So I found changed/this in the code:
    Code:
    writecommand(0x3A);      // Interface Pixel Format
      // writedata(0x66);    //18 bit
    	writedata(0x55); 	  //16 bit
    Swapped 18 for 16 and the 9488 stays all white with no other change. Posted before that the ILI9341 worked with wrong colors using the 9488 working 18 bit code and - it also works with this change to "16 bit" only now the colors are just mostly grays and a muted yellow on the Groop testText().

    This is 9488 specific as my display doesn't run on T4 - KurtE indicated it worked - but not sure how mine is different as noted.
    Last edited by defragster; 03-08-2019 at 03:37 AM.

  24. #1899
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,419
    Hi Tim,
    yes I tried the 0x55, too. Does not work - and the chapter about 4-Wire SPI clearly says only 18BIT are supported.

    I hope I can find 3.5" or bigger ILI9341 Display for my usage. I don't need the increased resolution.

  25. #1900
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,807
    Quote Originally Posted by Frank B View Post
    Hi Tim,
    yes I tried the 0x55, too. Does not work - and the chapter about 4-Wire SPI clearly says only 18BIT are supported.

    I hope I can find 3.5" or bigger ILI9341 Display for my usage. I don't need the increased resolution.
    Indeed - larger display would be nice - though the minor screen growth is dwarfed by the doubled resolution on the 3.5" 9488

    Good to know my attempt was as good as yours I did not edit the library to only send 2 color bytes - but 9341 gave some pixels. The rPi mounting display I got has silkscreen saying '16/18 bit' - mjs513 got a similar/same board - but no apparent jumper or board edit to change that - I'll run those wires again and see if it works where it did not with 18 bit - though it oddly is missing the Data/Cmd pin. Somehow it works on rPi and my scan of the 9488 PDF didn't find a mode where that is not expected - I wonder if it works when held either Hi or Low? The 9488 KurtE got seemed to have a large number of external components that could/had to be edited to work - not sure if one of those sets the controller mode 16 .vs. 18?

    I just found it very odd the old trusted ILI8341 displays 'something showing function' with the 9488 library - in both 16 and 18 bit modes where the 9488 goes blank. Also odd that the MISO trace to display had to be cut to use the Touch on the one I have that looks like Paul's.

Posting Permissions

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