Digistump Forums

The Digispark => Digispark Pro Support => Topic started by: danowar on December 05, 2014, 04:15:48 pm

Title: DigiCDC
Post by: danowar on December 05, 2014, 04:15:48 pm
I am trying to use the Echo example from the DigiCDC.  After I upload, the Digispark Pro reboots, then comes up an "Unrecognized USB Device" error.  Checking the device managers show it as an "Unknown USB Device (Invalid COnfiguration Descriptor)".

I have reinstalled the drivers from the newest Digistump1.5addons-v092, same results. 

I have 64 bit Windows 8.1.

Any suggestions?
Title: Re: DigiCDC
Post by: defragster on December 25, 2014, 12:36:30 am
I just loaded the example in the 1.5.8B drop and it compiles and runs as provided - what you type is echoed back. 

Exception is the The ‘SerialUSB.println("CDC Test");’ in setup() never prints.

I added a ‘SerialUSB.write("_");’ in the loop and it prints after each char, but it works more often without this.  Putting this outside the loop for incoming characters never works.

Then add in ‘SerialUSB.println("CDC Test");’ in loop() never prints, and then the echo stops feeding back.

Serial Monitor echoes nothing or will hang intermittently
o   Sending longer strings sometime works, sometimes get clipped, sometimes it stops working then
o   When 'hung' Punching ‘reset’ closes the serial monitor and releases the IDE

I think I need to reboot now my USB stopped connecting for CDC usage as the port doesn't show after the device is not recognized, but I can put out new code?

Edit(1/6/15): unplugging Pro's and waiting 5 minutes recently has let it see them connect/upload.  It seems multiple Pro's and or rapid connect disconnect confuses Win 7 driver and USB detection.  You can typically get away with quick compile/upload/repeat - but when I was trying to swap multiple Pro units on my Serial test pair I got it confused, had too much open to reboot - ate dinner with no Pro connected - and then it worked, another time I was busy 5 minutes and it came back to working.
Title: Re: DigiCDC
Post by: defragster on December 26, 2014, 10:46:58 pm
Underlying updates are coming - see this Thread as it has the focus:
http://digistump.com/board/index.php/topic,1519.15.html (http://digistump.com/board/index.php/topic,1519.15.html)
Title: Re: DigiCDC
Post by: defragster on January 05, 2015, 01:07:18 am
I got this larger example to work - with Write and case swap 2nd Write reliably.

This is a simple sample with two variables I count but RAM usage is  "Global variables use 233 bytes of dynamic memory".  USB must be a HOG as the OLED sample is running under 175 bytes with more user variables.

With WHILE rather than IF and short delay [in blink] I can get only about 37 characters to print from a message, then it clips.

Added LED Blink to show loops and activity, brightens during transfer.

Enter a Tilda '~' and the print happens and the light blinks and it prints the '~~' as expected, then the Serial monitor (and Phone) dies after making any other entry and you cannot close it until the Pro is reset. HOWEVER the heartbeat blink continues?


Code: [Select]
  SEE UPDATED CODE BELOW
Title: Re: DigiCDC
Post by: defragster on January 05, 2015, 01:33:28 am
In the loop's while if you zero this blink_swap(0);  wait it HANGS - you need the wait that is in the blink to be non-zero!
But make it blink_swap(1); or (5) and it works the same and you get 37 or 38 characters echoed before it clips
A SerialUSB.refresh(); alone will not keep USB alive - it requires calls to     SerialUSB.delay(>0) as indicated and shown.

With or without the second Write of the incoming character the limit is the same < 38 characters before clipping

Doing second print in setup() hangs the serial Monitor with now output, but the BLINK heartbeat runs.
  // SerialUSB.print("CDC Test"); // Print twice and Serial Mon HANGS until reset, though Blink heartbeat runs

I modified '~' print to print only 3 characters "CDC".  And the first '~' it prints NONE, then adds one each time it sees the '~'.  It works for NONE, 1 and 2 tildas - i.e the first second and third '~' - then it kills USB but the HeartBeat still runs.

*Note USB / Serial Monitor will never get another echo after too much Write, but it only hangs when you try to send another message after that.

I will update my current code in the prior message.
Title: Re: DigiCDC
Post by: defragster on January 05, 2015, 03:20:54 am
I got it to kill USB with a heartbeat alive as noted before when Tildas were entered.  But those prints were with no refresh() or delay() - those are time dependent issues, so I thought to add them to my Looping as shown in the code below.

The following two keys when entered do a print("C~C") or print("C?C") in an incremented loop each time pressed:
'~' (tilda): Shows # of times pressed before as it is echoed with a digit counter as it stops after 3-4, adding a refresh() did not help
'?' (question): Shows # of times pressed before as it is echoed with an 'ALPHA' counter (A is zero) as it stops after 10 to 26 times [or more sometimes] where a delay() has been added between each iteration.

This is only increment of three characters per print() with a break in between.

*NOTE: I had a code error in the Blink wait where the minimum was delay(10) - I have adjusted that and documented in the code, waits "tested" under 5 were actually 10, under 5 is prone to USB hanging even during the while send receive while() - though 8 seems good and in fact allows about 10 more characters per ECHO in the while().
*NOTE: Heartbeat never stops so the code is looping.  When more than 35 now 45 characters are clipped in the output, the next echo works.  When the print() hangs the USB, the next echo freezes the IDE.

