Access I2C EEPROM (was Reading value from AtMega328P pin)

Go To Last Post
84 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to read the value present on a pin of my AtMega328P.

 

I'm doing it by:


#define PIN_TO_READ PINB.1
/*..
**..code
**..more code
**/

DDRB &= ~(1 << PB1); //set input mode on this pin
PORTB &= ~(1 << PB1);//not sure if I need to do this
val = PINT_TO_READ;

//set PB1 pin back to output mode
DDRB |= (1 << PB1);

But the compiler says:

 

error: expected ‘;’ before numeric constant
#define PIN_TO_READ PINB.1
                         ^
                         |

How can I do this?

 

Last Edited: Wed. Nov 2, 2016 - 12:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include <avr/io.h>

int main()
{
	DDRD |= (1<<PD7);
	DDRC &=~ (1<<PC0);

	while(1)
	{
		if(PINC & (1<<PC0))
		{
			PORTD |= (1<<PD7);
		}
		else

		PORTD &=~ (1<<PD7);
	}
 return 0;
}

You may try this.

শূন্য  - The ZeRo

Last Edited: Sun. Oct 30, 2016 - 02:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eRony wrote:

#include <avr/io.h>

int main()
{
	DDRD |= (1<<PD7);
	DDRC &=~ (1<<PC0);

	while(1)
	{
		if(PINC & (1<<PC0))
		{
			PORTD |= (1<<PD7);
		}
		else

		PORTD &=~ (1<<PD7);
	}
 return 0;
}

You may try this.

 

I need to save the value of PB1 somewhere! Where in your code are you saving the value?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before this turns into another 70+ post count over a seemingly simple function can you explain what it is you want to do and why you need to save the value of a single pin?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Before this turns into another 70+ post count over a seemingly simple function can you explain what it is you want to do and why you need to save the value of a single pin? Jim

 

jgmdesign, I'm sorry to ask, but is there any problem with threads with a lot of posts???

 

I'm just trying to learn. If it takes over 70 posts and it is not allowed, then, I'm sorry... I'll stop asking questions here!

 

And probably is your question that is going to turn this thread is a huge thread, but sure, I can tell you why I'm reading and storing a single pin's value!

 

I'm trying to write my own version of software to interface external memory ICs with AtMega328P... And yes, I already took a look into Peter Fluery's I2C libraries and I don't know how to use them. They have too many variables that I just don't know! All those TWxxxxxx macros that I cannot find any reference to what they are. So I decided to try to make my own version of the software.

 

The reason I want to store a pin's value is to check the ACK state aka acknowledge bit!

Last Edited: Sun. Oct 30, 2016 - 03:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about your spelling mistake?

 

Is it 'PIN_TO_READ' or 'PINT_TO_READ'?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing wrong with asking questions but the proper way to start a thread is to explain what you are trying to achieve and why you need to do certain things.

I don't care If the thread goes 70 posts or more. But please provide all the pertinent information up front. Not fragments of information here and there like in your LCD thread. That's all.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read the bit manipulation 101 thread in the tutorial forum. Report back if there's anything you don't understand .  As you'll read there you read the state of PB1 with something like:

 

