Teensy 4.0 First Beta Test

Status
Not open for further replies.
Ah yes, that's a very good point. This probably needs to be done with another level of callback, where the EventResponder calls a function within the HardwareSerial class. Then that function calls serialEvent(), and after the serialEvent() function returns, if there's still data in the receive buffer after the user's serialEvent ran, it would again trigger the EventResponder to repeat this process on the next yield (or on some near-future yield).
...

If I followed that … "have data will callback" … when the user is reading data at some point in queue maintenance will be cases like these where added code could flag - disableSerialEvents ::
>> if (head == tail) return -1;
>> rx_buffer_tail_ = tail;

That would add code to a few places.

Or perhaps the system runs as it does and without extra code or effort the buffer goes empty :: (head == tail)

The next yield test calls - the one after it went empty and the first test split out ::
Code:
int HardwareSerial::available(void)
{
	uint32_t head, tail;

	head = rx_buffer_head_;
	tail = rx_buffer_tail_;
[U][B]if (head == tail) { disableSerialEvents(); return 0; }[/B][/U]
	else if (head > tail) return head - tail;
	return rx_buffer_total_size_ + head - tail;
}

This would mean just one call after going empty, but on a busy port data may arrive time between yield() checks and this case would not be met and new data would be distributed.
 
Who knows where to find the sourcecode of the size-tool ? (It shows the memory consumption at the bottom of the window)
We'd have to adjust that for OCRAM.

Have my ILI-9341 library working -
I'll try to make it work with Teensy 3.6 and Teensy 4
Need Suggestions for a new name.. works different from ILI9341_t3, because of the buffering and DMA.
so, ILI9341_t3 is not a good idea... ILI9341_t36t4dma? not good.
 
does anyone have the nanos() code i can play with? i think the chip is too fast to do speed tests on variables, as micros/millis never change when im testing floats
Also there doesnt seem to be a code limit size break in the IDE, always shows 1% program and 6% global variables, at a certain point i tried to exagerate as a test 10000 floats and doubles, and the T4 didn't lock up but went into a reboot-loop, so the post data was scrolling on Serial4 over and over and over and over. I didn't need to hit reset though to reprogram :)

To time fast things use the cycle counter instead of micros() - best possible resolution and very little overhead:
Code:
uint32_t usedCycles = ARM_DWT_CYCCNT;
Serial.print( " how many MCU cycles does this take ? " );
usedCycles = ARM_DWT_CYCCNT - usedCycles;
Serial.print( usedCycles );

shows :: how many MCU cycles does this take ? 31677
 
yeah i just wanted to test a conversion from cycles to nanos, cycles show “2” when multiplying 1000 floats
 
..........
Code:
ops.. TIM  big sorry .. hit the wrong button end editited this message instead replying..argh.. happened the first time. BIG sorry.
don't have your original text. Frank
 
this is ran from setup before a while(1); blocks the loop

Code:
float float_rand( float min, float max ) {
  float scale = rand() / (float) RAND_MAX; /* [0, 1.0] */
  return min + scale * ( max - min );      /* [min, max] */
}
double double_rand( double min, double max ) {
  double scale = rand() / (double) RAND_MAX; /* [0, 1.0] */
  return min + scale * ( max - min );      /* [min, max] */
}



void fishy() {

  uint16_t _size = 1000;
  float _float[_size] = { 0 };
  double _double[_size] = { 0 };

  for ( uint32_t i = 0; i < _size; i++ ) {
    _float[i] = random((float) - 1000.0, (float)1000.0);
    _double[i] = random((double) - 1000.0, (double)1000.0);

    _float[i] = float_rand(-1000, 1000);
    _double[i] = double_rand(-1000, 1000);
  }


  uint8_t jump = 0;
  for ( uint32_t i = 0; i < _size; i++ ) {
    Serial4.print(_double[i], 9); Serial4.print(" ");
    if ( jump >= 20 ) {
      jump = 0;
      Serial4.println();
      continue;
    }
    jump++;
  } Serial4.println();

  uint32_t _timeS, _timeE, _begin, _end, _calc;

  Serial4.println("Multiplication test running...");
  float _test;
  _timeS = micros();
  _begin = ARM_DWT_CYCCNT;
  for ( uint32_t i = 0; i < _size; i++ ) {
    _test *= _float[i];
  }
  _timeE = micros();
  _end = ARM_DWT_CYCCNT;
  Serial4.print("Completed: ");
//  Serial4.print( (_end - _begin) ); // == 2?
  Serial4.println("uS");
  Serial4.println(_timeE - _timeS);
}

