Maximum string length on one line with Arduino IDE?

[DimitriP]

Perhaps I'm missing something too obvious by why can't the "transmission" code be put in a loop so the same "short" string is being transmitted over and over?

That is a very fair question.  The answer is that by sending the same short transmission over and over it is pretty hard to know which of the transmissions is being decoded and viewed on the oscilloscope.  By sending a long text with reasonably unique paragraphs, sentences, and words it is much easier to verify where in the long string a particular set of characters resides.  Not only can you use a word processor to search for text location (if need be), but after a few hours of tedious examination you can pretty much know the document and the relative text location by human memory, if not recite it 

A)If you are hell bent on sending WarAndPeace across the wire at 9600 baud, you better get a Pi and be done.

B)As for "pretty hard to know which of the transmissions is being decoded and viewed on the oscilloscope.",      C'mon now...send the counter value out as well and you'll know the exact group you are looking at.

C)As for learning the document as a side effect....see A)

I'm pretty happy to conclude that the largest part of the problem you are trying to solve, is not the actual problem, but your solution.

[Electro Fan]

If you're testing the instruments functionality, why not send out Hello World! repeatedly?

Code: [Select]

void loop()
{
  Wire.beginTransmission(...);
  for (int i = 0; i < 250; i++)
  {
    Wire.write("Hello World!");
  }
  Wire.endTransmission();
}
The Hello World! string is 12 characters, times 250 is 3000 characters of text.

I imagine you want to see what happens if you decode the I2C midstream. I know that my Rigol DS1074Z (old firmware nevertheless) can only decode what is on screen, and wont do a good job if the start bit is not on screen or you're far zoomed out.

Exactly.  The Rigol scopes do a pretty good job but they have a few quirks as you describe.  I have found that if you send data to be dedcoded and immediately scroll around you run the risk of having data that barely moves off the screen disappear.  If you use the record feature the review process becomes much more resilient against the scroll off the screen problem.  In fact, if you record long strings of text the scope will break the long text into segments and each segment from the beginning of the text to the end can be searched in order.  I have one document that spanned 120 segments.  For the most part the end of one segment marries to the beginning of the next segment.  This first project was done with RS232 from a text editor through a PC serial port.  It proved that the Rigol decoder function can work with relatively large data sets.  This next project is intended to do the same with I2C - which is why I'm  trying to figure out how to code the Uno.  My first test showed what everyone is pointing out (the 32 Byte limitation); initially I thought I was seeing a problem with the scope - but it was my improper use of code with the Uno.  So... now I just want to easily cut and paste (not learn to program) a long string into an Arduino sketch.  I'm not adverse to learning to code (in fact it's on my list of stuff I'd very much like to learn).  Maybe with a few more pointers (and preferably an example sketch that I could cut and paste for this project) I can earn some coding basics here.  (I have already learned one - wire.write is limited to 32 Bytes.) 

[Electro Fan]

Perhaps I'm missing something too obvious by why can't the "transmission" code be put in a loop so the same "short" string is being transmitted over and over?

That is a very fair question.  The answer is that by sending the same short transmission over and over it is pretty hard to know which of the transmissions is being decoded and viewed on the oscilloscope.  By sending a long text with reasonably unique paragraphs, sentences, and words it is much easier to verify where in the long string a particular set of characters resides.  Not only can you use a word processor to search for text location (if need be), but after a few hours of tedious examination you can pretty much know the document and the relative text location by human memory, if not recite it 

A)If you are hell bent on sending WarAndPeace across the wire at 9600 baud, you better get a Pi and be done.

B)As for "pretty hard to know which of the transmissions is being decoded and viewed on the oscilloscope.",      C'mon now...send the counter value out as well and you'll know the exact group you are looking at.

C)As for learning the document as a side effect....see A)

I'm pretty happy to conclude that the largest part of the problem you are trying to solve, is not the actual problem, but your solution.

Ok, whatever you say

