I use PlatformIO and an Atmege 328P. In the code I have a simple save operation that should write an area in memory with the value one. This works so far, but the value is entered twice. I suspect that I am doing something wrong with the addressing, do you have an approach for me?
After I have transferred the code, I read the EEPROM with an STK500 via Microchip Studio, which shows the entries twice. Noticeably shifted by 512 addresses?
I haven't an answer to your issue, but take the note...
The code below has a great chance to ruin an EEPROM in very short time, because you write the EEPROM unconditionally in endless loop.
Thanks for the hint, you are right. Fortunately, I only created the code briefly to show you the problem separately from my program, where it is only run once initially. For the result I only had voltage on the chip for a short time.
I am confused to read the above line when my understanding is this that a byte-type (8-bit) data is written into an int-type (address) memory location. In the above line, i (second argument of write() method) is an int-type (16-bit) data item.
Your confusion is not sufficient reason to hijack this thread, @GolamMostafa. Read the documentation for Arduino's EEPROM.write fn, which clearly states a single byte will be written. Even in their example, they may pass an int, but a byte gets written: https://docs.arduino.cc/learn/built-in-libraries/eeprom/
I disagree and don't see that as an hijacking. I think it's a fair question given it's not obvious what happens as the doc states
value: the value to write, from 0 to 255 (byte)
and I'm not using a byte but an int type. Good opportunity to discuss promotions.
I think we had a recent discussion where I explained about implicit promotions (the float being truncated into an integer). Here it's the same thing, the write() function expects a byte so C++ will apply an int to byte implicit conversion which basically takes the least significant byte of the variable as is (bit for bit) and that's what makes it to the write() function. as my index does not go over 255 nor goes negative, it's the exact index value that gets written in EEPROM
address: the location to write to, starting from 0 (int)
value: the value to write, from 0 to 255 (byte)
I tend to take it at face value; I don't hand it an int and expect an int to be written. It's going to write a byte. Whether you give it an int, or a double, it's going to write a byte.
Want to write something other than a byte, explore EEPROM.put(). But beware, there are still limitations.
Meh. More off-topic wander. The OP is asking us why two different location blocks are being written, and we've wandered off on a discussion of whether a byte is really a byte. I'm out.
don't you think it's a fair question for newbie/non C++ experts to ask by which magical trick an int a float or a double would become a byte to be written? because indeed I'm not (and there example is not either) following their own specification.
I changed it a bit and saved a number and then had the entire memory output, with the result that everything is displayed correctly, all entries except for the first area are blank
Start
1
255
255
.
.
.
.
255
255
but reading the EEPROM via Microchip Studio/STK500 still shows a duplicate entry. It seems to be due to a setting of the tool ?
that's what I did now and it all seems to work correctly, it's just that I didn't use a ready-made board with all possible interfaces already built in, but a custom design. That's why I didn't have an I2C to USB or other interface to test my code, hence the way I read out the memory, which I could easily read out via the ISP interface and stumbled across the error. Now I have returned the values via the I2C and a serial to USB converter, so it is probably due to the Microchip Studio. I have not yet been able to find any options for setting the memory size, for example.