Teensy Qt

If you are using Serial inside Teensy - any number works to talk to TYQT over USB that has a fixed mechanism for setting maximum speed.
 
As defragster said, the baudrate and other serial settings have no direct effect on the USB serial emulation, so it did not feel worth it to clutter the UI with these useless settings. I believe they can be used for some kind of out-of-band PC/Teensy communication though, but I'm not sure if that's enough to justify exposing them.
 
stevech said:
Those posts also discussed how you can use a "self administred" MAC address - there are two bits in the MSB of the MAC that say it's self-administered not assigned by the IEEE or manufacturer.
Click to expand...

Are you talking about this?

https://en.wikipedia.org/wiki/MAC_address

Universally administered and locally administered addresses are distinguished by setting the second-least-significant bit of the most significant byte of the address. This bit is also referred to as the U/L bit, short for Universal/Local, which identifies how the address is administered. If the bit is 0, the address is universally administered. If it is 1, the address is locally administered. In the example address 06-00-00-00-00-00 the most significant byte is 06 (hex), the binary form of which is 00000110, where the second-least-significant bit is 1. Therefore, it is a locally administered address. Consequently, this bit is 0 in all OUIs.

If the least significant bit of the most significant octet of an address is set to 0 (zero), the frame is meant to reach only one receiving NIC. This type of transmission is called unicast. A unicast frame is transmitted to all nodes within the collision domain, which typically ends at the nearest network switch or router. A switch will forward a unicast frame through all of its ports (except for the port that originated the frame) if the switch has no knowledge of which port leads to that MAC address, or just to the proper port if it does have knowledge. Only the node with the matching hardware MAC address will accept the frame; network frames with non-matching MAC-addresses are ignored, unless the device is in promiscuous mode.
Click to expand...
 
Yes, that looks like the detail confirming having a local device make a safe/compatible MAC - when you make a serial# for a homebrew/other Teensy.
JBeale said:
Are you talking about this?
Click to expand...
the second-least-significant bit of the most significant byte of the address ... If it is 1, the address is locally administered. In the example address 06-00-00-00-00-00 the most significant byte is 06 (hex), the binary form of which is 00000110, where the second-least-significant bit is 1. Therefore, it is a locally administered address
Click to expand...
 
Last edited:
yes, that's locally administered. You can set your MCUs to whatever unique address you want so long as bit 0 of the MSByte is 0. You have to assure the addresses are unique via a crib sheet or some other means.

I used that with bits from the MCU's unique ID number (an older ARM7).

LAN only. Can't be used in an edge router.
 
defragster said:
I should have noted C> in my post #235 above: Tyqt might indicate or give preference to 'bootloader mode' devices or when a button is pushed when the select dialog is up? That could lead to trouble like with single minded TeensyDuino - but sometimes it helps identify the right device? Maybe just color change devices in bootloader state?
Click to expand...

Well the icon changes to a "house" in bootloader mode, although it remains black. I prefer to reserve colors for ponctual states (orange = working / red = error).

defragster said:
Koromix - what does TYQT do when presented with a -1 serial #? I assume multiple such devices would get confused?
Click to expand...

It does nothing special. Multiples devices with the same serial number won't get confused while TyQt is running because the USB topology information is used to follow boards across resets. However, persistent settings and labels use the serial number, so after you restart TyQt your custom settings will get mixed.

As for why you get a "-1", either that's what the board is presenting, or it is possible that the current Win32 enumeration code is wrong. You'd think that getting the descriptors and the S/N of a USB device would be straightworward... well, it is except on Win32. The mix of SetupAPI / Configuration Manager / registry you need to do that is just a mess. Though I probably need to refactor that code a little bit, as it was made by a lot of trial & error.
 
Koromix said:
Well the icon changes to a "house" in bootloader mode, although it remains black. I prefer to reserve colors for ponctual states (orange = working / red = error).
Click to expand...

