Wire Library and how it sets the slave address

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been working with a simple i2c library (Peter Fleury). I added the following method to simply check if an address is valid on the bus.

 

uint8_t i2cScan(uint8_t address)
{
	// reset TWI control register
	TWCR = 0;
	// transmit START condition
	TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);
	// wait for end of transmission
	while( !(TWCR & (1<<TWINT)) );
	
	// load slave address into data register
	TWDR = address;
	// start transmission of address
	TWCR = (1<<TWINT) | (1<<TWEN);
	// wait for end of transmission
	while( !(TWCR & (1<<TWINT)) );
	
	// check if the device has acknowledged the READ / WRITE mode
	uint8_t twst = TW_STATUS & 0xF8;
	if (twst != TW_MT_SLA_ACK)  return 1;
	
	return 0;
}

I am testing with a MCP23017 i2c expanded. I have configured the address (A0, A1 and A2) to 000 (e.g all tied to ground). This when scanned is address 0x40. Only the 3 LSB are applicable. Using the library I linked below, the address is correct and I can communicate on address 0x40 B‭0010 0000‬.

 

Here is my question. Using the Arduino library, I can scan with this sketch.

 

I get an address of 0x20. B‭0100 0000‬. As you can see the 5 & 6 bit differs. So using 0x40 with the Wire Library does not work but with the Peter Fleury library it does and visa versa. I plan on digging into the Wire library to see why, but I was wondering if someone knows why these 2 libraries interpret the address differently.

 

"When all else fails, read the directions"

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

The Wire library uses 7-bit Slave addresses.  e.g. 0x50 for a 24Cxxx

The TWI peripheral uses 8-bit Slave addresses.  e.g. 0xA0 for 24Cxxx (write), 0xA1 for (read)

The Fleury library uses 8-bit addresses.

 

There are respected I2C libraries.    Use them.    Your scanner function can return the GOOD or BAD status from i2c_start().

In your (untested) code:

	// load slave address into data register
	TWDR = (address << 1);    //if you use 7-bit addresses

David.

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

david.prentice wrote:
There are respected I2C libraries. Use them.

Thank you David - Any suggestion on a respected library?

"When all else fails, read the directions"

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

Fleury library is respected.
Wire library is respected. In fact, I am pretty certain that it was derived from Fleury.
.
As I said earlier, the two libraries use different conventions i.e. 8-bit and 7-bit.
.
David.

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

Hello,

 Allow me to put my two cents worth in here.  

 

 If you are using the Arduino, stick with the Wire library.   It works, it is documented, it is as straight-forward and easy-to-understand as I2C (Two Wire) is going to get, and everybody in ArduinoLand uses it.   Arduino was designed to be an easy-to-use standard for beginners and people who want to integrate a microcontroller in a semi-custom project without many hours of technical study and code re-writing.  It succeeds at this rather well.  That doesn't mean that this library is deficient or inflexible. 

 

 Two-Wire interface is a complicated subject.  I've been reading and studying it for years and am just about at the point where I feel comfortable with it.  The commands for the Wire library for Arduino look different from all the other I2C libraries, but it works well.  And it works well across all the AVR and ARM devices that use the Arduino software format, both now and in the future.   It works with entire I2C transmissions and messages, instead of individual bytes, addresses, and START/STOP/ACK/NACK conditions.

 

So read and study the various I2C libraries, including the Wire lib source code, to understand how this linkage works.  Then stick with the Arduino standard. 

 

A lot of embedded-systems programmers giving advice seem to be stuck in the 20th-century where code was written to the component part level.  In the 21 century, applications are developed by putting together pre-written code modules like LEGO blocks.  This significantly increases the productivity of the programmer.  But it only works when using tested and debugged standard code modules.   Any library like PeterFleury's I2C isn't going to be as easy to use or maintainable as an Arduino standard code module simply because these libraries have to be reviewed before use in order to see if and how it fits in an application, and how it is different from the Arduino standard library that everyone now learns to program with.

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

Simonetta wrote:
If you are using the Arduino, stick with the Wire library. It works, it is documented, it is as straight-forward and easy-to-understand as I2C (Two Wire) is going to get, and everybody in ArduinoLand uses it. Arduino was designed to be an easy-to-use standard for beginners and people who want to integrate a microcontroller in a semi-custom project without many hours of technical study and code re-writing. It succeeds at this rather well. That doesn't mean that this library is deficient or inflexible.

 

Thanks for the input. For me, I want to see whats under-the-hood. To do that, I like to read and create the library from scratch. I seem to learn more that way. Not to mention, I enjoy the heck out of it. There are libraries that are very complicated, and I just use it. I may go back months later and see how it works.

 

