Forum Rule: Always post complete source code & details to reproduce any issue!
Page 37 of 134 FirstFirst ... 27 35 36 37 38 39 47 87 ... LastLast
Results 901 to 925 of 3338

Thread: Teensy 4.0 First Beta Test

  1. #901
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    Played a little bit with the new "F_BUS" (IPG). Default is 150MHz (max in Reference Manual) ..but..at least with 600MHZ core, F_BUS can work with 300MHZ, too.
    edit: 492000000 Hz at "Ludicrous Speed"
    Last edited by Frank B; 01-14-2019 at 10:02 PM.

  2. #902
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Quote Originally Posted by defragster View Post
    Nothing in particular - just that that it would rollover and be confusing. I was perhaps conflating it with micros rolling in ~87 secs where it was used for longer as a reference.

    Also the quick look I gave to the elapsedus code didn't turn out right - given everything coming or going needs to be handled with 1/F_CPU_ACTUAL in the proper fashion. Having a steady 1 MHz value to feed it would make it fit in less code and run faster. The T_3.x version of elapsedus and micros goes to some effort to resolve/round the current value - running overhead extra code.

    Mike, does NeoPixel modifiy the CycleCounter or just start and use it as a running value? <edit> seems to have two places it starts it and then just reads it for it's value. Though it uses F_CPU for resolution that will be wrong.
    Just went through it again - just to verify. Like you said, just enables and reads. Doesn't modify from what I can see.

  3. #903
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,973
    Quote Originally Posted by mjs513 View Post
    Started with some of the libraries I touched so far:
    Attachment 15599

    Comments - suggestions?
    Thanks. you need to go deeper to find hardware timer that is being used. For example, IntervalTimer uses PIT (maybe all 4 channels), PWM uses some channels of QTIMER and flexPWM timer, IRremote uses flexPWM1 timer, FreqMeasure uses FLEXPWM4...

  4. #904
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Quote Originally Posted by manitou View Post
    Thanks. you need to go deeper to find hardware timer that is being used. For example, IntervalTimer uses PIT (maybe all 4 channels), PWM uses some channels of QTIMER and flexPWM timer, IRremote uses flexPWM1 timer, FreqMeasure uses FLEXPWM4...
    Ok will do. FreqMeasure I got as FlexPWM4, it was obvious at that one. Will relook at the other IntervalTimer again. Will keep in mind that in mind as I go through them.

  5. #905
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Going to test tonight to make sure but this seems to be working - I did a Cycle Counter based Micros from systick_ms. For now it has a unique name to allow Verification - code it replaces is below.

    <edit> problem is taking two volatile vars from systick_isr and the return could cross a tick. Code below measures 11% faster, 17% slower with disable_irq and re-enable_irq? As getting old systick_cycle_count then updated systick_millis_count would add a tick on that call. My auto checked test running 3-4 passes per second [delay(300) to keep sermon happy JIC] on the 120 test values - when it was wrong it was way wrong - test allows ccmicros()+/-1 to pass - will see where it is in a few hours. Can try reading one count twice [before and after the other] and repeating if diff and not disable interrupt ...
    Code:
    uint32_t ccmicros(void)
    {
    	uint32_t ccdelta = ARM_DWT_CYCCNT, usec;
    	ccdelta -= systick_cycle_count;
    	usec = 1000*systick_millis_count + (ccdelta/(F_CPU_ACTUAL/1000000));
    	return usec;
    }
    In the end if it really works it would replace current micros() - including elapsedMicros() usage - no interrupt disabling and what seems to be a lot less code - no conditionals and no wondering how long ago the clock ticked.
    In fact should work over 7 seconds with interrupts disabled. I just put __disable_irq(); and __enable_irq(); around my test code and they run fed from prior systick_ms and delta cycleCounter. So if systicks are lost the clock base ref will diverge - though correction from ccdelta might be workable.
    There is of course the startup issue given that the calculation is delta based we need the base first so while countably accurate up to 200ms, it will 'cusp' to get in sync - I won't show that cute trick that happens after 2nd systick_isr() until I run automated test run overnight

    Works with one added line here:
    Code:
    extern "C" void systick_isr(void)
    {
    	systick_cycle_count += F_CPU_ACTUAL/1000;
    	systick_millis_count++;
    	MillisTimer::runFromTimer();
    }
    This is the current T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\dela y.c
    Code:
    uint32_t micros(void)
    {
    	uint32_t msec, tick, elapsed, istatus, usec;
    	static uint32_t prev_usec=0;
    	static int doprint=180;
    
    	__disable_irq();
    	tick = SYST_CVR;
    	msec = systick_millis_count;
    	istatus = SCB_ICSR;     // bit 26 indicates if systick exception pending
    #ifndef SYSTICK_EXT_FREQ
    	const uint32_t fcpu = F_CPU;
    #endif
    	__enable_irq();
    	istatus &= SCB_ICSR_PENDSTSET;
    #ifdef SYSTICK_EXT_FREQ
    	if ((istatus & SCB_ICSR_PENDSTSET) && (tick == 0 || tick > (SYSTICK_EXT_FREQ / 2000))) {
    #else
    	if ((istatus & SCB_ICSR_PENDSTSET) && (tick == 0 || tick > (fcpu / 2000))) {
    #endif
    		msec++;
    	}
    #if defined(SYSTICK_EXT_FREQ) && SYSTICK_EXT_FREQ <= 1000000
    	elapsed = (SYSTICK_EXT_FREQ / 1000) - tick;
    	if (tick == 0) elapsed = 0;
    	usec = msec * 1000 + elapsed * (1000000 / SYSTICK_EXT_FREQ);
    #elif defined(SYSTICK_EXT_FREQ) && SYSTICK_EXT_FREQ > 1000000
    	elapsed = (SYSTICK_EXT_FREQ / 1000) - tick;
    	if (tick == 0) elapsed = 0;
    	usec = msec * 1000 + elapsed / (SYSTICK_EXT_FREQ / 1000000);
    #else
    	elapsed = (fcpu / 1000) - tick;
    	if (tick == 0) elapsed = 0;
    	usec = msec * 1000 + elapsed / (fcpu / 1000000);
    #endif
    	if (usec < prev_usec && doprint) {
    		if (doprint > 0) doprint--;
    	}
    	prev_usec = usec;
    	return usec;
    }
    output from current test after 471 seconds with this running each 3 seconds:
    base rtc ticks=: 471

    micros: 471617000 // base times before ALL test groups
    ccmicros: 471617026
    millis: 471617

    micros: 471620330 // base times after ALL test groups
    ccmicros: 471620343
    millis: 471620
    // This group updates 60,000 cpu cycles apart or 0.1 ms
    471617105 471617205 471617305 471617405 471617505 471617605 471617705 471617805 471617905 471618005
    471618105 471618205 471618305 471618405 471618505 471618605 471618705 471618805 471618905 471619005
    471619105 471619205 471619305 471619405 471619505 471619605 471619705 471619805 471619905 471620005

    // This group updates 6000 cpu cycles apart or 0.01 ms
    471620015 471620025 471620035 471620045 471620055 471620065 471620075 471620085 471620095 471620105
    471620115 471620125 471620136 471620146 471620156 471620166 471620176 471620186 471620196 471620206
    471620216 471620226 471620236 471620246 471620256 471620266 471620276 471620286 471620296 471620306

    // This group updates 600 cpu cycles apart or 0.001 ms
    471620307 471620308 471620309 471620310 471620311 471620312 471620313 471620314 471620315 471620316
    471620317 471620318 471620319 471620320 471620321 471620322 471620323 471620324 471620325 471620326
    471620327 471620328 471620329 471620330 471620331 471620332 471620333 471620334 471620335 471620336
    Last edited by defragster; 01-15-2019 at 10:17 AM.

  6. #906
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    CORE_PINS.H

    Think minor error on pin assignment:
    Code:
    // pad config registers control pullup/pulldown/keeper, drive strength, etc
    #define CORE_PIN0_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_02
    #define CORE_PIN1_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_03
    Should this be:
    Code:
    // pad config registers control pullup/pulldown/keeper, drive strength, etc
    #define CORE_PIN0_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_03
    #define CORE_PIN1_PADCONFIG	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B0_02
    Its about line 337

  7. #907
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,973
    Quote Originally Posted by manitou View Post
    seems to fix the inversion problem with pins 0 and 1 (and presumably with pins 24 and 25).
    With T4 breakout, I checked the PWM waveforms on the backside pins and confirmed PWM on pins 24 and 25 have proper polarity. Also did digitalWrite tests on backside pins, and Rx-Tx tests on Serial6, Serial7, Serial8. Also did GPT input capture on pin 26 (ref post #146 )

  8. #908
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,683
    Yesterday I was mostly busy with some other stuff, but did some experimenting on my ili9341_t3n library and SPIN...

    So far I am not having any luck updating the SPI->TCR register on the fly and get the results output. Trying to use for DC.

    I have hacked the code to enable the one CS pin to be enabled in SPI mode and I use the GPIO Set/Clear registers to manipulate the CS pin for CS

    The graphic test program runs and does manipulate all of the pins but having issues.

    a) My code to wait until transmission is complete is not working, so CS pin unasserted to early. I don't see anything like the EOQ flag that was used for T3.x in these libraries, so may update the SPIN code to work like TLC and count words/bytes output versus ones received back...

    b) The changing of the TCR - while data is still in FIFO is not working and everything is output in 8 bits only...

    c) The attempt to change which CS pin is asserted from 0 to non-zero is not working, currently the real CS is being set/cleared for each byte...

    Here is an LA output showing the starting to try to clear the screen.
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	16 
Size:	35.8 KB 
ID:	15604
    The trace line (CS, Reset, DC - hardware controlled CS, MOSI, SCLK, MISO)

    Let me know if anyone wishes to play along, and I could update my GITHUB projects with this WIP

    EDIT: - Found typo errors in my macros (used || instead of | ) So getting some better outputs...
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	15 
Size:	52.1 KB 
ID:	15605
    Now to hack up fix for knowing when transmission is complete to update CS pin at the proper time.


    Kurt

    P.S. - @Frank B - I meant to say it yesterday, sorry to hear about your family member going to the hospital. I hope they are doing better! Take care!
    Last edited by KurtE; 01-15-2019 at 02:12 PM.

  9. #909
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    @KurtE
    Let me know if anyone wishes to play along, and I could update my GITHUB projects with this WIP
    I started this so I willing to play along You might want to check out TXCOUNT and maybe tx watermark? Maybe one of these will help.

    Working another problem I am having, really just don't understand how to do it to be honest but will post that as a separate question

    EDIT: That second image is just about what I saw on the scope when I hooked up DC and CS to the scope with the Adafruit library - man logic analyzers are nice

  10. #910
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,683
    Yep - Still WIP - But I pushed up T4_WIP branches for my SPIN and ili9341_t3n github projects...

    Will be busy with some other stuff this morning... Will play more later. Also want to move some of my CS pin hacks out of the ILI9341_t3n library and put into SPI library update. That is define pin 10 is pinIsChipSelect in hardware table and to have the setCS put the pin into SPI mode...
    i.e. let SPI do the normal SPI stuff here...

  11. #911
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    USING ALTERNATE DEFINITIONS OF PINS - HOW TO?

    Getting myself really confused on this one, trying to read the manual and testing. Looking at PINs 0 and 1 for instance the default is Serial1 (LPUART6). Now if I want to reassign it to XBARA or FLEXCAN. I was looking at the quadrature encoder module and it use the xbara pins for input. Anyway this is the process I think:

    1. Turn LPUART6 clock off (CCGR3)
    2. Disable the LPUART6 IRQ
    3. didn't see a way to update the vtable so guess that stays
    4. Update pin configurations, i.e.,
    Code:
    000 ALT0  Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
    001 ALT1  Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
    010 ALT2  Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6
    and sion bit to enable
    5. Select input - output modes for pins, i.e.
    Code:
    IOMUXC_FLEXCAN2_RX_SELECT_INPUT for Flexcan
    xbar_connect  (saw this in pwm.c)
    6. Configure Flexcan2 or Xbar clocks
    7. Enable clocks with CCM_CCGR0 or CCM_CCGR2
    8. Almost forgot enable IRQs for XBAR or FLEXCAN2

    Still need to work some of the details but just want to see if this makes sense and I am on the right track.

  12. #912
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Quote Originally Posted by KurtE View Post
    Yep - Still WIP - But I pushed up T4_WIP branches for my SPIN and ili9341_t3n github projects...

    Will be busy with some other stuff this morning... Will play more later. Also want to move some of my CS pin hacks out of the ILI9341_t3n library and put into SPI library update. That is define pin 10 is pinIsChipSelect in hardware table and to have the setCS put the pin into SPI mode...
    i.e. let SPI do the normal SPI stuff here...
    Thanks = will work on this, this afternoon. Just picked up a stepper motor and Adafruits breakout motor controller board to test their library. Have their shield but that's a pain to work with. So have a bunch of soldering to do this afternoon as well.

  13. #913
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    Problem(?) - not sure if it is..

    I replaced set_arm_clock(600000000); with set_arm_clock(12000000); (12MHz) - teensy ist still fast but that is not the problem
    If I use this, the T4 blinks slowly (orange LED) after upload, and I have to press the button.

  14. #914
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by Frank B View Post
    Problem(?) - not sure if it is..

    I replaced set_arm_clock(600000000); with set_arm_clock(12000000); (12MHz) - teensy ist still fast but that is not the problem
    If I use this, the T4 blinks slowly (orange LED) after upload, and I have to press the button.
    @Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?

    I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?

    Current test running is on the way to us wrap - currently at 2,857,980,987 with 1024 * 2748000 successful tests of 1us update … then I'll try one more edit without int disable - my _isr occurred test correction was faulty.

  15. #915
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Quote Originally Posted by defragster View Post
    @Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?

    I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?

    Current test running is on the way to us wrap - currently at 2,857,980,987 with 1024 * 2748000 successful tests of 1us update … then I'll try one more edit without int disable - my _isr occurred test correction was faulty.
    Tim,
    Meant to say it last night, but, great work on the microsecond timer, hope it gets incorporated.

    @Frank. There are so many different clocks that can get affected by the arm clock. Tim may be right about USB being offline - ran to a similar problem last night when trying to redefine pins and associated clocks. Sketch updates wouldn't load unless I hit the button. Once I changed the clocks back uploads worked normal.

  16. #916
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    Quote Originally Posted by defragster View Post
    @Frank: Was the set_arm_clock(12000000) in the active sketch before upload? So the T4 is not doing a restart after the upload? Is that because USB is offline at 12 MHz?
    Yes it was active, and USB is online.. so I don't know the reason.

    Quote Originally Posted by defragster View Post
    I refined my [cc]micros() using ARM_DWT_CYCCNT and it is working with noInterrupts(). It takes about 19% longer and the codeline added to systick_isr() - is that better than wasting a GPT timer to work around the slow systick driven clock?
    Good job! That's fine in my opinion Does the code disable interrupts? If yes, is there a way without it?


    I played with SPI, again.. I have a serious problem with SPI, or SPI with me..
    How do you guys do it witout the gap between bytes?
    If I use 32BIT transfers, it looks like this:
    Click image for larger version. 

