True Serial on DigiSpark PRO with OLED

[defragster]

Serial Debugging with No serial ports on my PC - but I have a spare Pro&OLED so I built my own debugging terminal!

I did the initial Port of the OLED code I found - and then I could debug by printing - once the OLED was working- OLED not perfect and jamming data to the screen being worked on flies in the face of MultiMon_101!

So I tried USB: and it isn't up to snuff in the 1.5.8B release (and I was on a RAW pro with no screen just a light to blink).  I saw SoftSerial getting worked on - but the PRO has true Serial Hardware Support built in - and this works: http://arduino.cc/en/Reference/Serial

So I looked at the Pro OLED PCB board and saw it holds Tx/Rx for the GPS - then figured out how I wanted to expose the other pins to keep it tiny and yet usable for future, without sockets. { 90 degree angle pin strip everywhere and then solder and trim or double solder long legs}

Much more to do to have usable code for a terminal - but I have hardware and it works!  I have more pics - but two PRO's [ each with 8 line 20 char displays] in a mint box below - with a USB hole it fits.

OLED debugger terminal starts and waits for incoming strings to put onto OLED.  The Debuggee OLED does the sample and once each loop it says HI and prints the loop count.

Code: [Select]

void setup()
{
  lcd.begin();
  lcd.clear();
  lcd.setFontSize(FONT_SIZE_SMALL);
  lcd.println("Hello, world!");

  Serial.begin(19200);      // open the serial port at 19200 bps:
  Serial.write("Hello Serial");
}


Code: [Select]

long lscount = 0;
int incomingByte = 0;   // for incoming serial data

void loop() {
  int in = 0;
  while (Serial.available() > 0) {
    if ( 0 == in ) {
      delay(20);  // pause for message to xmit
      in = 1;
      lcd.clear();
      lcd.setCursor(0, 0); // setCursor needed after clear() ???? BUGBUG
      lcd.setFontSize(FONT_SIZE_SMALL);
      lcd.println(F("_._.5._._0_._.5"));
      lcd.println(F("Msg Count"));
      lcd.printLong(lscount);
      lscount++;
      lcd.println(F(":Serial Msg #"));
    }
    // read the incoming byte:
    incomingByte = Serial.read();
    if ( -1 != incomingByte )
      // say what you got:
      lcd.print((char)incomingByte);
    if (Serial.available() == 0)
      delay(10);  // pause for message to xmit
  }
  if ( 0 != in ) {
    lcd.println("<end>");
    lcd.println(F("_._.5._._0_._.5"));
    lcd.println("<end>");
  }
}
Thus was born my dedicated pair or Pro OLED serial debugger boards.  Up and functional on the build and simple add on Serial write and read.  Code snippet shows some mods to OLED that bring serial to life - very simple.  For now I'm editing one file and swapping the name loop() and loop2() to decide which code runs.  I have more pics of how I pieced it together.  And hopefully I'll soon make the code more robust.

Question: Is there a set of debugging/terminal commands commonly used anywhere I can emulate to control how the OLED screen is used and maximize the debug detail while not overloading the serial channel and provide a usable interface and not re-invent some wheel?

[defragster]

The Pro twins ran over 4,000 paired loops and text transfers over night.

This topic is as much about testing the OLED as showing how the PRO can be used for serial transfer - in this case debugging.  I am using an OLED on both Pro's, but you could use an OLED Pro to display serial output from any device.

Before calling it quits I discovered a workaround to the one println() anomaly, the workaround for now is shown in the updated code above and I found the clear() code currently requires this after it to keep the display controller in sync:

Code: [Select]

lcd.setCursor(0, 0); // setCursor needed after clear() ???? BUGBUG
That affects the sample, but it also stopped my debugger status printing which is how I found it.  Other than the shared setup() above, here is the only code I inserted in to the OLED sample loop to send out status once each loop.

Code: [Select]

