Forum Rule: Always post complete source code & details to reproduce any issue!
Page 31 of 63 FirstFirst ... 21 29 30 31 32 33 41 ... LastLast
Results 751 to 775 of 1559

Thread: K66 Beta Test

  1. #751
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,398
    Quote Originally Posted by Frank B View Post
    Hm that looks good. I used FAT32... did you create a new File with > 120MHZ ?
    Well..if it works for you.. why does it not work for me ? I'll try FAT16...

    Ok, Paul said, he used I2S @ with Teensy @ 240MHz... does not work for me, too.

    A problem with my board ?
    Found an issue with FATFS
    Unicode (needed for Long Filename) on Teensy seems to be 32 bit and not 16 bit as assumed by Chan
    (I only tested on K64)
    can be tested with printf("%d",sizeof(L'1'))

    updated https://github.com/WMXZ-EU/uSDFS

  2. #752
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    Another SPI Question/Maybe API change/extend...

    Many of our Display drivers and the like have code in them like:
    Code:
    void ILI9341_t3::begin(void)
    {
        // verify SPI pins are valid;
        if ((_mosi == 11 || _mosi == 7) && (_miso == 12 || _miso == 8) && (_sclk == 13 || _sclk == 14)) {
            ILI9341_SPI.setMOSI(_mosi);
            ILI9341_SPI.setMISO(_miso);
            ILI9341_SPI.setSCK(_sclk);
    	} else {
    		// allow user to say use current ones...
    		if ((_mosi != 255) || (_miso != 255) || (_sclk != 255))
            	return; // not valid pins...
    	}
    	ILI9341_SPI.begin();
    	if (ILI9341_SPI.pinIsChipSelect(_cs, _dc)) {
    		pcs_data = ILI9341_SPI.setCS(_cs);
    		pcs_command = pcs_data | ILI9341_SPI.setCS(_dc);
    	} else {
    Note: This version was hacked up to allow me to not to specify MOSI, MISO, SCK and use whatever the SPI Buss is currently configured for.

    However I am wondering as we add more different processors which may have different SPI busses and/or different SPI pins, if we should not extend the SPI interface, like what was done for chip Select pins.

    So could add: SPI.pinIsMOSI(pin)... methods, which does the test for the appropriate pins for the processor... And/Or could also change functions like SPI.setMOSI(pin), to return something like a bool, which could be tested.

    Actually at times not sure how much these tests help as in most cases if the tests fail and we simply return without a working display, there is nothing returned by void ILI9341_t3::begin, to let you know it failed and if so why... But that is another story...

    Thoughts?

  3. #753
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    A second -red- LED on a dedicated pin would be great... not only to indicate such error-conditions, but for other problems like the NMIs, too (e.g. bus-faults)

  4. #754
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,241
    K66 ethernet -- projected TCP performance

    Using UDP, I have attempted to project K66 TCP performance, details on post 686 with comparisons to mbed K64.

    The K66 hardware checksums for IP are flakey (fail (0) for packets > 198 bytes?). There might be some additional configuration magic that might fix it, or maybe a hardware errata exists. I have reverted to software checksums, using 0 for UDP checksum for max speed.

  5. #755
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    The OSC-Library (lol..i don't know what it does ;-) - i just saw it when searching mentions of K20 ) misses a whole bunch of #defines for k64/k66 - even in the examples.

    What is this lib ? :-)

    Edit: More missing #defines (and perhaps more work) in :

    - openGLCD
    - RA8875
    - UTFT
    - XBEE

    for freqmeasure, I have done a PR some minutes ago
    Last edited by Frank B; 07-13-2016 at 11:10 PM.

  6. #756
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    Quote Originally Posted by PaulStoffregen View Post
    Here's an update on the likely extra bottom-side pins.

    There will probably be a total of 18 bottom side pins, similar to the 14 we have now on the bottom of Teensy 3.2. They will be in 2 groups of 8 and 10 pins. This is the expected pinout for the bottom side:

    Code:
    Pin  ADC  Ser  PWM  SPI     I2C   CAN  Touch  I2S   Eth   Native
    ---  ---  ---  ---  ---     ---   ---  -----  ---   ---   ------
    
    GND
    DBGEN
    SWCLK
    SWDAT
    40                                                        D15
    41                                                        D11
    42                          SDA3              txd0        E10
    43                          SCL3              lrclk       E11
    
    44                  CS2                                   B20
    45                  MOSI2                                 B22
    46                  MISO2                                 B23
    47                  SCK2                                  B21
    GND
    3.3V
    48        RX6               scl0                          D8
    49        TX6               sca0                          D9
    50   A23                                            TIMER B4
    51   A24                                            TIMER B5
    Hi Paul,

    I See last night, you did a delta to add new pins to the build. Actually it looks like you added 17 new IO pins If I looked at your changes it looks like: Pin 41-57

    I have not updated my Excel document yet, but it looks like fun.

    So it looks like time to start playing?

    Edit: I think the pins map like:
    Code:
    #   PIN ALT0    ALT1    ALT2        ALT3    ALT4        ALT5        ALT6            ALT7
    --  --- ----    ------  ---------   -----   ---------   ------      --------        --------- 
    40  A28         PTA28                       MII0_TXER               FB_A25  
    41  A29         PTA29                       MII0_COL                FB_A24  
    42  A26         PTA26                       MII0_TXD3               FB_A27  
    43  B20         PTB20   SPI2_PCS0                       FB_AD31/SDRAM_D31   CMP0_OUT    
    44  B22         PTB22   SPI2_SOUT                       FB_AD29/SDRAM_D29   CMP2_OUT    
    45  B23         PTB23   SPI2_SIN    SPI0_PCS5           FB_AD28/SDRAM_D28   CMP3_OUT    
    46  B21         PTB21   SPI2_SCK                        FB_AD30/SDRAM_D30   CMP1_OUT    
    47  D8          PTD8    I2C0_SCL                        LPUART0_RX  FB_A16  
    48  D9          PTD9    I2C0_SDA                        LPUART0_TX  FB_A17  
    49  B4  A1_10   PTB4                        ENET0_1588_TMR2 SDRAM_CS1-b FTM1_FLT0   
    50  B5  A1_11   PTB5                        ENET0_1588_TMR3     FTM2_FLT0   
    51  D14         PTD14   SPI2_SIN            SDHC0_D6        FB_A22  
    52  D13         PTD13   SPI2_SOUT           SDHC0_D5        FB_A21  
    53  D12         PTD12   SPI2_SCK    FTM3_FLT0   SDHC0_D4        FB_A20  
    54  D15         PTD15   SPI2_PCS1           SDHC0_D7    FB_A23      
    55  D11         PTD11   SPI2_PCS0           SDHC0_CLKIN LPUART0_CTS_b   FB_A19  
    56  E10         PTE10   I2C3_SDA            I2S0_TXD0   LPUART0_CTS_b   FTM3_CH5    USB1_ID
    57  E11         PTE11   I2C3_SCL            I2S0_TX_FS  LPUART0_RTS_b   FTM3_CH6
    Warning: some of the spacing above is a little off, but hard to fit, Only on ALT7....
    Last edited by KurtE; 07-14-2016 at 03:34 PM.

  7. #757
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Quote Originally Posted by Frank B View Post
    The OSC-Library (lol..i don't know what it does ;-) - i just saw it when searching mentions of K20 ) misses a whole bunch of #defines for k64/k66 - even in the examples.

    What is this lib ? :-)

    Edit: More missing #defines (and perhaps more work) in :

    - openGLCD
    - RA8875
    - UTFT
    - XBEE

    for freqmeasure, I have done a PR some minutes ago
    https://github.com/CNMAT/OSC

    ;-)

  8. #758
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    Before I start playing with all those new pins, thought I would update my SPI playing around. Also I may be busy with some none Teensy stuff for a few days...

    I created a new version of my SPIN (SPIn library). I decided to try a different approach and I created a base class with all the members virtual. I then created subclasses for SPIN0 and SPIN1 and soon SPIN2, which implement these methods to call of to the SPI and SPI objects, which most of their code is always inline. So now I have virtual function equivalents for these.

    I then added some more virtual functions for checking SCK/MISO/MOSI pins as I mentioned earlier. I also added a method that returns a pointer to the System level SPI KINETISK object and also another one which returns the SPI queue size for that SPI object.

    I then played around with a copy of the ili9341_t3 code base, which I added the constructor takes a pointer to a SPIN object (default SPIN0) and then made all of the changes to call through the virtual functions and to use the pointer to the hardware SPI registers. Then I ended up moving the functions like: waitFifoEmpty out of the ili9341 code and added them to my spin object. That way I don't have to loop knowing queue sizes or the like...

    With it was able to get the graphic test to run on SPI1 (using my hacks for using SDCard pins), or to run on SPI with normal CS pin.

    Note: I have three displays hooked up: that I have #ifdef for which one to use.
    SPI1 ...
    SPI with default CS pins (CS 10, DC 9)

    The third is SPI with CS pins (CS 23, DC 9)

    Funny thing still investigating: if I run the the version with CS 10, only the one display does anything, but if instead I run the one with CS=23, both displays on SPI run in sync...
    I even tried doing a pinMode(10, OUTPUT); after the tft.begin call and both display appear to still run (in sync)

    Edit: never mind it is because pin 10 was floating low. changing to INPUT_PULLUP causes it to no longer output (still see it flicker as it sees the commands...). Could also probably solve by digitalWrite(10, HIGH);

    In case anyone is interested in any of this stuff, I included a zip file, with the SPIN stuff, plus a hacked up ili9341_t3n and the updated graphictest with the different defines for different display.
    Attached Files Attached Files
    Last edited by KurtE; 07-14-2016 at 07:52 PM.

  9. #759
    Quote Originally Posted by Frank B View Post
    A second -red- LED on a dedicated pin would be great... not only to indicate such error-conditions, but for other problems like the NMIs, too (e.g. bus-faults)
    What do you think of a bi-color LED? Something like these. I haven't used this specific part, but other red/green LEDs I've used light orange when both elements are lit at the same time. This effectively gives you a 4 status display(3 colors and off) on one part using only 2 controller pins.
    Last edited by slomobile; 07-15-2016 at 12:14 AM.

  10. #760
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,845
    At this point, the hardware design is pretty much fixed, with the same orange LED as every other Teensy.

  11. #761
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    Hi Paul, just wondering if any of the other new pin numbers you defined are available on the test boards.
    I have verified I an talk to the 8 of them that are part of the 10 pin connector and they have the pin numbers:
    Code:
     3.3V  [] ()  GND
       48  () ()  47
       57  () ()  56
       51  () ()  52
       53  () ()  55
    Right now playing around defining SPI2, may have to do minor tweaks once I know which MISO and MOSI should be the defaults.
    I pushed up changes for SPI2 into my T35_USE_SDCARD_PINS branch of the cores and SPI projects. I have not tested SPI2 yet, but have it compiling and I have a SPIN2 locally
    Last edited by KurtE; 07-15-2016 at 02:53 AM.

  12. #762
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    426
    Quote Originally Posted by KurtE View Post
    Edit: I think the pins map like:
    Code:
    #   PIN ALT0    ALT1    ALT2        ALT3    ALT4        ALT5        ALT6            ALT7
    --  --- ----    ------  ---------   -----   ---------   ------      --------        --------- 
    40  A28         PTA28                       MII0_TXER               FB_A25  
    41  A29         PTA29                       MII0_COL                FB_A24  
    42  A26         PTA26                       MII0_TXD3               FB_A27  
    43  B20         PTB20   SPI2_PCS0                       FB_AD31/SDRAM_D31   CMP0_OUT    
    44  B22         PTB22   SPI2_SOUT                       FB_AD29/SDRAM_D29   CMP2_OUT    
    45  B23         PTB23   SPI2_SIN    SPI0_PCS5           FB_AD28/SDRAM_D28   CMP3_OUT    
    46  B21         PTB21   SPI2_SCK                        FB_AD30/SDRAM_D30   CMP1_OUT    
    47  D8          PTD8    I2C0_SCL                        LPUART0_RX  FB_A16  
    48  D9          PTD9    I2C0_SDA                        LPUART0_TX  FB_A17  
    49  B4  A1_10   PTB4                        ENET0_1588_TMR2 SDRAM_CS1-b FTM1_FLT0   
    50  B5  A1_11   PTB5                        ENET0_1588_TMR3     FTM2_FLT0   
    51  D14         PTD14   SPI2_SIN            SDHC0_D6        FB_A22  
    52  D13         PTD13   SPI2_SOUT           SDHC0_D5        FB_A21  
    53  D12         PTD12   SPI2_SCK    FTM3_FLT0   SDHC0_D4        FB_A20  
    54  D15         PTD15   SPI2_PCS1           SDHC0_D7    FB_A23      
    55  D11         PTD11   SPI2_PCS0           SDHC0_CLKIN LPUART0_CTS_b   FB_A19  
    56  E10         PTE10   I2C3_SDA            I2S0_TXD0   LPUART0_CTS_b   FTM3_CH5    USB1_ID
    57  E11         PTE11   I2C3_SCL            I2S0_TX_FS  LPUART0_RTS_b   FTM3_CH6
    Warning: some of the spacing above is a little off, but hard to fit, Only on ALT7....
    I don't get it, your pin numbers don't look at all like the ones Paul posted, he goes up to 51 and you have 57. Which one is right?

  13. #763
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    Look at the code delta Paul made in core yesterday.
    Last edited by KurtE; 07-15-2016 at 03:54 AM.

  14. #764
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,845
    The code on github is the most up-to-date with the PCB layout.

    I believe we still have a few of the round 2 boards unassembled. If anyone (on the beta testers list) still wants to jump in now, just email Robin. Sometime next week I'm going to order the first prototype run. 2 weeks for the PCB and probably another 1-2 weeks for the BGA soldering. If those work, they will become round 3. If they have any show stopper problems, it'll be another PCB+assembly turn before round 3.

    Soon the extra Ethernet boards are due to arrive. Those will be hand soldered by Erin, so quick turnaround. If anyone else wants to play with Ethernet, email Robin to request one of those boards.

    For the next several days I will be continuing to focus on PCB layout, which also includes 3 boards to make the bed-of-nails test fixture. After next week all the PCBs should be sent, and I'll be able to participate much more here. Until the, please know my absence is due to what's turning out to be the most challenging PCB design I've ever attempted....

  15. #765
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    532
    Paul: Where is the pad/thruhole for bypassing the protection diode for VBUS <-> VIN?
    Sure, I can bypass the diode, that's all well and fine, since my power source is all from the same source.
    I could use a powered hub to bypass the "problem" too.
    2 host ports could be useful if you do not want to use a hub to hook up 2 devices.


    FYI once I bypass the diode, UHS3 works dandy on the native FS OTG. I'll post benchmarks after you answer.

  16. #766
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,241
    Quote Originally Posted by PaulStoffregen View Post
    Any chance you could benchmark simultaneous transmit & receive UDP data flow? Maybe with sequence numbers or some other data inside the packets, so you could detect packet loss?

    Performance metrics are nice, but I'm really most curious to know if there's any packet loss. I recall reading some conversations, maybe from the Beaglebone devs, about issues with packet loss with RMII (but magically solved by using MII) during fast bidirectional data flows.
    Paul, the latest UDP tests I did simulating a TCP flow using a linux "ACK server" has simultaneous flows. I did not observe packet loss in either direction. see post 686. "Absence of proof is not proof of absence."

  17. #767
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    SPI/ILI9341 - Quick update,

    Before I am busy doing other stuff off of the computer, I thought I would upload an updated version of the SPIN and my updated ILI9341_t3n library. The latest hacks to the display code was to handle case where DC is on a chip select pin but the CS pin is not. Then made inline functions that called the SPIBeginTrns.../End calls and added simple test that if I have a _csport, then clear or set it.... Appears to work fine and I am not noticing any change in speed... When I can get back to playing, I will then test SPI1 and SPI2 with using the only 1 CS pin...
    Attached Files Attached Files

  18. #768
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,124
    Quote Originally Posted by KurtE View Post
    SPI/ILI9341 - Quick update,
    Before I am busy doing other stuff off of the computer ...
    That's cool KurtE - I'll look to give it a try. Have you ever worked with the TOUCH display? It needs another CS pin, but uses the same data lines. It seems those fixed (IIRC) ~10-15 commands could be issued with manual CS selection easily enough in the case the SPI is not using SPI0? And when set up with INT_pin it would never poll when a Touch wasn't indicated. From what I know the CS would be asserted before the groups of commands and then dropped when done? Perhaps your work would account for that in the calls?

  19. #769
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,845
    Quote Originally Posted by xxxajk View Post
    Paul: Where is the pad/thruhole for bypassing the protection diode for VBUS <-> VIN?
    There isn't any such thing on the round 1 & 2 beta test boards.

  20. #770
    Senior Member sumotoy's Avatar
    Join Date
    Nov 2012
    Location
    Venezia, Italia
    Posts
    421
    Kurt, I'm confused about K65/K66 pin you used for SPI1 experiments.
    I was supposing use:
    MOSI:0
    SCLK:32
    CS:6
    but you are using:
    DC = 0xe4
    CS = 0xe5
    SCK = 0xe2
    MISO = 0xe3
    MOSI = 0xe1
    Probing with oscilloscope I've seen activity only on PIN 20 and 0 (this one should be MOSI)
    Can you tell me witch pin are you are using (in DEC) and why 0xE1 should be PIN:0, I'm sure I've missed something...

  21. #771
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,754
    It is using hacked version using io pins on sdcard using adapter. Will try later with real easy to get pins

    Forgot to mention yesterday that th oxe1-5 are the physical pin names on the adapter, needed that as only place with multiple CS pins, uses my changes in core and spi to make those pins work. Should now be able to make work on one CS so will try on official Sp1 and Sp2 pins. But maybe not until maybe Mon or Tue.
    Last edited by KurtE; 07-16-2016 at 01:52 PM.

  22. #772
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,124
    K66 at 240 MHz I finally powered up the onehorse i2c bubble display :: HT16K33_Display_Driver. Swapped in K66 edited : C:\sketchbook\libraries\i2c_t3
    Code:
    //#include "Wire.h"
    #include <i2c_t3.h>
    #define Wire Wire1
    //#define Wire Wire2
    Sketch works on Wire and Wire1 as written up to 1,600K, won't run at 2,400K.

    us time to run the 4 digit print loop for 200 digits at 240 MHz except as noted::
    1,257,759 :: At Default Wire.begin Speed and higher Wire.setClock() as noted after .begin()
    387,297 :: Then runs fine at 400K and 3+ times faster
    227,966 :: Doubling to 800K runs fine as well
    177,820 :: At 1,200K runs fine as well
    152,642 :: At 1,600K runs fine as well
    184,969 :: At 1,600K runs fine as well dropped speed to 96 MHz
    340,007 :: At 1,600K runs fine as well dropped speed to 24 MHz
    With setClock(800000UL) a 5ms delay() each loop, to the 200 count test loop still runs faster than default speed at 1,227,956
    With setClock(1600000UL) a 5ms delay() completes at 1,152,639

    <edit> Merged AdaFruit_SSD1306 sample using Wire2 at 400K with above Wire1 at 1.6M at K66 speeds 120 MHz and 216 MHz. Made their busy loops re-entrant to share CPU and Flakes fall smoothly and the bubble digits run nicely. I'll put Manitou's RTC time checker in to see how that works.
    Kris' i2c bubble-display-frontpack interface multiplexor chip is fast and nice running 16 LED 8 segment digits at 1.6M! I don't see a speed in the HT16K33 data sheet - but it's working.
    Last edited by defragster; 07-16-2016 at 10:31 AM.

  23. #773
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    426
    Quote Originally Posted by defragster View Post
    Merged AdaFruit_SSD1306 sample using Wire2 at 400K with above Wire1 at 1.6M at K66 speeds 120 MHz and 216 MHz. Made their busy loops re-entrant to share CPU and Flakes fall smoothly and the bubble digits run nicely. I'll put Manitou's RTC time checker in to see how that works.
    Kris' i2c bubble-display-frontpack interface multiplexor chip is fast and nice running 16 LED 8 segment digits at 1.6M! I don't see a speed in the HT16K33 data sheet - but it's working.
    Cool results, multibus is awesome when it works. I think this thing having 4 buses has a lot more potential for background operation. If I had time I would write an API that would queue traffic and background it as bus time opened up.

    Question - When you run the higher clocks have you ever tried running bus overclock? (IIRC requires editing kinetis.h around line ~760) I wasn't able to get any bus overclock to compile last time I tried.

  24. #774
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,124
    Quote Originally Posted by nox771 View Post
    Cool results, multibus is awesome when it works. I think this thing having 4 buses has a lot more potential for background operation. If I had time I would write an API that would queue traffic and background it as bus time opened up.

    Question - When you run the higher clocks have you ever tried running bus overclock? (IIRC requires editing kinetis.h around line ~760) I wasn't able to get any bus overclock to compile last time I tried.
    Yes - nice to have parallel shared multibus - I'm not sharing - but the 4::1 speed is nice when you can adjust it per device group! Ran 6+ hours ( I didn't sleep enough!) - everything cool and pretty. Can't read a red blur updating - but shoving out a number doesn't take very long to the bubble display - I'll use it to show RTC time diff per second.

    On your pointer - yes - about line 760 in Kinetis.h I made this change at 216MHz and it compiled and is running both displays:
    #elif (F_CPU == 216000000)
    #define F_PLL 216000000
    #ifndef F_BUS
    //#define F_BUS 54000000
    //#define F_BUS 72000000
    #define F_BUS 108000000
    #endif
    Minor difference in overall runtime in usec for 600 number bursts given the i2c time is fixed:
    F_BUS 108000000 == 6,376,109 versus F_BUS 54000000 == 6,417,613

  25. #775
    Senior Member sumotoy's Avatar
    Join Date
    Nov 2012
    Location
    Venezia, Italia
    Posts
    421

    SPI1 test

    Kurt, nevermind, it's too weird to me, finded a better solution. Thanks anyway!
    defragster, I got SPI1 working on a test version of TFT_ILI93XX, you don't need to do anything special or change any define.
    The SPI1 is used only on K64/k66 and when MOSI=0,SCLK=32 and DC=6, in this case CS can be any pin.
    Example:
    Code:
    TFT_ILI93XX tft = TFT_ILI93XX(10,6,255,0,32); //(CS,DC,RST,MOSI,SCLK)
    It's pretty fast since libraries has been thinked to use as less CS than possible, of course there's buffer drawback as well (4 vs 1).
    It's easy to transfer code to TFT_ILI9163C and all the other libraries, if it works ok I'll do it.
    The CS pin is now drived by legacy digitalWriteFast so using direct port method can be much faster! DC it's drived directly by SPI FIFO.
    The TFT_ILI93XX can be used to test ILI9341, here's a benchmark (using SPI_FIFO, 4 bytes buffer vs 1 byte buffer)

    Code:
    Benchmark                Time (microseconds) (K66/96Mhz, ILI9341)
    test                     SPI0           SPI1
    Screen fill              280032         280231
    Text                     13061          15532
    Lines                    73205          79968
    Horiz/Vert Lines         23099          23178
    Rectangles (outline)     14629          14673
    Rectangles (filled)      581465         581870
    Circles (filled)         81090          83012
    Circles (outline)        64639          67148
    Triangles (outline)      17579          19208
    Triangles (filled)       188506         190019
    Rounded rects (outline)  27054          28702
    Rounded rects (filled)   632272         633550
    Last edited by sumotoy; 07-16-2016 at 06:41 PM.

Posting Permissions

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