Not sure what ili9341 branch to use? _T3 or the T4_WIP? The _t3 updated 2 months ago seemed to fail on T4 if I tried it right - The T4_WIP is 3 months old.
Using @KurtE's current adafruit_GFX on T4:
So using the T4_WIP The touch Paint compiled and ran - the graphicstest example worked after swapping the DC and CS #defines. No problems with the _GFX or T4 beta processor.
I put ALL Serial POGO pins on the pre-Ribbon Breakout when extra pins came with the Ribbon T4_B2m - just dared to do that with the Ribbon board so it is all POGO'd out on 10 under pads too.
Staring at TWO T4_B2mod boards on breakouts with Seven Serial ports what should I do but get a 14 pin ribbon cable and Feed one T4 Tx to the other T4 Rx 7 times over --- to Test @KurtE's Serial work using his prior sample as a guide.
>> One end Connection ribbon cable starts on Serial1 Tx and progresses to the end with the extra end pin coming back to Rx
>> The other end of the ribbon Starts on Serial1 Rx and goes consecutively to the end on Serial7 Tx
>> I also added a GND to GND wire two connect them when I pull the USB cable - if I used my 5V USB line switch it provided GND.
Got code working and 'Hello World!' makes the loop! … after setting 'print.h' to have "//#define PRINT_DEBUG_STUFF" turned off.
> The cycled String isn't error checked and both T4's running same sketch and somehow The string comes through in FULL - from whichever one started last. So it needs some work for error check and changing the string and maybe EEPROM ID to differentiate one T4 from the other. Should probably skip Serial4 and feed them with DEBUG_STUFF to each other and special case print them to USB
… out of time a bit ago … here is what I see … Just confirmed the on T4_b2 has the ribbon (and VBat) , the other on 2nd breakout Does Have White Wire.
This is a CODE problem - not the T4!
*note*: At one point TeensyLoader stuck on Upload screen of MCU image and verbose said: ~ '... teensy still online …' - it was stuck that way for some time - I prepped to clear the long verbose log and repro and it went away - that is when I discovered this. It may have related to having TyComm active - so I closed TeensyLoader and used TyComm with a 'Verify' build HEX file - then it hasn't done that again going back to TeensyLoader - and TyComm for Dual SerMon's.PROBLEM: Unplugging the either T4 results in this (or similar) where the other powered T4 doesn't STOP output but continues to RUN:
This "T4 FREE" pic shows wiring and how bright the upper Breakout Green LED is when it is unplugged from USB - but getting fed power from 7 Rx and 7 Tx pins with common GND:
This is the code:
opps - trivial code change - I did the same thing here I did serial cross testing on T_3.6 - crossed wiring and the printing … doing this I found the second "Hello World!" - depending on the start RACE:Code:#define SPD 2000000 #define BUFFER_SIZE 320 char buffer_out[BUFFER_SIZE]; char buffer[80]; HardwareSerial *psAll[7] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5, &Serial6, &Serial7 }; void setup() { pinMode(13, OUTPUT); for ( int ii = 0; ii < 7; ii++ ) { psAll[ii]->begin(SPD); } digitalWrite( LED_BUILTIN, 1 ); while (!Serial && millis() < 2200) digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN) ); Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__); digitalWrite( LED_BUILTIN, 1 ); delay(100); Serial.print("Test all Serials - Serial @ms="); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(100); Serial.println(millis()); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(10); Serial.printf("Baud rate: %d\n", SPD); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); Serial1.println( "Hello World!" ); } void serialXfer(HardwareSerial * psIn, HardwareSerial * psOut, bool bWrite) { uint32_t cb = psIn->available(); if (cb) { if (cb > sizeof(buffer)) cb = sizeof(buffer); if (cb > psOut->availableForWrite()) cb = psOut->availableForWrite(); psIn->readBytes(buffer, cb); if ( bWrite ) psOut->write(buffer, cb); } } void loop() { for ( int ii = 0; ii < 7; ii++ ) { serialXfer( psAll[ii], psAll[ii], true ); // opps - this was double crossed … fixed here } Serial.println( buffer ); delay(100); }
Problem persists - when one unpowered: ... DUE to BAD CODE ...Hello World! #2
Hello World!
Hello World! #2
Hello World!
Hello World! #2
Hello World!
Hello World! #2
Hello World!
Hello World! #2
Hello World!
Last edited by defragster; 06-26-2019 at 01:51 AM. Reason: minor code change
@defragster - which version of ILI9341_t3 did you try... The released one or the one I modified: https://github.com/KurtE/ILI9341_t3/tree/T4_BetaOriginally Posted by defragster
There is a current outstanding PR: https://github.com/PaulStoffregen/ILI9341_t3/pull/52
(As you know this library does not rely on Adafruit_GFX)
EDIT:
I probably need to get a better Idea of your Serial test... Does it repeat with just Serial1-5? (i.e. does not require Pogo pins?) Wonder how much voltage is making it between the two boards when you have that many common pins.
Last edited by KurtE; 06-25-2019 at 01:48 PM.
I was in wrong ili9341 tree - it had the T4_WIP not T4_Beta. Will retest.
As far as the Serial test :: "ALL Serial POGO pins"
it is running #1 through #7 :: HardwareSerial *psAll[7] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5, &Serial6, &Serial7 };
14 pins - lots of current leaking … Turning one T4 off does noticeably DIM the LED that instant - but not really significantly looking afterwards. Current could be tested across the GND wire.
Thanks for your advice Paul, it did help.
I now have a picture for the Atari520ST emulator port. I still miss 8K to allocate outside the OCRAM but I can now see how fast the T4 is compare to the ESP32 with the SPI RAM.
It is just amazing!
As soon this is done, next core to port will be the amiga500.
Paul - back in the stuck this state { hardware setup as the Serial#1-7 prior post w/picture } :: 11:09:56.762 (loader): HID/win32: HidD_GetPreparsedData ok, device still online :-)
Edit> Seems to be perhaps from hitting Program on 2nd T4 before TeensyLoader was done programming the First T4? And TeensyLoader interrupted went out of Auto mode?
Something to do with UART power applied not taking the MCU offline? Not sure how any char data { above corrupted chars } is feeding though the 'unpowered' T4.
Put DVM instead of GND connect to unplugged T4 and it is showing 19.9 Ma drawing from the UARTS?
TyComm serial offline, 2nd T4 offline, pushing button repeats the : device still online :-)
It was more weirder before - I pushed one T4 Button to upload new code - then the other :: Each T4 ended up blinking RED LED in turn and TeensyLoader was in the above state showing the MCU.
Here is the LOG after that: T4_BLtoggle.txt
I cleared the log and went to one T4 and this shows where I am above: T4_BLtoggle_B.txt
Powering both down - then powering up only one comes online - the other must be blanked?
They are both working again no 15s Restore - just power them down - power and upload to the one with running code - power the other and Button push.
And @KurtE:
Did a quick edit to code to prepend chars on each buffer to show passage form Serial# to Serial# port - it shows something but not 'right' as the two T4's are both doing the same - they need to be differentiated for clearer results. And after each 10 passes it clears the buffers ( ideally ) - then restarts fresh?
Upload code below to one then "Verify" and button push to the other with this edit of 'A' to 'a' to see how each adds:
if ( bWrite ) {
psOut->print((char)('a' + ii));Code:#define SPD 2000000 #define BUFFER_SIZE 320 char buffer_out[BUFFER_SIZE]; char buffer[80]; HardwareSerial *psAll[7] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5, &Serial6, &Serial7 }; void setup() { pinMode(13, OUTPUT); for ( int ii = 0; ii < 7; ii++ ) { psAll[ii]->begin(SPD); } digitalWrite( LED_BUILTIN, 1 ); while (!Serial && millis() < 2200) digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN) ); Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__); digitalWrite( LED_BUILTIN, 1 ); delay(100); Serial.print("Test all Serials - Serial @ms="); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(100); Serial.println(millis()); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(10); Serial.printf("Baud rate: %d\n", SPD); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); Serial1.println( "Hello World! #1" ); } void serialXfer(HardwareSerial * psIn, HardwareSerial * psOut, bool bWrite, uint32_t ii) { uint32_t cb = psIn->available(); if (cb) { if (cb > sizeof(buffer)) cb = sizeof(buffer); if (cb > psOut->availableForWrite()) cb = psOut->availableForWrite(); psIn->readBytes(buffer, cb); if ( bWrite ) { psOut->print((char)('A' + ii)); psOut->write(buffer, cb); } } } uint32_t iiCnt = 0; void loop() { for ( int ii = 0; ii < 7; ii++ ) { serialXfer( psAll[ii], psAll[ii], true, ii ); Serial.print( buffer ); delay(10); } Serial.println( "==============================" ); delay(2000); iiCnt++; if ( !(iiCnt % 10) ) { for ( int jj = 0; jj < 4; jj++ ) { for ( int ii = 0; ii < 7; ii++ ) { serialXfer( psAll[ii], psAll[ii], false, ii ); delay(5); } } Serial1.print( "Hello World!" ); Serial1.println( iiCnt ); buffer[0] = 0; } }
Last edited by defragster; 06-26-2019 at 06:03 AM.
@KurtE - got the right ILI9341_t3-T4_Beta And DemoSauce and graphicstest compile and run well. Those version were tested before as I don't see fresh updates - and of course it is not using adafruit_GFX. I remember the 'jittery' updates to the Cube3D.
@Paul :: >Update to prior - it seems when one T4 stopped the other T4 was continuing to print a buffer that was no longer valid. Going to update those post WRT bogus report of strings from an unpowered T4.
@KurtE - @defragster.
Just hooked up my Waveshare 1.3in ST7789 display. Ran both the graphicstest and speedtest examples and worked right out of the box. Man the print in small but if I use a magnifier I can read it - nice and clear. Display is the 240x240 one you have from amazon.
Would probably be better if you had the colors specified as ST77XX_BLACK, etc as you mentioned in the post with questions to Paul. Going to play more tomorrow with it and then give a try to the ST7735 display that I picked up.
Paul update #3406 - : Is it expected that one Teensy being programmed - and just blanked but not completed - would have the upload interrupted on a separate USB Teensy when the button is pushed?
@mjs513 - I think I mentioned magnifying glass for the HD 240x240 display in 1.4"
Teensy Loader only talks to 1 board at a time, so no, not expected behavior.
But if you're simultaneously running another program (like TyQT) which also talks to Teensy boards, then I suppose all sorts of strange behaviors are possible.
I set TyComm Beta to not upload - it refuses without an ENV var set that I removed. It also - like TeensyLoader when 'Not Auto' will see a Teensy in Bootloader and ignore it until told to upload - unless it initiated it - but to rule that out I'm not starting it - I've been using it only because it allows Dual (+) Serial Monitor windows - and this is a twin T4 test.
No TyComm - Did a Verify Build - TeensyLoader opened - only the two T4B2m's active t1 and t2. Two T4's have all 7 Serial# ports cross wired to each other.
> Program t1 then t2 - timing was okay.
> Program t1, saw Reboot TLoader msg, pressed Button on t2
>> Deactivated AUTO, gave message about 'too fast'
> In this case t1 was left programmed, t2 was left in bootloader
>> … pressed button the 'too fast' message went away but not programmed … repeat press 'TLoader shows normal press button image, then back to MCU image' similar … Pressed AUTO and it was programmed: TwinT4Button.txt
> Removing 5V power and restoring 5v returns to 'Button' image - but no Auto so Button just goes to MCU image - maybe this is normal once interrupted until 'AUTO' reenabled.
You are correct - it normally works right. Pressing t2 Button too fast properly programs the t1, then halts with t2 in bootloader w/fast message.
In setup() for t1 it does LED_BUILTIN blink { so programmed and running at least 300 ms } and pressing t2 Button then can generate the 'too fast' "Automatic mode has been disabled …" - given it is on a different USB port I wouldn't expect that (unless by design) - or in the transition it conflates t2 Button with t1 device just programmed - in which case there may be a window where the blank for t2 Button hits t1? { if not this then there is no issue I can repro easily }
>> Though GENERALLY it works - I just alternated programming t1...t2..t1... as the setup LED was blinking and got away with it like 5 times {not rushing after first LED blink 100ms on/off/on } before 'too fast', but no Dual RED LED's repro
I cannot repro the DUAL RED LEDS just now - it is almost like t1 was programmed, t2 Button caused it to Blank t1, and then leave t2 in bootloader - perhaps I hit it at the exact right moment programming t1 was done and it responded to t2 Button by blanking the still 'active' t1?
Another ODD thing - Seems this relates to a prior issue where a T4 in this state would stay offline that you corrected by restarting USB when repowered, which is happening - but somehow the 'unpowered' T4 is semi conscious with UART & VBat power.
> When I started the IDE the one T4 was 'switched' off - the 5V line was 'open' Data +/- and GND still connected and VBat installed, 7 UART pairs connected from active T4 - but the IDE loaded and showed both T4's in Ports menu. Once TLoader was active - turning it on and off showed '_DEVICEREMOVECOMPLETE' message and then it was then not on the port menu:
Repeating that then Manually opened TLoader ( teensy.exe ) and Verbose shows this - is that two T4's reported?
Did a verify after verbose and no 'Remove' reported and both are still in the Port list.Code:02:36:15.130 (loader): Teensy Loader 1.47-beta4, begin program 02:36:15.469 (loader): Listening for remote control on port 3149 02:36:15.470 (loader): initialized, showing main window 02:36:15.584 (loader): HID/win32: vid:046D pid:C534 ver:2901 02:36:15.584 (loader): HID/win32: vid:1B80 pid:B406 ver:0100 02:36:15.585 (loader): HID/win32: vid:046D pid:C534 ver:2901 02:36:15.585 (loader): HID/win32: vid:1B80 pid:B406 ver:0100 02:36:15.586 (loader): HID/win32: vid:0764 pid:0501 ver:0001 02:36:15.586 (loader): HID/win32: vid:1B80 pid:B406 ver:0100 02:36:15.586 (loader): HID/win32: vid:046D pid:C534 ver:2901 02:36:15.587 (loader): HID/win32: vid:1B80 pid:B406 ver:0100 02:36:15.587 (loader): HID/win32: vid:046D pid:C534 ver:2901 02:36:20.444 (loader): Verbose Info event
To verify opened TyComm ( then closed ) it shows that T4 as ''running' but an 'x' through connect on highlighted/selected T4:
Verbose logged this when I switched the 5V back on:
> There is something odd about 'garbage' showing from t1 UARTS when t2 is removed - but until I can see it isn't my code ... the buffer is set [0]=NULL before & after each use now - and added return check on .readBytes() ???Code:02:44:43.044 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE 02:44:43.050 (loader): remote connection 1388 opened 02:44:43.056 (ports 2): remove: loc=usb:0/140000/0/8/6 02:44:43.056 (ports 2): usb_remove: usb:0/140000/0/8/6 02:44:43.056 (ports 2): nothing new, skipping HID & Ports enum 02:44:43.085 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED 02:44:43.086 (ports 2): nothing new, skipping HID & Ports enum 02:44:43.086 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE 02:44:43.087 (ports 2): nothing new, skipping HID & Ports enum 02:44:43.260 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL 02:44:43.261 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#5889290#{a5dcbf10-6530-11d2-901f-00c04fb951ed} 02:44:43.261 (ports 2): found_usb_device, loc=usb:0/140000/0/8/6 Port_#0006.Hub_#0009 02:44:43.261 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279 02:44:43.261 (ports 2): found_usb_device, devinst=00000001 02:44:43.262 (ports 2): add: loc=usb:0/140000/0/8/6, class=Ports, vid=16C0, pid=0483, ver=0279, serial=5889290, dev=\\?\usb#vid_16c0&pid_0483#5889290#{a5dcbf10-6530-11d2-901f-00c04fb951ed} 02:44:43.262 (ports 2): comport_from_devinst_list attempt 02:44:43.262 (ports 2): found Ports in classguid_list at index=0 02:44:43.262 (ports 2): port COM30 found from devnode 02:44:43.262 (ports 2): found_usb_device complete 02:44:43.264 (ports 2): usb_add: usb:0/140000/0/8/6 COM30 (Teensy 4-Beta2) Serial 02:44:43.344 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED 02:44:43.344 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL 02:44:43.346 (ports 2): nothing new, skipping HID & Ports enum 02:44:43.392 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED 02:44:43.393 (ports 2): nothing new, skipping HID & Ports enum
teensy beta 7 installs fine on 1.8,9 on raspbian buster, newest version. will hook a teensy up to the rpi later tonight and see what happens.
Audio Lib use of PT8211 fails on IDE 1.89 TD1.46 {b1} but works on IDE1.88 TD1.45 {b2} - when tested with a T_3.5
So PT8211 does not work on T4 { or T_3.5 } with TD1.47 current Beta on IDE 1.89
>> Assuming the PT8211 pins to Beta Breakout headers are correct for PT8211?
Post Here has perhaps more detail { and a simple sketch } with T_3.2 user noting failure after TD upgrade : PT8211-Not-Working-After-Upgrade-to-Arduino-IDE-1-8-9-and-Teensy-Loader-1-46 is where I tested my freshly assembled PT8211 I ordered from PJRC when the T4B1 shipped.
GOOD NEWS is the PJRC AUDIO board on T4 { and T3.5 } worked on the same Sketches as noted in that post - Also great that I ordered that kit and soldered it to work on the T_3.5 with TD1.45 so I know it works for T4 testing
>> Added to Post #6
I'd just like to put a bug in someone's ear that USB-C (or USB-C hub) functionality would be very useful for some T4 projects. I don't see CCx pin definitions or other indications that this has been worked on, so it is probably too late for a feature request on this variant. However, I ask that someone involved with USB Host/Device development give at least a cursory glance at the technical requirements to implement USB-C. https://www.scorpia.co.uk/2016/03/17...yist-projects/ and comment on feasibility.
While working on new things like T3.6 2nd device support, it might be possible to consider what library changes would be required to support USB-C and start some kind of roadmap toward a future variant. Perhaps some additional // TODO: comments in cores/teensy4/usb.c could serve as that roadmap. If the core developers could identify some roadblocks, the slightly less talented but broader community with time on its hands can get started clearing them.
https://www.eevblog.com/forum/projec...e-connectors)/ is a dead end but gives some overlayed footprint comparisons.
https://www.newegg.com/p/0S8-019C-000E6 brings possibilities to mind.
ALL usb signals could be brought to pads at T4 board edge and the user chooses their combination of host/device connectors on a castellated sub board, flex cable, or captive cables soldered directly, or omit for minimalist installations. One interesting option could be the 10 pin motherboard usb connector for installation inside a pc for fan/lighting control, etc. Personally, I still prefer mini B for some projects such as connecting to a TI-Nspire Graphing Calculator.
RE: USB-C - the hardware has USB 2.0 ports with speed to 480 Mbps - they are not wired/capable of USB 3 speed or connectivity. For compatibility Paul noted he was sticking with the micro USB connector. The T4's are well beyond change and possibly somewhere far along in production at this point …
I brought this up Jan 3 in post #340 this thread and here was the answer then …
Near term plan is (currently) to stay with Micro-B. But don't take this as a promise or any sort of commitment from PJRC about future products. We could change course at any time for any reason, or even for no reason at all.
But I can tell you I'm not ever planning to make another product with the all-SMT Micro-AB connector we still use on Teensy LC & 3.2. ~7 years ago those were the most common. No longer. The newer type with the 4 tabs that fit into through-holes is so much better, far stronger and more durable. All the PCB vendors have become much better about slots. The new types is also slightly less expensive now (wasn't always the case), and our contract manufacturer reports much better yield with them, compared to the old type. I never want to design another board using the old one with only SMT tabs.
Long-term, USB-C does appear to be the one connector to rule them all.
Quick update: Went ahead and did a PR to Adafruit for the GFX library for T4 support and it was merged...
Also Github conversation with Ladyada about issue with ST7735/89 with rotation and she suggested a new API to allow user to set the zero points , and wondered if I might play with it... So hopefully that will allow users to handle displays like ST7735 128x128 regardless if the maker decided to use top of memory or bottom of memory...
Very nice @KurtE! Congrats …
@KurtE - any chance the serialEvent#() code doesn't work on #'[2-7]? I only see data coming in on #1.
Modifying my prior example to get the SLAVE to just read and write whatever it gets out the same port which with cross wired ports results in bytes traveling from port X to X+1 - with Two T4B2m breakouts.
Using the same code on each T4 - but EEPROM[0] holds 0==Master or 1==Slave, the Slave skips the loop to process ports and uses serialEvent() now because the unsynchronized timing was preventing good results.
<edit> @KurtE - I should be able to make a slave only version just cutting this sketch down and a couple of jumpers for Serial 1,2 perhaps if you don't find anything obvious. Since yield() and serialEvent1() work - I assume the whole change got in for all #'s?
Maybe you can read the code and find my error or trace it to yours rather than set it up?
The Master is never getting anything to print and the Slave is only catching chars on Serial1: " #01112131111 #01112131111 #01112131111 … "
I just added debug print in sEvent1() to force write to Serial[2,3] and the Master gets that - and should be passing it on as it did before - but it never comes in to Slave sEvent[2,3]():
Code://https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195343&viewfull=1#post195343 #define SPD 2000000 #define BUFFER_SIZE 320 char buffer_out[BUFFER_SIZE]; char buffer[80]; #include <EEPROM.h> int whoami = 2; char chWho = 'z'; HardwareSerial *psAll[7] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5, &Serial6, &Serial7 }; void setup() { // To set the whoami run one time on each Teensy with // EEPROM[0]=0; // or EEPROM[0]=1; pinMode(13, OUTPUT); for ( int ii = 0; ii < 7; ii++ ) { psAll[ii]->begin(SPD); } digitalWrite( LED_BUILTIN, 1 ); while (!Serial && millis() < 2200) digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN) ); Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__); digitalWrite( LED_BUILTIN, 1 ); if ( 1 == EEPROM[0] ) { whoami = 1; chWho = 'A'; Serial.print( " __I am 1 :: Slave__ " ); } else { whoami = 0; // ZERO is the MASTER chWho = 'a'; Serial.print( " __I am 0 :: Master__ " ); } delay(100); Serial.print("Test all Serials - Serial @ms="); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(100); Serial.println(millis()); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); delay(10); Serial.printf("Baud rate: %d\n", SPD); digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN)); if ( 0 == whoami ) { while ( 0 == Serial2.availableForWrite() ) { Serial1.print( 'x' ); delay(1); } Serial1.println( "Hello World! #1" ); } } void serialXfer(HardwareSerial * psIn, HardwareSerial * psOut, bool bWrite, uint32_t ii) { uint32_t cb = psIn->available(); buffer[0] = 0; // NULL buffer when nothing read !!! if (cb) { if ( 0 != whoami ) Serial.print( cb ); // bugbug debug if (cb > sizeof(buffer)) cb = sizeof(buffer); if (cb > psOut->availableForWrite()) cb = psOut->availableForWrite(); if ( 0 == psIn->readBytes(buffer, cb) ) { Serial.printf( "Read Error on %u - expected %u Bytes" , ii, cb ); buffer[0] = 0; // NULL buffer when nothing read !!! } else if ( bWrite ) { psOut->print((char)( chWho + ii)); psOut->write(buffer, cb); } } if ( 0 == whoami ) // bugbug debug // FORCE OUTPUT psOut->print((char)( chWho + ii)); // bugbug debug } uint32_t iiCnt = 0; void loop() { if ( 0 != whoami ) { return; // Slave uses serialEvent# } for ( int ii = 0; ii < 7; ii++ ) { serialXfer( psAll[ii], psAll[ii], true, ii ); if ( 0 != buffer[0] ) { Serial.print( ii ); Serial.print( ">>_" ); Serial.print( buffer ); } buffer[0] = 0; delay(8); } Serial.println( "<<==============================" ); delay(100); iiCnt++; if ( !(iiCnt % 14) ) { for ( int jj = 0; jj < 8; jj++ ) { for ( int ii = 0; ii < 7; ii++ ) { serialXfer( psAll[ii], psAll[ii], false, ii ); buffer[0] = 0; delay(5); } } if ( 0 == whoami ) { Serial1.print( "Hello World!" ); Serial1.println( iiCnt ); } buffer[0] = 0; } } void serialEvent1() { // ONLY this one receives calls if ( 0 == whoami ) return; // this is for SLAVE processing test uint32_t ii = 0; Serial.print( " #" ); Serial.println( ii ); Serial2.print( "sE1>2 " ); // BUGBUG DEBUG >> Serial3.print( "sE1>3 " ); // BUGBUG DEBUG do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent2() { if ( 0 == whoami ) return; uint32_t ii = 1; Serial.print( ii ); do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent3() { if ( 0 == whoami ) return; uint32_t ii = 2; Serial.print( ii ); do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent4() { if ( 0 == whoami ) return; uint32_t ii = 3; Serial.print( ii ); do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent5() { if ( 0 == whoami ) return; uint32_t ii = 4; do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent6() { if ( 0 == whoami ) return; uint32_t ii = 5; do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; } void serialEvent7() { if ( 0 == whoami ) return; uint32_t ii = 6; do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(50); } while ( psAll[ii]->available() > 0 ); buffer[0] = 0; }
Last edited by defragster; 06-28-2019 at 10:22 AM.
@defragster - Hard to say what is going on... Maybe CPU Starvation. While in each SerialEvents you are doing waits and the like. Wondering for example if you ever make it out of SerialEvent1 processing? If you are within a yield which does the calls off to SerialEvents will not call it recursively... That is if you are within SerialEvent1 and do things that call yield... The yield will more or less return without doing much of anything (like T3.x), Except I think it does the OTHER event code...
If it were me, I would probably use some other digital pins and put in digitalWrite(...) HIGH and start LOW when return and see if/when they are processed.
Also check wiring, that you don't have some lose connection or went wrong connection...
Or wonder about this code:
That is you are checking Serial2 if it has space for writes and then you write to Serial1...Code:while ( 0 == Serial2.availableForWrite() ) { Serial1.print( 'x' ); delay(1); }
Hi,
still catching up with backlog from vacations... anyway, I'm starting to play with my beautiful T4beta3.
Installed Arduino 1.8.9 and TD 1.47beta4.
I have a small bug to report: when building with " + pure-code", build fails.
Example sketch: the stock "Blink" example
The error log:Code:/* Blink Turns on an LED on for one second, then off for one second, repeatedly. This example code is in the public domain. */ // Pin 13 has an LED connected on most Arduino boards. // Pin 11 has the LED on Teensy 2.0 // Pin 6 has the LED on Teensy++ 2.0 // Pin 13 has the LED on Teensy 3.0 // give it a name: int led = 13; // the setup routine runs once when you press reset: void setup() { // initialize the digital pin as an output. pinMode(led, OUTPUT); } // the loop routine runs over and over again forever: void loop() { digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level) delay(1000); // wait for a second digitalWrite(led, LOW); // turn the LED off by making the voltage LOW delay(1000); // wait for a second }
Code:D:\Arduino\arduino-builder -dump-prefs -logger=machine -hardware D:\Arduino\hardware -hardware L:\Progetti\Arduino\hardware -tools D:\Arduino\tools-builder -tools D:\Arduino\hardware\tools\avr -built-in-libraries D:\Arduino\libraries -libraries L:\Progetti\Arduino\libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o3purestd,keys=en-us -ide-version=10809 -build-path c:\temp\arduino_build_128500 -warnings=none -build-cache c:\temp\arduino_cache_672517 -verbose D:\Arduino\examples\01.Basics\Blink\Blink.ino D:\Arduino\arduino-builder -compile -logger=machine -hardware D:\Arduino\hardware -hardware L:\Progetti\Arduino\hardware -tools D:\Arduino\tools-builder -tools D:\Arduino\hardware\tools\avr -built-in-libraries D:\Arduino\libraries -libraries L:\Progetti\Arduino\libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o3purestd,keys=en-us -ide-version=10809 -build-path c:\temp\arduino_build_128500 -warnings=none -build-cache c:\temp\arduino_cache_672517 -verbose D:\Arduino\examples\01.Basics\Blink\Blink.ino Using board 'teensy4b2' from platform in folder: D:\Arduino\hardware\teensy\avr Using core 'teensy4' from platform in folder: D:\Arduino\hardware\teensy\avr Warning: Board breadboard:avr:atmega328bb doesn't define a 'build.board' preference. Auto-set to: AVR_ATMEGA328BB Detecting libraries used... "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "c:\\temp\\arduino_build_128500\\sketch\\Blink.ino.cpp" -o nul Generating function prototypes... "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "c:\\temp\\arduino_build_128500\\sketch\\Blink.ino.cpp" -o "c:\\temp\\arduino_build_128500\\preproc\\ctags_target_for_gcc_minus_e.cpp" "D:\\Arduino\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "c:\\temp\\arduino_build_128500\\preproc\\ctags_target_for_gcc_minus_e.cpp" Compiling sketch... "D:\\Arduino\\hardware\\teensy/../tools/precompile_helper" "D:\\Arduino\\hardware\\teensy\\avr/cores/teensy4" "c:\\temp\\arduino_build_128500" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -x c++-header -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr/cores/teensy4" "c:\\temp\\arduino_build_128500/pch/Arduino.h" -o "c:\\temp\\arduino_build_128500/pch/Arduino.h.gch" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-Ic:\\temp\\arduino_build_128500/pch" "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "c:\\temp\\arduino_build_128500\\sketch\\Blink.ino.cpp" -o "c:\\temp\\arduino_build_128500\\sketch\\Blink.ino.cpp.o" Compiling libraries... Compiling core... "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -x assembler-with-cpp -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\memset.S" -o "c:\\temp\\arduino_build_128500\\core\\memset.S.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -x assembler-with-cpp -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\memcpy-armv7m.S" -o "c:\\temp\\arduino_build_128500\\core\\memcpy-armv7m.S.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\analog.c" -o "c:\\temp\\arduino_build_128500\\core\\analog.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\delay.c" -o "c:\\temp\\arduino_build_128500\\core\\delay.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\rtc.c" -o "c:\\temp\\arduino_build_128500\\core\\rtc.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\keylayouts.c" -o "c:\\temp\\arduino_build_128500\\core\\keylayouts.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\interrupt.c" -o "c:\\temp\\arduino_build_128500\\core\\interrupt.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\nonstd.c" -o "c:\\temp\\arduino_build_128500\\core\\nonstd.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\clockspeed.c" -o "c:\\temp\\arduino_build_128500\\core\\clockspeed.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\usb.c" -o "c:\\temp\\arduino_build_128500\\core\\usb.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\debugprintf.c" -o "c:\\temp\\arduino_build_128500\\core\\debugprintf.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\tempmon.c" -o "c:\\temp\\arduino_build_128500\\core\\tempmon.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\startup.c" -o "c:\\temp\\arduino_build_128500\\core\\startup.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\eeprom.c" -o "c:\\temp\\arduino_build_128500\\core\\eeprom.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\digital.c" -o "c:\\temp\\arduino_build_128500\\core\\digital.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\usb_desc.c" -o "c:\\temp\\arduino_build_128500\\core\\usb_desc.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\usb_serial.c" -o "c:\\temp\\arduino_build_128500\\core\\usb_serial.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\bootdata.c" -o "c:\\temp\\arduino_build_128500\\core\\bootdata.c.o" "D:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O3 -mpure-code -D__PURE_CODE__ -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "D:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4\\pwm.c" -o "c:\\temp\\arduino_build_128500\\core\\pwm.c.o" D:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c: In function 'flexpwmFrequency': D:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:150:1: error: insn does not satisfy its constraints: } ^ (insn 32 27 28 2 (set (reg:SI 31 s15 [orig:114 D.5878 ] [114]) (mem/v/c:SI (reg/f:SI 2 r2 [175]) [4 F_BUS_ACTUAL+0 S4 A32])) D:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:130 615 {*thumb2_movsi_vfp} (nil)) D:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:150:1: internal compiler error: in extract_constrain_insn, at recog.c:2246 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Error compiling for board Teensy 4-Beta2.
@KurtE
Trying to minimize and having a tough time - in setup() with delay() in use - which will call yield() - is there any issue with that - shouldn't be as .begin is done on Serial#'s - but taking out delay()'s changed the startup output and stopped the sketch hanging.
The code Snippet of Wonder is the Master spitting out looking for Slave to be online - it is not hanging there - though it should probably have been:
That was a lame attempt to synchronize Master to Slave - and why I decided to move to serialEvent() code for the Slave to avoid that. Then only to find I can't get that to work as well as it was working.Code:while ( 0 == Serial1.availableForWrite() ) { Serial7.print( 'x' ); delay(1); }
Will try to get a working sketch - maybe something odd in my method with array of hardware Serial mapping and usage?
> In serialEvent() the delayMicroseconds(50); is short, and by design does not call yield() - and just to let added chars come in to keep the strings together for printing as long as new chars arrive in that short time. This isn't _isr() code - but an 'extension' of loop().
> So it leaves that is shown by each "#" in this : " #01112131111 #01112131111 #01112131111 … ". Then the next char is the Serial# { only from Zero } - then the number of chars count per while{}
Using other T4B2 on breakout with just Serial1 Tx > Serial2 Rx and Serial2 Tx to Serial1 Rx
… out of time - it seems I am doing something horribly wrong … or there is something extremely weird I didn't pinpoint yet.
SHIFTIN TEST
Hi guys since this is still on the list decided to give it a try with 74HC165 with 8 buttons. Used this for a test: https://infectedbytes.com/2016/07/arduino-shiftin.html with their shift library: https://github.com/InfectedBytes/ArduinoShiftIn. Seems to work when I push the button the value for that button changes from 0 to 1. So don't think there should be any problem with SHIFTIN.
@defragster - Will try to take another look later... Playing right now with ST7xx stuff...
@all I ordered another few displays yesterday from Amazon (1 ST7789 and 2 ST7735yesterday that should arrive Monday...) But then I remember I already ordered that same ST7789 back in April, and had issues with it back then... As they don't have a CS pin on them... So needless to say you can not use these displays and share SPI buss...
What is interesting is that: there is a secondary picture with advice from an Enthusiastic customer, which says you nee to:
a) Feed it 5v instead of 3.3v.
b) In Adafruit set CS to -1 as theire is no CS
c) Change the SPISettings call from using SPI_MODE0 to SPI_MODE3... (They had success then talking to an UNO)...
Note: This is from MakerFocus TFT: https://smile.amazon.com/MakerFocus-.../dp/B07P9X3L7M
But it looks like there are several others with no CS pin as well including:
https://smile.amazon.com/WINGONEER-D...gateway&sr=8-6
https://smile.amazon.com/TOOGOO-Comm...gateway&sr=8-7
https://smile.amazon.com/ST7789-Comm...ateway&sr=8-12
What I mainly was interested in seeing is if any of the other displays align memory differently than the one I have that works, as ST7789 can handle 240x320...
Probably should pick up an Adafruit one...
EDIT: Or does someone already have an Adafruit one? https://www.adafruit.com/product/3787 It is interesting that the majority of the ST7789 displays I also see up on EBAY don't have CS pin! What I am curious about is how they align the display in memory... I believe they do the same as the one I have as their code is setup to start at row 80...
Last edited by KurtE; 06-28-2019 at 09:09 PM.
@KurtE - it is probably my own issue not yet resolved - at least getting a working sample that would show any trouble. So please do other until I get closer on my end.
It isn't _isr() code - but the way I have it forwarding Serial# data in serialEvent - and am using delay() probably results in similar behavior because every event() causes writes and thus a new event() on the next Serial# with a delay() or loop()'s yield() in between the data is cascading fast.
> That wasn't the original plan - and hacking in serialEvent() quickly wasn't properly planned - but added for debug and created new issues.
With a few million extra loop passes each second on the T4, and super fast SerialMon I/O I see now the screen that looked static/hung is really moving very fast - but same data output sequence looks unchanging - turning on 'Show timestamp' really shows that.
RE: ST7789/7735 That explains the multi #defines and efforts that sumotoy was making cataloging the boards for his 7735 work.
New Sketch :: serialEvent[1-5]() working well. @KurtE - thanks for review - it was code/connect error.
Moved from breakout to same wires direct pin to pin and new sample started working. I noticed going for button when on breakout I would trigger the 'Read Error' in the code - I put that in other test to see if there was an issue, but it never triggered.
I developed this using only 4 serial ports and then put five in software before adding and updating the wiring - when I touched it then to unplug to add wire with the unconnected port I saw the 'Read Error' trigger again. Need to DVM the breakout to the end pin array - seems an open pin ??? With it working now and all connected - I can touch any or all pins without any change in the execution/transfer.
<edit>: Updated code to show Loop() cycles per sec since I had a count - funny thing the 'delayMicroseconds(6); // Just for fun' while(){line} makes it run ~40K cycles/sec faster - because it reduces the number of serialEvent()'s allowing the FIFO's to run without triggering sE()'s. And changing elapsedMillis to an equal # elapsedMicros slows it down by 200K cycles/sec. Note: runs ~50K loop Hz slower at 1 Mbaud, assume from more serialEvent calls as the FIFO's batch fewer bytes.
>> For reference an empty 600 MHz T4 loop() cycles over 20 M/sec, adding the 5 serial port short string writes 1K/sec shows 2.15 M/sec - this code at once per sec is over 20M {with #define WaitRepeat 1000}.
With single T4 Wired:: Tx1>Rx2, Tx2>Rx3, Tx3>Rx4, Tx4>Rx5, Tx5>Rx1 ::
output start at 5 Mbaud, transfer time of "loop #5 @418" is 73 us:Code:#define SPD 5000000 #define ACTIVE_SER 5 #define QB_SIZE 80 char qsB[ACTIVE_SER][QB_SIZE]; uint32_t qsI[ACTIVE_SER]; HardwareSerial *psAll[7] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5, &Serial6, &Serial7 }; void serialXfer(HardwareSerial * psIn, HardwareSerial * psOut, bool bWrite, uint32_t ii) { uint32_t cb = psIn->available(); if (cb) { if (cb > (QB_SIZE - qsI[ii])) cb = QB_SIZE - qsI[ii]; if ( 0 == psIn->readBytes(&qsB[ii][qsI[ii]], cb) ) { Serial.printf( "Read Error on %u - expected %u Bytes" , ii, cb ); } else qsI[ii] += cb; } } uint32_t firstXfer = 0, lastXfer = 0; void serialEvent1() { uint32_t ii = 0; serialXfer( psAll[ii], psAll[ii], false, ii ); lastXfer = micros(); } void serialEvent2() { uint32_t ii = 1; serialXfer( psAll[ii], psAll[ii], false, ii ); } void serialEvent3() { uint32_t ii = 2; do { serialXfer( psAll[ii], psAll[ii], false, ii ); delayMicroseconds(6); // Just for fun } while ( psAll[ii]->available() > 0 ); } void serialEvent4() { uint32_t ii = 3; serialXfer( psAll[ii], psAll[ii], false, ii ); } void serialEvent5() { uint32_t ii = 4; serialXfer( psAll[ii], psAll[ii], false, ii ); } elapsedMillis emWait; void setup() { pinMode(13, OUTPUT); for ( int ii = 0; ii < ACTIVE_SER; ii++ ) { psAll[ii]->begin(SPD); qsB[ii][0] = 0; qsI[ii] = 0; } digitalWrite( LED_BUILTIN, 1 ); while (!Serial && millis() < 2200) digitalWrite( LED_BUILTIN, !digitalRead( LED_BUILTIN) ); Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__); Serial.print("serialEvent() Test - Serial @ms="); digitalWrite( LED_BUILTIN, 0); Serial.println(millis()); Serial.printf("Baud rate: %d\n", SPD); digitalWrite( LED_BUILTIN, 1); firstXfer = micros(); for ( int ii = 0; ii < ACTIVE_SER; ii++ ) { psAll[ii]->print( " setup #" ); psAll[ii]->println( (char)('1' + ii) ); } emWait = 0; } #define WaitRepeat 1 uint32_t iiCnt = 0, iiCntL = 0; void loop() { iiCnt++; if ( emWait >= WaitRepeat ) { emWait -= WaitRepeat; if ( qsI[0] > 0 ) { //&& qsB[0][qsI[0] - 1] == '\n' for ( int ii = 0; ii < ACTIVE_SER; ii++ ) { Serial.print( qsB[ii]); qsB[ii][0] = 0; qsI[ii] = 0; } } for ( int ii = 0; ii < ACTIVE_SER; ii++ ) { if ( 0 != psAll[ii]->available( ) ) { Serial.print( 1 + ii ); Serial.print( "# Ser.available( )" ); Serial.println( psAll[ii]->available( ) ); } } Serial.print( " [lpHz=" ); Serial.print( 1000/WaitRepeat*(iiCnt - iiCntL) ); iiCntL = iiCnt; Serial.print( " xFer us=" ); Serial.println( lastXfer - firstXfer ); firstXfer = micros(); for ( int ii = 0; ii < ACTIVE_SER; ii++ ) psAll[ii]->printf( " loop #%c @%u ", (char)('1' + ii), millis() ); } }
Code:T:\tCode\T4\One2_SerTest_MIN\One2_SerTest_MIN.ino Jun 29 2019 02:35:42 serialEvent() Test - Serial @ms=809 Baud rate: 5000000 setup #5 setup #1 setup #2 setup #3 setup #4 [lpHz=2225000 xFer us=45 loop #5 @810 loop #1 @810 loop #2 @810 loop #3 @810 loop #4 @810 [lpHz=2181000 xFer us=74 loop #5 @811 loop #1 @811 loop #2 @811 loop #3 @811 loop #4 @811 [lpHz=2181000 xFer us=75 loop #5 @812 loop #1 @812 loop #2 @812 loop #3 @812 loop #4 @812 [lpHz=2180000 xFer us=74 loop #5 @813 loop #1 @813 loop #2 @813 loop #3 @813 loop #4 @813 [lpHz=2181000 xFer us=74 // ...
Last edited by defragster; 06-29-2019 at 10:19 AM. Reason: Updated code to track loop() Hz
Posting Permissions
Reply With Quote