Forum Rule: Always post complete source code & details to reproduce any issue!
Page 20 of 134 FirstFirst ... 10 18 19 20 21 22 30 70 120 ... LastLast
Results 476 to 500 of 3341

Thread: Teensy 4.0 First Beta Test

  1. #476
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,693
    @FrankB - Great work. Would be interesting in seeing it at some point as to play along... I would like to play some with SPI library and if not already done, flesh out more of it. Like transfer(buf, rxbuf, cnt) and the DMA versions. But figure would be good to get most of the SerialX objects working properly.

    @Paul - I issued PR for SerialX stuff. Still have not split up objects into their own files yet. Will do that pretty soon and make a version of the yield() code that hopefully only pulls in those SerialX objects that the users program requires.

    But before that maybe a few more things to flesh out. Like implement ::end(). Also more testing...


    Would also like to try out some of the features to see if it works with Hardware. Like maybe driving some Robotis Servos... Was trying to figure out hardware setup for this, and thought of a hacky way to do so. I think I could use one of the Robotis OpenCM485 expansion boards, that you typically plug in an OpenCM9.04 board, and jumper some appropriate pins to the correct place on this board, for RX, TX, direction... Might just work

    Might also want to hack up my own library that others use BioloidSerial for controlling servos and make it work with this board as well. Note: need to maybe add in support in my library for it's version of half duplex...

  2. #477
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    Re: analogWrite() anomalies

    In my testing pin 0 and pin 1 PWM are inverted??? There is a polarity bit in OCTRL, but that is zero'd, so it should be OK. So as a hack, I reversed polarity for pins 0 and 1 in flexpwmWrite() in hardware/teensy/avr/cores/teensy4/pwm.c
    Code:
    void flexpwmWrite(IMXRT_FLEXPWM_t *p, unsigned int submodule, uint8_t channel, uint16_t val)
    {
    uint16_t mask = 1 << submodule;
    uint32_t modulo = p->SM[submodule].VAL1;
    uint32_t cval = ((uint32_t)val * (modulo + 1)) >> analog_write_res;
    if (cval > modulo) cval = modulo; // TODO: is this check correct?

    //printf("flexpwmWrite, p=%08lX, sm=%d, ch=%c, cval=%ld\n",
    //(uint32_t)p, submodule, channel == 0 ? 'X' : (channel == 1 ? 'A' : 'B'), cval);
    p->MCTRL |= FLEXPWM_MCTRL_CLDOK(mask);
    switch (channel) {
    case 0: // X
    p->SM[submodule].VAL0 = cval;
    p->SM[submodule].OCTRL = FLEXPWM_SMOCTRL_POLX;
    p->OUTEN |= FLEXPWM_OUTEN_PWMX_EN(mask);
    //printf(" write channel X\n");
    break;
    case 1: // A
    ...
    that seemed to fix duty polarity on pins 0 and 1. Doesn't make sense (is there an errata?), and there may be a better fix.
    @manitou - thanks for tracking down the polarity problem. Thought I was going crazy.

  3. #478
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    I got this morning's updated WIRE lib to my machine - Adafruit SSD1306 still getting 'Wire' not declared on Verify build of T_3.6 and T_3.2 of:
    >> "T:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit _SSD1306\examples\ssd1306_128x64_i2c\ssd1306_128x6 4_i2c.ino"
    It does Verify on the TD_1.45 w/IDE1.88, not seeing why that won't build - Console display of paths and included lib looks right.

    I see that the T4 version of 'T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy3\avr_ emulation.h" is where 'class SPCRemulation; class SPSRemulation; class SPDRemulation;' reside so that is pending that completion.

    At least I left KurtE's combined test running as I've been distracted. It ran again the last 7.6 hours with (166 Hz * 2) HEX digit updates on Lcd Display plus the other stuff - noted prior.

  4. #479
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    ANALOGRESOLUTION
    Think I have a fix for that, bit manipulation is real weak, but if you want to give it a try, you can put this in any sketch an just call it to change the resolution:
    Code:
    void aReadRes(unsigned int bits)
    {
      uint32_t tmp32, mode;
    
       if (bits == 8) {
        // 8 bit conversion (17 clocks) plus 8 clocks for input settling
        mode = ADC_CFG_MODE(0) | ADC_CFG_ADSTS(3);
      } else if (bits == 10) {
        // 10 bit conversion (17 clocks) plus 20 clocks for input settling
        mode = ADC_CFG_MODE(1) | ADC_CFG_ADSTS(2) | ADC_CFG_ADLSMP;
      } else {
        // 12 bit conversion (25 clocks) plus 24 clocks for input settling
        mode = ADC_CFG_MODE(2) | ADC_CFG_ADSTS(3) | ADC_CFG_ADLSMP;
      }
      tmp32  = (ADC1_CFG & ((1u << 22)-1) << 10);
      tmp32 |= (ADC1_CFG & ((1u << 2)-1) << 0);  // ADICLK
      tmp32 |= ADC1_CFG & (((1u << 3)-1) << 5);  // ADIV & ADLPC
    
      tmp32 |= mode; 
      ADC1_CFG = tmp32;
    }
    have to take a break - eyes an mind are mush

  5. #480
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    DMA Problem - Cache

    Paul, what's the best solution:
    I have a fillScreen:
    Code:
    void ILI9341_t4DMA::fillScreen(uint16_t color)
    {
      uint32_t c = (color << 16) | color;
      uint32_t * buf32;
      buf32 = (uint32_t * ) buffer;
      unsigned i = 0;
      do {
        buf32[i++] = c; buf32[i++] = c;
        buf32[i++] = c; buf32[i++] = c;
        buf32[i++] = c; buf32[i++] = c;
        buf32[i++] = c; buf32[i++] = c;
      } while (i < BUFSIZE32);
      arm_dcache_flush_delete(buffer, 256);
    }
    Without that arm_dcache_flush_delete(buffer, 256); I get "snow" (random pixels) on the first part of the screen (transfered via DMA). Buffer is in OCRAM, (via malloc(), and afterwards aligned to 32).
    I fear, when using other operations, like "line" or "circle" i have to flush, too - all locations ? - That will be slower than without cache and much more code. This flush contains a loop, too... :-(

    Can you give a short example how to disable the cache for my buffer (320*240*2 bytes) or a hint how to do it better ? I guess, there must be a better solution..


    Edit: Can I configure it as write-trough? - It's write-back, i guess? Maybe it makes sense to configure the whole OCRAM as write-though.. ?


    Last edited by Frank B; 01-05-2019 at 07:29 PM.

  6. #481
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,064
    If you want to experiment with different cache settings, find this in startup.c.

    Code:
            SCB_MPU_RBAR = 0x20200000 | REGION(3); // RAM (AXI bus)
            SCB_MPU_RASR = MEM_CACHE_WBWA | READWRITE | NOEXEC | SIZE_1M;
    You can try changing MEM_CACHE_WBWA to MEM_CACHE_WB, MEM_CACHE_WT, or MEM_NOCACHE.

    I hope you'll do something like a digitalWriteFast() before and after each code segment and actually measure the pulse width to see how long the code is really taking.

    For a general purpose TFT library, which "plays nice" on the SPI bus with other libs, a more complex and slightly slower update which does a few lines at a time as its own SPI transaction is probably going to be needed. I know you're probably not happy with ideas like that. No pressure right now, but please keep in mind the overall value of a general purpose library is more than only its raw speed.

  7. #482
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    Ok, I was about to write that I found exactly this location..

    changing
    Code:
        SCB_MPU_RBAR = 0x20200000 | REGION(3); // RAM (AXI bus)
        SCB_MPU_RASR = MEM_CACHE_WBWA | READWRITE | NOEXEC | SIZE_1M;
    to
    Code:
        SCB_MPU_RBAR = 0x20200000 | REGION(3); // RAM (AXI bus)
        SCB_MPU_RASR = MEM_CACHE_WT | READWRITE | NOEXEC | SIZE_1M;
    Works.

    If using "autoRefresh" - which refreshes the whole screen, there is no way to "play nice" as it needs exclusive access - no way without. Either this or no autorefresh with a fixed framerate.
    It will be possible to disable this and refresh manually by calling a function.

    Speed: Yes, I use transactions and other techniques, but this does not matter. Its not about speed - it is just not working without disabling the write-back. It's a problem with the IMXT Hardware - You'll see it if you do more with DMA.. Perhaps it's a silicon-bug - don't know. DMA should read from the cache.. hm, difficult. No, more likely, it is intended like it is. So, don't use write-back in conjunction with DMA. - the best solution in my eyes.
    Last edited by Frank B; 01-05-2019 at 09:06 PM.

  8. #483
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    So cool the 1062 is coming with the extra 512KB! - that will have different/developing segmentation/cache rules as Paul noted :: bummer to waste/suffer with the case of 1052's until they get delivered.

    Mike for UBlox we just went toward 128 at the time IIRC as that was enough to buffer one message.

    And as Mike noted - "Never ceases to amaze me, what you all can do."

  9. #484
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,064
    For performance optimization, another idea to try is incorporating those address writes to SCB_CACHE_DCCIMVAC inside your loop every 32 bytes, rather than calling arm_dcache_flush_delete() after all the writes.

    Now this is the part where I'm going to suggest possibly bad ideas...

    ARM's guidance is to always execute a DSB instruction, which apparently forces the cache operations to be done.

    https://developer.arm.com/docs/dui06...hints-and-tips

    If you call arm_dcache_flush_delete(), all the writes to SCB_CACHE_DCCIMVAC are done in a loop, then one DSB is executed at the end. I'd really like to know how much time that BSD instruction takes. Does it actually stall the CPU for many cycles? I do not know, and honestly I really can not spend time right now experimenting (as much as I would like to do so) because so much other stuff needs my attention. But at least I can write this message with my thoughts and questions...

    If the DSB instruction causes the cache to flush and stalls the CPU for many cycles, another question is whether it allows the CPU to continue quickly when there is just 1 cache row needing to be written (as one atomic AXI bus operation)? If so, perhaps putting DSB inside the loop which is writing to the cache might help? Or it might make things worse? I do not know. Someday I hope to have more time to experiment with this and so much more. For now, all I can do is mention it, because the USB code desperately needs to be improved....

  10. #485
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    You probably don't want arduino users to fiddle with flush-delete or other weird things.. if you simultanoulsy use things like single precision consts to ensure they do this simple thing right.
    You and me and all in this thread can do it - others probably not.

    Pullrequest :
    https://github.com/PaulStoffregen/cores/pull/316


    Last edited by Frank B; 01-05-2019 at 08:29 PM.

  11. #486
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,973
    FWIW, the NXP SDK EVKB examples usually used non-cacheable memory for DMA buffers, and many examples used SCB_DisableDCache() to disable DCache

    Code:
    __STATIC_INLINE void SCB_DisableDCache (void)
    {
      #if defined (__DCACHE_PRESENT) && (__DCACHE_PRESENT == 1U)
        register uint32_t ccsidr;
        register uint32_t sets;
        register uint32_t ways;
    
        SCB->CSSELR = 0U; /*(0U << 1U) | 0U;*/  /* Level 1 data cache */
        __DSB();
    
        SCB->CCR &= ~(uint32_t)SCB_CCR_DC_Msk;  /* disable D-Cache */
        __DSB();
    
        ccsidr = SCB->CCSIDR;
    
                                                /* clean & invalidate D-Cache */
        sets = (uint32_t)(CCSIDR_SETS(ccsidr));
        do {
          ways = (uint32_t)(CCSIDR_WAYS(ccsidr));
          do {
            SCB->DCCISW = (((sets << SCB_DCCISW_SET_Pos) & SCB_DCCISW_SET_Msk) |
                           ((ways << SCB_DCCISW_WAY_Pos) & SCB_DCCISW_WAY_Msk)  );
            #if defined ( __CC_ARM )
              __schedule_barrier();
            #endif
          } while (ways-- != 0U);
        } while(sets-- != 0U);
    
        __DSB();
        __ISB();
      #endif
    }
    and most of the example with ISR's had the following at the end of the IRQHandler()
    Code:
    /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F, Cortex-M7, Cortex-M7F Store immediate overlapping
      exception return operation might vector to incorrect interrupt */
    #if defined __CORTEX_M && (__CORTEX_M == 4U || __CORTEX_M == 7U)
        __DSB();
    #endif
    EDIT: for T4 implementation of disableDCache() see post #1509
    Last edited by manitou; 02-06-2019 at 11:50 AM.

  12. #487
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,586
    Perhaps things will be even more weird when we try to *read* data that was written by DMA...
    If this does not work reliable we might even have to disable the cache for these areas.

    Thanks for the code, manitou!!

    Edit: I found a more detailed description:
    The Cortex-M4 includes a write buffer that permits execution to continue while a store is
    waiting on the bus. Under specific timing conditions, during an exception return while this
    buffer is still in use by a store instruction, a late change in selection of the next interrupt to be
    taken might result in there being a mismatch between the interrupt acknowledged by the
    interrupt controller and the vector fetched by the processor.
    Configurations Affected
    This erratum only affects systems where writeable memory locations can exhibit more than
    one wait state.
    Workaround:
    For software not using the memory protection unit, this erratum can be worked around by
    setting DISDEFWBUF in the Auxiliary Control Register.
    In all other cases, the erratum can be avoided by ensuring a DSB occurs between the store
    and the BX instruction. For exception handlers written in C, this can be achieved by inserting
    the appropriate set of intrinsics or inline assembly just before the end of the interrupt function,
    for example:
    ARMCC:
    ...
    __schedule_barrier();
    __asm{DSB};
    __schedule_barrier();
    }
    GCC:
    ...
    __asm volatile (“dsb 0xf” ::: “memory”);
    }

    Last edited by Frank B; 01-05-2019 at 09:02 PM.

  13. #488
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    AnalogReadResoultion
    Need a sanity check when with analogReadResolution.

    In https://forum.pjrc.com/threads/54711...l=1#post194670 in gave the code to change the resolution for 8, 10, and 12bits. I checked the register changes going from one to another and they look ok. But when I attach a Sharp Distance Sensor at 12bits something strange or maybe not is happening.

    At 8 and 10bit resolution I will get numbers around 728, but when I change to 12bit I get around 2900? Could this be possibly right - or do I have to recalibrate for 12bit?

  14. #489
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,973
    Quote Originally Posted by mjs513 View Post
    AnalogReadResoultion
    Need a sanity check when with analogReadResolution.

    In https://forum.pjrc.com/threads/54711...l=1#post194670 in gave the code to change the resolution for 8, 10, and 12bits. I checked the register changes going from one to another and they look ok. But when I attach a Sharp Distance Sensor at 12bits something strange or maybe not is happening.

    At 8 and 10bit resolution I will get numbers around 728, but when I change to 12bit I get around 2900? Could this be possibly right - or do I have to recalibrate for 12bit?
    i think that's OK, 728/1024 is about same as 2900/4096. You could also do simple loop() with analogRead(), and jumper your ADC pin to GND or 3v3. On T3*, I would jumper DAC pin to ADC and do sanity checks. I miss the DAC -- though T4 does have 6-bit DAC as reference for CMPA, and i think a DAC output is available on one of the pads on the underside of T4 .... TODO

  15. #490
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    Mike: If you can give me a zip of the changed files - so I know I have them all right - I have two T_3.6 DAC's on board I can use to feed a pair of Analog's [ specify which two T4 pins too ] to read test at various resolutions? Now that I have working Serial I can have the T4 ask for values and then read them and collect results in some fashion if that would help?

  16. #491
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    Sorry guys had to take my afternoon nap just woke up

    Tim, pretty simple standalone sketch to test with - I haven't posted the changes yet:AnalogResolution.zip

    Tom, I tested to ground and 3.3v. With just those 2 points I would say it works, but I will let Tim have the final say.

    By the analogReadAveraging is in the core so you can play with that as well if you need to.

    Mike

  17. #492
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    Mike - just that INO is the only needed file?

  18. #493
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    Believe it or, yep. That's all I have been testing with like testing before I put it into the core.

  19. #494
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    Okay … amazing how simple some involved stuff can be … - back in a bit - gotta run to get stuff for supper … have a sz atol test done so I can pass command values …

  20. #495
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    Thank Paul. He already had a most of it set up when he did the adc_init function. I try not to reinvent the wheel if I don't have to

  21. #496
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    EVENTRESPONDER

    Looks like its working. Just ran one of my old test sketches and timers look good between firing. In case you want to try it its on my WIP GitHub repository

    TEENSYTHREADS
    Not operational. Besides issues with setting up the PIT timer (fixable) fritas has an assembly context switcher that I do not think will work on the T4.

  22. #497
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555

    It is Back ...

    It is BACK! - ??? -

    PAUL : No red light flash on T4 Connect? No sign of T4? I have not done 15 second reset - I can try that or send it back for your review. Cables were fine - and just exchanged with working T_3.1 - but the light 'shows' with power even on bad cable I assume?

    not doing anything I haven't done before - except uploading Variant of mjs513's post #491 code? WIP - not connected to T_3.6 Serial yet to work :: AnalogResolution.ino

    Once before I noted T4 left T_port menu, closed All Teensy and IDE software - replugged - perhaps holding button and it recovered.
    <edit> In that case however I noted that the IDE 'Serial Ports' still showed the T4 active on COM20 - this time it is 'sleeping' - NOTE - the MCU is NOT warm to touch and no smoke or similar events occurred - pretty sure I was hands on keyboard and not adjusting any DAC or Serial connect wires - T_3.6 and T_3.1 on paired BreadBoards are still happy.

    Tried that again - and no dice?

    Here "T4_noPort.txt" is the Verbose TLoader output from that time if I captured before cleanup: T4_noPort.txt

    Here is what is current "T4_noT4.txt" after cleanup and no signs: T4_noT4.txt

    <EDIT>: I am doing programming of T_3.6 and the Debug Serial T_3.1 "In the Background' with Prior IDE 1.88 and TD 1.45. I've uploaded the Echo sketch to a T_3.1 - then the T_3.6 now back to another T_3.1 in the past week. And just now using that same process to upload to the T_3.6 the program to test Mike's resolution setting with T_3.6's DAC0 output - doing this from within SublimeText using my Mod to FrankB's Compile.cmd batch process to use the TD_1.45 builder to upload with TyComm since I need TyComm open for Spare Serial Monitors as well. I had not been paying attention to TLoader but just watched it catch the T_3.6 bootloader action and display 'frowny face' - just repeated and I didn't see that to actually read the text this time.

    Mike: Never got out of 12 bit mode - or to couple results in sync with T_3.6 - but it seemed to follow the sin() data from DAC0 in initial setup.
    Last edited by defragster; 01-06-2019 at 01:28 AM.

  23. #498
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,332
    Tim: Just took a look at your sketch. Looks like you have aaRes hardcoded to 12,
    Code:
     int aaRes = 12;
    . Also in setup its set to 12. Don't see anywhere you can change it on the fly, think that's what you mean. Try changing int aaRes to 10 and you should see the difference.

  24. #499
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    RE T4 Disappear :: I had that LED unit plugged in and with no VCC power line - it seems to draw power from DIN/CS/CLK lines? Unplugged from BBoard for testing.

  25. #500
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,555
    Quote Originally Posted by mjs513 View Post
    Tim: Just took a look at your sketch. Looks like you have aaRes hardcoded to 12,
    Code:
     int aaRes = 12;
    . Also in setup its set to 12. Don't see anywhere you can change it on the fly, think that's what you mean. Try changing int aaRes to 10 and you should see the difference.
    Doesn't it have this as posted ? It does now.:
    Code:
        if ( ch == 'n') {
          if ( 8 == aaRes )
            aaRes = 10;
          else if ( 10 == aaRes )
            aaRes = 12;
          else
            aaRes = 8;
          aReadRes(aaRes);
    It is working with Serial lines right and un-nested WHILE()'s:

    Here is the output - Crude at the start … but it finishes well. This shows 8 bit group - then 10 bit group then - 12 bit group.
    <EDIT>:: I had it hit ZERO out a few times first to clear transfer Serial …
    Code:
    T:\arduino-1.8.8T4_146\examples\03.Analog\AnalogInOutSerial\AnalogInOutSerial.ino Jan  5 2019 18:38:21
     T4 RECEIVE >>0	 output = 142
     T4 RECEIVE >>8	 output = 142
     T4 RECEIVE >>8	 output = 285
     T4 RECEIVE >>17	 output = 428
     T4 RECEIVE >>26	 output = 570
     T4 RECEIVE >>35	 output = 711
     T4 RECEIVE >>44	 output = 851
     T4 RECEIVE >>53	 output = 990
     T4 RECEIVE >>62	 output = 1129
     T4 RECEIVE >>71	 output = 1265
     T4 RECEIVE >>79	 output = 1400
     T4 RECEIVE >>88	 output = 1534
     T4 RECEIVE >>96	 output = 1665
     T4 RECEIVE >>104	 output = 1795
     T4 RECEIVE >>112	 output = 1922
     T4 RECEIVE >>120	 output = 2048
     T4 RECEIVE >>129	 output = 2170
     T4 RECEIVE >>137	 output = 2290
     T4 RECEIVE >>144	 output = 2407
     T4 RECEIVE >>152	 output = 2521
     T4 RECEIVE >>159	 output = 2632
     T4 RECEIVE >>166	 output = 2740
     T4 RECEIVE >>173	 output = 2845
     T4 RECEIVE >>179	 output = 2946
     T4 RECEIVE >>186	 output = 3043
     T4 RECEIVE >>192	 output = 3137
     T4 RECEIVE >>198	 output = 3227
     T4 RECEIVE >>203	 output = 3313
     T4 RECEIVE >>209	 output = 3395
     T4 RECEIVE >>214	 output = 3473
     T4 RECEIVE >>219	 output = 3547
     T4 RECEIVE >>223	 output = 3616
     T4 RECEIVE >>228	 output = 3681
     T4 RECEIVE >>232	 output = 3741
     T4 RECEIVE >>236	 output = 3797
     T4 RECEIVE >>239	 output = 3848
     T4 RECEIVE >>242	 output = 3895
     T4 RECEIVE >>245	 output = 3937
     T4 RECEIVE >>248	 output = 3974
     T4 RECEIVE >>250	 output = 4006
     T4 RECEIVE >>252	 output = 4033
     T4 RECEIVE >>254	 output = 4056
     T4 RECEIVE >>255	 output = 4073
     T4 RECEIVE >>255	 output = 4086
     T4 RECEIVE >>255	 output = 4093
    
     T4 RECEIVE >>0	 output = 142
     T4 RECEIVE >>34	 output = 142
     T4 RECEIVE >>35	 output = 285
     T4 RECEIVE >>71	 output = 428
     T4 RECEIVE >>107	 output = 570
     T4 RECEIVE >>142	 output = 711
     T4 RECEIVE >>178	 output = 851
     T4 RECEIVE >>213	 output = 990
     T4 RECEIVE >>249	 output = 1129
     T4 RECEIVE >>283	 output = 1265
     T4 RECEIVE >>318	 output = 1400
     T4 RECEIVE >>352	 output = 1534
     T4 RECEIVE >>385	 output = 1665
     T4 RECEIVE >>418	 output = 1795
     T4 RECEIVE >>451	 output = 1922
     T4 RECEIVE >>483	 output = 2048
     T4 RECEIVE >>516	 output = 2170
     T4 RECEIVE >>548	 output = 2290
     T4 RECEIVE >>579	 output = 2407
     T4 RECEIVE >>608	 output = 2521
     T4 RECEIVE >>637	 output = 2632
     T4 RECEIVE >>665	 output = 2740
     T4 RECEIVE >>692	 output = 2845
     T4 RECEIVE >>718	 output = 2946
     T4 RECEIVE >>745	 output = 3043
     T4 RECEIVE >>768	 output = 3137
     T4 RECEIVE >>792	 output = 3227
     T4 RECEIVE >>813	 output = 3313
     T4 RECEIVE >>836	 output = 3395
     T4 RECEIVE >>857	 output = 3473
     T4 RECEIVE >>876	 output = 3547
     T4 RECEIVE >>895	 output = 3616
     T4 RECEIVE >>912	 output = 3681
     T4 RECEIVE >>928	 output = 3741
     T4 RECEIVE >>944	 output = 3797
     T4 RECEIVE >>957	 output = 3848
     T4 RECEIVE >>970	 output = 3895
     T4 RECEIVE >>982	 output = 3937
     T4 RECEIVE >>993	 output = 3974
     T4 RECEIVE >>1002	 output = 4006
     T4 RECEIVE >>1010	 output = 4033
     T4 RECEIVE >>1017	 output = 4056
     T4 RECEIVE >>1023	 output = 4073
     T4 RECEIVE >>1023	 output = 4086
     T4 RECEIVE >>1023	 output = 4093
    
     T4 RECEIVE >>0	 output = 142
     T4 RECEIVE >>140	 output = 142
     T4 RECEIVE >>141	 output = 285
     T4 RECEIVE >>284	 output = 428
     T4 RECEIVE >>434	 output = 570
     T4 RECEIVE >>572	 output = 711
     T4 RECEIVE >>714	 output = 851
     T4 RECEIVE >>856	 output = 990
     T4 RECEIVE >>995	 output = 1129
     T4 RECEIVE >>1135	 output = 1265
     T4 RECEIVE >>1271	 output = 1400
     T4 RECEIVE >>1407	 output = 1534
     T4 RECEIVE >>1542	 output = 1665
     T4 RECEIVE >>1673	 output = 1795
     T4 RECEIVE >>1803	 output = 1922
     T4 RECEIVE >>1932	 output = 2048
     T4 RECEIVE >>2060	 output = 2170
     T4 RECEIVE >>2192	 output = 2290
     T4 RECEIVE >>2316	 output = 2407
     T4 RECEIVE >>2434	 output = 2521
     T4 RECEIVE >>2548	 output = 2632
     T4 RECEIVE >>2659	 output = 2740
     T4 RECEIVE >>2768	 output = 2845
     T4 RECEIVE >>2874	 output = 2946
     T4 RECEIVE >>2975	 output = 3043
     T4 RECEIVE >>3074	 output = 3137
     T4 RECEIVE >>3168	 output = 3227
     T4 RECEIVE >>3264	 output = 3313
     T4 RECEIVE >>3343	 output = 3395
     T4 RECEIVE >>3427	 output = 3473
     T4 RECEIVE >>3506	 output = 3547
     T4 RECEIVE >>3578	 output = 3616
     T4 RECEIVE >>3649	 output = 3681
     T4 RECEIVE >>3715	 output = 3741
     T4 RECEIVE >>3773	 output = 3797
     T4 RECEIVE >>3832	 output = 3848
     T4 RECEIVE >>3882	 output = 3895
     T4 RECEIVE >>3928	 output = 3937
     T4 RECEIVE >>3971	 output = 3974
     T4 RECEIVE >>4009	 output = 4006
     T4 RECEIVE >>4043	 output = 4033
     T4 RECEIVE >>4069	 output = 4056
     T4 RECEIVE >>4091	 output = 4073
     T4 RECEIVE >>4095	 output = 4086
     T4 RECEIVE >>4095	 output = 4093

Posting Permissions

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