Could I2C.readFrom() be made to return a Uint8? #600
Replies: 9 comments
-
Posted at 2014-03-27 by @gfwilliams Yes, I'd been wondering about this - it wasn't an issue until recently as I2C would only read in 32 bytes (line Arduino iirc). The problem is that Uint8Array!=Array, so you can't use things like splice, and people will definitely get upset with that as well :( I guess the best option might be to add an optional argument: I think SPI does act properly if you give it a Uint8Array to send - obviously in that case it's easy though as if you're using a Uint8Array in the first place you know what to expect. For now, can't you just read in smaller chunks? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-03-27 by DrAzzy Yeah - for now I can read it in chunks, though these have to be pretty small chunks if you're running short on memory. I2C.writeTo() works fine with Uint8Arrays and strings. What I do to write to the eeprom if the data is passed as an array (since I can't count on the array being splicable, since it could be a Uint8Array) is to convert it and the address to strings and concatenate them. In any event, my eeprom module seems to work pretty well. I'll submit it tonight. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-03-27 by @gfwilliams Great, thanks! Yes, I don't know if anyone else can suggest any way around this? I guess a specific option is the war forwards. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-04-07 by DrAzzy maybe I2C.readFrom(address,quantity, { as:"Uint8Array " }) (with support for options like "string") would be a more generic solution - but just being able to output in any form that has reasonable memory efficiency is sufficient to make life a lot easier when working with EEPROMs. (was working with eeproms this weekend, which brought this issue to mind...) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-07-16 by ExperimentalZeros Hopefully this is the proper place the following question: with the following code:
I get the following output:
My question(s): 1.- What is the purpose of displaying |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-07-16 by ExperimentalZeros Some background Info: I am using Espruino as an "external interface" to LabVIEW so I can control hardware away from my setup. I send and capture messages over TCP/IP and utilize its elements to either display and/or do something else. Over the computer I can discard anything from return string dump, utilize the information I need, and move on with the tasks. Nevertheless, I was really wondering how useful is the displaying of such type information is. And, if I am missing the whole point, please forgive me, I would love to take advantage of it. Still, regardless of how many messages are read or written: Aren't all I2C messages 1 Byte (Uint8) long by standard? Thank you all. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-07-18 by @MaBecker @ExperimentalZeros if you like you can use slice to convert uint8Array to Array
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-07-18 by @gfwilliams As @mabe says, you can convert it to a normal array as above. Also, if you just want to display it as a string, you could use The reason type info is displayed on the console is it's very useful as a debugging tool.
That'd be really confusing if you weren't aware that x was a Uint8Array. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-07-18 by ExperimentalZeros @mabe @gordon |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-03-27 by DrAzzy
I2C.readFrom() returns an array of bytes returned by the device - however, it is returned as a simple array, so each member of the array takes up two memory units.
This is particularly relevant for interfacing with an EEPROM (I was testing the module, when I discovered this). Reading in 512 bytes took up 1025 memory units... the corresponding Uint8Array takes up 35 memory units.
Beta Was this translation helpful? Give feedback.
All reactions