@Frank B
I added an I2Cscanner function to the playsynthmusic.ino and it does recognoize a i2c device:
Code:Begin C:\Users\Merli\AppData\Local\Temp\arduino_modified_sketch_641255\PlaySynthMusic.ino setup done Scanning... I2C device found at address 0x0A ! done Proc = 1.38 (1.42), Mem = 2 (5) Proc = 2.74 (2.82), Mem = 2 (16)
I am doing some Serial port tests, and my updates for Serial2 -
My Serial test program however is having some issues with Serial6 and Serial 7... I deleted Serial8
For testing it, I am using Serial4 as the echo point (normally would have been Serial, but...). I start off jumper TX1->RX2 and then if I jumper TX2->RX1 it shows the string I was outputting.. So then move the RX1 to RX3 and then try TX3 to RX1 and it works... So I get to TX1->RX2, TX2->RX3, TX3->RX5, TX5-> RX1 and it works. Trying to RX6 or RX7 it is not showing it receiving any data.Code://connect Serial1 TX -> Serial2 RX, Serial2 TX -> Serial3 RX, Serial3 TX -> Serial4 RX.... #define SPD 1000000 int loop_count = 0; int receive_counts[8]; int callback_counts[8]; void setup() { pinMode(13, OUTPUT); // while (!Serial && millis() < 4000) ; // Serial.begin(115200); delay(800); Serial4.println("Test all Serials"); Serial4.printf("Baud rate: %d\n", SPD); Serial1.begin(SPD); Serial2.begin(SPD); Serial3.begin(SPD); Serial4.begin(SPD); Serial5.begin(SPD); Serial6.begin(SPD); Serial7.begin(SPD); } void loop() { for (int i=0; i < 8; i++) { receive_counts[i] = 0; callback_counts[i] = 0; } Serial4.printf("Loop: %d\n", ++loop_count); Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n"); Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n"); Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n"); delay(1000); Serial4.println(); for (int i=0; i < 7; i++) { Serial4.printf("%d: %d %d ", i, callback_counts[i], receive_counts[i]); } Serial4.println(); } void serialEvent1() { digitalWrite(13, !digitalRead(13)); uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial1.available()), Serial4.availableForWrite()); Serial1.readBytes(buffer, cb); Serial4.write(buffer, cb); callback_counts[0]++; receive_counts[0] += cb; } void serialEvent2() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial2.available()), Serial2.availableForWrite()); Serial2.readBytes(buffer, cb); Serial2.write(buffer, cb); callback_counts[1]++; receive_counts[1] += cb; } void serialEvent3() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial3.available()), Serial3.availableForWrite()); Serial3.readBytes(buffer, cb); Serial3.write(buffer, cb); callback_counts[2]++; receive_counts[2] += cb; } #if 0 void serialEvent4() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial4.available()), Serial4.availableForWrite()); Serial4.readBytes(buffer, cb); Serial4.write(buffer, cb); callback_counts[3]++; receive_counts[3] += cb; } #endif void serialEvent5() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial5.available()), Serial5.availableForWrite()); Serial5.readBytes(buffer, cb); Serial5.write(buffer, cb); callback_counts[4]++; receive_counts[4] += cb; } void serialEvent6() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial6.available()), Serial6.availableForWrite()); Serial6.readBytes(buffer, cb); Serial6.write(buffer, cb); callback_counts[5]++; receive_counts[5] += cb; } void serialEvent7() { uint8_t buffer[80]; uint8_t cb = min (min((int)sizeof(buffer), Serial7.available()), Serial7.availableForWrite()); Serial7.readBytes(buffer, cb); Serial7.write(buffer, cb); callback_counts[6]++; receive_counts[6] += cb; }
Wondering if
A) the Pogo pins are working? Actually looking at the Adapter board I don't think there are any pogo pins installed for the bottom pins, except pins 30 and 31?
So makes sense it does they don't work
I have a working i2c SSD1306 on T4-2
To get that I pulled Adafruit_GFX and Adafruit_SSD1306 into sketchbook\libraries from prior releases. To the hardware is working - but needs working libraries. The GFX needs some fixes - at least as used by the no longer included SSD1306 lib.
I noticed just the two POGO pins on the bottom 'pad array' - I didn't note which - nice to know that is #30 and #31 and others missing.
KurtE - if the Pin Adds for 'SD ARRAY' goes through - like it did on the T_3.6 than Serial8 would be usable on those pins.
Becareful with the Adafruit GFX library - I had to update it to the latest from Adafruit - not sure if Paul pulled in the latest with beta11.Originally Posted by defragster
@mjs, Tim:
I2C:
Weird results with the audio-shield.
with my patched file (attached) I get different results every time i disconnect-and reconnect usb-cable. Output should be all 1s.
what I get is for example:
.. or it is completely different.Code:chip ID = A011 0 0 1 1 1 1 1 0
Oh thanks I didn't look at the commit time I thought that Teensy GitHub mirrored the teensyduino installer.
Most of the time if its stable. With T4 it can sometimes be a moving target and problems and PRs are incorporated. I feel bad for Paul - there is only so much time in the day for himRight now I actually pulled in SPI lib and Core changes from @KurtE for the T4-beta2.
@Frank B - @defragster
That is really weird. I have no ideas on this one. I keep wanting to say check pad config for SCL/SDA maybe something changes for 1062. But that is a passing thought.
I try SPDIF now. It does not need a codec or I2C
As noted in 2353 - my first/only test so far for i2c works as expected on SDA/SCL labelled breakout pins to the SSD1306 display I see running Adafruit Flakes - only issue is missing/broken libraries.
Mike - can you compare the Adafruit_GFX you have versus the NEW one put into 1.46 late Beta when SSD1306 was pulled.
Is there a new SSD1306 we should get from AdaFruit? but the _GFX has type mismatch on Portset so it won't compile at least for T4
<UPDATE>: github.com/adafruit/Adafruit_SSD1306
This was last updated 5 months ago - and it is working with the "OLD _GFX" - I changed this line in header as needed that says this is deprecatated - perhaps with new _GFX?
#define SSD1306_128_64 ///< DEPRECTAED: old way to specify 128x64 screen
I see this was updated 2 days ago :: github.com/adafruit/Adafruit-GFX-Library
The one included in 1.46 is giving errors - so if one were to be Teensy Fixed for inclusion it should be the latest?
Pulled the Current Adafruit_GFX linked above and similar set of errors as that included in TD1.46:
Code:"T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -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=146 -DARDUINO=10809 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_906278/pch" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\libraries\\Wire" "-It:\\tcode\\libraries\\Adafruit_GFX" "-It:\\tcode\\libraries\\Adafruit_SSD1306" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\libraries\\SPI" "t:\\tcode\\libraries\\Adafruit_GFX\\Adafruit_SPITFT.cpp" -o "T:\\TEMP\\arduino_build_906278\\libraries\\Adafruit_GFX\\Adafruit_SPITFT.cpp.o" In file included from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:35:0: t:\tcode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined #define PROGMEM ^ In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0, from T:\TEMP\arduino_build_906278/pch/Arduino.h:6, from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.h:5, from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:34: T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition #define PROGMEM __attribute__((section(".progmem"))) ^ t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp: In constructor 'Adafruit_SPITFT::Adafruit_SPITFT(uint16_t, uint16_t, int8_t, int8_t, int8_t, int8_t, int8_t, int8_t)': t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:124:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment dcPortSet = portSetRegister(dc); ^ t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:125:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment dcPortClr = portClearRegister(dc); ^ t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:126:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment swspi.sckPortSet = portSetRegister(sck); // … more
Last edited by defragster; 04-23-2019 at 08:49 PM.
OK, S/PDIF works on pin 2 ("output SPDIF2"), not on Pin 6 ("Output SPDIF") I remember there were changed pins.. which post-# was it?
found it.
So.. no problem with I2S Timing - the emulated SPDIF works
Patch for SPDIF(i2s0 Pin6 -> Pin7) is here: https://github.com/PaulStoffregen/Au...oesing:patch-1
The same patch is needed for I2s .. but .. there must be more.
I am actually trying to debug the extra pins now... As can not test the other bottom pins yet, as nothing connecting them...
But so far my access to pins 34-39 with my current stuff is faulting:
Right now using Serial4 to test pins...
Using my blink any pin:Code:***********IMXRT Startup********** test 1 -1234567 3 CCM_ANALOG_PLL_USB1=80003000 enable USB clocks CCM_ANALOG_PLL_USB1=80003040 Increasing voltage to 1250 mV need to switch to alternate clock during reconfigure of ARM PLL USB PLL is running, so we can use 120 MHz Freq: 12 MHz * 100 / 2 / 1 ARM PLL=80002042 ARM PLL needs reconfigure ARM PLL=80002064 New Frequency: ARM=600000000, IPG=150000000 USB reset took 6 loops analogInit usb_cdc_line_coding, baud=0 before C++ constructors after C++ constructors before setup Find Pin by blinking Enter pin number to blink Now Blinking pin 33 Fault irq 3 stacked_r0 :: 3D314253 stacked_r1 :: 00000001 stacked_r2 :: 52452020 stacked_r3 :: 200002A4 stacked_r12 :: E33CC779 stacked_lr :: 000000CB stacked_pc :: 00000974 stacked_psr :: 610E0200 _CFSR :: 00000082 _HFSR :: 40000000 _DFSR :: 00000000 _AFSR :: 00000000 _BFAR :: 3D314257 _MMAR :: 3D314257 need to switch to alternate clock during reconfigure of ARM PLL USB PLL is running, so we can use 120 MHz Freq: 12 MHz * 75 / 3 / 1 ARM PLL=80002064 ARM PLL needs reconfigure ARM PLL=8000204B New Frequency: ARM=300000000, IPG=150000000 Decreasing voltage to 1150 mV
If not pin 13, it sets pin 13 to input so you can just jumper from specified pin to 13 and you should see blinks... Now debuggingCode:int current_pin = 13; int next_pin_number = 0; #define DBGSerial Serial4 void setup() { // Blink any pin. Note: I put pin 13 as input to see if we can // jumper to it to see if we can find the pin... while (!Serial && millis() < 5000); DBGSerial.begin(115200); delay (250); DBGSerial.println("Find Pin by blinking"); DBGSerial.println("Enter pin number to blink"); pinMode(13, OUTPUT); } void loop() { // put your main code here, to run repeatedly: if (DBGSerial.available()) { int ch; while ((ch = DBGSerial.read()) != -1) { if ((ch >='0') && (ch <= '9')) { next_pin_number = next_pin_number * 10 + (ch-'0'); } else { if (next_pin_number != 0) { digitalWrite(current_pin, LOW); // turn the previous pin to low... current_pin = next_pin_number; pinMode(current_pin, OUTPUT); if (current_pin != 13) pinMode(13, INPUT); digitalWrite(current_pin, HIGH); next_pin_number = 0; // setup to enter next pin DBGSerial.printf("Now Blinking pin %d\n\r", current_pin); } } } } else { digitalWrite(current_pin, !digitalRead(current_pin)); delay(250); } }
EDIT: Fixedpins 34-39 blink appropriately. Pushed up changes to my core branch
Thanks - that works - move to Serial from Serial4.
Added TempMon and it quickly gets to °C=57.869564 at 600 MHz … now with heat soaking it is °C=59.695652 { 139.4521736 degree Fahrenheit }
Odd the top is no where near that hot to touch. Max IR Thermo read on surface is 43C or 109F. Code now showing 60.3C as room is warming.
Did a quick mod for ~1 sec passes with count of 2500:
I put asm "wfi" in prior simple loop and it dropped temps 4-5 degrees C.Code:float myTemp = 0; myTemp = tempmonGetTemp(); Serial.printf( "BEFORE :: \t°C=%f\n" , myTemp ); while (1) { mainCoreMark(); myTemp = tempmonGetTemp(); Serial.printf( "AFTER :: \t°C=%f\n" , myTemp ); }
Doing this to make sure the new smaller PCB is as tolerant and capable of moving heat at speed.
@Paul, @mjs513 ...
Will do a PR with my pin changes soon. But first probably should convert mine to be in same format as Paul's changes. That is I made changes in the middle of the definitions for 1052 and 1062 versus Paul's creating new sections...
So will convert to Paul's and hopefully add new pins.
@defragster - forgot to answer your question:
Assuming PR is taken, the Uart8 pins are also on other IO pins associated with Serial5... So we can add Serial5.setTX and setRX for these pins. Will be a little more complicated then on T3 boards as you both have to change the mode of the IO pin as well as settings for associated MUX register.
Tim - looks like Adafruit did a mass rewrite of their spitft function to include DMA, etc. Now it bears no resemblance to what I was using when I tested it and said it was working with the latest version. I have the 1.3.6 version I think that works - unfortunately I deleted the version in my core library folder when I did the install.
EDIT: Ok found the version that worked - 1.3.6.
Probably 1.47-beta1 tomorrow. Going to fix some more stuff and merge pull requests. I have a little time now, since the next round of PCB have been ordered.
Nice, Since I'm not messing with Cores I'll wait for gathering of fixes and just poke around as I do. New PCB seems to be okay with MCU at 800 MHz.
@mjs513 - Bummer on the AdaFruit updates to _GFX needing attention to get running.
Merged arm_clock change into CoreMark, left output on Serial4 and just used Serial for the text below. I cut the iterations down to 300 so 100 MHz completed in a second and then just call until 30 seconds passes. And I killed 'error' on short run but put in a Serial.print if Other errors in CoreMark. Temp is rising ( Calibration seems off? as my finger and thermometer see max 110F ) - but no errors in running the CoreMark.
CM# is the number of calls to Coremark with 300 iterations - this shows how many complete in each period @MHzCode:F_CPU MHz 99 Sec=30 CM#=43 [Max C=54.217392] AFTER :: °C=53.000000 F_CPU MHz 201 Sec=30 CM#=67 [Max C=53.000000] AFTER :: °C=52.391304 F_CPU MHz 300 Sec=30 CM#=94 [Max C=54.217392] AFTER :: °C=53.608696 F_CPU MHz 402 Sec=30 CM#=119 [Max C=54.217392] AFTER :: °C=54.217392 F_CPU MHz 498 Sec=30 CM#=140 [Max C=55.434784] AFTER :: °C=54.826088 F_CPU MHz 600 Sec=30 CM#=160 [Max C=58.478260] AFTER :: °C=57.869564 F_CPU MHz 696 Sec=30 CM#=177 [Max C=60.913044] AFTER :: °C=60.913044 F_CPU MHz 804 Sec=30 CM#=194 [Max C=63.347824] AFTER :: °C=63.347824 F_CPU MHz 99 25 sec Cooling Period ... °C=62.739132After Cool :: °C=54.217392
Updated my core_pins.h file to use add my changes to Paul's version.
Next up try to run the ILI9488 display on SPI2
@Paul (and others) One thing I noticed with both this Beta 2 board as well as Beta 1 (at least in the adapter boards). If I have the something like a USB to Serial adapter plugged into lets say Serial4 connection (using CP2104 adapter). And then plug in the T4 into USB, the board is not detected by PC... Not sure if it booted or not, but no sounds showing Serial port plugged in... But if the adapter is not connected comes up fine.
My guess is it has to do with the voltage on the RX pin back feeding?
@defragster
Not sure why it is off - looked at the code several times and didn't see anything - will play around a little more it might be timing between measurements is too short.Temp is rising ( Calibration seems off? as my finger and thermometer see max 110F ) - but no errors in running the CoreMark.
in Post #6 :: teensy_ports issues with 3+ boards, #1330, #1398,
That sounds like behavior I was seeing many weeks back? Where I had to have other Teensy's OFFLINE in order for the T4-1 so show up. Those posts suggest it failed to start … @KurtE put a blink to see if it is running to confirm similarity
Seems I attributed that to Current Beta_T4 USB Stack function? Not seen for some time, perhaps it was not using IDE+SerMon+TeensyPorts - but moved to fulltime TyCommander. Since moving to Display off of the Breakout I have not had Serial UART out to other Teensys [ where I use a Teensy not lame USB adapter
One thing I did as a workaround was a powered USB HUB with 5 ports switch controlled and two Always On - so the T4-1 was Always on and I flipped the switch to disable all others when I saw the trouble.
Speaking of TyCommander - I emailed koromix power up and bootloader messages he shows in his app log - hopefully that will let him ID the T4-2 and get an update shortly.
Measurements are at least 150 ms apart ( 194 in 30 secs at the fastest )
Here is the code to see if you get the same results: TeensyCoremark.zip
Opps, I probably should have made one with all 10 pins for you. They were all done the same and soldering extra pins times 9 boards was time I didn't have.Trying to RX6 or RX7 it is not showing it receiving any data.
Wondering if
A) the Pogo pins are working? Actually looking at the Adapter board I don't think there are any pogo pins installed for the bottom pins, except pins 30 and 31?
So makes sense it does they don't work
I'll send you a package today with extra pogo pins and another bare PCB. Some assembly required. That's the most I can do at this moment. If you're still needing Serial6 & Serial7 hardware, ping me in a week or so and I'll get another board soldered up for you.
Posting Permissions
Reply With Quote