Of course it doesn't have to be War and Peace - any document that will help push the limits and identify the capacity of the scope's decoder memory will do (I realize code is pretty literal, sometimes coding by coders might benefit from interpretation)

I like the idea of a counter - trouble is that is something I couldn't have asked about since I hadn't thought of it, but now that you mention it, how would that work?  I know, read the documentation and figure it out.

As an aside, I think there is a kind of disposition (I won't say attitude) that sometimes comes up with some programmers who say - well, just read the documentation and/or just figure it out.  An alternative view is that one of the beauties of the Arduino is the ability to cut and paste.  In addition to giving some more immediate results it also allows newbies to then tinker a line at a time to see what causes what - while still having the benefit of some working code that is just an undo away. 

I do get the fact that some folks have the gift to just get software, and that's cool.  But the ability to spoon feed it with Arduino sketches is potentially powerful.  I just think the intermediate and advanced users should maybe be a little more inclined to leverage existing sketches as opposed to taking the position that sketch reuse is meaningless or harmful.  Just sayin'

PS, I didn't say I want to send War and Peace; if you read the post it says "cut and paste a few pages of text from War and Peace (or any other text)"

PSS, the counter idea really is a great idea 

[Electro Fan]

To get back on track / stay on track, the objective is:

To figure out how to code an Arduino IDE sketch that would allow many (thousands or tens of thousands of characters) to be transmitted from a Master Uno to a Slave Uno via I2C.  The current wire.write approach that I am using seems to be limited to 32 Bytes, so I'm looking for a work around if possible, or if need be a different better approach.

The current approach is shown here:


]https://www.youtube.com/watch?v=Jndb2vpAWwU

If this could be modified to accommodate longer transmissions, that would be A-OK - seems like there should be an easy way to get around the 32 Byte wire.write limit.

In doing some research (as part of "reading the documents"), I found the web post below.  Don't know if this could be part of the solution - but any help would be appreciated. 

An ideal winner would be a link to a sketch that would allow a bunch of text to be inserted and transmitted from an Uno Master to an Uno Slave using I2C.    Alternatively, a clear-cut modification of the sketch shown in the video would be fine.  Just looking for something clear and understandable for an Arduino beginner.

Thx

Two other thoughts:  1) is there a limit specified by I2C regarding how many characters can be transmitted/received?  2) Unless there is an I2C limit it would seem that next limit would be the memory capacity of the an Arduino Uno, correct?  Thx again

---

Re: Send string using i2c
#3
Apr 22, 2015, 10:49 pm 

For future humans reading this who are having this issue but still don't understand why PaulS is saying that Strings aren't strings, here is a more verbose explanation:

Arduino nomenclature uses the word "string" (little s) as a shorthand method of denoting an array of chars.  This is distinctly different from the class "String" (big S). 

http://www.arduino.cc/en/Reference/String  (it really doesn't help that the URL uses big S...)
http://www.arduino.cc/en/Reference/StringObject

Humans who use phonetic pronunciations to derive meaning (or machines that have the ignoreCase flag set  ) might not understand at first that these two things are very different.  You can concatenate a String very easily with concat().  You can not do the same operation with a string.  Functions that say they want a string input actually want a char array input, and will get very fussy if you try to give them a String.

The main point of confusion (for me, at least) came from the Wire.write() doc page:

http://www.arduino.cc/en/Reference/WireWrite