IMO, the Arduino library is very good, but hides whats really going on. This is fine I guess for most Arduino users, but I have no problem spending hours or days figuring out how it all works. I recently have been working on my own NRF24L01+ library. Not because I think I can do a better job (I dont think I could), but because I want to learn how it works. To do that, I may read and use other libraries and assemble my own. Also, the Arduino comes with some overhead. e.g digitalWrite(), needs to look up the pin, the port and register every time its called. This is ok if I want to blink an LED, but what about a TFT when I need to send 72k of bytes to display an image?

 

I view the Arduino library as a good tool in my coding tool box. It may or may not work, depending on my project.

 

Perhaps many coders can read others code and know exactly whats going on. For me, it is a bit of a struggle. At least it is when I read c or c++. So researching each line and playing with it helps me understand how it all works. When I struggle, I hit the forum here and the freaks always help out.

 

 

 

 

"When all else fails, read the directions"

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

PhillyNJ wrote:
the Arduino library is very good, but (sic) hides whats really going on

 

What do you mean, "but" - that is the entire point of such a library!

 

PhillyNJ wrote:
I want to see whats under-the-hood

In that case, you should start by understanding the I2C protocol itself - as that is what the library is trying to implement.

 

I2C was defined by Philips (now NXP),  and NXP continue to publish & maintain the standard.

It is available for free:

 

UM10204 - 2C-bus specification and user manual

http://www.nxp.com/documents/use... - currently Rev. 6 — 4 April 2014

 

The discrepancy between talking of I2C addresses as 7 or 8 bits is very common indeed in software, tutorials, articles, and device datasheets.

 

But, the specification is quite clear:

 

UM10204 - 2C-bus specification and user manual, wrote:

3.1.10 The slave address and R/W bit
Data transfers follow the format shown in Figure 9. After the START condition (S), a slave
address is sent. This address is seven bits long followed by an eighth bit which is a data
direction bit (R/W)

So you can see where the confusion arises: the actual address itself is only 7 bits,  but it is always used in conjunction with the R/W bit - which makes an inseparable 8-bit unit.

 

And, of course, most microcontrollers & programming languages are better at working with 8-bit units than 7-bits.

 

In other words, the people who speak of 8-bit I2C addresses are really talking about the address plus the R/W bit.

 

Note that I2C also supports 10-bit addresses - and that's also 10 bits plus the R/W bit

 

3.1.11 10-bit addressing
10-bit addressing expands the number of possible addresses. Devices with 7-bit and
10-bit addresses can be connected to the same I2C-bus, and both 7-bit and 10-bit
addressing can be used in all bus speed modes. Currently, 10-bit addressing is not being
widely used.

 

#I2Caddress #I2CaddressConfusion

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Feb 28, 2018 - 10:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
 that is the entire point of such a library!

 

Just seen this in another thread which puts it very nicely:

 

clawson wrote:
The point ... is that it doesn't really matter how any of them are actually implemented internally as long as they provide you the documented API. Just use them,  don't stare too deeply INTO them! 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Just use them, don't stare too deeply INTO them!

 

So how do you learn then ?

"When all else fails, read the directions"

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

You learn by following Andy's and Johan's advice.
.
Get your project working with proven and certified components using conventional techniques.
Much like your house must be built according to Building Regulations at every stage.
Or a bridge should use quality steel and certified bolts.
.
Yes, you might think it onerous. Yes, you might have some clever ideas to make things cheaper or faster.
You have to understand the existing Building Regs before you can argue your case.
.
In practice you learn best by doing the job properly first. e.g. an apprenticeship
Then replacing one round wheel at a time. Introducing your own square modifications.
.
I2C is incredibly simple. It is a perfect subject for you to "develop your own implementation".
Test it against the proven versions.
Rinse and repeat until satisfied.
.
David.

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

Yes.

 

1. Get something working with proven code. Now you have verified that both hardware and software is correct (incl e.g. that you are running at the clock frequency you think you are.) Save this software setup. Document this hardware setup (notes, photyos, whatever...).

 

2. Start tinkering. Either by changing the working code from step 1, or by writing your own. Whenever in doubt you've e.g. broken the hardware, roll back to what you had in step 1 and verify everything is in order.

 

If you just want to get s complete project working, go with proven code and "libraries".

 