if (PINB & (1 << PB1) )  {. . . 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

As you'll read there you read the state of PB1 with something like...

 

Although, without wanting to confuse the OP, he should be aware that some sample code he'll find online might show something like this...

 

#include <io.h>
#include <stdint.h>

#define PIN_TO_READ PINB.1

uint8_t val;

void main(void)
{
	DDRB &= ~(1 << PORTB1); //set input mode on this pin
	PORTB &= ~(1 << PORTB1);//not sure if I need to do this
	val = PIN_TO_READ;

	//set PB1 pin back to output mode
	DDRB |= (1 << PORTB1);
}

 

...which is perfectly valid in Codevision.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include <avr/io.h>

int main()
{
	DDRC &=~ (1<<PC0);
        int pin_status;

	while(1)
	{
		if(PINC & (1<<PC0))
		{
			pin_status = 1
		}
		else
		pin_status = 0;

	}
  return 0;
 }

 

Hope you realize it.

শূন্য  - The ZeRo

Last Edited: Sun. Oct 30, 2016 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

What about your spelling mistake?

 

Is it 'PIN_TO_READ' or 'PINT_TO_READ'?

 

I'm not sure it is a spelling mistake!

PINT suggests to me something like "P integer". I want to read the state of a pin, so "pin to read" doesn't look like a spelling mistake to me! Anyway, my major concern is not my English language skills, as I'm not English native! But I can also understand your reasoning!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
There is nothing wrong with asking questions but the proper way to start a thread is to explain what you are trying to achieve and why you need to do certain things. I don't care If the thread goes 70 posts or more. But please provide all the pertinent information up front. Not fragments of information here and there like in your LCD thread. That's all. Jim

 

Ok jmdesign... You have a point there! The reason why I have not said it all was to try to narrow the replies to strictly what I needed. But I absolutely understand that if you all know my goal, probably we can find an answer faster!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

clawson wrote:

As you'll read there you read the state of PB1 with something like...

 

Although, without wanting to confuse the OP, he should be aware that some sample code he'll find online might show something like this...

 

#include <io.h>
#include <stdint.h>

#define PIN_TO_READ PINB.1

uint8_t val;

void main(void)
{
	DDRB &= ~(1 << PORTB1); //set input mode on this pin
	PORTB &= ~(1 << PORTB1);//not sure if I need to do this
	val = PIN_TO_READ;

	//set PB1 pin back to output mode
	DDRB |= (1 << PORTB1);
}

 

...which is perfectly valid in Codevision.

 

You mean that there is similar code to that piece of code I posted on the Internet?

 

Atmel Toolchain complains about the code that way! Not sure why you're able to compile the code using CodeVision!

Last Edited: Sun. Oct 30, 2016 - 06:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah but he's not using Codevision? Surely that's the point of this thread? He's found some Codevision code and tried to use it in GCC and that's been rejected. That's why I'm advising him about standard code that will work in any compiler (even though that CV syntax is nice if you can use it)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:

You mean that there is similar code to that piece of code I posted on the Internet?

 

I didn't bother to look. I assumed that since you used PINB.1 that you'd found some code online meant for Codevision.

 

 

PsySc0rpi0n wrote:

Not sure why you're able to compile the code using CodeVision!

 

Well I am. The code I posted compiles perfectly in Codevision.

 

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:

I'm not sure it is a spelling mistake!

 

Trust me, it is.

 

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about the OP tell everyo e what IDE you are using to write your code in. Like I said. The more you tell us the better the answers and less back and forth.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And posts the whole code.

 

There's no way the code posted in #1 will compile in any compiler without lots of errors, certainly more than just the one the OP mentioned.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest everyone read the OP's post #5. He does not understand Peter Fleurys TWI library so he wants to write his own library instead.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian, you clearly haven't been party to his interminable thread about LCD? There is no doubt in my mind that he's using avr-gcc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

   What kind of memory are you trying to interface to the ATmega328p?   Parallel EEPROM, parallel Static RAM,  serial EEPROM, or serial SRAM?  Serial EEPROM is the only type that uses the I2C interface.   Serial SRAM uses the SPI interface and the parallel chips will use between ten to twelve in/out lines ( for Data0-Data7, ReadStrobe\, WriteStrobe\, ChipEnable 1 and maybe chip enable 2.)

 

Is this Mega328P part of an Arduino UNO/nano system? if yes then I suggest using the "Audrey" libraries for Wire.h and SPI.h interfacing.  Parallel interfacing is only for when very high speed interfacing is needed (or your company has a stockpile of these types of memory chips).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, everyone, I'm sorry for the lack of information. I always try to stick to what I really needed so that we don't get lost with other details like, if I post the whole code, I know that will rain down lots of questions about my coding method! I'm new to C programming oriented to micro controllers, so there's a lot of habits I don not know and do not understand at a first glance!

 

Now, trying to answer to everyone by order:

 

Brain Fairchild:

You mean that his code is valid in CodeVision?

 

#include <io.h>
#include <stdint.h>

#define PIN_TO_READ PINB.1

uint8_t val;

void main(void)
{
	DDRB &= ~(1 << PORTB1); //set input mode on this pin
	PORTB &= ~(1 << PORTB1);//not sure if I need to do this
	val = PIN_TO_READ;

	//set PB1 pin back to output mode
	DDRB |= (1 << PORTB1);
}

 

If so, lucky you... I can't compile it.

About the typing mistake, I can give whatever name I want to my macros, so PIN_TO_READ is perfectly valid and there was no mistake made by me when I typed the macro's name! And more, that name was just an example! I have no macro with that name in my code!

 

About posting the whole code, this forum is not very reasonable when we use the tags to show the code here! It shows up all in green which is almost the same as paste it to here as plain text! That's why I avoid to post more than a few lines of code here!

But I'll use, for instance, ideone.com site to post code and share the link here!

 

jgmdesign, I don't know if it can be called "my own library". I like more to call it my own version of the code! I just want to create a couple of functions that allows me to read and write bytes from/to an external memory device!

 

clawson, everyone talks about the big thread about LCD. I don't know what is wrong with long threads! Anyway, yes, I'm using Atmel Toolchain, version 3.4, I guess!

 

Ok, I'm going to try to say everything I can remember about what I'm trying to do!

 

As I'm new to external memory devices and to I2C protocol, there are a lot of questions about these two matters! I have already read a bit about I2C protocol and I'm also constantly checking my external memory device datasheet!

 

But as for now I'm using:

 

USB-to-serial converter to communicate with AtMega328P-PU that is siting on a breadboard.

I'm using a 16MHz crystal.

I'm trying to interface the AtMega328P-PU with a Microchip 24LC08B external memory device! This is the datasheet I'm using.

To compile the code I'm using avr-gcc from Atmel Toolcahin.

And tu upload the firmware I'm using avrdude, as usual!

 

This is my code... I know that it will probably won't work, but the code is a work in progress, and fixing the problems will be my way to understand things

https://ideone.com/VErKsX

 

I'm posting the code just to give you guys a context! Of course you're free to pint the code's problems but that is what will make the thread so huge that everybody will talk about it for ages! :p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:
Brain Fairchild: You mean that his code is valid in CodeVision? #include #include #define PIN_TO_READ PINB.1 uint8_t val; void main(void) { DDRB &= ~(1 << PORTB1); //set input mode on this pin PORTB &= ~(1 << PORTB1);//not sure if I need to do this val = PIN_TO_READ; //set PB1 pin back to output mode DDRB |= (1 << PORTB1); } If so, lucky you... I can't compile it.

??? Weren't you asked about toolchain and version earlier?  Why have you chosen not to answer thse queries?

 

Are you using CodeVision or not?

 

If you are using CodeVision, what version?

 

If you are using CodeVision, why "can't compile it"?  If you are getting errors, post them here.  >>After<< telling what version you are using.

 

As discussed above, from your other thread it does NOT appear that you are using CodeVision.

 

I see you have now corrected the typo that you claimed earlier did not exist.

 

I'm starting to get quite confused.  Several respondents have told you the generic (non-tooclchain-dependent) way to read a pin. 

 

PsySc0rpi0n wrote:
PIN_TO_READ is perfectly valid and there was no mistake made by me when I typed the macro's name!

You did NOT type that.  You typed...

 

PsySc0rpi0n wrote:
val = PINT_TO_READ;

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was a typo in your original code. This was pointed out to you, but you seem to argue.

Ok, you want to learn about i2c and talk to a i2c eeprom.

You need to do some reading first, otherwise you'll skip some fundamental things.

1.i2c spec - this is the source of knowlege with i2c.

http://esd.cs.ucr.edu/webres/i2c...

You can safely ignore the stuff with multimaster- as you don't need this for a simple master/slave arrangement.

2. The mega328 datasheet - especially the section on the port pins. Understand the combinations of ddr and port bits.

3. Bit twiddling: https://www.avrfreaks.net/forum/t...

 

Hint: for i2c, it is an open collector bus - thus the devices only actively pull the signals down to 0V, for logic '1', they are pulled to VCC via resistors. So, for your port setup, set the required PORT bits to 0. Then twiddle the required DDR bits to select between output (logic 0) and input (logic 1). This means the logic gets inverted when you send. If you don't get what I said - you need to think some more.

If you read the i2c spec, you'll find there are four primitives you need to implement - start,stop,read a byte and write a byte. If you understand all this, you'll find your code will be near identical to just about anyone else's.

If you follow the above, you'll reach your goal faster without having to create long,boring threads where we've seen the same shite over and over again. I can tell you the last time I wrote a bit-bashed i2c library was in the 80's. Nothing much has changed since then. Well, actually the interwebs came about. In them olden days, we had to solve these things by ourselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

PsySc0rpi0n wrote:
Brain Fairchild: You mean that his code is valid in CodeVision? #include #include #define PIN_TO_READ PINB.1 uint8_t val; void main(void) { DDRB &= ~(1 << PORTB1); //set input mode on this pin PORTB &= ~(1 << PORTB1);//not sure if I need to do this val = PIN_TO_READ; //set PB1 pin back to output mode DDRB |= (1 << PORTB1); } If so, lucky you... I can't compile it.

??? Weren't you asked about toolchain and version earlier?  Why have you chosen not to answer thse queries?

 

Are you using CodeVision or not?

 

If you are using CodeVision, what version?

 

If you are using CodeVision, why "can't compile it"?  If you are getting errors, post them here.  >>After<< telling what version you are using.

 

As discussed above, from your other thread it does NOT appear that you are using CodeVision.

 

I see you have now corrected the typo that you claimed earlier did not exist.

 

I'm starting to get quite confused.  Several respondents have told you the generic (non-tooclchain-dependent) way to read a pin. 

 

PsySc0rpi0n wrote:
PIN_TO_READ is perfectly valid and there was no mistake made by me when I typed the macro's name!

You did NOT type that.  You typed...

 

PsySc0rpi0n wrote:
val = PINT_TO_READ;

 

 

??? Weren't you asked about toolchain and version earlier?  Why have you chosen not to answer thse queries?

I have not chosen to answer or not to answer to any questions... Nobody asked me what toolchain I was using before post #17.

Reply #22 was my 1st reply after being asked to post more info about what were my intentions and what I was using and the code, etc, etc. So, when I was asked, I have answered!

 

Are you using CodeVision or not?

If you are using CodeVision, what version?

If you are using CodeVision, why "can't compile it"?  If you are getting errors, post them here.  >>After<< telling what version you are using.

Where the hell have I ever told I was using CodeVision??? The 1st user ever talked about CodeVision was Brain Fairchild in post #9 and I replied in such way suggesting I was not understanding what he had just said. I think clawson understood me in post #14. There was clearly some confusion about what Brain Fairchild said!

Then I said Atmel toolchain was complaining about the error! This could be a tip to tell everyone I was using avr-gcc and avrdude to manage my code compilation and firmware uploading!

 

As discussed above, from your other thread it does NOT appear that you are using CodeVision.

You have just answered to your own questions! :|

 

I see you have now corrected the typo that you claimed earlier did not exist.

I have just realised what Brain Fairchild meant when he told me about the typo... However I haven't corrected it. It's still there! I didn't realised it earlier because I was thinking that Brain Fairchild was referring himself to the macro name and not the macro in the code! I'm sorry for that!

 

Are you now cleared??? I might be not the best when I start a thread but maybe you should also pay more attention to everyone's posts!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

There was a typo in your original code. This was pointed out to you, but you seem to argue.

Ok, you want to learn about i2c and talk to a i2c eeprom.

You need to do some reading first, otherwise you'll skip some fundamental things.

1.i2c spec - this is the source of knowlege with i2c.

http://esd.cs.ucr.edu/webres/i2c...

You can safely ignore the stuff with multimaster- as you don't need this for a simple master/slave arrangement.

2. The mega328 datasheet - especially the section on the port pins. Understand the combinations of ddr and port bits.

3. Bit twiddling: https://www.avrfreaks.net/forum/t...

 

Hint: for i2c, it is an open collector bus - thus the devices only actively pull the signals down to 0V, for logic '1', they are pulled to VCC via resistors. So, for your port setup, set the required PORT bits to 0. Then twiddle the required DDR bits to select between output (logic 0) and input (logic 1). This means the logic gets inverted when you send. If you don't get what I said - you need to think some more.

If you read the i2c spec, you'll find there are four primitives you need to implement - start,stop,read a byte and write a byte. If you understand all this, you'll find your code will be near identical to just about anyone else's.

If you follow the above, you'll reach your goal faster without having to create long,boring threads where we've seen the same shite over and over again. I can tell you the last time I wrote a bit-bashed i2c library was in the 80's. Nothing much has changed since then. Well, actually the interwebs came about. In them olden days, we had to solve these things by ourselves.

 

Ok, indeed I need to think a bit more... It's still a bit confusing to me that subject of internal pull-ups and tri-state pins, etc!

 

I'll read those links you provided!

I think I have already understood the general concept of I2C protocol... But implementing it can be yet tricky to me! I'm new to this AVR stuff, both hardware and software. No more than 2 months!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rather than writing your own bit bang library, read the datasheet on the Mega 328's TWI interface thats already there and does the work for you?  It's only a few registers.  The interface is rather easy once it's set up properly.

 

PsySc0rpi0n wrote:
Then I said Atmel toolchain was complaining about the error! This could be a tip to tell everyone I was using avr-gcc and avrdude to manage my code compilation and firmware uploading!

Um, I have asked you in your other thread if you were using Atmel Studio and I never got a clear answer there as far as I remember.  Just because you are using avr-gcc can mean that you are using only the compiler.  If you are using Studio then we might suggest using the simulator to run your code as an assistant to you.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Rather than writing your own bit bang library, read the datasheet on the Mega 328's TWI interface thats already there and does the work for you?  It's only a few registers.  The interface is rather easy once it's set up properly.

 

PsySc0rpi0n wrote:
Then I said Atmel toolchain was complaining about the error! This could be a tip to tell everyone I was using avr-gcc and avrdude to manage my code compilation and firmware uploading!

Um, I have asked you in your other thread if you were using Atmel Studio and I never got a clear answer there as far as I remember.  Just because you are using avr-gcc can mean that you are using only the compiler.  If you are using Studio then we might suggest using the simulator to run your code as an assistant to you.

 

Jim

 

Ok, I'll read that documentation but when I saw the files of Peter Fleury's libraries, they looked like a lot to learn! A lot of registers that I couldn't find what they were! I also saw some straight forward codes that looked like simple to me! There were no TWI's registers. Only the SDA and SCL manipulation, the ACK bit check, a loop to send a byte and not much more!

 

About Atmel Studio, I think I already said, more than once that I'm using Linux and that I'm using Atmel Toolchain 3.4 but I'm not sure why, I'm keeping being asked what IDE I'm using. As far as I know, Atmel Studio is not Available for Linux! And when I say Atmel Toolchain, doesn't this explicitly means that I'm using avr-gcc and avrdude to do the job? Or does Atmel Toolchain might also mean Atmel Studio?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:
About Atmel Studio, I think I already said, more than once that I'm using Linux and that I'm using Atmel Toolchain 3.4 but I'm not sure why, I'm keeping being asked what IDE I'm using.
What people have been trying to get to the bottom of is which C compiler you use. Finally you have revealed it is Atmela Toolchain 3.4 in Linux. At least that tells us all it is avr-gcc. What is not entirely clear is which version of avr-gcc it is "3.4" is not a complete version number and, anyway, that is the toolchain version not the compiler version. I imagine if you run "avr-gcc -v" you will see something like 4.8.1 or 4.9.2 or similar.

 

Anyway the reason this whole thread headed off in a Codevision direction is because in the very first post you included:

#define PIN_TO_READ PINB.1

Across all the code development systems for AVR the only C compiler that could possibly support that syntax is Codevision. So anyone scanning the first post of this thread will see Codevision syntax and naturally assume you are using it. Why else would you use Codevision syntax if not using the Codevision compiler? Makes sense doesn't it?

 

The reason no other compiler supports that is that C says that when '.' appears in the middle of symbol name it is introducing the name of a sub-element in a struct or union. The rules of C also say that the symbol names of struct or union members (indeed any smbol name in C) cannot start with a digit. So ".1" is illegal syntax.

 

Now the clever author at HPInfoTech who develops the Codevision compiler (and, admittedly, the authors of C compilers on a few other micros) have said "yeah, it may be considered illegal but it's a very nice way to address the bits of a bye, especially the pins in an IO port." If you read PORTB.5 or PINC.3 you almost immediately think "pin 5 of PORTB or pin3 of PORTC". So it's kind of natural.

 

But in other C compilers the only way to achieve anything close is to insert at least one letter before the digit so things like PORTB.b5 or PINC.pin3 or whatever. More generally (as the 101 thread I directed you to will show), the access to individual bits in PORT and PIN registers tends to be done using "normal" bit access rather than struct/union access. So things like:

PORTB |= (1 << 5);
PORTB &= ~(1 << 3);

if (PINC & (1 << 3)) { ...

That's all the stuff explained in the 101 thread (PLEASE read it!). So your original code here:

#define PIN_TO_READ PINB.1
/*..
**..code
**..more code
**/

val = PINT_TO_READ;

could be done in avr-gcc (or other compilers, even Codevision ;) using:

val = PINB & (1 << 1);

except that would not be quite the same behvaiour because either the bit isn't set so val=0 (same as before) or the bit is set and val=(1<<1) which is the same as val=2. In the Codevision syntax the bit being set would set this to be 1 not 2. You have a couple of ways to achieve that (if it's actually important). Perhaps most obvious:

val = (PINB & (1 << 1)) == (1 << 1);

the bit in the brackets with PINB still gives the answer 2 when the bit is set but then the comparison with (1 << 1) will give a 1/0 answer. So the outcome of this will be 0 if the bit is not set or 1 if it is. Personally I prefer this solution to turn a non-0 into 1:

val = !!(PINB & (1 << 1));

You need to think about that one for a while(!) but, trust me, this will set val to 1 if the bit is set or 0 if it is not.

 

Another approach is this:

typedef struct {
    int b0:1;
    int b1:1;
    int b2:1;
    int b3:1;
    int b4:1;
    int b5:1;
    int b6:1;
    int b7:1;
} bits_t;

#define Pinb (*((volatile bits_t *)&PINB)

...

    val = Pinb.b1;

Again, this is 100% standard C and should work in any C compiler. I'm effectively defining a new name for PINB called Pinb and this casts a bitfield structure interpretation onto the location so Pinb.b3 means "the state of the 3rd bit at location PINB". This is about as close to the Codevision syntax you can get in avr-gcc. A lot of people will think this is too much hassle and will simply use a solution like:

val = !!(PINB & (1 << 1));

Your choice really.

 

BTW "Atmel Toolchain" does NOT imply avrdude as your programming software - Toolchain does not include it. If you are using avrdude you got/installed it from somewhere else.

 

EDIT: corrected some typos. Here's some real code using the typedef...

C:\SysGCC\avr\bin>cat test.c
#include <avr/io.h>

typedef struct {
    int b0:1;
    int b1:1;
    int b2:1;
    int b3:1;
    int b4:1;
    int b5:1;
    int b6:1;
    int b7:1;
} bits_t;

#define Pinb (*(volatile bits_t *)&PINB)

int main(void){
        if (Pinb.b1) {
                PORTC = 0x55;
        }
        while(1){
        }
}

C:\SysGCC\avr\bin>avr-gcc -save-temps -Os -g -mmcu=atmega16 test.c -o test.elf

C:\SysGCC\avr\bin>avr-objdump -S test.elf

              [SNIP!]

0000006c <main>:
} bits_t;

