Maximum string length on one line with Arduino IDE?

[Electro Fan]

This is the back to square one code for the images shown just above:

//i2c Master Code(UNO)
#include <Wire.h>

void setup()
{
  Serial.begin(9600);
 
  Wire.begin();
}

void loop()
{
  while(Serial.available())
  {
    char c = Serial.read();
   
    if(c == 'H')
    {
      Wire.beginTransmission(5);
      Wire.write('U');
      Wire.endTransmission();
    }
    else if(c == 'L')
    {
      Wire.beginTransmission(5);
      Wire.write('L');
      Wire.endTransmission();
    }
  }
}

[Electro Fan]

Ian, I was editing the last post and might have had a bad (old) image in the first image when you looked/commented; please take a look at the first image again and see if it still looks bad?  Thx, EF

[Ian.M]

It looks like you took down the first image in post#73 after I commented on it.  Did you post one of the old images by mistake?   Try sending 0x5A ('Z'), because it has alterbating 1 and 0 apart from a doubled 1 in the middle so its much easier to count bytes.   

Unless your scope is reacting to fast glitches on SCL its serial data decoder display really shouldn't be skewed from the waveform like that.  Try the longest possible repeated block of 'Z' filled strings that you can and look at the last few bytes of the message. If its skewed  but is displaying 'Z' (or binary 01011010) the scope's protocol decoder dosplay is borked.  If it shows anything else, the scope is responding to glitches on SCL which are causing it to mis-count the bits.

[Ian.M]

Yes. those are OK.  It looks like the problem is only showing up after a *LOT* of data.

[Electro Fan]

Might have found the problem.

Here is just a small progression in modifying the code.

Previously, in the original off the shelf sketch from the video, the code sent one character as 'H'; when I modified to 'U' no problem.  But when I change it to more than one character - which only seemed to work when I used "" instead of '' it falls off the railroad tracks.  Look at 'U' vs. "UU" (both in the Binary form).  I think my homemade code which changed 'H' to "H" and then started adding multiple characters was the beginning of the goof.

[Ian.M]

No that's clearly a scope problem.  SDA goes low while SCL is high, clearly an I2C Start or Restart condition, but the scope's decoded data display is showing <Write 0x05> where that is happening.  A start condition should be resynching the scope's decoder.

[Electro Fan]

Yep, I think you are right.  I redid the original sketch with the 'H' and simply made it 'U' and the decode looks as shown below.  I think I might be  against a scope decode issue.  I'm not 100% sure yet, but it is looking like something is goofy with the scope decoding process.  It gets the ASCII and Binary right but it isn't lining up graphically.

[Electro Fan]

I have a few things to try.  I'm going to see if it behaves the same way with I2C on the analog channels.  I'm also going to see how it performs on the analog channels and the digital channels with RS232.  I'll keep you posted here as I learn more.  Thanks very much for hanging in there with me on this - your experience not only on the coding but with I2C has been very helpful.

[Electro Fan]

Ian, here is analog I2C.  Waveforms definitely not as clean but the alignment makes more sense?

[Ian.M]

That's much happier.  Now try it on a *Looooooooong* message, and make sure you have the stop condition in view so you can be certain of the actual alignment

[Electro Fan]

A step at a time, here are 32 Bytes with the sequence

"UUUABCDEFGHIJKLMNOPQRSTUVWXYZUUU"

[Ian.M]

That does look OK, but for ease of reading it manually, set the gain to get 1 div high waveforms, and put the the SCL signal immediately below and very close to SDA.  The decoded data should be below SCL (as it is), but if possible closer, so any alignment skew is more obvious

[Electro Fan]

Here are two 32 Byte segments (analog again).

38 are the two segments

39 shows near the end of segment 001 the U looks lined up

40 is the transition between segment 001 and 002

41 shows near the end of segment 002 the U looks lined up

42 shows the very end of segment 002

[Electro Fan]

That does look OK, but for ease of reading it manually, set the gain to get 1 div high waveforms, and put the the SCL signal immediately below and very close to SDA.  The decoded data should be below SCL (as it is), but if possible closer, so any alignment skew is more obvious

Will do on next batch - but that will require overlaying SCL and SDA, is that what you prefer?

[Electro Fan]

That does look OK, but for ease of reading it manually, set the gain to get 1 div high waveforms, and put the the SCL signal immediately below and very close to SDA.  The decoded data should be below SCL (as it is), but if possible closer, so any alignment skew is more obvious

I think 44 is what you are looking for - it shows how the decodes line up on the clk; 43 shows how it the decodes line up on the data; I kind of like 43 but if you want to standardize on 44 that's A-Ok.  (Or I can squeeze them tighter with the decodes in the middle so we can see how they line up against both the clk and the data.)  Here's 45 as an example.

[Ian.M]

I can live with them overlaid with at least 1/2 division offset, but its better to have the top of SCL fractionally below the bottom of SDA.  That way all you have to do is look at the middle of the two waveforms to read them manually.  See the image I posted that I had tweaked to decode it in post #69.  Obviously if you were looking for waveform distortions, you'd separate them enough to see any ringing etc. but for checking the data content, the less vertical distance (within reason) you have to move your point of focus, the better.

If you can bring SCL right up to the decode trace, you can easily check for skew by seeing if the ACK bit display is centered on the last SCL pulse in each group of nine.