If you're taking the clock apart to se how it's working, then by all means tinker away. I would suggest reading other peoples code. It has long been a meme that you learn to code good by reading good code. I would argue that 99% of the time someone says "I learn better by writing own code, not looking at others etc" it is b*llsh*t. Learning how to learn things is the first step. Sit down, nice cup of tea, lots of paper and pencil and a good eraser. When you see code and think "why is it coded this way?" the fun begins.

 

Stepwise refinement rules.

 

Seasoned software writers clone working code and slowly nudge it into what they need. This is done on a daily basis. Seldom, code is written from scratch.

 

Code is read 10  times as often as it is written. It is not embarrassing or a sign of lacking abilities to study someone else's code.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

PhillyNJ wrote:
IMO, the Arduino library is very good, but hides whats really going on.

But nothing in Arduino (well not the library code anyway) is really "hidden". You can study:

/windows/Program Files/arduino-1.6.3/hardware/arduino/avr/libraries/Wire$ tree
.
├── examples
│   ├── digital_potentiometer
│   │   └── digital_potentiometer.ino
│   ├── master_reader
│   │   └── master_reader.ino
│   ├── master_writer
│   │   └── master_writer.ino
│   ├── SFRRanger_reader
│   │   └── SFRRanger_reader.ino
│   ├── slave_receiver
│   │   └── slave_receiver.ino
│   └── slave_sender
│       └── slave_sender.ino
├── keywords.txt
├── library.properties
├── utility
│   ├── twi.c
│   └── twi.h
├── Wire.cpp
└── Wire.h

in particular the Wire.cpp that is there although it just seems to be a C++ "wrapper" on top of a twi.c/twi.h C code in the utility subdirectory. The whole thing seems to be mainly based on a state machine in TWI ISR.

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

PhillyNJ wrote:

awneil wrote:

Just use them, don't stare too deeply INTO them!

 

Actually, clawson wrote that - I just quoted it!

 

Quote:
So how do you learn then ?

 

Did you see the bit about studying the I2C documentation?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read a lot. Write a lot. In that order.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I believe you all are missing my point except for joeymorin:

 

joeymorin wrote:
Read a lot. Write a lot. In that order.

 

Which I do and love it.

 

Perhaps its hard for me to explain what I mean in a forum post.

"When all else fails, read the directions"

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

JohanEkdahl wrote:
Code is read 10  times as often as it is written.

You may want to consider increasing that a few orders of magnitude (particularly for "good" code) smiley

David (aka frog_jr)

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

frog_jr wrote:

JohanEkdahl wrote:
Code is read 10  times as often as it is written.

You may want to consider increasing that a few orders of magnitude (particularly for "good" code) smiley

+1.0E+4

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

JohanEkdahl wrote:
I would suggest reading other peoples code. It has long been a meme that you learn to code good by reading good code. I would argue that 99% of the time someone says "I learn better by writing own code, not looking at others etc" it is b*llsh*t.

By that very logic, if I studied the 50 greatest painters production in detail, I could then grab a brush and start painting like a boss; but it does not work that way. Because unless I've tried before drawing this curve, rendering this color, hinting at this sentiment, and failed (or at least struggled with it), I don't even know what to look for. I'm just missing 90% of the knowledge and expertise that is displayed before me.

Programming works the same (everything works the same, actually). You cannot possibly understand why this line of code is so clever until you've tried to do it differently and felt the burn.

It's quite easy to read some code and feel you get it. And then you change a couple things to fit your use-case and the whole thing goes to shit. Because what you understood only was a tiny bit of what was put into it. And you won't feel the depth of that fracture until you start messing with it. Reading good code (alone) is a very good way to feel smarter and a better expert than you actually are. :-]

 

Don't get me wrong: reading good code is a good thing; We should do it more. There's always something to learn from the masters. But there's a reason if we all instinctively rather write poor code than read good one. It's not because we're positively counter-productive, it's because we intuitively know reading can only get us so far. That's why teachers won't jus throw theory at you, but will ask for exercises and projects. That's also why experts often step into unknown territory by taking some working code, modifying it a bit, see how it goes, face a bug, fix it, and so on.

All in all, knowledge and expertise are very Darwinist: 99% of what we do is just uninspired modification of previous work. And most of it is worth shit, to be honest. And sometimes, some stuff luckily happens to be worth something; And your line of code will be reused and your commit will last. How many of us have actually produced such a piece of code? Who here has produced a library that can be considered standard? Most of the times you're just doing shit, but it's your shit, and for that reason alone it smells better than anyone else's. Not because it's a really beautiful turd, but because it's the unavoidable step to your next meal. It feels good because it was a practical step towards further mastery.

ɴᴇᴛɪᴢᴇᴎ

