Could I2C.readFrom() be made to return a Uint8?

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.

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: I2C.readFrom(address,quantity, { asUint8Array : true })

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?

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.

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.

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...)

Hopefully this is the proper place the following question:

with the following code:

I2C1.setup({sda:D4,scl:D5});

//var result;

function m(){
var PAYLOAD = [];
var data = [];
  for (var i = 0; i < 2; i++){
    I2C1.writeTo(0x40,(i));
    data = I2C1.readFrom(0x40,0x02);
    PAYLOAD.push(data);
	}
  
//result = PAYLOAD;
  return PAYLOAD;
  
}

I get the following output:

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v86.tve_master_247bc37 Copyright 2016 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:512/512, manuf 0xe0 chip 0x4016
>echo(0);
=undefined
>
=undefined
>m();
=[
  new Uint8Array([113, 39]),
  new Uint8Array(2)
 ]
> 

My question(s):

1.- What is the purpose of displaying new Uint8Array([113, 39]), instead of [113, 39]?

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.

@ExperimentalZeros if you like you can use slice to convert uint8Array to Array

x = new Uint8Array([113, 39]);
=new Uint8Array([113, 39])
y  = [].slice.call(x);
=[ 113, 39 ]

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 x.join(",") to create a string by sticking all elements together with , inbetween.

The reason type info is displayed on the console is it's very useful as a debugging tool. Uint8Array isn't the same as an array at all. You can imaging the following scenario:

>x
=[ 113, 39 ]
>x[0]=-1
=255
>x
=[255, 39]

That'd be really confusing if you weren't aware that x was a Uint8Array.

@MaBe
Excellent! Great approach!

@Gordon
Thank you for the explanation, it does make sense.