Code: [Select]
[/#include <DigiCDC.h>
void setup() {
  // initialize the digital pin as an output.
  SerialUSB.begin();
  SerialUSB.refresh();
  pinMode(1, OUTPUT); //LED on Model A  or Pro
  blink_swap(700);
  blink_swap(700);
  SerialUSB.print("CDC Tst"); // Need long wait to see on PC Serial Monitor
  blink_swap(700);
  SerialUSB.print("CDC TST"); // Need long wait to see on PC Serial Monitor
  // SerialUSB.println("CDC Test 2"); // println hangs serial monitor, though Blink heartbeat runs
  // SerialUSB.print("CDC Test"); // Print twice and Serial Mon HANGS until reset, though Blink heartbeat runs
}

bool blinkState = 0;
void blink_swap( int wait ) {
  if (blinkState && 10 < wait) {
    blinkState = 0;
    digitalWrite(1, LOW);
  }
  else if ( 0 == blinkState) {
    blinkState = 1;
    digitalWrite(1, HIGH);
  }

  while ( 10 <= wait ) {
    SerialUSB.delay(10);               // keep usb alive // can alos use SerialUSB.refresh();
    wait -= 10;
  }
  if ( 0 < wait ) {
    SerialUSB.delay(wait);               // keep usb alive // can alos use SerialUSB.refresh();
  }
}

int CntTildas = 0;
int CntQues = 0;

// the loop routine runs over and over again forever:
void loop() {
  int sr;
  while (SerialUSB.available()) {
    sr = SerialUSB.read();
    SerialUSB.write(sr);
    if (65 <= sr && 90 >= sr) sr = sr + 32;
    else if (97 <= sr && 122 >= sr) sr = sr - 32;
    SerialUSB.refresh();
    if ('~' == sr) SerialUSB.write(48 + CntTildas);
    if ('?' == sr) SerialUSB.write(65 + CntQues);
    SerialUSB.refresh();
    SerialUSB.write(sr);
    blink_swap(5); // This must be larger than 1 or it hangs USB, 5 seems to allow 45 characters without loss/clipping
    // When it clips the string it typoically keeps working on the next echo
    if ( '~' == sr ) {
      for ( int ii = 0; ii < CntTildas; ii++ ) {
        SerialUSB.print("C~C"); // Enter a '~' 3-4 times and the Monitor Freezes, heartbeat Alive
        SerialUSB.refresh(); // even with refresh() here at tilda
      }
      CntTildas++;
      blink_swap(5);
    }
    if ( '?' == sr ) {
      for ( int ii = 0; ii < CntQues; ii++ ) {
        SerialUSB.print("C?C"); // Enter a '?' 10-14-19-26 or more times and the Monitor Freezes, heartbeat Alive
        blink_swap(8); // at wait(5) it hangs USB after about 6 "?" at wait(8) it runs about 6-8 "?" but I did see 24
      }
      CntQues++;
    }
  }
  //  SerialUSB.delay(10);               // keep usb alive // can alos use SerialUSB.refresh();
  blink_swap(10);
}
code]
Title: Re: DigiCDC
Post by: defragster on January 05, 2015, 03:38:58 am
Just realized this note was in another thread.  I found a free ANDROID terminal program that will OTG connect this CDC app - I tried a few and this was the best.

Though after my latest changes it will connect but no longer works to echo anything?  It used to echo the start strings as it connected faster than the IDE serial monitor, now nothing.

what I added: longer setup() delay and setup prints, shorter delay per character in the while loop - not going to debug this now as it repros real PC issues as documented and worked with simple version.

This APP:: https://play.google.com/store/apps/details?id=jp.ksksue.app.terminal (https://play.google.com/store/apps/details?id=jp.ksksue.app.terminal) has a decent UI and No Ads - no weird permissions.  Menu/Setting/Serial::Set to baud=57600, 8data, no=parity, 1=stop.

The App often Faults on reconnect - more than once.  Hit Menu/Open Device.  Sometimes it takes a few tries to reconnect and a menu / Close Device.
Title: Re: DigiCDC
Post by: defragster on January 05, 2015, 03:32:22 pm
If anyone is working on the CDC library - or improvements are pending let me know I can pre-test (even flash bootloader if needed).  I can rewrite my code to incorporate my Serial debug output it there are any values that would help tune this - Since the heartBeatBlink survives I should be able to expose info on serial.  My summary 'feel' for what I've hit follows - as noted this CDC hogs RAM so I can't power an OLED.  I hope the CDC RAM load can be dropped - though the code is only one third as big as current OLED.

I plugged and programmed a 2nd Pro with this CDC app to make sure my results repeated.  It behaved similarly – but hung on lower counts than documented on the other Pro.  And on a second phone the current app also fails to echo after it connects.

> The problem seems timing related if the delay() is not big enough or often enough, and a refresh() does nothing to help.
> The worst part about timing is that printing under 10 characters is too much, and you often cannot print a string in smaller pieces
> Even in groups of three characters – 9 characters is too much with a refresh() each three.
> Delay() helps extend that, but not consistently and not infinitely – sometimes 5 or 10 groups of 3 even with delay() stops USB dead
> I added a heartbeat blink and it never stops even when USB stops dead, so the user sketch is loop()’ing.

PROBLEM: The CDC app is a memory HOG!  I have just a few variables and get this on compile: Global variables use 251 bytes of dynamic memory.
That is way more than my OLED example that might be near 175 with a similar number of variables (now that I have F(strings) ) .
Title: Re: DigiCDC
Post by: defragster on January 06, 2015, 01:25:00 am
The one Android terminal app presented this view of the OTG connected PRO in case it adds anything about how the device is seen I'll post it.

Quote
Device ID: 3003
Device Name: /dev/bus/usb/003/003
Device Class: Communications and CDC Control
Device Sub Class: Unspecified
Device Protocol: 0
Vendor ID: 5840
Product ID: 2174
USB Version: 16.1
Product Version in BCD: 0.1
Serial: null
Interface Count: 2

