Incrementing int produces bizarre behavior

Status
Not open for further replies.

owhite

Active member
Hello people,

am I taking crazy pills? I have the following code:

Code:
   int val = 0;
    
    void setup() {
      Serial.begin(9600);
    }
    
    void loop() {
      val++;
      Serial.println(val);
    }
Which produces the following (truncated output)

Code:
    1
    2
    3
    4
    5
    .
    .
    .
    .
    147
    148
    149
    150
    381772
    381773
    381774
    381775
    381776
    .
    .
    .

That's right, when val gets to 150, after the next val++; val is then equal to 381772. This is only my 8th year of using teensys in fairly elaborate projects and I have never seen this behavior before. what the hell is happening? I'm thinking there must be something that I corrupted about my programming environment (I used platformio on the command line).
 
Last edited:
If I try running it here, which Teensy should I use? And which operating system? And version of Arduino & Teensyduino?
 
Interestingly, if I put:

Code:
void loop() {
  val++;
  Serial.println(val);
  if (val > 30000) {
    val = 0;
  }
}

will roll over and behave the way I would expect .... with val going from 0 - 30000 with no bizarre behavior - also using platformio. I must have corrupted my programming environment or something - because when I try it on a mac at work it behaves. Hopefully I can just make this go away with a reinstall of platformio. I should mention platformio has been rock solid for quite a while so this i quite strange.
 
Isn't that just the loop going too fast to write to the screen?

Agreed - depending on computer and Serial Monitor processing speed and behavior on getting too much too fast the output will be suspect.

Drop the T_3.2 program speed to 24 MHz - lowest with working USB - and the output rate will be slowed some amount without any functional code changes allowing the computer USB to keep up a bit better.

Try TyCommander or the IDE SerMon or use the Teensy_Ports Serial monitor interface included by PJRC.

Add this code to the sketch. The yield() function is already called outside of loop - this just changes what it does to add a bit of slowdown to allow USB processing:
Code:
void yield() {
  delayMicroseconds( 50 );
}

Before that change with count about 100,000 at 96 MHz the TyCommander SerMon would hiccup the smooth running output on my Win 10 machine.

I bumped to 120 MHz on T_3.1 with the alternate yield() and it adds enough slowdown to keep running smoothly so no output is clipped as I see it.
 
I'm running it here with Arduino 1.8.8 and Teensyduino 1.45 on MacOS 10.14.2 (Mojave).

sc.png

Looks like we may indeed have trouble with maximum sustained data rate on this newer version of MacOS. I'm seeing it appear to stall in the serial monitor, then start again. It's much too fast to easily scroll back up and tell if this is actual data loss, or the Java runtime stalling somehow.

I can't do any more investigation right now, but I am putting this on my list of high priority issues to investigate. For now, just want to confirm I did this quick test and it's looking like we may indeed have trouble on Mojave with maximum speed USB output.

For now, please add a small delay. I did a few quick tests. Both delay(1) and delayMicroseconds(100) seem to allow my Macbook Air to smoothly scroll the data in the Arduino Serial Monitor, but delayMicroseconds(50) does still occasionally hit the stalling problem.
 
Just to realistic, even though this is near the top of my priority list, at this moment I'm working on new hardware (which is already way behind schedule). Might not be able to do much with this for a month or two.

But it is a very serious issue, because soon will have ~45X faster USB bandwidth. If we're not able to keep up with ~1.1 MByte/sec now on Mojave, how are we going to do with the new hardware having (theoretically) ~50 Mbyte/sec bandwidth? Right now, I don't have any answer to this rhetorical question, and until the hardware is well into beta I probably won't have much time to address it, but I can tell you this is definitely a place I'm going to be focusing serious dev time relatively "soon".
 
Works with WIN10, Arduino 1.8.8, TD 1.45, on a I5-3570k 3.4 GHz, Arduino serial monitor, Teensy 3.2 96MHz
 
An thing that I found annoying often, is, that you can't press ctrl-a, ctrl-c if the monitor is disabled. Can you patch this (later this year) , Paul? - an additional button ("copy contents to clipboard") would be even better.
It woulf be helpful (not only) here- one could just copy the output to an editor which shows linenumbers and verify the output
 