Name:	2019-01-15 23_26_47-Start.jpg 
Views:	26 
Size:	19.0 KB 
ID:	15613
    o...even then gaps between BYTES..(32BIt!!) that effectivly halfes the transferrate.. What the hell i'm doing wrong? (24MHz here)

    @Kurt, LPSPI_CCR_SCKDIV(div) /*| LPSPI_CCR_DBT(0);*/ does not help.
    Last edited by Frank B; 01-15-2019 at 09:45 PM.

  17. #917
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by mjs513 View Post
    Tim,
    Meant to say it last night, but, great work on the microsecond timer, hope it gets incorporated.
    ...
    Thanks Mike - I was wondering So my current test with disabling interrupts just completed a wrap of us uint32_t. This test runs for 1024 us changes in a row and stores the value into an array when it changes. Then I compare sequential elements for 1us difference. Here is where that completed and crossed the number wrap of us's.
    Code isn't much so posted below for any reviews ??? - this is the Version that allows INTERRUPTS TO STAY ON! Will do a PR if no notes and the current test wraps without error.
    Paul: Is F_CPU_ACTUAL valid at all clock speeds so this works without ifdef's of the current micros()?
    This could Port back to the T_3.6 and T_3.5 ( and T_3.2 ) if the cycle counter was started?
    This shows 40 dots printed to entertain me for the just over 4 seconds it takes to test the 1024 values 4000 times per line. After that running count is new ccmicros() with usable last digit and the current micros() with a frozen digit.
    Code:
    ........................................ #1024's=4116000 @ccus=4279366619 <> us=4279366610
    ........................................ #1024's=4120000 @ccus=4283522713 <> us=4283522710
    ........................................ #1024's=4124000 @ccus=4287678817 <> us=4287678810
    ........................................ #1024's=4128000 @ccus=4291834926 <> us=4291834920
    ........................................ #1024's=4132000 @ccus=1023739 <> us=1023734
    ........................................ #1024's=4136000 @ccus=5179837 <> us=5179834
    ........................................ #1024's=4140000 @ccus=9335940 <> us=9335934
    ........................................ #1024's=4144000 @ccus=13492033 <> us=13492024
    ........................................ #1024's=4148000 @ccus=17648127 <> us=17648124
    ........................................ #1024's=4152000 @ccus=21804225 <> us=21804224
    ........................................ #1024's=4156000 @ccus=25960333 <> us=25960324
    ........................................ #1024's=4160000 @ccus=30116431 <> us=30116424
    ........................................ #1024's=4164000 @ccus=34272524 <> us=34272524
    ........................................ #1024's=4168000 @ccus=38428632 <> us=38428624
    ........................................ #1024's=4172000 @ccus=42584735 <> us=42584734
    ........................................ #1024's=4176000 @ccus=46740843 <> us=46740834
    ........................................ #1024's=4180000 @ccus=50896951 <> us=50896944
    ........................................ #1024's=4184000 @ccus=55053054 <> us=55053054
    ........................................ #1024's=4188000 @ccus=59209152 <> us=59209144
    ........................................ #1024's=4192000 @ccus=63365245 <> us=63365244
    ........................................ #1024's=4196000 @ccus=67521343 <> us=67521334
    ........................................ #1024's=4200000 @ccus=71677441 <> us=71677434
    ........................................ #1024's=4204000 @ccus=75833534 <> us=75833534
    ........................................ #1024's=4208000 @ccus=79989627 <> us=79989624
    ........................................ #1024's=4212000 @ccus=84145735 <> us=84145734
    ........................................ #1024's=4216000 @ccus=88301838 <> us=88301834
    ........................................ #1024's=4220000 @ccus=92457931 <> us=92457924
    ........................................ #1024's=4224000 @ccus=96614029 <> us=96614024
    ........................................ #1024's=4228000 @ccus=100770122 <> us=100770114
    ........................................ #1024's=4232000 @ccus=104926227 <> us=104926224
    ........................................ #1024's=4236000 @ccus=109082325 <> us=109082324
    ........................................ #1024's=4240000 @ccus=113238424 <> us=113238424
    This version looks like this timewise for repeat calls:
    50K micros: 1647897
    50K ccmicros: 1950699
    Using the non interrupt display version looks a bit faster - on average:
    50K micros: 1597772
    50K ccmicros: 1601041
    So far it is running right - just finished the first 2.3 million sets of 1024 tests:
    ... #1024's=2336000 @ccus=2447826438 <> us=2447826430
    This is the current code in use to restart if it catches systick_isr having fired:
    Code:
    uint32_t ccmicros(void)
    {
    	uint32_t ccdelta, usec, smc, smc2;
    	do {
    		smc = systick_millis_count;
    		ccdelta = ARM_DWT_CYCCNT;
    		ccdelta -= systick_cycle_count;
    		smc2 = systick_millis_count;
    	} while ( smc != smc2 );
    	usec = 1000*smc + (ccdelta/(F_CPU_ACTUAL/1000000));
    	return usec;
    }
    Any ideas for trouble spots or improvements?

    Here's the code in use to establish the base for the Arm CycCnt in the first 2 systicks as the first fire of the _isr() may hit before the cycle counter is running:
    Code:
    static void systick_isr_sync(void)
    {
    	systick_cycle_count = ARM_DWT_CYCCNT;
    	systick_millis_count++;
    	if ( 2 == systick_millis_count )
    	_VectorsRam[15] = systick_isr;
    }
    static void configure_systick(void)
    {
    	_VectorsRam[14] = pendablesrvreq_isr;
    	_VectorsRam[15] = systick_isr_sync;
    	SYST_RVR = (SYSTICK_EXT_FREQ / 1000) - 1;
    	SYST_CVR = 0;
    	SYST_CSR = SYST_CSR_TICKINT | SYST_CSR_ENABLE;
    	SCB_SHPR3 = 0x20000000;  // Systick = priority 32
    	ARM_DEMCR |= ARM_DEMCR_TRCENA;
    	ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
    	systick_cycle_count = ARM_DWT_CYCCNT;
    }
    And then the real _isr() code with one line added:
    Code:
    extern "C" void systick_isr(void)
    {
    	systick_cycle_count += F_CPU_ACTUAL/1000;
    	systick_millis_count++;
    	MillisTimer::runFromTimer();
    }

  18. #918
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,683
    @Frank B - SPI - No gaps....

    As I mentioned in some previous post (getting hard to keep track of things here)

    Transfer delays: a couple of things.

    A certain amount of the time is taken up by the simple overhead.
    So: SPI.transfer(0);SPI.transfer(1);
    Each transfer puts the thing into the fifo (TDR) and then we wait for the data to be shifted out and then wait for SPI to say that SPI completed and data is available on RDR, which often we then read and ignore, finally returning, to repeat.

    Now currently in the code there is now a defined delay after a transfer complete: I added it in the SPISettings...
    ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2);

    I added the DBT settings. (Page 2660) - Some of this was guesstimates by me... Why?

    If you do what I mentioned, SPI.transfer(0); SPI.transfer(1);
    You already get a significant delay without it...
    But: if you do:
    Code:
        uint8_t buf[] = {0, 1};
        SPI.transfer(buf, NULL, sizeof(buf));
    This uses the FIFO buffer, and with the FIFO buffer, without the DBT settings, the gap between bytes defaults to something like 2SPI timing units or when measure was just a blip on my Logic Analyzer... So I set it up... And then I measured at near full speed, asked 30mhz, 8mhz, 2mhz, 400khz... And it measured reasonably close...

    One thing I thought of was to hack the field in the CCR, like 0 it when Transfer(0), and Transfer(16) are called and set it for buffer transfers... But then would have to decide should it default to being set, such that if anyone like my ili9341_t3n library code who uses the queue would have proper timing...

    Now still trying to figure out how to know when all transfers have fully shifted out... More experiments...

    @Paul and @mjs513 - I did another PR on my open SPI changes (Fix for Serial Flash) - that now will return 1 if you ask if pin 10 is a chip select pin and it will set it into SPI mode if you call setCS(10);

  19. #919
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    @Frank - we cross posted

    The "Leave Interrupts Running version" just completed a uint32_t wrap of microseconds on the clock - passed my testing where out of 4,293,134,314 us up to the WRAP point I tested 4,210,688,000 to present sequential microseconds - and the new versus the old micros() doesn't diverge.

    ........................................ #1024's=4108000 @ccus=4288978220 <> us=4288978220
    ........................................ #1024's=4112000 @ccus=4293134314 <> us=4293134310
    ........................................ #1024's=4116000 @ccus=2323112 <> us=2323104
    ........................................ #1024's=4120000 @ccus=6479219 <> us=6479214
    ........................................ #1024's=4124000 @ccus=10635321 <> us=10635314
    ........................................ #1024's=4128000 @ccus=14791424 <> us=14791424

    Now the hardest part … jousting with GitHub to get a Pull request entered ...

    As far as the time of the call - last post showed one set of 10K loops of 5 calls varied. Here is a set of 10 of those 50K each runs - looks like this CycleCount version runs in the same time but does not stop interrupts, and gives the true us's digit. NOTE: Times are in ARM_DWT_CYCCNT clock cycles - <33.2 clocks for each at 600 MHz.
    50K micros: 1657928
    50K ccmicros: 1650100

    50K micros: 1657870
    50K ccmicros: 1650285

    50K micros: 1657862
    50K ccmicros: 1651132

    50K micros: 1657872
    50K ccmicros: 1650306

    50K micros: 1657854
    50K ccmicros: 1652015

    50K micros: 1657862
    50K ccmicros: 1650303

    50K micros: 1657855
    50K ccmicros: 1653517

    50K micros: 1657869
    50K ccmicros: 1650305

    50K micros: 1657855
    50K ccmicros: 1655375

    50K micros: 1657866
    50K ccmicros: 1650303

  20. #920
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Tim u got that right:
    Now the hardest part … jousting with GitHub to get a Pull request entered ...
    @KurtE - just downloaded your forked version of SPI so I could get you t3n_WIP running. Put a scope on the CS and DC pins running the GraphicsTest sketch. DC is firing constantly - have to come up with a better sketch to test with. Just started looking so not much else to say at this point.

  21. #921
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by mjs513 View Post
    Tim u got that right:
    ...
    And tempmon_init broke my build after copying merged files - so I got current core Teensy4 - now I'm stuck on this. Is this a bug in github CORE files or something out of sync on my end?
    T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\Inte rvalTimer.cpp:38:119: error: expected ',' or ';' before '__attribute'

    static void (*funct_table[4])(void) __attribute((aligned(32))) = {dummy_funct, dummy_funct, dummy_funct, dummy_funct} __attribute((aligned(32)));

    ^

  22. #922
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,331
    Quote Originally Posted by defragster View Post
    And tempmon_init broke my build after copying merged files - so I got current core Teensy4 - now I'm stuck on this. Is this a bug in github CORE files or something out of sync on my end?
    Tim
    Not sure why tempmon_init would break your build. I see the function table in interval timer but it not throwing any errors when I run a intervaltimer example sketch that I have.

  23. #923
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    I had not done an update of my core in some time - I didn't have tempmon code - the init is in a file I touched so to do my code merge I needed to update.

    With that done I get the dummy error in code I'm not using - it worked before when I did it - but something was added and my compiler doesn't like the syntax.

    I just hacked it off to compile - but now the nebulous chore of watching time pass is made difficult because the old core micros() is no more - and millis and elapsedMillis not working … I'm hoping the problem relates to that vector not being aligned but am not sure why it is broken or how to fix it properly...

  24. #924
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,683
    Making some progress with my ili9341_t3n/SPIN library implementations

    Needed to clear out some of the states (W1C in the SR register). Appears to be working better.

    Still needs work. Also need to enable frame buffer, also need to work on DMA support and ...

    But if I run the Adafruit_ili9341 library, the timings show:
    Code:
    ILI9341 Test!
    SPI MISO: 12 MOSI: 11, SCK: 13
    Display Power Mode: 0x94
    MADCTL Mode: 0x48
    Pixel Format: 0x5
    Image Format: 0x80
    Self Diagnostic: 0xC0
    Benchmark                Time (microseconds)
    Screen fill              993370
    Text                     49080
    Lines                    465640
    Horiz/Vert Lines         81250
    Rectangles (outline)     51720
    Rectangles (filled)      2061730
    Circles (filled)         288390
    Circles (outline)        203800
    Triangles (outline)      106080
    Triangles (filled)       670390
    Rounded rects (outline)  97400
    Rounded rects (filled)   2241290
    Done!
    If I run mine, which at least some of the outputs are coming to the screen... And maybe a crash... But some progress...
    Code:
    LI9341 Test!
    SPI MISO: 12 MOSI: 11, SCK: 13
    After TFT Begin
    13
    Display Power Mode: 0x10
    MADCTL Mode: 0x10
    Pixel Format: 0x10
    Image Format: 0x10
    Self Diagnostic: 0x10
    Benchmark                Time (microseconds)
    Screen fill              244740
    Text                     10920
    Lines                    68330
    Horiz/Vert Lines         20010
    Rectangles (outline)     12780
    Rectangles (filled)      502180
    Circles (filled)         73360
    Circles (outline)        62200
    Triangles (outline)      16330
    Triangles (filled)       166190
    Rounded rects (outline)  27460
    Rounded rects (filled)   547750
    Hit key to continue
    Again there are issues to resolve, but hopefully progress...
    As mentioned in previous post SPI project updated, likewise SPIN and ILI9341_t3n project updated as well.

  25. #925
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Undid my few changes - and IntervalTimer.cpp:38:119 still broken - is there something outside of CORES I need to update?

    <edit> - I reverted my few changes and my system is still broken on this last Merge from Frank 3 days ago:
    T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\Inte rvalTimer.cpp:38:119: error: expected ',' or ';' before '__attribute'

    static void (*funct_table[4])(void) __attribute((aligned(32))) = {dummy_funct, dummy_funct, dummy_funct, dummy_funct} __attribute((aligned(32)));
    Last edited by defragster; 01-16-2019 at 02:40 AM.

Posting Permissions

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