It very clearly states that you can send a string using this function.  This, however, does NOT mean that you can send a String (believe me, I've tried - you get about a thousand lines of error messages).

So, the solution to this is to convert your String to a string, like so:

Code: [Select]

Big_S_String.toCharArray(little_s_string, ;
Wire.write(little_s_string);

I would personally love it if they changed the documentation to say "char array" instead of "string", since it is not intuitively obvious when first starting out down with an Arduino.

As a side note, I'm replying to this year old topic since it was the most relevant to the issue I was facing in hopes that other people who have the same problem and stumble across this thread will understand why their Wire.write() function isn't working.  Izak, I hope you've figured all of this out by now. 

[Ian.M]

There is no limit in the I2C protocol: If you have a device that can accept it (e.g. the PCF8574 8 bit 'dumb' I/O expander), you can stream data to it all day at its max. clock speed.

There is no limit in the MCU hardware:  I2C master peripherals (in general) send the bytes given to them, receive the Ack bits and only add Start, Stop and Restart framing when commanded to.  Bitbanged I2C is only limited by the program writer!

There is no practical limit in the amount of data available to send: An I2C bus can be clocked at frequencies right down to DC, so can easily be paused between bytes while the MCU goes off to fetch another sector of data from SD card or other mass storage.

The limits you are hitting will be in the 'wire' library, or one of its dependencies, and they are only there because the library was written to be block oriented. You need to get at the raw byte level I2C bus handling primitives so you control the byte flow.

[Electro Fan]

There is no limit in the I2C protocol: If you have a device that can accept it (e.g. the PCF8574 8 bit 'dumb' I/O expander), you can stream data to it all day at its max. clock speed.

There is no limit in the MCU hardware:  I2C master peripherals (in general) send the bytes given to them, receive the Ack bits and only add Start, Stop and Restart framing when commanded to.  Bitbanged I2C is only limited by the program writer!

There is no practical limit in the amount of data available to send: An I2C bus can be clocked at frequencies right down to DC, so can easily be paused between bytes while the MCU goes off to fetch another sector of data from SD card or other mass storage.

The limits you are hitting will be in the 'wire' library, or one of its dependencies, and they are only there because the library was written to be block oriented. You need to get at the raw byte level I2C bus handling primitives so you control the byte flow.

That's all good news - Thanks.

So, given that it's doable, I just need to figure out "how"?  Seems like there should be an example sketch out there somewhere of a couple Uno's talking to each other Master to Slave that are coded to send long text strings.  If anyone sees one, please post it.  If there is no such thing it could be a chance for someone to be the first to publish such a sketch

[westfw]

To figure out how to code an Arduino IDE sketch that would allow many (thousands or tens of thousands of characters) to be transmitted from a Master Uno to a Slave Uno via I2C. 

You could, you know, just NOT use the Arduino "Wire"  library.  It seems to be heavily (and not very well) tuned to allowing multiple I2C devices to be used "simultaneously", even if transmits are initiated in ISRs, and using interrupts for the actual transmission as well.  If you don't need that, it should be pretty simple to write your own "bare metal" i2c code, following one of the non-arduino AVR examples (say: http://www.ermicro.com/blog/?p=744 ?)

Alternately, you can just break your data into <32byte chunks:

Code: [Select]

i2c_bigwrite(const char PROGMEM *bigdata, int length) {
    char shortbuf[16];   // nothing like another layer of buffering.
    while (length > 0) {
      Wire.beginTransmission();
      memcpy_P(shortbuf, bigdata, 16);
      Wire.write(shortbuf, 16);
      Wire.endTransmission();
      p += 16;
      length -= 16;
    }
}


[amyk]

You could, you know, just NOT use the Arduino "Wire"  library.

+1 to this. 32-byte limitation that is not even mentioned in what appears to be the official documentation? If the function is just sending a null-terminated string it should be able to keep going until it hits the terminator, not at some arbitrary 32 bytes limit!

I've had people ask me why I don't use Arduino, "because it's so much easier"...

[westfw]

I'm inclined to agree.   The multiple-device capability I was thinking was there doesn't seem to actually exist, either.  :-(
(although, it is non-blocking...)

OTOH, it's amazing how long this library has been in use without anyone noticing the (undocumented) limitations.

[Ian.M]

What do you expect of a whole ecosystem designed to encourage cargo-cult programming by the great unwashed?   Any sane embedded developer takes a look at the supplied library source (and if there is no source available, either runs screaming for the hills or gives that library + any other tools that demand it a loooooooooooong drop kick), and when the library's code stench is too vile, bites the bullet, grabs the MCU and peripheral chip datasheets and rolls their own.   Unfortunately Arduinoland suffers from Sturgeons law to a greater extent than most other platforms, tacking on a second or third coprological '9', and the fractional percentage of $paid$ developers only scrutinise the most odious code turds that have floated to the top of their project cesspool.  <dons Nomex suit>

[obiwanjacobi]

In general I would opt for using a library in the assumption that code is tested and used by many others and should not suffer from the bugs you own code may have... Was-Not-Invented-Here is something to be mindful of.

[Ian.M]

Unfortunately, far far too many libraries with published source make you go "W.T.F? Was this the proverbial crack-smoking intern's summer project?".  If you use a low cost or free library, you'd better scrutinise it carefully, because you are usually being paid to code the application, not to become a major contributor to an open source or 3rd party project on your employer's dollar.

[Electro Fan]

In general I would opt for using a library in the assumption that code is tested and used by many others and should not suffer from the bugs you own code may have... Was-Not-Invented-Here is something to be mindful of.

Anything you might recommend as an alternative relatively easy Uno sketch that would communicate large numbers of Bytes via I2C?  Thx

[westfw]

Far too many libraries with published source make you go "W.T.F?

Whereas libraries with unpublished source code avoid that only by ... not letting you see the soucre code...

If you use a low cost or free library, you'd better scrutinise it carefully

If you use an expensive, proprietary, library, you had better scrutinize it carefully and test the hell out of it.  But in that case, you probably have the resources to do so.  (actually, I was pretty happy with the only expensive proprietary library that I "bought" and was intimately acquainted with.)
(There's nothing quite like the disappointment of being let down by code that you were sure you could trust.  The nice thing about poor open source and vendor libraries that that you never quite reach the point of trusting them :-))

recommend as an alternative

Do you actually need a "very large" single I2C transaction?  How big, exactly?   Do you have a receiver in mind that can receive the data without NAKing?  Or do you need a receiver implementation as well?  It looks like you can prevent the "Stop" from being sent in endTransmission(), which should give you the same effect as one long packet even though you're calling beginTransmission() multiple times.  How many more clues do you want, or do you just want someone to write the code for you so that you can focus on ?analyzing the bitstream on OtherDevice? or whatever?

[Ian.M]

Far too many libraries with published source make you go "W.T.F?

Whereas libraries with unpublished source code avoid that only by ... not letting you see the source code...

Yes. That's where "....(and if there is no source available, either runs screaming for the hills or give that library + any other tools that demand it a loooooooooooong drop kick)...." comes into play.   

If you use a low cost or free library, you'd better scrutinise it carefully

If you use an expensive, proprietary, library, you had better scrutinize it carefully and test the hell out of it.  But in that case, you probably have the resources to do so.  (actually, I was pretty happy with the only expensive proprietary library that I "bought" and was intimately acquainted with.)
(There's nothing quite like the disappointment of being let down by code that you were sure you could trust.  The nice thing about poor open source and vendor libraries that that you never quite reach the point of trusting them :-))

Of course, if you've paid for the library, there is an expectation that (paid) support will also be available.   I have paid for a source code licence for bundled libraries just because I didn't trust an apparently working binary blob, and wanted to be able to be certain the bugs were in my code not the library.  I've also developed a binary patch for an annoying range checking bug in a closed source library

@O.P.  Stop worshipping John Frum and take look at the wire library's I2C primitives (twi.c) and the processor datasheet to find out what's actually going on 'under the hood'.  Also get a PCF8574 chip, to use as a reciever for testing rather than another Arduino.  Its just about the dumbest I2C device on the market and you can stream data to it indefinitely.  You need each byte ACKed promptly to get low jitter streaming to work, and trying to debug the master end without a bug-free slave is a recipe for frustration.

[Electro Fan]

recommend as an alternative

Do you actually need a "very large" single I2C transaction?  How big, exactly?   Do you have a receiver in mind that can receive the data without NAKing?  Or do you need a receiver implementation as well?  It looks like you can prevent the "Stop" from being sent in endTransmission(), which should give you the same effect as one long packet even though you're calling beginTransmission() multiple times.  How many more clues do you want, or do you just want someone to write the code for you so that you can focus on ?analyzing the bitstream on OtherDevice? or whatever?

Preface: I used (ie, cut and pasted) the sketch shown in the video previously linked into this thread.  I did not write the sketch but in the process of using it I discovered that wire.write has a 32 Byte limitation that is perhaps not so well documented.  I wrote a post asking for suggestions on how to get around the 32 Byte limitation.  To be clear, I did not ask for any "clues".  As explained multiple times, I don't have much experience with either I2C or Arduino code.  And btw in case it's not clear yet, I don't want "clues". 

Now to try to answer your questions:  Yes, making a relatively large single transaction (transmission) is the objective (I get what an Ack and Nak are, but I have no idea how to get two Unos to manage Acks and Naks).   If the code will run by preventing the "Stop", that's swell.  I don't care - I'm just trying to make Bytes move via I2C from one Uno to another. 

As previously mentioned in this this thread, the objective is to be able to transmit thousands of Bytes.  So, let's say 40k Bytes plus or minus.  (I can of course insert the 40k Bytes - I'm not that clueless  , so no need for anyone to do that.)

To be clear, the preference, if possible, would be to send the Bytes from one Uno as the master to the second Uno as the slave - so yes, that would take code for the slave Uno to go with code for the master Uno - perhaps along the lines of the sketch shown in the video posted earlier in this thread but without the 32 Byte limitation of wire.write.

Yes, I just want to use the code to make the I2C transmissions between the Unos so as to have a testbed which in turn will enable me to focus on better learning the operation and better understand the performance of an oscilloscope's logic analyzer functions.  If anyone has ever seen an education demo board, that is sort of what I am looking to establish with this project.  I don't really want to code the demo board, but if I had a sketch (or really clear clue-free instructions on how write the code) then I could load the code onto a couple Unos, and that would be great.  If in the process, I learn some Uno coding that's A-OK, but it's not the number one objective for this project. 

So yes, if someone wanted to write the code I would not be too proud too use it.  (Although, if it took more than 5 or 10 minutes or about the time it takes to read and write these posts, I'd say forget it unless you enjoy doing such coding.)

I realize Arduino is not everyone's first choice but Unos happen to be something I have available and I'd like to use them if possible.  So if you or someone knows of such a master/slave I2C sketch on the web and you can post a link to the sketch would be great, or if you or someone wanted to write such a sketch, cool.  If not, no worries. 

[obiwanjacobi]

Anything you might recommend as an alternative relatively easy Uno sketch that would communicate large numbers of Bytes via I2C?

Well, besides the undocumented 'feature' of the internal 32 byte buffer, the code does work. So just do what was suggested earlier and send the large message in chunks.

If you're not getting the speed you're looking for, you may want to read up on the USART registers of the 328, specifically the synchronous part... I don't believe that Arduino has any support for that..? (not sure).

[Electro Fan]

Anything you might recommend as an alternative relatively easy Uno sketch that would communicate large numbers of Bytes via I2C?

Well, besides the undocumented 'feature' of the internal 32 byte buffer, the code does work. So just do what was suggested earlier and send the large message in chunks.

If you're not getting the speed you're looking for, you may want to read up on the USART registers of the 328, specifically the synchronous part... I don't believe that Arduino has any support for that..? (not sure).

Eh, Ok, but the clues aren't helping the clueless

When you say send the large message in chunks, does that mean chunks that are less than 32 Bytes?  Or are you suggesting a method by which the chunks can be larger than 32 Bytes (presumably by not using wire.write)?   How about a few lines of example code showing how the chunk method would look within the otherwise working master sketch?  Thanks

[amyk]

In general I would opt for using a library in the assumption that code is tested and used by many others and should not suffer from the bugs you own code may have... Was-Not-Invented-Here is something to be mindful of.

"tested and used", but which parts? Something like Arduino is not going to be subject to the same sort of thorough use as e.g. the GNU C Library, so it's a mess of code that's just barely working. ST's is no better, when you can find a bug just from a few minutes of actually reading the source. NIH is just a poor excuse for accepting and using sub-optimal solutions. ("If people didn't reinvent the wheel, we'd still be using ones made of stone.")

Get the datasheet and give it a good read. Setting up the peripheral directly to do the appropriate transfers is not hard.

Arduino is a tool like any other. As others have alluded to here, you are not obligated to use it for any reason. Use it to make things easier, but when it makes things harder, you should move on to find a better solution.

[westfw]

  (I can of course insert the 40k Bytes

I want to see that.  Given that the Uno only has 32k of flash... :-)

I must be missing something.
Wouldn't it be better to exercise the scope's logic-analyzer functions on a scenario that is likely to actually occur in the real world?
Something like writing waveform data to an I2C A2D converter, or continuously reading navigation data from a 9DoF sensor board?
The Arduino library continues to exist in its relatively broken form, because 99% of the things that people do with it don't hit the broken part...
(I found some large I2C EEPROMs that could use an I2C transaction of ~128 bytes, but ... 40k?)

[obiwanjacobi]

@Electro Fan: if you have a buffer of 32 bytes doesn't it makes sense to take chunk of 32 bytes??

As to the stability and quality of libraries... Yeah, I'm not going there.

[Electro Fan]

@Electro Fan: if you have a buffer of 32 bytes doesn't it makes sense to take chunk of 32 bytes??

As to the stability and quality of libraries... Yeah, I'm not going there.

If I understand - the suggestion is to break 40k Bytes into chunks that are 32 Bytes or shorter?

I suppose this is doable, but I see a couple challenges with this approach.  One challenge is to write 1000 lines of code.  Another challenge is to have some way to navigate the "chunks" so that I know what I am looking at when viewing the monitored transmission. 

This leads to the earlier idea of a counter or some time of incremented/numbered approach.  Conceptually, I can get my head around this:  a thousand or so  lines numbered 1 thru 1000.  Unfortunately, without better coding skills I can't see how to automate this, so it seems like a lot of labor.  (But maybe it's a good time learn how to make incrementally numbered lines - I realize it's simple, if you know how.)  Alternatively, if I could get past the 32 Byte limitation (still looking for a way to do that) I could cut and past "War and Peace" (it's a joke, it's just an example) or any other several pages of text with a familiar "story" that would enable me to navigate by context when monitoring the transmissions.

So far I'm kind of hung up on the fact that 40k / 32 is over a thousand lines of code - it would be a lot easier to paste in 40k Bytes in one big chunk....

Thx

[Electro Fan]

  (I can of course insert the 40k Bytes

I want to see that.  Given that the Uno only has 32k of flash... :-)

I must be missing something.
Wouldn't it be better to exercise the scope's logic-analyzer functions on a scenario that is likely to actually occur in the real world?
Something like writing waveform data to an I2C A2D converter, or continuously reading navigation data from a 9DoF sensor board?
The Arduino library continues to exist in its relatively broken form, because 99% of the things that people do with it don't hit the broken part...
(I found some large I2C EEPROMs that could use an I2C transaction of ~128 bytes, but ... 40k?)

Good point now that you mention it.  Previously, before the 32 Byte wire.write limit was surfaced, I asked if there was possibly a limit with the Uno and someone said no - but I think you are right about the 32k limit.  So I guess that is the ceiling.  The job just got about 20% easier

[DimitriP]

[Electro Fan]

I guess sending long strings between Arduinos with I2C is too difficult for anyone on this thread to make happen.