Last Edited: Wed. May 4, 2016 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When interfacing with TFTs the libraries that I have reviewed use macros to toggle Port pins quickly.  The macros also use dereferenced pointers to put new values into the AVR's peripheral-control registers. 

 

  I believe that this is what using deref ptr macros is doing on the assembler level:

-  load one of the register-pairs (example: X) with the address of the periph-control register (which are located at the beginning of the AVR SRAM).

-  load a temp register indirectly with periph-cntrl reg's  current value:  LD temp, X.

-  adjust that value by setting or clearing a bit.

-  write back the temp register (with the adjusted value) using indirect addressing: ST X, temp.

 

The biggest slow-down factor in the Adafruit TFT libraries is their use of the Nokia5510 font set, in which each character has five bytes of seven active pixel bits per byte.  Adafruit TFT then sets the TFT display-RAM buffer to a working frame that is one pixel in size, and writes the pixel from the font into the one-pixel sized address block using pre-selected foreground and background colors.  Most TFTs will then advance the display-RAM pointer to the next pixel address. You could set the display block to six pixels across and eight down and send 48 pixels sequencially to make the char.   As opposed to writing a 1x1 frame size and then writing a 16-bit pixel color to this 1x1 frame.  Doing that would at least double the speed of the Adafruit TFT text display routines.  

 

Be sure to check out all the "Idiot's Guide to C++" books that are on the shelves of the public library.  They have lots of background not apparent from reading/studying mostly working code.

Last Edited: Wed. May 4, 2016 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, that was even further from the original post than my previous comment. :)

Are you sure you did not answer to the wrong thread?

ɴᴇᴛɪᴢᴇᴎ

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

Of course you need to try things yourself. My point was to criticize the ones going "I don't want to look at other peoples code - I learn by doing everything myself". Extrapolating that, one should not read the data sheet or e.g. K&Rs book..

Yes you meet to tinker yourself. My analogy re this is learning to bike. You can't learn that by simply looking at other people riding bikes.

BUT by observing other bike riders you will learn that the pattern is to have your arse on the saddle and your hands on the handles. Not the other way around.

To bring my argument home: We see a lot of arses on handlebars around here. When we say "why not look at how others do riding bikes" the answer is "no, I don't learn that way". Personally I suspect that for a lot of those it's just about not being willing to spend the time and have the patience and stamina reading and thinking...

On a meta level, they should also ponder if they need to learn how to learn stuff. That's an art of its own.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. May 5, 2016 - 07:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, the OP does not seems to fit the arse-on-handlebar condition here: he wrote additional functions for a respected library and is now trying to replace other parts with his own code. That looks OK to me.

On the other hand, I often see answers like "why don't you use a car instead? It's faster and you don't need to balance". Which is all very true (and worth mentioning once) but won't help anyone handle his bike any better. :-)

 

JohanEkdahl wrote:
On a meta level, they should also ponder if they need to learn how to learn stuff. That's an art of its own.

Agreed. And the most important one according to me.

ɴᴇᴛɪᴢᴇᴎ

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

Yes but most of the "use a car" suggestions are because someone has said "I'm planning to ride my bike from New York to LA - do you think I'll make it in 2 days?". In such circumstance I think it's quite valid to suggest "did you ever think of using a car instead?" cheeky

Last Edited: Thu. May 5, 2016 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ is not a bike rider.
.
We do differ in our views.
l would start from a proven design and work backwards. Replacing one module at a time, testing against the proven design.
He wants to start from the bottom and work up. Quite possible but unlikely to be very effective.
.
I was shown how to use methods by my Maths teacher. We would do plenty of exercises using a particular method until we thoroughly understood it. With experience, you can answer familiar problems under examination conditions.
.
PhillyNJ wants to learn Maths by inventing everything himself i.e. without a Maths Teacher or even a text book.
Obviously this worked fine for Newton, Maxwell, Einstein, ...
.
I am not in that league. I doubt if anyone can imagine learning Maths without a Teacher.
.
IMHO, reading a library source code is like your Maths Teacher showing you a method. You still have to understand the method. You still have to do some exercises before you can re-use the method blindfolded.
In practice, most people use certified tools and proven methods with access to information books or internet.
I would agree that these might not be available on a desert island.
.
David.

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

Johan Ekdahl wrote:

    We see a lot of arses on handlebars around here.

I have no choice but to immortalise that.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

david.prentice wrote:
PhillyNJ wants to learn Maths by inventing everything himself i.e. without a Maths Teacher or even a text book.