With the code above i am getting 0uS and 0ms with micros and millis, but possibly it could be optimized
 
what I wrote was to the effect of : that can't be right - every clock tick is counted. if there are only 2 cycles then nothing happened - as Frank then wrote - the compiler probably optimized it away.

I've seen that before trying to do time test that the compiler detects no meaningful use of the computation - discard computation.

..........
Code:
ops.. TIM  big sorry .. hit the wrong button end editited this message instead replying..argh.. happened the first time. BIG sorry.
don't have your original text. Frank

Odd - doesn't even show 'who' that was????

I've done that at least 5 times - but always caught myself … so far

Machine needs restart after only 3 days … that prior post #512 was the sign of something … I have text and picture but need to restart before I can see my hard disk it seems ...
 
indeed.
not really good, but you can make _test volatile :)
- but, this adds the time to write that to memory.. on the other hand, it might be cached. not easy to test this stuff. you need assembler, maybe..

...and you might want to swap these lines:
Code:
  _timeE = micros();
  _end = ARM_DWT_CYCCNT;
otherwise it adds the time for the micros() - call, too.
 
Okay - it booted - not a normal boot - something got odd … related to IDE and the post #512 confusion AFAIK ...

So to follow up on post #512 - I quit the overnight test on Serial/LedControl/IntervalTimer - all was good and running - though last night when I was looking for info for post 512 SerMon got closed and paused the T4 :( - luckily I came back and saw that …

In editing the couple lines I decided to time for Tony my open IDE - connected to T4 SerMon and set as Board I got this from TLoader:
WrongBoard.PNG

For some reason the T_3.6 - not shown in ports was selected for upload - even though it was in a running state?

The TLoader Verbose at that time is this :: View attachment WrongBoard.txt
 
IRrecv Lib
Got my receiver a little while ago, hooked it up and ran the demo sketch - picked up my old Samsung remote as well the FiosTV remote. Another lib off the list.
 
Yes, already flagged in Post #4 ::
Adafruit_SSD1306 post #478 Needs avr_emulation for SP[?]R - uses _GFX

Paul noted sometime before the emulation layer was to be done <entries in Post #6>.

I ordered that Amazon IR Board - I have two kits with remotes I got from SparkFun one sale day … don't know where they are

Also noted in post #478 yesterday that WIRE isn't found when building for T_3.x's - will have to check that with Beta 7 code
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.

<edit> 2 WIRE examples I just T_3.6 Verify on work though
 
Last edited:
Something is wrong with DMA..
I tried my "fillscreen" all the time, and indeed it worked.
Well, in fact it filled the screen with same *wrong* adresses in the buffer - was not visible because it had the same contents.. The same code worked for 3.6, so there must be some difference in the hardware..

Edit:
..or..not..it was a cached TCD, I think.

solved.

Frank,
do you have small example that you can share that demonstrates SPI DMA for T4?
thanks
 
manitou, hm, no, I can upload my library in one or two days, but it is not good as example.
more or less it works as with 3.6
some differences:
to send:
- dmasettings.TCD->DADDR = &LPSPI4_TDR;
- the LPSPI does not like a full RX fifo by default, and stops sending if it is full
- the LPSPI is a bit tricky when you want to STOP a transfer.
- works best with tx-fifo-watermark set to 0 (zero)
some code:

Code:
  LPSPI4_CR &= ~LPSPI_CR_MEN;//disable LPSPI:
  LPSPI4_CFGR1 |= LPSPI_CFGR1_NOSTALL; //prevent stall from RX
  //LPSPI4_TCR = 15; // Framesize 16 Bits 
  LPSPI4_FCR = 0; // Fifo Watermark
  LPSPI4_DER = LPSPI_DER_TDDE; //TX DMA Request Enable
  LPSPI4_CR |= LPSPI_CR_MEN; //enable LPSPI:
stopping is tricky (or i may have a wrong setting somewhere)
I use this code, currently:
Code:
  while (!dmatx.complete());
  LPSPI4_DER = 0;

  //Wait for last transfer done:
  while ( ((LPSPI4_FSR)) > 0) {
    LPSPI4_RDR;
  }
  while (!(LPSPI4_SR & LPSPI_SR_TCF) && ((LPSPI4_SR & LPSPI_SR_MBF)));