-----------------------------------------------
Interface ID: 0
Interface Class: Communications and CDC Control
Interface Sub Class: Communications and CDC Control
Interface Protocol: 1
Interface Endpoint Count: 1

======================================
Endpoint Number: 3
Endpoint Address: 131
Endpoint Direction: IN
Endpoint Interval: 255
Endpoint Max Packet Size: 8
Endpoint Type: Interrupt endpoint type
-----------------------------------------------
Interface ID: 1
Interface Class: CDC-Data
Interface Sub Class: Unspecified
Interface Protocol: 0
Interface Endpoint Count: 2
======================================
Endpoint Number: 1
Endpoint Address: 1
Endpoint Direction: OUT
Endpoint Interval: 0
Endpoint Max Packet Size: 8
Endpoint Type: Bulk endpoint type
======================================
Endpoint Number: 1
Endpoint Address: 129
Endpoint Direction: IN
Endpoint Interval: 0
Endpoint Max Packet Size: 8
Endpoint Type: Bulk endpoint type
Title: Re: DigiCDC
Post by: defragster on January 08, 2015, 01:17:03 am
There is a CDC update on github.  It is more robust and in general passes the chokepoints noted before as far as I checked, but seems glacially paced now – 9.3 times slower.

It does fail the simple echo test after fewer characters echoed, and it does it 9.3 times more slowly.  To quantify I have serial output from two runs on the same Pro.  I renamed and setup the 'updated' cdc library as DigiCDCC so I could alternate compiles.  The new library is generally more robust – to get this output I had to tweek the desired changes to print to work around where the 1.5.8B library would HANG trying to print debug to the CDC terminal.
> neither library HANGS on this test – they just abort/clip at different spots
> I removed unused code from prior example
> this demonstrates the ‘perceived’ performance slow down on the sample ECHO sample

I manipulated my prior code to time the while (SerialUSB.available()) loop and print out the millis() used in the loop.  Only the library is different for the same sketch (see commented #include).  What the following shows is that for the user input of 'ABCDEFGHIJKLMNOPQRSTUVWXYZ.ABCDEFGHIJKLMNOPQRSTUVWXYZ':

> pending library clips the write after 34 characters printed double  (missed the "Hh" )
> pending library consumes 3.752 seconds in the loop to generate this output
> pending library blank ‘enter’ takes 215 millis

> 1.5.8B library clips the write after 37 characters printed double (missed the "Kk" )
> 1.5.8B library consumes 0.402 seconds in the loop to generate this output
> 1.5.8B library blank ‘enter’ takes 20 millis


----CDCC (pending github) –blank enter is 215milis --- 3,752millis to ABORT [clips after 2nd G ]  a-z.a-z::--------------------------
215AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz..AaBbCcDdEeFfGgNn3752
----CDC (1.5.8B) –blank enter is 20milis ---- 402millis to ABORT [clips after 2nd J ]  a-z.a-z::--------------------------
 20AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz..AaBbCcDdEeFfGgHhIiJjNnOoVv402 

Code: [Select]
#include <DigiCDC.h>    // 1.5.8B release CDC library
// #include <DigiCDCC.h>  // github pending CDC library 1/8/2015

void setup() {
  // initialize the digital pin as an output.
  SerialUSB.begin();
  SerialUSB.refresh();
  pinMode(1, OUTPUT); //LED on Model A  or Pro
  blink_swap(1500);
  SerialUSB.print("CDC TST"); // Need long wait to see on PC Serial Monitor
}

bool blinkState = 0;
void blink_swap( int wait ) {
// blinks under 8 don't change the LED state so it will stay bright/off during USB I/O loop, otherwise it pulses
  if (blinkState && 7 < wait) {
    blinkState = 0;
    digitalWrite(1, LOW);
  }
  else if ( 0 == blinkState && 7 < wait) {
    blinkState = 1;
    digitalWrite(1, HIGH);
  }

  while ( 10 <= wait ) {
    SerialUSB.delay(10);               // keep usb alive // can alos use SerialUSB.refresh();
    wait -= 10;
  }
  if ( 0 < wait ) SerialUSB.delay(wait);               // keep usb alive // can alos use SerialUSB.refresh();
}

// the loop routine runs over and over again forever:
void loop() {
  int sr;
  unsigned long time;
  time = 0;
  while (SerialUSB.available()) {
    if ( 0 == time )   time = millis();
    sr = SerialUSB.read();
    SerialUSB.write(sr);
    if (65 <= sr && 90 >= sr) sr = sr + 32;
    else if (97 <= sr && 122 >= sr) sr = sr - 32;
    SerialUSB.refresh();
    SerialUSB.write(sr);
    blink_swap(5); 
    // When it clips the string it typically keeps working on the next echo
    blink_swap(5);
  }
  if ( time ) time = millis() - time;
  blink_swap(10);
  if ( 5 < time ) SerialUSB.print( time );
}
Title: Re: DigiCDC
Post by: digistump on January 08, 2015, 01:50:58 pm
You're just running into the computer filling the buffer faster than the Pro can empty it and running out of buffer - this is exacerbated by the fact that the new library is slower to write (not to read) and you are doing double the writes as reads.

These limitations apply to all serial but are way more apparent here because of the speed. I'm sure it can be sped up from where it is now with more clever knowledge of v-usb, but I'm going with what is most stable since this is designed mostly for short infrequent messages or control signals.

That said it will never be able to print an endless string of all-at-once input - but even in its current very slow speed state you can send 10 chars to it every say 250ms and have it echo back without issue (I'm sure you can do more/less delay - that's just an example) - so in short your test shows the buffer to timing limitation correctly, but it is not a bug, just a limitation of this type of software implementation.

If you want to mess with the speed for fun - look in DigiCDC.cpp and change the delay in the write - but we'll be sticking with this slow version (unless someone dives in and comes up with a better method than delay) because it works across all of our test devices even when print and println are used.

Thanks for your testing!
Title: Re: DigiCDC
Post by: defragster on January 09, 2015, 03:30:09 am
In steps I set the delay down to '3' from '45' and it was robust - didn't hang.  One ( '1' ) seemed to be the breaking point.

I think the other changes you made were more responsible for the robustness than you saw!  Good Work!

I saw nothing but reliable transmission taking the delay down to that point and if you could show me an example that breaks at 9 or half of that I'd like to understand it.  If you wanted to stick with a higher number - I'd offer you add a version of USB.begin that takes an optional  parameter [Unsafe(4), Fast (9), Quick (15), Slow (25), Glacial (45 )].

The edge cases I found are no longer a problem.  And I even got to add generous debug newlines and verbiage to explain what was spewing forth, and with just a few 'in case' refreshes nothing I did broke the code, except for taking the Delay to '1'.

I took my code, hooked into the delay in the library.  Added a watch for '_' to programmatically drop the delay from 45 in steps to minimize boredom.  And I altered the code to do EACH one of the abusive tests I found to fail in turn on the '_' and an added '*' key test and could repeat the test at will.  Other test keys still active, but I preset their values above where they used to fail {~.?.>}.  Enter the dual alphabet and results are consistent down to under delay of 4 you see an extra clipped character.

Put this on a Pro (make indicated DIGICDC changes in top comments)- start the monitor - push the following characters between the commas in turn and then repeat - no spaces: ENTER, *ENTER, ENTER, _ENTER
You see increasing speed and consistent output.  Push * again to make no changes but watch it cycle to look for loss or hang.

Quote
Results Summary:
[[time>38433 <time::delay>45<delay]]]
[[time>5930  <time::delay>5 <delay]]]