#define Pinb (*(volatile bits_t *)&PINB)

int main(void){
        if (Pinb.b1) {
  6c:   b1 9b           sbis    0x16, 1 ; 22
  6e:   02 c0           rjmp    .+4             ; 0x74 <main+0x8>
                PORTC = 0x55;
  70:   85 e5           ldi     r24, 0x55       ; 85
  72:   85 bb           out     0x15, r24       ; 21
  74:   ff cf           rjmp    .-2             ; 0x74 <main+0x8>

00000076 <_exit>:
  76:   f8 94           cli

00000078 <__stop_program>:
  78:   ff cf           rjmp    .-2             ; 0x78 <__stop_program>

As you can see this code is testing the state of bit 1 in location 0x16 (PINB) to decide whether to skip or not.

Last Edited: Mon. Oct 31, 2016 - 01:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:
Ok, I'll read that documentation but when I saw the files of Peter Fleury's libraries, they looked like a lot to learn! A lot of registers that I couldn't find what they were! I also saw some straight forward codes that looked like simple to me! There were no TWI's registers. Only the SDA and SCL manipulation, the ACK bit check, a loop to send a byte and not much more!

 

You have missed the point of a library to some extent. 

 

In the Mega328 there are six registers associated with the TWI.  The library takes care of the configuration of all of this.  The only thing you need to set in the library is the SCL speed....Traditionally 100khz or 400khz.  This is done in the .c file TWIMASTER.c

 

You will need to INCLUDE i2cmaster.h in your main.c to use the library.  YOu must also define F_CPU as well

 

After that, in your code you would write:

i2c_init();

and this will set the SCL for you as it does the math required.  YOu only have to do this once.

 

After that it's just basic function calls.

i2c_start(addr);

i2c_stop();

i2c_write(byte); 

i2c_readAck();

i2c_readNak();

i2c_start_wait(address);

i2c_rep_start(address);

 

All of these functions are explained in the Online Manual here:

 

http://homepage.hispeed.ch/peter...

 

 

In your case, the eeprom you are using does not have an address.  The A0...An lines on the IC are not connected, but the bits normally used in the control word for address are for bank select.  YOU would still use the library normally, you just need to make sure you address the proper bank when you are reading or writing.

 

Jim

 

 

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PsySc0rpi0n wrote:
All those TWxxxxxx macros that I cannot find any reference to what they are.

I gave in and re-read this entire thread.

 

The TWIxxxx you cannot find any reference to are in the 328P datasheet:

 

 

The full documentation of them is the whole of chapter 26 onwards...

 

 

That chapter makes multiple references to TWAR, TWBR, TWSR and so on. You program the registers and the bits and the block of silicon inside your chip, attached the AVR core will wiggle (and listen) to SDA and SCL at the right moments to do almost all the work of operating I2C (that Atmel call TWI) for you.

 

The Fleury (and other code) is simply taking what is written in a chapter such as chapter 26 here and putting it into C code so you don't need to bother with all the gory details. As Jim says you just call high level functions like i2c_start(), i2c_write() and Mr. Fleury programs TWBR, TWCR and so on appropriately.

 

If  you want to sit down with Peter's code and a copy of chapter 26 you can pull it apart line by line to see why he's doing the things the datasheet has told him to. (if very lucky you might even spot an error - but I doubt it).

 

Or if you have that investigative spirit you could throw away the Fleury code and just sit with a copy of chapter 26 and your C editor and have a crack at trying to provide the same kind of functionality - but you probably need a fairly deep understanding of I2C before you start. That's kind of the point of using pre-written driver code. So you don't have to be an expert on every last detail just to be able to set the RTC or read the temperature sensor or whatever it is. In a very Arudino like way, using driver code like this gives you some trustworthy, prewritten driver code so you can just get on and design your RTC/temp/whatever based device and leave the details of what's really going on with the SDA/SCL wires to someone else to worry about.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I'm willing to give a try to Peter's libraries and test code!

 

What is the '.S'? I'm using a Makefile. Is that a source code file or an header file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

YOU probably will not need the .s file.  Thats for Assembly programming.  Just use the .c and .h files and make sure you specify the SCL frequency AND the F_CPU frequency otherwise you will be very disappointed

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

YOU probably will not need the .s file.  Thats for Assembly programming.  Just use the .c and .h files and make sure you specify the SCL frequency AND the F_CPU frequency otherwise you will be very disappointed

 

Jim

 

Ok... The F_CPU and SCL_CLOCK are already set. I set them to F_CPU 16000000UL and SCL_CLOCK 400000L. But I'm also not sure about the 400KHz. The datasheet says frequencies up to 400KHz max and 100KHz for voltages beloy 2.5V. So is this a choice of ours?

 

Edited;

Don't I also need to change the ports where SDA and SCL lines are connected to in any of the project files?

Last Edited: Mon. Oct 31, 2016 - 07:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No.  THe library will take care of that for you.

 

For now I would run SCL at 100khz this way should something not work clock speed is removed from the list of suspects.  100khz works at all voltages

 

JIm

 

Edit,

I might take the chance at splitting this thread since you are going to work with a TWI library now.  No pin checking needed.

 

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok...

 

Anyway, I might need to change a few more things... My memory device is a 24LC08B device. The code assusmes the usage of a 24C02. Is this irrelevant regarding the memory address that is being used by the default code?

Also, how the code kind of "auto-detects" the pins where I have connected SDA and SCL lines?

 

I have connected a LED to the 19th pin of AtMega. And after I upload the firmware, the LED turns ON permanently. I think this is a bad sign when I look to the main function code that lights ON all LEDs connected to PORTB of the uC, right?

 

Edited;

I'm also not being able to capture any signal on the scope where I have SDA and SCL pins connected! :s

Last Edited: Mon. Oct 31, 2016 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Code assumes NOTHING  That is there for the example code only.

 

I can look for the version I use later today.  I cannot remember if I left it there, or removed it. 

 

 

PsySc0rpi0n wrote:
I have connected a LED to the 19th pin of AtMega. And after I upload the firmware, the LED turns ON permanently. I think this is a bad sign when I look to the main function code that lights ON all LEDs connected to PORTB of the uC, right?

Could be.  DEpends on whats written there.  Post MAIN and lets see.

 

PsySc0rpi0n wrote:
Edited; I'm also not being able to capture any signal on the scope where I have SDA and SCL pins connected! :s

Did you put a 4.7k resistor from each pin to Vcc like you are supposed to?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Code assumes NOTHING  That is there for the example code only.

 

I can look for the version I use later today.  I cannot remember if I left it there, or removed it. 

 

 

PsySc0rpi0n wrote:
I have connected a LED to the 19th pin of AtMega. And after I upload the firmware, the LED turns ON permanently. I think this is a bad sign when I look to the main function code that lights ON all LEDs connected to PORTB of the uC, right?

Could be.  DEpends on whats written there.  Post MAIN and lets see.

 

PsySc0rpi0n wrote:
Edited; I'm also not being able to capture any signal on the scope where I have SDA and SCL pins connected! :s

Did you put a 4.7k resistor from each pin to Vcc like you are supposed to?

 

JIm

 

This is the main code:

#include <avr/io.h>
#include "i2cmaster.h"


#define Dev24C02  0xA2      // device address of EEPROM 24C02, see datasheet


int main(void){
    unsigned char ret;


    DDRB  = 0xff;                              // use all pins on port B for output
    PORTB = 0xff;                              // (active low LED's )

    i2c_init();                                // init I2C interface

    /* write 0x75 to eeprom address 0x05 (Byte Write) */
    ret = i2c_start(Dev24C02+I2C_WRITE);       // set device address and write mode
    if ( ret ){
        /* failed to issue start condition, possibly no device found */
        i2c_stop();
        PORTB=0x00;                            // activate all 8 LED to show error */
    }else{
        /* issuing start condition ok, device accessible */
        i2c_write(0x05);                       // write address = 5
        i2c_write(0x75);                       // ret=0 -> Ok, ret=1 -> no ACK
        i2c_stop();                            // set stop conditon = release bus

        /* write ok, read value back from eeprom address 0x05, wait until
           the device is no longer busy from the previous write operation */
        i2c_start_wait(Dev24C02+I2C_WRITE);     // set device address and write mode
        i2c_write(0x05);                        // write address = 5
        i2c_rep_start(Dev24C02+I2C_READ);       // set device address and read mode
        ret = i2c_readNak();                    // read one byte
        i2c_stop();

        PORTB = ~ret;                           // output byte on the LED's

        /* write 0x70,0x71,072,073 to eeprom address 0x00..0x03 (Page Write),
           wait until the device is no longer busy from the previous write operation */
        i2c_start_wait(Dev24C02+I2C_WRITE);     // set device address and write mode
        i2c_write(0x00);                        // write start address = 0
        i2c_write(0x70);                        // write data to address 0
        i2c_write(0x71);                        //    "    "   "    "    1
        i2c_write(0x72);                        //    "    "   "    "    2
        i2c_write(0x74);                        //    "    "   "    "    3
        i2c_stop();                             // set stop conditon = release bus

        /* write ok, read value back from eeprom address 0..3 (Sequencial Read),
           wait until the device is no longer busy from the previous write operation */
        i2c_start_wait(Dev24C02+I2C_WRITE);      // set device address and write mode
        i2c_write(0x00);                         // write address = 0
        i2c_rep_start(Dev24C02+I2C_READ);        // set device address and read mode
        ret = i2c_readAck();                       // read one byte form address 0
        ret = i2c_readAck();                       //  "    "    "    "     "    1
        ret = i2c_readAck();                       //  "    "    "    "     "    2
        ret = i2c_readNak();                       //  "    "    "    "     "    3
        i2c_stop();                              // set stop condition = release bus

        PORTB = ~ret;                            // output byte on the LED's
    }

    for(;;);
}

 

 

Yes, I have a 4k7 ohm resistors between SDA and Vcc and SCL and Vcc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
YOU probably will not need the .s file. Thats for Assembly programming.

Not entirely true. As the user manual says:

 

http://homepage.hispeed.ch/peter...

This I2c library is implemented as a compact assembler software implementation of the I2C protocol which runs on any AVR (i2cmaster.S) and as a TWI hardware interface for all AVR with built-in TWI hardware (twimaster.c). Since the API for these two implementations is exactly the same, an application can be linked either against the software I2C implementation or the hardware I2C implementation.

So the idea is that if you use a micro that has TWI (basically a "mega") then you use twimaster.c and forget all about the .S file. But if you use some brain dead (and I don't mean just the brain dead ones!) tiny that has no real TWI then you use i2cmaster.S instead of the twimaster.c and it "bit bangs" I2C/TWI on GPIO lines to simulate SDA/SCL.

 

As this is a mega328P one would be using twimaster.c UNLESS you have already tied up those pins for something else and cannot use the real TWI unit in which case bit-bang is the only option.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It might be worth noting that you have no choice of what pins are used when using the hardware TWI - they are fixed. You only get to choose when using software bit-bang.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, clawson...

 

 

Adapt the SCL and SDA port and pin definitions and eventually the delay routine in the module i2cmaster.S to your target when using the software I2C implementation !

But I'm still thinking about the AtMega pins where I should connect the SDA and SCL lines of the external memory IC!

Last Edited: Mon. Oct 31, 2016 - 09:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
It might be worth noting that you have no choice of what pins are used when using the hardware TWI - they are fixed. You only get to choose when using software bit-bang.

 

And what pins are those on the AtMega??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's why we have the datasheet. I could read this for you, but we don't know exactly what device you are using so it would be likely i'd give you wrong information. Just take a few minutes reading the relevant sections of the datasheet and you'll have your answer first hand.

(Edit) actually you did in the title :(
10seconds of googling atmega328 pinout
Tells me pins 27 & 28

Last Edited: Mon. Oct 31, 2016 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
That's why we have the datasheet. I could read this for you, but we don't know exactly what device you are using so it would be likely i'd give you wrong information. Just take a few minutes reading the relevant sections of the datasheet and you'll have your answer first hand.

 

If I'm asking is because I haven't found that information!

And I already said what I'm using, more than once, but I'll say once again:

 

I'm using AtMega328P-PU and a 24LC08B from Microchip!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It amazes me that you can't find fundamental information on one of the most widely used hobbyist microcontrollers known to man. Yes, I did correct my post before you responded.
Since you're using a mega328, all the questions you could possibly have, have been answered already.....a million times. All you need is to Google. Maybe I should write a sticky on "how to Google"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
It amazes me that you can't find fundamental information on one of the most widely used hobbyist microcontrollers known to man. Yes, I did correct my post before you responded. Since you're using a mega328, all the questions you could possibly have, have been answered already.....a million times. All you need is to Google. Maybe I should write a sticky on "how to Google"?

Thanks for replying...

 

I have the extended datasheet opened but in faact this is the first time I noticed that those pins were assigned to SDA ans SCL! :o

Last Edited: Mon. Oct 31, 2016 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so then what have you learned so far?

 

 

How do you have the LED that stays on connected to the port pin? And which port pin?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's on PAGE 1?!? It's not exactly rocket science is it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyway, I need some more info about the code!

 

I see this:

#define Dev24C02  0xA2      // device address of EEPROM 24C02, see datasheet

and this:

ret = i2c_start(Dev24C02+I2C_WRITE);       // set device address and write mode

in the test code... Does these lines of code needs to be changed according to the memory IC I'm using?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you read the datasheet on your memory IC like I did you would know what needs to be done.  In fact I told you how to address the EEPROM in post #30, last sentence.

 

 

Before this goes any further, I think you should post a schematic of how you have everything connected first.  If that's wrong, then all the code in the world is not worth squat diddley.

 

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

If you read the datasheet on your memory IC like I did you would know what needs to be done.  In fact I told you how to address the EEPROM in post #30, last sentence.

 

 

Before this goes any further, I think you should post a schematic of how you have everything connected first.  If that's wrong, then all the code in the world is not worth squat diddley.

 

 

JIm

 

I read your sentence. I'm just not sure what is or what could be "proper bank". I know that my IC has A0, A1 and A2 not connected internally.

I'm reading the datasheet of my IC at page 7.

 

The circuit I have is kind of this:

Pages

Topic locked