without that, you may end with starting a new transfer, while the old is still running.
- I've struggled with that hours.. the LPSPI4_DER = 0; seems to be very important .. don't know exactly, why. did not work reliable without.
- Even with "LPSPI_CFGR1_NOSTALL" there are some RX-Bytes that need to be removed.

If it's just for benchmarks, you can ignore all that...
 
Paul - just confirmed on my other machine still with Beta 3 1.46 also cannot compile for T_3.6 the Adafruit_SSD1306 i2c Example :: problem with WIRE
"C:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit_SSD1306\examples\ssd1306_128x32_i2c\ssd1306_128x32_i2c.ino"::
C:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp: In member function 'void Adafruit_SSD1306::begin(uint8_t, uint8_t, bool)':

C:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:206:5: error: 'Wire' was not declared in this scope

Wire.begin();

I saw this on my desktop with current beta #6 as noted and didn't see what was behind it.
 
SerialX objects, did PR for .end(), objects split into separate source files, and first pass at serialEventX calls, like mentioned in previous post. Will look into how to use event responder soon, but may first get more stuff working.
 
SerialX objects, did PR for .end(), objects split into separate source files, and first pass at serialEventX calls, like mentioned in previous post. Will look into how to use event responder soon, but may first get more stuff working.

@KurtE - Nice, I can work up an event responder sample for SerialEventX with beta 7 release if that helps choosing.

IIRC - Event responder list is only parsed/checked in yield() case? So not unlike SerialEvent in some respects. It won't be an unpredictable interrupt during normal loop() operations - without delay()/yield() - and that would include the Serial_callbacks?

If my earlier note was on point about stopping callback when (0 ==.available) then it would be up to the Rx_isr to enable it when data arrives back to the buffer?

If those extra tests to unused Serial#'s drop out efficiently that will make calling yield() during loop() less expensive and more productive.
 
Thanks @defragster - Hopefully all of the pieces are in place, for a good test of the Serial Events... I have not done anything yet for serialEvent (USB). As I believe a lot of the USB serial code may be updated maybe this week? ...

@Paul (and others), Thought I might take a quick diversion and play with a few other things.

Thought that since my wireless breadboard has a Sparkfun TeensyView display plugged in on the other end of it, thought I might try it... (SPI SSD1306).

Does not compile... At least my version of the library, I assume also the default Sparkfun one as well...
Again with the standard stuff of:
Code:
	pinMode(csPin, OUTPUT);
	_csport    = portOutputRegister(digitalPinToPort(csPin));
	_cspinmask = digitalPinToBitMask(csPin);
	*_csport |= _cspinmask;
	pinMode(dcPin, OUTPUT);

Errors:
Code:
C:\Users\kurte\Documents\Arduino\libraries\SparkFun_TeensyView_Arduino_Library\src\hardware.cpp:99:13: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'volatile uint8_t* {aka volatile unsigned char*}' in assignment

  _csport    = portOutputRegister(digitalPinToPort(csPin));

             ^

C:\Users\kurte\Documents\Arduino\libraries\SparkFun_TeensyView_Arduino_Library\src\hardware.cpp:103:13: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'volatile uint8_t* {aka volatile unsigned char*}' in assignment

  _dcport    = portOutputRegister(digitalPinToPort(dcPin));

             ^

Error compiling for board Teensy 4-Beta1.
Again I know I can copy some of the stuff from onewire to fix... But wondering if some of the OneWire stuff maybe should be defined in Core?
 
Maybe I should get a default version of Sparkfun library... Mine is hacked up to allow things like multiple displays on same or different SPI busses...

Hacked up to get around first error messages mentioned above, now running into a few other compiler/linker issues. It appears that the library or at least their test program uses the
Serial object, so running into:

Code:
D:\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TD:\\arduino-1.8.8\\hardware\\teensy\\avr\\cores\\teensy4/imxrt.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -fsingle-precision-constant -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409/Teensyview_ScreenDemo.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409\\sketch\\Teensyview_ScreenDemo.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409\\libraries\\SPI\\SPI.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409\\libraries\\SparkFun_TeensyView_Arduino_Library\\TeensyView.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409\\libraries\\SparkFun_TeensyView_Arduino_Library\\hardware.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409/..\\arduino_cache_651785\\core\\core_teensy_avr_teensy4b_usb_serial,opt_o2std,keys_en-us_86f260b7ebc565879a7e32f9efe1770a.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_108409" -larm_cortexM4lf_math -lm -lstdc++
C:\Users\kurte\AppData\Local\Temp\arduino_build_108409\sketch\Teensyview_ScreenDemo.ino.cpp.o: In function `pixelExample()':

C:\Users\kurte\Documents\Arduino\Teensy Tests\Teensyview_ScreenDemo/Teensyview_ScreenDemo.ino:126: undefined reference to `String::String(char const*)'