T_4's faster USB will be a chore for SerMon display for sure. It took effort for the tools I've found to keep up with 1 MB speed and too fast to read at that - jumping to ~40 MB will challenge hardware (disk/flash) writes without GUI display.

An thing that I found annoying often, is, that you can't press ctrl-a, ctrl-c if the monitor is disabled. Can you patch this (later this year) , Paul? - an additional button ("copy contents to clipboard") would be even better.
It woulf be helpful (not only) here- one could just copy the output to an editor which shows linenumbers and verify the output

Indeed - having IDE's SerMon go 'offline' is something I noted before as far as not being able to select and copy. One of the great koromix TyComm features - AutoScroll takes user context to stop and restart autoscroll to capture output - and it never goes offline when in bootloader or during programming to allow copy. And selectively doesn't reset prior data on next reprogram so output from two run cycles can be seen side by side. It also keeps a running copy in a disk file if lost from display.
 
Maybe, longterm, it would make sense to drop that javacode and write a new monitor in a faster language.. This thing is a constant source of annoyance, and always has been, although Paul has greatly improved it. I bet you a case of beer that you could find almost finished code in c/c++ for it... ok, without HID maybe, but that won't be too hard to add.
 
Last edited:
... drop that javacode and write a new monitor in a faster language..

I've been seriously considering this. The change to native teensy_serialmon with stdin/stdout so Java never talks to the hardware was meant as a first step in that general direction. Well, and of course to solve the problems where Java & JSCC don't handle USB disconnect & reconnect.

I'm still undecided on this and so many other long-term choices.

In the short term, I'm planning to add a layer in the native code to try slightly delaying delivery of data to Java (only milliseconds - less than 1 video refresh on most computer monitors). When it's arriving rapidly in small pieces like only 64 or 128 bytes, we can (hopefully) batch them up into 4096 byte chunks to create fewer events on the slow Java side.
 
By design or system slowed response not sure - but TyComm display goes toward pagination updates with a jumpy screen.

Duff's adding Serial Plotter : Arduino-Serial-Plotter-2-0-(update)

Might be a good direction as a picture 'is worth a thousand words'. It is still Java coded but could quickly replace streams of numbers with graphics, that ideally draw and update usably and faster, though no history.

Though as noted there - it would still need a way to support standard text out display.

Though this test with 240 MHz T_3.6 halted JAVA and I had to KILL it - it seemed to run with single 'val' - though display was too fast and spastic (win 10 i7 CPU + GPU), died when I added val2 to try to keep constant scale:

Code:
int val = 0;
int val2 = 0;
void setup() {
  Serial.begin(9600);
  while (!Serial && millis() < 5000 );
}

void loop() {
  val++;
  Serial.println(val);
  if ( val > 300 ) {
    val = 0;
    val2 ++;
  }
  Serial.println(val2);
}

Re-ran with this and JAVA died again in a short time: void yield() { delayMicroseconds( 5 ); }
 
Thanks for your help everyone. Your guesses were correct, it was some kind of weird serial display problem. I have changed the clock speed to 24Mhz - that did not help.

When I tested if the incremented val was actually changing in value > 1 :

Code:
void loop() {

  val++;
  if (val != old_val + 1) {
    Serial.println("This is odd. What is happening?");
    delay(4000);
  }
  old_val = val;
}

....it was not.

But when I looked into if it was overwelming the serial display:

Code:
void loop() {
  if (count > 30) {
    Serial.println();
    count = 0;
  }
  count++;

  Serial.printf("%0.3d ",val);
  
  val++;
  delay(1);
}

A delay of 1 millisecond produces:
Code:
000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 
031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 
062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 
093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 
155 156 157761 7762 7763 7764 7765 7766 7767 7768 7769 7770 7771 7772 7773 7774 7775 7776 7777 7778 7779 7780 
7781 7782 7783 7784 7785 7786 7787 7788 7789 7790 7791 7792 7793 7794 7795 7796 7797 7798 7799 7800 7801 7802 7803 7804 7805 7806 7807 7808 7809 7810 7811

and when I bump up the delay to 400 millisec I get what you'd expect:

Code:
000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 
031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 
062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 
093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 
155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 
186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 
217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 
248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 
279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309

Looks like a transmission problem.

thanks again for all your help.
 
Status
Not open for further replies.
Back
Top