Porting from Atmega128 to Atmega32, RTC and EEPROM

I need to use RTC DS1307 and EEPROM 24C256.
I tried to use RTC DS1307 using inputs from resources at https://www.dharmanitech.com
From this and similar resources I could successfully test RTC DS1307 and EEPROM 24C64 (so I hope 24C256 will not be much different.
My difficulty is that I am unable to combine both in one. Following link uses both in one but uses Atmega128. All details are available at the link but I dont (rather can not) use Atmega128 and want to implement it on Atmega32.
I am done if I cam port the atmega128 programs to atmega32 OR
I could combine the two in one, I2C combining both in one should be possible as I understand but I dont know how to implement it.

https://www.dharmanitech.com/search/label/serial%20EEPROM

Any suggestion or link to knowledge base and resource will be very much appreciated. I learnt a lot from this forum and now I am able to use C instead of assembly, life is easy in C but finer details become less important unless one is stuck up !!

Porting or migrating from atmega128 to atmega32 is not yet resolved, however it is clear that the I2C bus can handle more than one device at a time. Therefore RTC DS1307 and EEPROM 24C256 can be connected to the same bus of Atmega32 as their addresses are different.
Now the issue of Porting or migrating is not important. I will implement the two I2C parts on Atmega32 and see if it works alright. This will solve one of my problems.

You are right about EEPROM and RTC ICs, they can connect to the same I2C bus.
About migrating from ATmega128 to ATmega32, it is not such a hard task if you write in C. All AVR low level routines (ADC, timers etc) run on all AVRs. Watchdog and EEPROM registers may have slightly differrent names, maybe status register as well.

Yes, the resources that are not common to Atmega32 and Atmega128 pose difficulty of modifying the routines and at times the approach itself. Thanks for the help.

ark5230 said:

Yes, the resources that are not common to Atmega32 and Atmega128 pose difficulty of modifying the routines and at times the approach itself. Thanks for the help.

Click to expand...

Which resources are you referring to? Your code is in assembly? If not then the migration should be a quick task. You will have to change the port defines and you should be ready to move on. As for watchdog or EEPROM registers, the compiler will throw an error for those. You can enter the datasheet to see the correct names, then replace them in the code and move on. Just keep in mind to include the specific MCU's header file and not the general AVR file, I don't know what will happen in such a case, maybe nothing if those registers reside in the same address for both MCUs.

Regards,
Alexandros

Yes, in the definition part there are registers and I noticed some difference in the USART registers, I will figure those out and try to make it work, in the event of a problem I will specifically post that point so that the question becomes straight forward. I will have to do some homework before I post the actual problem.
The code I am trying to implement on Atmega 32 is at the link below.
https://www.dharmanitech.com/search/label/ATmega128
Zip file containing the code is also attached, if any body can make a comment it will be of great help.
Thanks and Regards
The zipped stuff complies properly without issues using AVR Studio4. If the MCU is changed to Atmega128 the Register definitions as pointed out in above post are needed !! I try this and see if I can make it work

Yes, in the definition part there are registers and I noticed some difference in the USART registers

Click to expand...

Yes, this is what I was talking about. ATmega128 has two UARTs, 0 and 1. On the other hand ATmega32 has only one. "USCRA" register in ATmega32 becomes "USCR0A" and "UCSR1A" for UART0 and UART1 respectively in ATmega128. In the same manner, UBRRH becomes UBRR0H and UBRR1H, in order to be applied for both ATmega128 UARTs, and so on for the rest of UART's registers.

If the MCU is changed to Atmega128 the Register definitions as pointed out in above post are needed !!

Click to expand...

After a quick look into the source files you posted, I think that except UART registers, all others will be the same. As for port defines, the posted schematic's circuit doesn't use any GPIOs (LEDs, buttons, relays etc). So no need to worry about that one.

True, I found that the UART Routines both .c and .h files are changed (as they are different for Atmega 128 and Atmega32) after doing this I am getting two warning messages regarding the data types I am not able to locate where from these originate (exactly what part needs correction or change). The warnings are attached as part of snapshot and the whole code folder is also attached as zip file. If one gets time and looks at it, it may be resolved, as I am new to Embedded C I am not able to figure it out.

You get this warning because transmitString() takes as argument a pointer to an unsigned char:

void transmitString(unsigned char* string)

But time and date variables which are to be passed as arguments, are declared as char. If you declare them as unsigned char the warnings will be lost.

However, those warnings are not MCU dependent, they would be there even with an ATmega128.

Atmega128 programs compile without Error or Warnings, may be it is because they use different header files and declarations. The change you suggested is expected to do the job. I check and implement it just now.
I checked it by correcting the two declarations as unsigned char and it compiles without any errors or warnings.
I have connected almost all the hardware and check it once and download the Hex code and see the working.
Thanks so much for kind help.
ARK