I was actually making a wish for a magical 'do what I'm thinking' modification. I'm often not sure what I'm thinking - but what seemed nice would be when the 'where to upload' list dialog comes up - that a Teensy in 'bootloader state' would somehow be the default selection or otherwise stand out as the one I want to click - as the list of lines is not 'full size':
tyqtbootloader.PNG

Koromix said:
It does nothing special. Multiples devices with the same serial number won't get confused while TyQt is running because the USB topology information is used to follow boards across resets. However, persistent settings and labels use the serial number, so after you restart TyQt your custom settings will get mixed.

As for why you get a "-1", either that's what the board is presenting, or it is possible that the current Win32 enumeration code is wrong. You'd think that getting the descriptors and the S/N of a USB device would be straightworward... well, it is except on Win32. The mix of SetupAPI / Configuration Manager / registry you need to do that is just a mess. Though I probably need to refactor that code a little bit, as it was made by a lot of trial & error.
Click to expand...

That is what I feared - or - expected because the serial # isn't set to PJRC standards. In case you missed the details in the THREAD HIJACK - the "-1" comes from a non-PJRC Teensy using the PJRC boot loader chip that was shipped with the CORTEX write once FLASH BITS not having values written to the area used by PJRC to embed a MAC ID and Serial number to each Teensy in the accustomed format. Of course uninitialized flash is all ones - which reads as "-1' and will for any and all such devices shipped by anyone not taking that step. As noted - to try to minimize the HIJACK ( I started ) - there really should be a thread that covers this so that anyone buying or making a PJRC based programmable PCB gets the same respect. I only have one such device at this time - so I'm not really in a position to experiment or test out writing to that write once area . . . though I should take time to put these details in a thread . . .

It would be nice to have a similar standard that is a local MAC address - based off the CORTEX serial number perhaps. I'm now wondering since that value is returned as part of the USB descriptor - if PJRC might not be able to make up a 'serial #' on the fly based on the CPU serial #? A new thread might get an answer to that.
 
I have a monitor line feed problem. In the TyQt monitor, I have to use only a \r so as not to get an extra line feed. In the Arduino IDE monitor, I need a \n\r. Is there a way of making them act the same?
 
You should use "\n" (LF) or "\r\n" (CRLF) for newlines. The first is the standard newline character on Unix derivatives, the combined form tends to be used on DOS and Windows. Both should work the same in Arduino and TyQt.

I don't recall ever reading about a platform using "\n\r" although I would not be surprised if it got used on obscure long-obsoleted platforms. "\r" was used by Apple before Mac OS X, now it will just bring you a lot of pain as each software will treat it differently.
 
Last edited:
Koromix said:
You should use "\n" (LF) or "\r\n" (CRLF) for newlines. The first is the standard newline character on Unix derivatives, the combined form tends to be used on DOS and Windows. Both should work the same in Arduino and TyQt.

I don't recall ever reading about a platform using "\n\r" although I would not be surprised if it got used on obscure long-obsoleted platforms. "\r" was used by Apple before Mac OS X, now it will just bring you a lot of pain as each software will treat it differently.
Click to expand...
windows/DOS did or still does use CR/LF by default. Most terminal programs have an option choice of LF, CR and auto-insert LF, or CR/LF. I use Bray's Terminal a lot.
 
I am aware of that, this is what I said in the first paragraph. "\n\r" (LF+CR) is the form I have never seen, which is what Arctic_Eddie was trying to use.
 
The "\r\n" works as expected on both Arduino and Qt. However, "\n\r" works on Arduino but generates an extra LF on Qt. I'll stick with the "\r\n" as it behaves the same on both monitors. The "\n\r" form I was using for several years was found in an example some place. I never thought about the correctness or history as it always did what I expected in Arduino. Only recently have I started using Teensy and Qt.

Thanks for the explanation and suggestion.
 
Why does TYQT -206- on Win_10 show recurring out of order prints from the simple sketch below in the second set? I added generous delays and it persists?

