Author Topic: Theory and practical on Serial Comms with a Digispark Pro  (Read 5785 times)

Socco

  • Newbie
  • *
  • Posts: 2
Theory and practical on Serial Comms with a Digispark Pro
« on: January 06, 2015, 08:45:45 pm »
Hi there

1) General suggestion
There needs to be a simple page to explain how to get the Digispark Pro to communicate with the IDE's serial monitor, given that it is different to standard Arduino.


2) Specific plea for help

Q1. Will the following code work (send to serial monitor) if any needed pre-reqs have been achieved?

   #include <DigiCDC.h>

   void setup()
   {               
     SerialUSB.begin();
     pinMode(1, OUTPUT);}

   void loop() {
     SerialUSB.print("Hello");
     digitalWrite(1,HIGH);
     delay(1000);

     SerialUSB.println(" there!");
     digitalWrite(1,LOW);
     delay(1000);
   }


Code compliles and downloads. LED blinks but serial monitor doesn't work. 
I am using IDE 1.5.8B downloaded yesterday.

Separate to whether the code should work in theory is the practical showstopper that DigisparkPro becomes an unknown device in device manager after each bootup with the following reported properties:
   Device type: Universal Serial Bus controllers
   Manufacturer:   (Standard USB Host Controller)
   Device Status:   Windows has stopped this device because it has reported problems. (Code 43)

Q2. Do I need to install any Windows7 driver which DigistumpArduinoInstall1.5.8B did not? (I would presume not for this most basic of functions)
note that if the code's serial comms lines are removed, all is happy.

Any help much appreciated

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #1 on: January 06, 2015, 09:03:09 pm »
Please read this thread for a good working example.  I got a more complex example working with CDC. And I found some limitations and posted them.  Ideally there is work pending that will remove them.

http://digistump.com/board/index.php/topic,1597.0.html

defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #2 on: January 06, 2015, 09:13:32 pm »
Other posts/wiki note that unless a sketch is running a working USB sketch, after 5 seconds the device goes unknown.  With a driver install as provided in the download the machine should have what it needs. And, no, based on my example and findings you won't get those prints working.

Good luck and see what you can make of my posted example.
« Last Edit: January 07, 2015, 12:38:34 am by defragster »

digistump

  • Administrator
  • Hero Member
  • *****
  • Posts: 1465
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #3 on: January 07, 2015, 10:36:37 am »
Using the latest updates to the library here: https://github.com/digistump/DigistumpArduino/tree/master/hardware/digistump/avr/libraries/DigisparkCDC

code very similar to yours would work - you just need to use the special SerialUSB.delay():

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

   void setup()
   {               
     SerialUSB.begin();
     pinMode(1, OUTPUT);}

   void loop() {
     SerialUSB.print("Hello");
     digitalWrite(1,HIGH);
     SerialUSB.delay(1000);

     SerialUSB.println(" there!");
     digitalWrite(1,LOW);
     SerialUSB.delay(1000);
   }

A simple tutorial page will be up as soon as we build version 1.5.8C which will include the fixes liked above - we didn't want to make a tutorial on it before we had the bugs worked out.

The drivers provided in the install are all you need.

Socco

  • Newbie
  • *
  • Posts: 2
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #4 on: January 07, 2015, 06:28:11 pm »
Thank you digistump for the info and the link to updated library files. 

Following the page instructions (and a bit of guessing) I copied the files to
C:\Program Files (x86)\Digistump_Arduino\hardware\digistump\avr\libraries\DigiCDC 
then restarted the IDE.  I didn't think it would work because I was putting uncompiled source files only.

But it did work!  YAY!
Initial playing around seems positive. 
But the interface stops if a SerialUSB.println is put into setup()

Thanks also to defragster. 


defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #5 on: January 07, 2015, 07:49:54 pm »
Yay an update! - my sample from other thread is mostly working on the edge cases.  It seems as if the display/baud rate has dropped down noticeably.  I may look and comment over there.

I pulled it down and on the ECHO sample enter 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' and all is well, as it was before with echo of chars.

However enter 'ABCDEFGHIJKLMNOPQRSTUVWXYZ.ABCDEFGHIJKLMNOPQRSTUVWXYZ' and you only get the following where it clips as below, but will run and repeat (as before) - this is about the same net count of characters in a loop.

ABCDEFGHIJKLMNOPQRSTUVWXYZ.ABCDEFGHINV


defragster

  • Sr. Member
  • ****
  • Posts: 467
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #6 on: January 08, 2015, 02:01:31 am »
Indeed I measured github update as 9.3 times slower than 1.5.8B ; in original thread: http://digistump.com/board/index.php/topic,1597.msg7653.html#msg7653
« Last Edit: January 08, 2015, 12:31:02 pm by defragster »

digistump

  • Administrator
  • Hero Member
  • *****
  • Posts: 1465
Re: Theory and practical on Serial Comms with a Digispark Pro
« Reply #7 on: January 08, 2015, 01:43:40 pm »
@Socco

the following works fine for me with the println in the setup:

Code: [Select]
#include <DigiCDC.h>    // 1.5.8B release CDC library

void setup() {
  // initialize the digital pin as an output.
  SerialUSB.begin();

  SerialUSB.println("test");
}


// the loop routine runs over and over again forever:
void loop() {
  while (SerialUSB.available()) {
    SerialUSB.write(SerialUSB.read());
  }
}

The "test" never prints because I never get the serial terminal open fast enough - but the echo works and the port appears.

Can you give an example of what isn't working with println in the setup, but is if you remove it?


@defragster - yes it is slower - but I think your test just shows the shortcoming of all ring buffer communication - I'll respond in your thread with your test