This is the same testbed code from before tweaked for presets and automation aid - generous use of delay and refresh - at least enough so it never dies.  ANd I safely added more Print and PrintLn calls.

Code: [Select]
#include <DigiCDC.h> // #include <DigiCDCC.h>

// ADD TO DIGICDC.cpp :: int         CDCvDelay = 45;   /* used to expose the OuchWait */
// Change this line that held 45::      DigiCDCDevice::delay(CDCvDelay); //ouch its slow but it ensures it will work no matter how long of a string is thrown at it

extern  int CDCvDelay;

void setup() {
  // initialize the digital pin as an output.
  SerialUSB.begin();
  SerialUSB.refresh();
  pinMode(1, OUTPUT); //LED on Model A  or Pro
  blink_swap(700);
  blink_swap(700);
  SerialUSB.print("CDC Tst"); // Need long wait to see on PC Serial Monitor
  blink_swap(700);
  CDCvDelay = 45;
  SerialUSB.print("CDC TST"); // Need long wait to see on PC Serial Monitor
}

char astring[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

bool blinkState = 0;
void blink_swap( int wait ) {
  if (blinkState && 7 < wait) {
    blinkState = 0;
    digitalWrite(1, LOW);
  }
  else if ( 0 == blinkState && 7 < wait) {
    blinkState = 1;
    digitalWrite(1, HIGH);
  }

  while ( 10 <= wait ) {
    SerialUSB.delay(10);               // keep usb alive // can alos use SerialUSB.refresh();
    wait -= 10;
  }
  if ( 0 < wait ) {
    SerialUSB.delay(wait);               // keep usb alive // can alos use SerialUSB.refresh();
  }
}

int CntTildas = 20; // ~
int CntQues = 20;  // ?
int CntAlpha = 30;  // >

// the loop routine runs over and over again forever:
void loop() {
  int sr;
  unsigned long SeeStar = 0;
  unsigned long time;
  time = 0;
  while (SerialUSB.available()) {
    if ( 0 == time )   time = millis();
    sr = SerialUSB.read();
    SerialUSB.write(sr);
    if (65 <= sr && 90 >= sr) sr = sr + 32;
    else if (97 <= sr && 122 >= sr) sr = sr - 32;
    SerialUSB.refresh();
    if ('~' == sr) SerialUSB.write(48 + CntTildas);
    if ('?' == sr) SerialUSB.print( CntQues );
    if ('>' == sr) SerialUSB.print( CntAlpha );
    if ('*' == sr) {
      SeeStar = millis();
      blink_swap(5);
      SerialUSB.print(&astring[0]);
      blink_swap(5);
    }
    SerialUSB.refresh();
    SerialUSB.write(sr);
    blink_swap(5);
    // When it clips the string it typically keeps working on the next echo
    if ('_' == sr   || SeeStar) {
      blink_swap(8);
      if ( 0 == SeeStar ) {
        if ( 40 < CDCvDelay ) CDCvDelay = 25;
        else if ( 18 > CDCvDelay ) CDCvDelay -= 2;
        else CDCvDelay -= 10;
        SeeStar = millis();
      }
      SerialUSB.print( CDCvDelay );
      SerialUSB.print("<del");
      blink_swap(8);
      SerialUSB.print(&astring[0]); // Need long wait to see on PC Serial Monitor
    }
    if ( '~' == sr  || SeeStar ) {
      for ( int ii = 0; ii < CntTildas; ii++ ) {
        SerialUSB.print("C~C");
        SerialUSB.refresh();
        SerialUSB.print( ii );
        SerialUSB.refresh();
      }
      if ( 0 ==  SeeStar ) CntTildas++;
      blink_swap(5);
    }
    if ( '?' == sr || SeeStar ) {
      for ( int ii = 0; ii < CntQues; ii++ ) {
        SerialUSB.print("C?C");
        blink_swap(8);
        SerialUSB.print( ii );
        SerialUSB.refresh(); // even with refresh() here at tilda
      }
      if ( 0 ==  SeeStar ) CntQues++;
    }
    if ( '>' == sr || SeeStar ) {
      blink_swap(5);
      for ( int ii = 0; ii < CntAlpha; ii++ ) {
        if ( 27 > ii ) SerialUSB.write(ii + 65);
        else SerialUSB.write(ii + 97);
        if ( CntTildas ) SerialUSB.refresh(); // even with refresh() here at tilda
      }
      blink_swap(5);
      SerialUSB.print("CDC > TST"); // Need long wait to see on PC Serial Monitor
      blink_swap(10);
      if ( 0 ==  SeeStar ) CntAlpha++;
    }
  }
  //  SerialUSB.delay(10);               // keep usb alive // can alos use SerialUSB.refresh();
  blink_swap(10);
  if ( time ) time = millis() - time;
  if ( 5 < time ) {
    SerialUSB.println("]END[");
    SerialUSB.refresh(); // even with refresh() here at tilda
    SerialUSB.print("[[time>");
    SerialUSB.refresh(); // even with refresh() here at tilda
    SerialUSB.println( time );
    SerialUSB.refresh(); // even with refresh() here at tilda
    SerialUSB.print("<time::del>");
    SerialUSB.refresh(); // even with refresh() here at tilda
    SerialUSB.print( CDCvDelay );
    SerialUSB.refresh(); // even with refresh() here at tilda
    SerialUSB.println("<del]]]");
    SerialUSB.refresh(); // even with refresh() here at tilda
  }
}

Title: Re: DigiCDC
Post by: JeffRand on January 09, 2015, 01:39:06 pm
Like the original poster indicated, I also have Windows 8.1 64 bit, and I'm having the same issue with Invalid Configuration Descriptor. Looks like a problem related to the drivers, but I have no idea how to fix.
Title: Re: DigiCDC
Post by: defragster on January 10, 2015, 02:02:55 am
I've put some time into the CDC sketch and the pending release is VERY ROBUST and good.  Though it gets touchy when using F("txt")!  My prior test sample code runs great without F() and I forked the library to run fast with 'native' text.  But I have to cut the sample way back to see F() work at all - and then it needs to slow down the USB output on those transfers.  Posted my findings to Digistump for review.

F() usage adds a good deal 1.6K of code to the Sketch, and all that code is busily working to get you that text separate from the code, and into ram to use.

Title: Re: DigiCDC
Post by: defragster on January 10, 2015, 11:12:42 am
Looking into PROGMEM - pulling user strings from FLASH I found an example that works full speed like RAM text, on longer strings.  Drops RAM usage, does not use F(), is just a bit less handy that direct strings or F() - but seems way more reliable.  See example below - I did not try this on the 1.5.8B code but on the 1/7/15 Github. [ @EK: using DigiCDCDevice::delay(9); in DigiCDC.cpp ]

based on http://forum.arduino.cc/index.php?topic=110307.0 (http://forum.arduino.cc/index.php?topic=110307.0)

Code: [Select]
#include <DigiCDC.h>

const char HEADER[]  PROGMEM  = { "-A--B---C----D-----E=A==B===C====D=====E"};
const char HEADER2[]  PROGMEM  = { "C*C_0123456789_0123456789_"};
const char HEADER3[]  PROGMEM  = { "CDC TST begin()"};
const char HEADER4[]  PROGMEM  = { "CDC > TST loop."};
__FlashStringHelper* HP_columns = (__FlashStringHelper*)HEADER;
__FlashStringHelper* HP_digits = (__FlashStringHelper*)HEADER2;
__FlashStringHelper* HP_begin = (__FlashStringHelper*)HEADER3;
__FlashStringHelper* HP_loop = (__FlashStringHelper*)HEADER4;

void setup() {
  SerialUSB.begin();
  SerialUSB.refresh();
  pinMode(1, OUTPUT); //LED on Model A  or Pro
  blink_swap(2000);
  SerialUSB.println(HP_begin); // Need long wait to see on PC Serial Monitor
  blink_swap(10);
}

bool blinkState = 0;
void blink_swap( int wait ) {
  if (blinkState && 7 < wait) {
    blinkState = 0;
    digitalWrite(1, LOW);
  }
  else if ( 0 == blinkState ) {
    blinkState = 1;
    digitalWrite(1, HIGH);
  }

  while ( 10 <= wait ) {
    SerialUSB.delay(10);               // keep usb alive
    wait -= 10;
  }
  if ( 0 < wait ) {
    SerialUSB.delay(wait);               // keep usb alive
  }
}

int AUTORUN = 1;
// the loop routine runs over and over again forever:
void loop() {
  int sr;
  bool SeeStar = 0;
  if ( AUTORUN ) sr = '*';
  if ( AUTORUN || SerialUSB.available() ) {
    if ( SerialUSB.available() ) {
      sr = SerialUSB.read();
      if ( '*' == sr ) {
        if ( AUTORUN ) AUTORUN = 0; else AUTORUN = 1;
      }
    }
    SerialUSB.write(sr);
    SerialUSB.refresh();
    if ('*' == sr) SeeStar = 1;;
    SerialUSB.refresh();
    if ( SeeStar ) {
      blink_swap(5);
      for ( int ii = 0; ii < 12; ii++ ) {
        if ( 10 > ii ) SerialUSB.print("C?C"); else SerialUSB.print(HP_digits);
        blink_swap(5);
        SerialUSB.print( ii );
        SerialUSB.refresh(); // even with refresh() here at tilda
      }
      blink_swap(5);
      SerialUSB.print(HP_loop);
      blink_swap(10);
    }
  }
  if ( 0 == SerialUSB.available() ) {
    SerialUSB.println (HP_columns);
    blink_swap(10);
  }
}


Quote
RUNNING SKETCH: looks for and echos input strings in an IF() not WHILE() pass through loop()
   It starts in ‘*’ auto run mode – just does a group of USB.print
   ‘ENTER’ any text and it is echoed and then the testing resumes
   Enter ‘*’ and it toggles AUTORUN, when off only does SerialUSB.println (HP_columns);
Title: Re: DigiCDC
Post by: defragster on January 10, 2015, 12:05:07 pm
It felt odd having a running example so I tried to break it adding this to the end and it worked with plain text - so I decided to put in F() to see it break - and it did not.  The RAM must be the critical factor [269 okay , over 300 and pulling any flash strings breaks] - NOTE: these LONG strings are printing full speed (9).  Except for defining 'unsigned long time = 0;' the above example was unchanged - with this segment replacing the last if(Serial ...).  This sample at delay speed (9) in the DigiCDC is 1.67 secs and with a delay of (45) it is 7.5 secs.

Code: [Select]
  if ( 0 == SerialUSB.available() ) {
    SerialUSB.println (HP_columns);
    blink_swap(10);
    if ( time ) time = millis() - time;
    blink_swap(10);
    if ( 14 < time ) {
      SerialUSB.print(F("]END["));
      SerialUSB.refresh();
      SerialUSB.print("[[time>");
      SerialUSB.refresh();
      SerialUSB.println( time );
      SerialUSB.refresh();
      SerialUSB.print(F("Too1MuchRamDontBreak"));
      SerialUSB.refresh();
      SerialUSB.print(F("Too2MuchRamDontBreak"));
      SerialUSB.refresh();
      SerialUSB.print("TooMuchRamDontBreak");
      SerialUSB.refresh();
    }
  }
Title: Re: DigiCDC
Post by: JeffRand on January 10, 2015, 02:23:16 pm
I'll have to try your sketch after I figure out a way for my PC's to recognize the devices. I've tried both my Digispark originals and my Digispark Pros. Both give the "Invalid Configuration Descriptor" error messages. What OS are you using?
Title: Re: DigiCDC
Post by: defragster on January 10, 2015, 02:34:54 pm
Running Win7 x64 primarily. Some Win8.1 that work when I last used those machines.

This is a decent sketch as it runs on a RAW board with just a USB cable.  Though I'm not sure it will work well until the pending release after 1.5.8B

This is an oddity 'assertion' error - I just figured I should write it down in case anything ever comes of it as it is the only error I see that is out of the blue and it comes from the IDE during upload - possibly from hitting reset at the wrong time if the upload started.

I don't recognize your 'descriptor' error.  My Pro's typically connect and work as expected.  They are only a USB device for 5 seconds - unless your sketch is running USB support.  Other than that they are just there for the power, until a reset or re-plug to upload.  I've done OLED and Serial sketches, and recently the CDC that is a USB device and they work reasonably.  I did the driver install as in the Wiki (either from the download .exe or the zip and run the driver install).  Once that was done the system complains or works but no drastic errors other than 'device not recognized' as expected.  If the error persists try the usual random shuffle changing: Cable / Port / Hub.  I've seen too many changes too fast can get the USB lost and then seems to stabilize after 5 minutes.
Title: Re: DigiCDC
Post by: JeffRand on January 10, 2015, 02:53:38 pm
I've had no trouble with any of my Digisparks at all and use them for all sorts of things. I'm only having trouble with CDC giving the descriptor error. I've tried cold booting everything and various hubs, cables and PC's and all give the descriptor error that the original poster was also seeing. I'll have to try one of my XP or Windows 7 machines when I get a chance. I would just like to get it working on my 8.1 machines, as I use them for all of my dev work now.
Title: Re: DigiCDC
Post by: defragster on January 11, 2015, 09:40:01 pm
On my Win8.1 machine - works with OLED (old and new) code - can download the CDC too - but gives 'device not recognized' error [same as win7], so it isn't seeing valid USB.

I recreated my User Account - so this is a fresh install.

Had a bad cable that failed any uploads - never saw device, other cable here uploads anything fine.

Yet to see any error like: "Invalid Configuration Descriptor
Title: Re: DigiCDC
Post by: JeffRand on January 12, 2015, 08:00:43 am
Yes, that is the message you see from the taskbar. But, if you look at the device manager, you will see the "Invalid Configuration Descriptor" error message.

Title: Re: DigiCDC
Post by: defragster on January 12, 2015, 01:31:57 pm
In going to my NEW Win 8 box for the 3rd time in a year (wow faster!) I realize it was using the OLD 1.5.8B CDC - I'll have to run the GitHub stuff there.

Never bothered looking deeper as the message only came up when expected.

Would be interesting to know if that same problem description info presents running BLINK and CDC sketches.  If the CDC code description is unique from the BLINK error detail might be interesting - if the same it just says 'device not acting like a known usb device'

http://blogs.msdn.com/b/usbcoreblog/archive/2012/06/08/new-for-windows-8-problem-descriptions-for-usb-devices-and-hubs-in-device-manager.aspx (http://blogs.msdn.com/b/usbcoreblog/archive/2012/06/08/new-for-windows-8-problem-descriptions-for-usb-devices-and-hubs-in-device-manager.aspx)
Title: Re: DigiCDC
Post by: defragster on January 12, 2015, 02:44:03 pm
Non USB sketch for OLED not showing 'unknown device' error message in Win8.

USB CDC sketch for 'unknown device' DevMan indeed shows the extended:
Quote
Windows has stopped this device because it has reported problems. (Code 43)

The USB device returned an invalid USB configuration descriptor

Then the IDE spews this NEW message on connecting to the COM1 it shows (usually no COM# seen when in error):
Quote
>> Micronucleus done. Thank you!
processing.app.SerialException: Error opening serial port 'COM1'.
   at processing.app.Serial.<init>(Serial.java:145)
   at processing.app.Serial.<init>(Serial.java:90)
   at processing.app.SerialMonitor.open(SerialMonitor.java:93)
   at processing.app.Editor.handleSerial(Editor.java:2537)
   at processing.app.EditorToolbar.mousePressed(EditorToolbar.java:357)
   at java.awt.Component.processMouseEvent(Unknown Source)
   at javax.swing.JComponent.processMouseEvent(Unknown Source)
   at java.awt.Component.processEvent(Unknown Source)
   at java.awt.Container.processEvent(Unknown Source)
   at java.awt.Component.dispatchEventImpl(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Window.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$200(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue$4.run(Unknown Source)
   at java.awt.EventQueue$4.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: jssc.SerialPortException: Port name - COM1; Method name - openPort(); Exception type - Port busy.
   at jssc.SerialPort.openPort(SerialPort.java:164)
   at processing.app.Serial.<init>(Serial.java:141)
   ... 35 more
Error opening serial port 'COM1'.
Title: Re: DigiCDC
Post by: defragster on January 12, 2015, 03:14:50 pm
Tried again compiling on Win8 with a different sketch that worked on Win7 and the heartbeat blink is running the TEST ECHO output, the device is in the error code 43 state , but the IDE sees COM1 and opens the SMonitor and thinks it is sending - but the heartbeat doesn't change so (with the device in error) it is not receiving/sending.

INDEED: Taking that same device immediately to my Win7 box the IDE sees COM21 and connects and the sketch is running as expected, including the SLOW LONG OUCH delay(45) on serial writes.

So I see a Win 8 problem it seems connecting to the GitHub Pending 1.5.8C release CDC library code.

And further: I modified the CDC code delay(45) to a delay(9) and reprogrammed on Win8 to the same failed end, walk to Win7 and it is powered up and running and responding FAST as expected.

Quote
NOTE: I have a MOUSE sketch that I uploaded and it is working on Win8:
> First with the library from 1.5.8B
> AGAIN using the GitHub pending 1.5.8C
Title: Re: DigiCDC
Post by: digistump on January 12, 2015, 04:16:06 pm
@JeffRand, defragster, and all - it looks like I need to do something special with the inf file for this to work on certain versions of Win8 - it works fine on my win8 but I'll test some more this week and see if I can duplicate the issue - thanks for all the details!
Title: Re: DigiCDC
Post by: defragster on January 15, 2015, 03:01:10 pm
I don't know if this relates to Win 8 - I will try ASAP, I'll bet double or nothing it does:

@EK: I refined my idea on the delay in DigiCDC:
void DigiCDCDevice::begin(){
    usbBegin();
   if (millis() <1000)
      DigiCDCDevice::delay(1000 - millis() );
}

My OLED can print millis() as fast as 375.
I then immediately:
  SerialUSB.begin();
  oled.println(millis());
And the next number I see is 1001 for Millis.  And all is well on USB CDC.



CURIOSITY: Infinite REBOOT LOOP with this code and a dozen variations if you do too much too fast with oled - but print millis() ok.
Code: [Select]
void setup() {
  // initialize the digital pin as an output.
  oled.begin();
  oled.clear(); //all black
  oled.setCursor(0, 0); //top left
  oled.setFont(FONT6X8);
  oled.println(millis());
  SerialUSB.begin();
  oled.println(millis());
  SerialUSB.setDelay(6);
  SerialUSB.print(F("Too1MuchRamDontBreak1_"));
  oled.println(millis());
}
Title: Re: DigiCDC
Post by: defragster on January 15, 2015, 10:32:12 pm
1.5.8C release:
Timing adjustment ( various attempts ) didn't keep Win8 from failing to recognize the device - and from with the OLED I saw that the PRO reboots when the first serialUSB.print is done.  With the ~6 second in delays the USB came online so the IDE could see it - then poof - gone.

OTG on my Phone with "Android USB Serial Monitor Lite" and it failed too - PRO does the same and reboots.

Wondering if the 'computer' asks device to reset when the recognition fails?

MSFT on code 43: http://technet.microsoft.com/en-us/library/cc725873(v=WS.10).aspx (http://technet.microsoft.com/en-us/library/cc725873(v=WS.10).aspx)

and "When you get this error with USB devices it’s because one of the drivers controlling the device notified the operating system that the device failed in some manner"
http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/error-code-43-when-usb-not-recognised/6a2a5531-8b80-4798-9aa6-ee2dcb705c7f (http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/error-code-43-when-usb-not-recognised/6a2a5531-8b80-4798-9aa6-ee2dcb705c7f)

Since my 'fall 2014' phone and Win8 act the same it seems there is a failure to 'comply with expectations', the second link (from 2010) above has directions to trace and log the event, will post results if it runs.
Title: Re: DigiCDC
Post by: defragster on January 15, 2015, 10:48:30 pm
Found ref that gave a trace file - huge and not human readable - opens in Event Viewer.

Reference was here: http://msdn.microsoft.com/en-us/library/windows/hardware/jj151573(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/jj151573(v=vs.85).aspx)

It was on USB 3 port - same net effect on USB 2.  In this log for time sync on the code 43 see this time frame:

Source:        Microsoft-Windows-USB-USBHUB3
Date:          1/15/2015 10:42:40 PM
Event ID:      43
Task Category: Prepare Hardware
<Data Name="fid_DeviceDescription">Digispark Bootloader</Data>

Source:        Microsoft-Windows-USB-USBHUB3
Date:          1/15/2015 10:42:48 PM
Event ID:      43
Task Category: Prepare Hardware

Source:        Microsoft-Windows-USB-USBHUB3
Date:          1/15/2015 10:42:53 PM
Event ID:      43

** Tried repeat on USB 2 port to log and there was no Device recognized to fail, but it did power - cycle - and restart
Title: DigiSpark Virtual Com Port INF is invalid
Post by: metatron99 on April 10, 2015, 08:24:53 pm
I am also having the same problem. The Device manager shows that the DigiSpark com port is recognized. But has a failure which is this...

A Service installation section in this INF is invalid

which usually means it is looking for a particular setup that's it deems is incorrect.

I am on window 8 pro. And everything works just fine except trying to get the virtual com port working.
Title: Re: DigiCDC
Post by: cromagn on August 15, 2015, 04:17:54 pm
I solved  this issue for windows 7 changing the DigiSerial.inf file in this way

[DriverInstall.NTamd64.CopyFiles]
usbser.sys
lowcdc.sys


More detailed info on my blog http://cromagn.blogspot.it/2015/08/usb-cdc-for-digispark-serial-on-windows.html (http://cromagn.blogspot.it/2015/08/usb-cdc-for-digispark-serial-on-windows.html)
Title: Re: DigiCDC
Post by: cooljam7 on October 15, 2015, 03:27:50 am
So I am having the same problem as the OP and I found it is directly due to an invalid or incompatible coded configuration descriptor 'configDescrCDC' in DigiCDC.cpp.

Although I am close, I unfortunately dont have intimate knowledge of what interrupts or pipes the developer is trying to use in the lowcdc.sys driver. I can see and work with the existing configuration descriptor but for the life of me, I cant figure out what is wrong with the descriptor except that it looks like it might be mistructured.

Duplicated with Windows 8.1 64 bit, Arduino IDE 1.6.5, Digistump AVR 1.6.5, on a brand new digistump pro board.

I am able to coerce the digistump virtual serial port driver to install by changing the size of the returned configuration descriptor, but then the device cannot start. This is line 392 - return sizeof(configDescrCDC); - changed to - return configDescrCDC[0] > of digiCDC.cpp. This change is wrong since windows will now think the descriptor size is only 9 bytes, but this lets windows read the first part and install the corresponding digistumpCDC driver.

If I leave the correct size on the configuration descriptor, and remove the class descriptor and data interface descriptor within it, then the device does start but windows immediately crashes out and gives a 'stack unhandled exception' in lowcdc.sys. I assume this is the case because since I have removed the pipes and it does start/connect, the lowcdc driver crashes because it cannot find an expected resource.

I am using Theyscon's descriptor dump utility to analyze my changes/findings - tool can be found here: http://www.thesycon.de/eng/usb_descriptordumper.shtml

If the developer of digistumpCDC would care to chime in, or any other working user of the latest digistumpCDC library, it would be very helpful.

If I could just get a dump of a working install, I may be able to figure out the problem for installations like mine. Any working setup could help by running the above tool, selecting the digistump pro device in the tool vendor 16D0/product 087E (if your vendor/product id differ you can find it by going to properties for the digistump virtual com port in device manager), select show hex dump under options, and then file - save to file.

Since the descriptor is seen as malformed by windows and the above tool in an installation like mine, I cant see what a good descriptor should look like. If someone can post theirs, I might have a chance at finding a solution. I have two machines with a similar setup, and I have the same problem on both.

My suspicion is that the endpoints are of the wrong count, or in the wrong order, as the class descriptor looks correct, and the interface descriptors look correct, and the total length and size of each descriptor seem fine. Its possible that different versions of windows or different architectures may be more tolerant or less picky, but not in all cases.
Title: Re: DigiCDC
Post by: Peping on October 20, 2015, 04:37:42 am
I just got a digispark as my first ever arduino. I wanted to make it into a computer-controllable LED and I thought using CDC would be really the simplest way to do it, but I'm running into the same problems.

Is this being investigated? Will it be fixed any time soon? I'd do the fix (http://cromagn.blogspot.it/2015/08/usb-cdc-for-digispark-serial-on-windows.html) suggested by cromagn, but only as a last resort as I'd have to download the tools necessary to self-sign the driver again.
Title: Re: DigiCDC
Post by: torchris on October 25, 2015, 06:48:11 pm
Would it be possible to update the Wiki page so that it is clearer on how this is to be used? I am getting the "USB device not recognized" in Windows 10 whenever I try this. How is it supposed to work? Is a port supposed to come up in the Tools -> Port menu in the IDE? Having some screen shots in the Wiki would be helpful for us new users.

Is it possible to use a serial adapter off of the DigiSpark Pro UART to do serial debugging.

Really, without being able to use the serial monitor in the Arduino IDE I can't see the point to using the DigiSpark Pro in my project and I may as well go over to the Arduino Pro Mini.
Title: Re: DigiCDC
Post by: jaromaz on January 27, 2019, 08:07:25 am
Try this:
https://digistump.com/board/index.php/topic,2321.msg13831.html#msg13831
Title: Re: DigiCDC
Post by: pitchakorn on May 20, 2019, 09:53:33 pm
try more
สมัครufabet (http://www.ufabet99.vip)