{ also at one point before this with more faster prints the output just stopped being logged ( double the interior for() loop code - and remove the internal delays }

14==pin, val==0
15==pin, val==0
16==pin, val==113
17==pin, val==1023
18==pin, val==1023
19==pin, val==417
20==pin, val==293
21==pin, val==1023
22==pin, val==339
23==pin, val==200
-------
-------

14==pin, val==0
15==pin, val==0
16==pin, val==169
17==pin, val==1023
19==pin, val==433 <<---------------
18==pin, val==1023
20==pin, val==204
21==pin, val==1023
22==pin, val==331
23==pin, val==252
-------
-------
Click to expand...

Code: 
#define analogInputs 10
// int inputAnalog[analogInputs];
[B]int inputAnalog[analogInputs*3];[/B]  // BUG BUG - played games below with i
// index variable for loop
int i;

void setup() {
  Serial.begin(31250);
  while ( !Serial && (millis() < 4000 ));
}

void loop() {
  // loop trough active inputs
  for (i = 14; i < (14 + analogInputs); i++) {
    // read current value at i-th input
    inputAnalog[i] = analogRead(i);
    Serial.print( i );
    Serial.print( "==pin, val==" );
    Serial.println( inputAnalog[i] );
    delay(25);
  }
    Serial.println( "-------" );
    Serial.println( "-------\n" );
  delay(5000);
}
 
Last edited:
I just tested it, and it also happens with a simple cat from the serial device on Linux. It comes from your sketch, your are writing past the end of your analogInputs array.

Code: 
#define analogInputs 10
int inputAnalog[analogInputs];
// index variable for loop
int i;

void setup() {
  Serial.begin(31250);
  while ( !Serial && (millis() < 4000 ));
}

void loop() {
  // loop trough active inputs
  for (i = 14; i < (14 + analogInputs); i++) {
    // read current value at i-th input
    [B]inputAnalog[i] = analogRead(i);[/B] // out of bound
    Serial.print( i );
    Serial.print( "==pin, val==" );
    [B]Serial.println( inputAnalog[i] );[/B] // out of bound
    delay(25);
  }
    Serial.println( "-------" );
    Serial.println( "-------\n" );
  delay(5000);
}
 
Thx - OF COURSE - I hacked 'i' to test something in a forum sketch without looking at the effect on the constraints on the array - DOH!

> Such subtle - repeating - anomalies!
 
KoroMix: does your OP this thread link to the code you want folks to download? I didn't see what version it gave - it loot like 'Qt' sourced?
 
I've published TyQt 0.7.5, so that people stop downloading TyQt 0.7.0, which has a few annoying bugs on Windows and OSX.

@defragster: The qt archives you can find on my BinTray contain a pre-built static version of Qt, it is used by the CI services (Travis and AppVeyor) to build TyQt automatically when I push changes.
 
Arctic_Eddie said:
This is the link I use. Go to the bottom of the page for the latest.
Click to expand...

Indeed - and in fact a NEW TYQT has been posted: " TyQt-0.7.5-win64.zip 3 hours ago "
{ Except I click the Updated column and it brings the latest to the top. }

My point was to make it easy for Folks pointed to or finding the thread to make sure they get the LATEST - without having to get to the point where this link is exposed as it is not in the OP.

This new version 7.5 is a MAJOR release - not an interim 'beta' - perhaps that is why the OP wasn't updated.

Running the new 7.5 and it is running well against my 3 active Teensy's!

Thanks again Koromix! The second best thing about *Teensy* - is TYQT to make it so much more usable!

*Teensy* #1 of course includes everything PJRC puts into it - hardware, software, forum, support
 
No but this is a very small software, there's not much to it beyond what is on the screenshot. It can replace Teensy Loader as the uploader used by Arduino IDE, if you need to program multiple Teensies with different sketches.

There may be more to it when I have enough time to do more than a few quick changes / commits here and there, but it will have to wait for a few months (after June). There are a few "big" ideas I'd like to work on after that. In the mean time, this small software is mostly a way for me to blow off stress.
 
You must log in or register to reply here.
Back
Top