Teensy 4.0 First Beta Test

Status
Not open for further replies.
@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 :D

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...
 
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.
 
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_128x64_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.
 
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 :)
 
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);
  [COLOR=#ff0000]arm_dcache_flush_delete(buffer, 256);[/COLOR]
}
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:
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.
 
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:
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."
 
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/dui0...tions/cache-maintenance-design-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....
 
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:
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:
AnalogReadResoultion
Need a sanity check when with analogReadResolution.

In https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194670&viewfull=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?
 
AnalogReadResoultion
Need a sanity check when with analogReadResolution.

In https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194670&viewfull=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
 
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?
 
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:View attachment 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
 
Believe it or, yep. That's all I have been testing with :) like testing before I put it into the core.
 
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 …
 
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 :)
 
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.
 
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 … :: View attachment 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: View attachment T4_noPort.txt

Here is what is current "T4_noT4.txt" after cleanup and no signs: View attachment 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:
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.
 
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.
 
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
 
Status
Not open for further replies.
Back
Top