C:\Users\kurte\Documents\Arduino\Teensy Tests\Teensyview_ScreenDemo/Teensyview_ScreenDemo.ino:126: undefined reference to `String::~String()'

C:\Users\kurte\AppData\Local\Temp\arduino_build_108409\sketch\Teensyview_ScreenDemo.ino.cpp.o: In function `lineExample()':

C:\Users\kurte\Documents\Arduino\Teensy Tests\Teensyview_ScreenDemo/Teensyview_ScreenDemo.ino:142: undefined reference to `String::String(char const*)'

C:\Users\kurte\Documents\Arduino\Teensy Tests\Teensyview_ScreenDemo/Teensyview_ScreenDemo.ino:142: undefined reference to `String::~String()'
...
Also other String functions undefined like: String::getBytes(unsigned char*, unsigned int, unsigned int) const'

Still investigating. Can probably create quick example if anyone wants...

Here is a quick example that fails to link
Code:
void setup() {
  while (!Serial && millis() < 4000);
  Serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
  printTitle("Test line", 1);

}
void printTitle(String title, int font)
{
  Serial.println(title);
}
void pixelExample()
{
  printTitle("Pixels", 1);
}
Could simplify more...

Code:
C:\Users\kurte\AppData\Local\Temp\arduino_build_13603\sketch\test_use_strings.ino.cpp.o: In function `loop':

C:\Users\kurte\Documents\Arduino\Teensy Tests\test_use_strings/test_use_strings.ino:8: undefined reference to `String::String(char const*)'

C:\Users\kurte\Documents\Arduino\Teensy Tests\test_use_strings/test_use_strings.ino:8: undefined reference to `String::~String()'

C:\Users\kurte\AppData\Local\Temp\arduino_build_13603/..\arduino_cache_651785\core\core_teensy_avr_teensy4b_usb_serial,opt_o2std,keys_en-us_86f260b7ebc565879a7e32f9efe1770a.a(Print.cpp.o): In function `Print::print(String const&)':

D:\arduino-1.8.8\hardware\teensy\avr\cores\teensy4/Print.h:59: undefined reference to `String::getBytes(unsigned char*, unsigned int, unsigned int) const'

collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy 4-Beta1.
Verified that it the simple example does compile and link for T3.6
 
Last edited:
Still have one of the SparkFun Tview on my desk - been trying to ignore it for SPI - didn't realize it was not standard. You did all that work and I got two but I never connected more than one. Seems like it might be closer than the Adafruit version ssd1306 through emulated calls.

Starting with the SparkFun default would be boring but make sure it is ready to use :(
 
TALKIE LIBRARY and EMIC2 and ADAFRUIT BNO055 Lib and NXPMOTIONSENSE

Starting testing other libraries in between other things. So here is what I found so far

EEPROM Library: On T4 to do list will be needed for NXPMOTIONSENSE, BNO055
SD/SDFAT: Needed for EMIC2 Library, also have to add a couple defines for the imxrt boards

Know EEPROM and SD/SDFAT are on the todo list.

TALKIE LIBRARY issues:
According to the readme the lib was modified to use the t3.x DAC well. However, no DAC available. So I hacked it just to go out to a PWM pin. You can definitely here voices under this very loud high pitch tone. Will have to dig into the code. Again this was just a kludge to test with.
 
Original Talkie from Arduino was PWM'd - Paul put on DAC - that code is still there IIRC - Paul hooked in a Teensy Timer - I put the non-blocking queue in the code - but that shouldn't affect the process. Hopefully the sound won't be corrupted by extra noise. I pushed a prop shield on my breadboard last night and thought of Talkie but didn't get as far as looking into the needed connect wires. Or thinking of the DAC needing to go back to PWM.

<edit>: Mike - just glanced at Talkie code - did you alter the PWM frequency? They indicate 62500Hz for PWM. (is that working yet?) I see the AVR stuff in there - but it is the AVR method - suppose it would just be a lesser pin: analogWrite(A8, nextPwm); and that shows as 'PWM4_A0' or maybe Pin_3 common to Arduino that also has 'PWM4_B2' indicated?
 
Last edited:
Status
Not open for further replies.
Back
Top