OMG no! smiley That was not what I meant or tried to do! As I said earlier, perhaps I failed to explain my intentions. I have no intention on inventing anything my self. I want to learn what was invented, I want to learn how to read a datasheet and get something working.

 

I have several books on programing, AVR and electronics which I read and reference all the time. This is not my full time job, its a hobby that I do in my spare time. I do most of my studying on AVR during the weekends and evening after the family goes to bed.

 

The fact is I do look at others code and its (for me) probably the best way to learn. In my OP, I was asking about the difference between 2 libraries. They both were able to accomplish the same goal but in different ways. What I don't like is when someone says, "don't worry about how it works, just use it". That doesn't help me. If I am implementing an I2C in to my project, I would like to know what its actually doing. Is there harm in that?

 

david.prentice wrote:
IMHO, reading a library source code is like your Maths Teacher showing you a method. You still have to understand the method. You still have to do some exercises before you can re-use the method blindfolded. In practice, most people use certified tools and proven methods with access to information books or internet.

 

I thought I was doing that...

 

In the end, it looks like I hit on a nerve, which seems to be healthy in this case.

 

 

 

"When all else fails, read the directions"

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

Go on. I replied in message #2. Accurately and concisely.
.
Both Johan and I suggested a top-down and tinker approach. I would recommend using Fleury first. Study it. Ask questions about it.
Yes, it is a hobby for me too. What I learned from Fleury was "choose a convenient API". Then everything falls into place.
If you sit down with either Fleury or the TWI chapter on paper, you can compare implementation with datasheet.
.
If your study struggles, ask. The polled I2C should be easy to follow.
.
It is a lot harder to use or understand the Atmel Interrupt app notes. Or the Wire library.
.
I do not want to give offence. I simply disagree with the "start from datasheet" approach. Every week, we see home-grown VOID functions. If you start with a sensible set of "thought about" functions, it is simple to write for AVR, Renesas, ARM, ...
.
David.

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

david.prentice wrote:
I do not want to give offence. I simply disagree with the "start from datasheet" approach. Every week, we see home-grown VOID functions. If you start with a sensible set of "thought about" functions, it is simple to write for AVR, Renesas, ARM, ... .

 

No worries. One day I would love to site down and have a pint and pick your brain. You advise is well received. As always, thanks for the help and guidance.

"When all else fails, read the directions"

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

joeymorin wrote:

Johan Ekdahl wrote:

    We see a lot of arses on handlebars around here.

I have no choice but to immortalise that.

I've seen my lot of kids struggling with learning how to ride a bike, but in absolutely none of those cases trouble was because they sat on the handle bar. But hey, if you guys are happy with that analogy…

 

PhillyNJ wrote:

david.prentice wrote:

PhillyNJ wants to learn Maths by inventing everything himself i.e. without a Maths Teacher or even a text book.

 

OMG no! smiley That was not what I meant or tried to do! As I said earlier, perhaps I failed to explain my intentions.

FWIW, I thought you made your point very clearly from the start. As far as I'm concerned, your arse was on the saddle all along. :-)

 

I hope it's clear my point was not to advise you not to read. But you won't get much out of it unless you conceive very clearly the problem at hand. And to get that kind of knowledge, you need to climb the mountain yourself. You know it: that's why you feel the need to code it again, starting from scratch — or so.

Being able to follow a working solution is not understanding it: understanding it would mean knowing why every alternative would not work (or not as well). The most fruitful reading you can do therefore is after you coded something similar yourself: same lines of code, but you're able to get infinitely more out of them. In fact you're not only following what is written, you're now also able to criticize it (or your own implementation for that matter).

 

Not long ago I had a discussion with theusch about a concept he's very familiar with and has been using for decades (ring buffers). The amount of reading necessary was very small (a couple one-liners), yet he missed the point for several days. To be fair, I don't mean to pick on theusch, in fact my point is precisely the opposite: it could have been any of us. Think about it: if an expert can miss a point you're explicitly pointing to in a couple one-liners about a topic he's very familiar with, what will a beginner get out of reading a whole lib about (say) a protocol he's unfamiliar with? Bits here and there, probably, but surely not the kind of knowledge he'd get by implementing it himself…

So, my advice would be: if you're really willing to learn and can spare the time, by all means implement it yourself from scratch. If you're a bit tight on time, do what you've done: start with a working implementation and replace parts of it with your own code. And if you're working (with unrealistic deadlines of course), grab a pseudo-standard implementation and don't even look into it. ;-)

Just my two cents…

ɴᴇᴛɪᴢᴇᴎ

Last Edited: Sat. May 7, 2016 - 01:10 AM