Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
DigitalDreams Regular Member Joined: 03/05/2025 Location: United KingdomPosts: 62
Posted: 05:18pm 14 Apr 2026
Copy link to clipboard
Print this post
My next challenge is to save signed integers to an I2c memory chip. They will only range from say -300 to +900 so will be saving as two bytes (high and low) as if a 16bit integer, not the incoming MMBasic 64bit.
For example -
Dim as integer Xmin,Dhi,Dlo Xmin=-298 ... ... I2c write &h50,0,4,1,0,Dhi,Dlo
I'm already writing small positive MMBasic 64bit integers as single bytes as MMBasic converts/truncates to 8bit in the i2c command itself.
Wondering what the fastest and most efficient way would be to do this ?
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11181
Posted: 05:23pm 14 Apr 2026
Copy link to clipboard
Print this post
bin2str$ was designed for specifically this Edited 2026-04-15 03:23 by matherp
DigitalDreams Regular Member Joined: 03/05/2025 Location: United KingdomPosts: 62
Posted: 05:37pm 14 Apr 2026
Copy link to clipboard
Print this post
I'll have a play sir....
bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 232
Posted: 09:58pm 14 Apr 2026
Copy link to clipboard
Print this post
A kind of "hack" according to C, which relies on the Pico using an ARM with a little-endian format:
Dim XminAddr As integer XminAddr = PEEK(VARADDR Xmin) Dlo = PEEK(BYTE XminAddr) Dhi = PEEK(BYTE (XminAddr+1))
DigitalDreams Regular Member Joined: 03/05/2025 Location: United KingdomPosts: 62
DigitalDreams Regular Member Joined: 03/05/2025 Location: United KingdomPosts: 62
Posted: 10:04pm 14 Apr 2026
Copy link to clipboard
Print this post
Interesting 😎
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 3131
Posted: 11:33pm 14 Apr 2026
Copy link to clipboard
Print this post
When writing a string to a 24Cxx EEPROM the 2 address bytes need to be added to the start of the data. So perhaps try:-
a$ = Chr$(Mem.addr>>8) + Chr$(Mem.addr And 255) + a$ 'prepend 2 byte memory address to the data I2C2 WRITE I2C.addr, 0, Len(a$), a$ 'write 2 memory address bytes + up to 32 data bytes Pause 6 'allow time to write
Currently you are trying to write a mix of integer bytes and a string which I2C WRITE doesn't accept. Edited 2026-04-15 11:04 by phil99
DigitalDreams Regular Member Joined: 03/05/2025 Location: United KingdomPosts: 62
Posted: 06:07pm 15 Apr 2026
Copy link to clipboard
Print this post
Done, created a 4byte string by concatenation of the 2 individual FRAM address bytes (INT8) and the 16bit signed integer data (INT16) into one string for a single I2C2 string write (adding three Bin2Str$ together).
Reading back was much simpler as the I2C read is preceeded by an I2C write that simply sets the FRAM address of the two data bytes that are then I2C read into a string in Str2Bin format.
Don't think there's a more efficient/faster way at the moment unless Peter adds the ability into I2C2write 😎... Edited 2026-04-16 05:58 by DigitalDreams
PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1835
Posted: 08:37pm 15 Apr 2026
Copy link to clipboard
Print this post
I find the To be a bit offensive Is it required?
Furthermore, I believe that in the manual, there's a paragraph that suggests the maximum speed is still 400KHz whereas elsewhere, it has been updated to 1000KHz.
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 3131
Posted: 09:35pm 15 Apr 2026
Copy link to clipboard
Print this post
Not if you are doing a single write. If writing to more than 1 32 byte page you get a garbled mess if you don't space the writes out. It doesn't have to be a pause, you could do the writes triggered by a timer or in a tick sub.
bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 232
Posted: 10:16pm 15 Apr 2026
Copy link to clipboard
Print this post
I just looked at the datasheet for the Microchip 24LC512 and it says the following:
I assume this behavior is common to many I2C EEPROMs?
This would mean that as long as the write cycle is still ongoing, a read command (to any address, or more precisely, to the LastWriteAddress + 1) will not be acknowledged, and this behavior can be interpreted as "busy"!
This way, a fixed (and unnecessarily long) delay could be avoided.