image 44 is OK, but would benefit by reducing the amplitude of both SDA and SCL by a factor of about 2 using the input attenuators.

Decode trace in the middle is a royal PITA as it makes it much harder to check by manual decoding.

Waveforms that show the scope and signal source working as expected aren't very interesting.  Concentrate on the ones you believe to show problems!

Be glad you aren't trying to resolve long I2C messages on an old delay timebase analog boatanchor!

(Not my photo - I'd never have the trace blooming like that)

[Electro Fan]

Assuming you prefer the 44 layout, here is the end of the second segment

[Electro Fan]

And here is the U from the second segment (002); I like it because it's recognizable and it helps show alignment; what do you think?  Does it grade out ok or is it out of alignment? Maybe the data is shifted a tad right?  Or maybe that's just the data trying to catch-up with the clock?

[Ian.M]

46 Looks fine.  See how easy to read manually it is?  Just let your eye follow along the midpoint horizontally and if the top of the blue SCL has the yellow SDA next to it, its a zero bit, otherwise its a one bit.   Within a message (apart from restart bits in a compound message) SDA is only permitted to change when SCL is low, so a small lag from SCL trailing edge to SDA changing is expected.

47 is showing very slight skew on the decoder trace, its no more than 1/5 of a bit and may even just be an artefact of the zoom setting.  Zoom in the X axis by 50% and see if it lines up better.

[Electro Fan]

Looks like about 420 ns offset - don't know if that's normal or a problem; probably not good enough to find particles in the Hadron Collider but maybe good enough for decoding I2C?  When I get back to the 62-64 segment test we can see if it's holding at 420 ns which could just be the response time between the data and the clock, or if it's something longer which would likely be some kind of drift.

[Electro Fan]

See how easy to read manually it is?  Just let your eye follow along the midpoint horizontally and if the top of the blue SCL has the yellow SDA next to it, its a zero bit, otherwise its a one bit.   Within a message (apart from restart bits in a compound message) SDA is only permitted to change when SCL is low, so a small lag from SCL trailing edge to SDA changing is expected.

Very good advice and info!!  Thx

[Electro Fan]

Looks like the signals are 5V; I noticed I had both SCL and SDA set to trigger at 1.34V.  The fall time on SCL looks a little steeper than the rise time on SDA. Maybe if I change the trigger we could pull them into alignment a little better - but I presume the trigger level should be set the same on both, or not so?  What do you recommend for the two trigger levels?

[Electro Fan]

Actually, the more we get into this, it looks like the delta between SCL and SDA is less than 420 ns.  I measured in the middle (about 50%) on both SCL and SDA.  Generally, rise time and fall time measurements are at 10% and 90% (or maybe 20 and 80).  Setting that aside, I think we can see that SDA starts to rise probably closer to within 300 ns of SCL going low, so what we might be seeing is the limitation of my 70 MHz scope.

- I just corrected a couple things in the posts; at first I thought the delta was 4 ns and that seemed mighty fine, but it's actually 300 ns so I doubt that is a limitation of the scope's rise time.

[Ian.M]

See that glitch (hump) on the high part of SDA in the fourth division to the right of the center.  That looks like capacitive cross-coupling between SDA and SCL.  Its not a problem at the moment, but if you push the speed up to 400KHz and have a longer bus, it could become an issue.  What pullup resistors are you using?

If you are talking about the trigger levels for the protocol decoder, check the I2C standard.  Modern devices use 30% and 70% (of VDD) logic threshholds, so the data should decode the same anywhere within that range.  If it doesn't, you've got signal integrity problems.

[Electro Fan]

See that glitch (hump) on the high part of SDA in the fourth division to the right of the center.  That looks like capacitive cross-coupling between SDA and SCL.  Its not a problem at the moment, but if you push the speed up to 400KHz and have a longer bus, it could become an issue.  What pullup resistors are you using?

If you are talking about the trigger levels for the protocol decoder, check the I2C standard.  Modern devices use 30% and 70% (of VDD) logic threshholds, so the data should decode the same anywhere within that range.  If it doesn't, you've got signal integrity problems.

Wow, the plot thickens.  You know, I thought I had 200 ohm resistors but my eyes failed me; I missed a yellow band so I think I have 4k resistors - might be less than optimum?  I think they are just quarter Watt so they are sort of small and the yellow was right on the hump and kind of blended in.  Let me know if you recommend different value and I'll change them.

Scratch all that - turns out my eyes must have been ok but my memory was off, duh.  I just looked at the original design and it called for 4.7k Ohm resistors - so I think I'm ok on the resistors unless you think otherwise.

What else could be causing the hump on all the highs for SDA?  I've never seen that type of hump before.  I've played with the probe ground but that didn't seem to matter.  Also tried two different probes (Rigol and Tektronix), no diff.  I also see some runts (I think that's what they are).  Overall, the signals don't look very pretty - but it's funny how these crummy analog signals are making the decoder happier than the beautiful digital signals.  I'm digital signal decoding issue had to do with software/firmware instead of signal integrity.  But if I can clean up the analog signals that would be good.

Also, at 1.34V I'm under the 30% guideline on trigger.  So, I'll bump it up to 50% on the assumption that if anywhere between 30 and 70 should be the same 50 should be a good level.

This is a great learning experience - Thank You!  EF