void loop()
{
  Serial.print("HI ");
  Serial.print(lcount);
One item of note is that the 'twins' fail to sync on start if they don't both start at the same time.  I didn't look at that yet.  The TEST OLED runs without care, but the DEBUG OLED won't get messages - even with a reset if not started in sync.

[defragster]

This thread has serial usage notes - http://digistump.com/board/index.php/topic,1596.0.html - hard versus soft serial and connection and usage methods.

My PRO second unit got a fresh flashed bootloader and it is working(edit 1/4/15). Will build a spare, so I don't know if serial is running.  With clarification I tried to wire shared VCC wires properly and ended up switching USB programming cable to DEBUG UNIT with USB battery running the TEST unit and something went to failure - OLED good and Pro still making VCC from VIN - but no other life signs on the DEBUG display unit.

I just put my OLED + Serial + DigiMouse into one and it runs the simple sample to shift the cursor! 

This means that TARGET Pro can serial to another DEBUG that Pro can have an active USB connection.  Without OLED it could just be a 'smart adapter' to the IDE serial monitor ideally.  With OLED it could provide OLED output and forward (selectively) other debug stream to DigiCDC perhaps, meaning you would need no serial hardware on your PC and not need to support USB on your target device that may not use USB, or target might be using USB for mouse or other.  The OLED code does eat some RAM (as does USB) and OLED also starts the code used near 11KB with serial and the OLED compiled to MEMORY_SAVING.

I tried adding the DigiCDC and it adds another 100+ RAM bytes and the OLED only shows part of my output, and fails to show as a PORT for the serial monitor - this may change with release post 1.5.8B.  But my first read says current OLED too FAT to run with CDC right now.

Remains to test with two Pro's active on USB - expect one needs to be unplugged to program the other - hopefully once programmed both devices should then run fine on USB together as suggested above as Mouse and CDC.

[defragster]

Quick teaser update I filmed while on the house phone with AT&T reminding them I get crummy service - they re-re-reset my phone and are going to do a formal service review this time.  I killed the audio because it was speaker phone to the tech I shot after I could power my Note4 back up to use the camera.

https://onedrive.live.com/redir?resid=5BE3704DEF865242!3864&authkey=!AGrTe2sgoEg-nME&ithint=video%2cmp4

This shows the two Pro+OLED's wired serially to each other from the GPS pins on the PCB board.  They are sharing a common USB Battery box - at least until I pull one to USB for program updates - which is risky with Rx/Tx left connected.  Be sure to read http://digistump.com/board/index.php/topic,1596.0.html about serial connects.  The ATMEL pins are unprotected and shouldn't be exposed to power when off, or 'confusion' from multiple power sources as they have no isolation or protection, and without a common ground power the serial won’t be reliable if it works at all (I ran a ground to no effect, that could only cause trouble).  I may have toasted one of my Pro's in the learning process, it shows some life so I’m going to re-dump the bootloader if I can.  I know it makes power and the OLED is good, both soldered in place.

OLED Library needs some work but tough to Debug it on same screen (that is the spew running between the smiley face)- so with this working I can export values to a second screen - the other Pro’s OLED.  This setup as you see it in fact helped me debug and diagnose the serial connection too.  There is a default 16byte serial buffer ( those IDE settings for PRO 32 and 64 will dedicate precious extra RAM for larger buffer space ) and when I displayed char counts on the screen I saw I crushed that boundary.  The instant I saw serial input my code was excitedly prepping and writing to the OLED and the other pro was still sending and I wasn't emptying the buffer and I lost 16 characters (thanks debugger).  So I started sending non displayed 'Tilda:~' characters to force the issue after the simple message starting at one I ran up to 200 of them ( I did more but that takes time and you can already see the delay growing at 200 [one Pro blinks as it starts to send, the other blinks on completion but the blinks are hard to see in the light]), and if you see the video I started tracking that.  I had to adjust my code timing on both sides to clean this up as there is no transmit control line [ I could add one, or a response character, but that would put code burden on the test machine ].  Once I sped up the receiver it could empty the buffer so fast it thought the sender was done - even at 115,200 baud and would quit before all the Tilda's were sent after I added a "delay(3);" on the sender's end, so I added a "delay(15);" on the receiver end before I declared the message done [now that I know it works I can add a stop character from the Test machine and cue on that].  Now that I know it can do 115kbs I need to see what happens at lower bps, these delay’s should be ‘harmless’ overkill.  Depending on the Test Application too fast can be as bad as too slow on the baud rate because it takes MCU cycles, so it needs to be flexible.

And inserting code in the system you are testing can cause its own problems, or hide them.  When I ported the OLED I wondered what a value was - so I extern'd a value from the Library to the sketch to OLED print and that fixed something, in fact when I pulled even the printed use of that variable it compiled out and the OLED code re-BROKE!  That variable created a buffer that kept something from being trashed, and the need for it went away after mshorer made a mod to the MicrOled library - though I'm now seeing other garbage on the screen (dots between the large font characters) that may be new, so I need to test the old library and that debug extern in the new version to see.

So much for this quick update – I’ll add pics of my newer Mark II device – and post my working code that might be a good example for the MicrOled library.  The Mark II went from exposed Male pins to long pin Females ($15 got me a 100 pack from Amazon), and I socketed the Pro in case.  I wanted access to all the Pro pins – but the 18 male pins hanging out the bottom are too often in harm’s way, especially with a handheld DMM probe. I finished my first 50 feet of lead free solder – the Pb stuff is way better!

[defragster]

NOTE: The pair in the video completed 17,500 iterations with no apparent problems (still in sync on all messages and still connected)!  I stopped to swap in the restored Pro and it is running fine!

I confused one Pro (bad power setup using my paired units trashed bootloader while programming) and it would chime in USB on PC (and never leave) but not program again.  I put on the latest bootloader with my UNO and it is back in business running the OLED debug test!

[defragster]

Here are the three OLED Pro's I've built and use for this.  Newest has socketed Pro and OLED and Female headers out the bottom instead of Male pins soldered direct to Pro.  All three have pins/sockets in Rx/Tx under OLED to support serial.  As noted I had to reflash bootloader to the one that I somehow zapped - and the full pin set on the bottom allowed me to do that.  After worrying about shorting the male pins I rebuilt with Long pin female headers and it should be more rugged and useful for more common male jumper pins.

[defragster]

More updates coming - working on my interface - and cabling now that 1.5.8C is out.

Seems to be working okay with 9DOF unit data streaming over.

[defragster]

I saw this article in MAKE mag: http://makezine.com/projects/make-41-tinkering-toys/avr-usart-serial/

Might have useful info - my pro work on hold just now - though what I last did was good and robust with OLED and Serial and the 9DOF seeming to work together at high 115,200 baud rate!

[defragster]

Not sure when I'll get back to this.  If anyone is interested in my sketches under development let me know.  I was busy hacking chasing timing issues as the Serial can come in faster than OLED can be updated on the Debug Output unit - then my Pro's got odd so returned them for evaluation.  The OLED has added control bytes of overhead (cursor movement and command management for character write) that makes it take longer to write than for the serial to send (at 115kbps) , even when it is waiting for data from the 9DOF with minor added delays.  Not a problem if the stream slows, but I wanted to try some things.

If I cleaned up the serial and dropped the oled from the debug unit, it would have room to pass all the serial out as USB to a terminal program (it may also fit but not before the last release with USB update and New Oled driver).  My goal in this too is to allow the program at hand on the primary PRO to run with minimal impact from debugging.  Adding Serial is about free as it has native hardware, OLED takes cycles and other resources, USB is about twice that.  So Pro#1 pushing debug output to Pro#2 can track any values.  Pro#2's only job it to report the debug output usably somehow, and this Pro#2 can be recycled from project to project for the same purpose if you can spare two pins.  It would likely work on ONE pin if you never receive on the Pro#1 - or use the OnePinSerial debugger - but that doesn't use the hardware resource of the Pro to best advantage - takes code space and more cpu time than True Serial.  I never tried only connecting Pro#1 Tx to Pro#2 Rx as I had the pins to use - but this should work as there is no handshaking.