can't find i2c-0 GPIO pins any more

[davenull]

I am a simple end-user and beginner to Raspi, no sytem developer or low lever hardware progger or Linux hacker.
Having purchased a Raspi designed for beginners I expect libs to be available which provide convenient C/C++ API libs for offered hardware, and not just for that Python crap.

But as I don't have HATs I simply want to use the very convenient and very handsome wiringPi API libs for C/C++ to i2c-0.
Eventually that would be what I need.


BTW:
wouldn't additional external pullups even reduce the overall- resistance as additional pullups always are put parallel to the internal ones?

(1/R = 1/R' + 1/R'' ) ??

[Massi]

BTW:
wouldn't additional external pullups even reduce the overall- resistance as additional pullups always are put parallel to the internal ones?

(1/R = 1/R' + 1/R'' ) ??

strong pullup = weak resistance

internal pullups are somewhere around 50k, these are too weak (in strength) or too big (in size) for an i2c bus.
but you can try with internel pullups and let us know..

enabling i2c-0 will not be a menu item in raspi-config, for sure you know this..

[davenull]

aaah, ok : internal too weak == too high.

But enabling i2c-0 must compellingly be a menu item in raspi-config for the future, just for all those developers!

And now: how to use i2c-0 by wiringPi?

[Massi]

But enabling i2c-0 must compellingly be a menu item in raspi-config for the future, just for all those developers!

you can hope in this and keep waiting

[Massi]

now what about witingPi on i2c-0 ?

i don't think wiringpi was written for this kind of use (2 concurrent i2c buses), but i suspect that:
- you WANT it to work as you expect
- if it doesn't, it is an undue restrictions of your rights
- obviously, you want answers and not to use any time to look around for information.

For sure someone on the forum will help you in this
not me.

[jamesh]

I am a simple end-user and beginner to Raspi, no sytem developer or low lever hardware progger or Linux hacker.
Having purchased a Raspi designed for beginners I expect libs to be available which provide convenient C/C++ API libs for offered hardware, and not just for that Python crap.

But as I don't have HATs I simply want to use the very convenient and very handsome wiringPi API libs for C/C++ to i2c-0.
Eventually that would be what I need.

Your expectations are out of kilter with the real world. IN an ideal world, we would have every library we needed for every thing we ever wanted to do. And that would be me out of a job. In the actual world, I still have a job, because there is always code that needs to be written.

In your particular case, there doesn't seem to be the exact thing you need. I find that in my job ALL the time. So I have to program something to do what I want. You may well have to do the same. That is, and I quote William Congreve, "The way of the world".

And please keep the language child suitable.

[davenull]

@massi: I don't expect you to post anything if you would not like to be helpful - I wouldn't even expect you to post this statement.

@jamesh:
an undue restriction of my rights would be to "reserve" either GPIOs for 3rd party products and exlude me from using them ! Please read closely!

My language is clean and child-suitable. I have two grand kids who grew up and developed with it excellently, but crap is crap, and mess is mess, and suck is suck.
I assume you don't know much about Children's speech ( or language).

[jamesh]

@massi: I don't expect you to post anything if you would not like to be helpful - I wouldn't even expect you to post this statement.

@jamesh:
an undue restriction of my rights would be to "reserve" either GPIOs for 3rd party products and exlude me from using them ! Please read closely!

My language is clean and child-suitable. I have two grand kids who grew up and developed with it excellently, but crap is crap, and mess is mess, and suck is suck.
I assume you don't know much about Children's speech ( or language).

Well, I do have three children, all young. I would hope that as a grandfather you would show a little more respect for people trying to help you, and respect for the work of others.

[myoung008]

@davenull: I'm tempted just to bow out, but I'll try one more time.

WiringPi is aiming to fill the needs of the masses, and that includes HATs.

That being said, i2c is dead-simple to use. All you would need to do is open the appropriate bus for each device, then pass the appropriate one to the read/write functions. For an example, check out the wiringPiI2CSetup function at the bottom of:
https://github.com/WiringPi/WiringPi/bl ... ingPiI2C.c

The setup function is the only thing that you would need to re-implement, other than that you can use the read and write functions normally.

[davenull]

myoung008,
thank you for your input, but to be honest: I don't understand a word what to do and how to proceed.

These are my 2 source codes for i2c (among others), but these 2 following programs have to be run definitely on 2 different busses because of speed and address reasons.

The 2nd code may stay as it is for running on i2c-1.

But how do I have to change te first code to make it run on i2c-0 ?

Code: Select all

// THIS code should run on i2c-0 !! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <wiringPi.h>
#include <wiringPiI2C.h>
#include <errno.h>
#include <string.h>


int main (void)
{
   
  int fd, i ;
  static unsigned char test=0;
  unsigned char data[32];

  if ((fd = wiringPiI2CSetup (0x60) ) < 0)
  {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

  while(1)
  {
    memset(data, 0, sizeof(data) );    
    read (fd, data, 32);
    delay(5);      // short delay   

    for (i = 0 ; i < 7 ; ++i)
    {
       memset(data, 0, sizeof(data) );
       data[6]= data[5];                // comm test
       data[5]= test++;     
       write(fd, data, 32) ;
       delay(5);   // short delay  
    }
  }

  return 0 ;
}

Code: Select all

#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>

#include <wiringPi.h>
#include <wiringPiI2C.h> 



int main() {   

   int   fd;
   unsigned char a, b, c, d, e;   
  
   if ((fd = wiringPiI2CSetup (0x60) ) < 0)
   {
      fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
      exit (EXIT_FAILURE) ;
   }     
  
   while(1) {           
     a = wiringPiI2CReadReg8 (fd, 1) ;
     b = wiringPiI2CReadReg8 (fd, 2) ;
     c = wiringPiI2CReadReg8 (fd, 3) ;
     d = wiringPiI2CReadReg8 (fd, 4) ;
     e = wiringPiI2CReadReg8 (fd, 5) ;          
     
     delay(100);         // long delay to pause device before next loop         
   }

   return (0);


} 

[myoung008]

instead of:

Code: Select all

  if ((fd = wiringPiI2CSetup (0x60) ) < 0)
  {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

try

Code: Select all

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/i2c-dev.h>


  if ((fd = open ("/dev/i2c-0", O_RDWR)) < 0) {
    fprintf (stderr, "Can't open i2c-0: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }
  if (ioctl (fd, I2C_SLAVE, 0x60) < 0) {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

Also, since I wrote yesterday, WiringPi has made a change. In a future version you will be able to use:
wiringPiI2CSetupInterface("/dev/i2c-0", 0x60) in place of wiringPiI2CSetup (0x60). This won't work right now unless you upgrade to the current git version.

Also, your use of read() and write() directly to the fd probably won't work. You should probably be using the various wiringpi readreg and writereg functions, similar to what you're doing in the other source for i2c-1.

[davenull]

about the codes:
both codes work fine, seperately driven on i2c-1

The if conditions I still don't understand:

Code: Select all

  if ((fd = open ("/dev/i2c-0", O_RDWR)) < 0) {
    fprintf (stderr, "Can't open i2c-0: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }
  if (ioctl (fd, I2C_SLAVE, 0x60) < 0) {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

of course
open ("/dev/i2c-0", O_RDWR))
will return no error,

and

if (ioctl (fd, I2C_SLAVE, 0x60) < 0)

will be true on either bus, as every bus runs a device at 0x60.
So when I merge those 2 programs into one (which will drive both i2c busses simultaneously): how will the program know when to read or write which device?

OTOH,
to have
wiringPiI2CSetupInterface("/dev/i2c-0", 0x60)
will be perfect!

Is it already available or just any time in the future? I will be better adviced then to wait for that, perhaps...
what do you think?

[myoung008]

If the code works fine on i2c-1 then ignore that part of what I said. My knowledge of i2c is not 100%.

The two ifs wrapping open() and ioctl() are there to trap any errors opening the device. If your config or kernel gets changed and i2c-0 disappears the first one fails. If you don't run with the appropriate permissions it could also fail. That's not a complete list.

Where did you hear that 0x60 is on every bus? I don't have it on mine. At any rate, the second 'if' could intermittently fail depending on the hardware or other issues. The whole idea of catching and displaying errors is to know where to start when the inevitable bugs / hardware issues begin.

To have multiple devices in a program you simply have to have multiple file descriptors (currently you only have (int fd)). The following is just a bunch of code that's been pulled together from our conversation, and probably won't compile exactly as-is, but you should get the idea:

Code: Select all

int dev1=wiringPiI2CSetupInterface("/dev/i2c-0", 0x60);
int dev2=wiringPiI2CSetupInterface("/dev/i2c-0", 0x22);
int dev3=wiringPiI2CSetup(0x45);
int dev4;
  if ((dev4 = open ("/dev/i2c-0", O_RDWR)) < 0) {
    fprintf (stderr, "Can't open i2c-0: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }
  if (ioctl (dev4, I2C_SLAVE, 0x60) < 0) {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

//read from dev2
     a = wiringPiI2CReadReg8 (dev2, 1) ;
//read from dev3
     b = wiringPiI2CReadReg8 (dev3, 2) ;

//read / write RTC
    memset(data, 0, sizeof(data) );   
    read (dev1, data, 32);
    delay(5);      // short delay   

    for (i = 0 ; i < 7 ; ++i)
    {
       memset(data, 0, sizeof(data) );
       data[6]= data[5];                // comm test
       data[5]= test++;     
       write(dev1, data, 32) ;
       delay(5);   // short delay 
    }
  }

//write to dev4
     b = wiringPiI2CWriteReg8 (dev4, 2, 0) ;

As far as getting wiringPiI2CSetupInterface, the source is at https://github.com/WiringPi/WiringPi . You will have to download, compile, and install, replacing the libs you already have. Otherwise you can wait for wiringPi to release it and your distro to package and make it available. Note that the two ifs I sent around the open and ioctl are exactly what wiringPiI2CSetupInterface does.

[davenull]

I have 2 devices with devaddr 0x60 each, 1 on i2c-1 and 1 on i2c-0, so it is supposed to be present at either bus ...

or what am I missing perhaps?


how do I have to download the new wiringPi release?
first uninstall?
how?
then sudo apt-get... .... what?

Gordon wrote:

Please note that the official way to get wiringPi is via git from
git.drogon.net and not GitHub.

ie.

git clone git://git.drogon.net/wiringPi

with the new version it surely would work:

int dev0=wiringPiI2CSetupInterface("/dev/i2c-0", 0x60);
int dev1=wiringPiI2CSetupInterface("/dev/i2c-1", 0x60);

[myoung008]

Ah, 0x60 on each of your buses. I read that wrong, I thought you meant ALL i2c buses (like a host address or something). At any rate, the code examples I sent will work just fine opening both devices simultaneously on different buses.

I was looking at the repo on github, but I just checked the official repo and it has the changes as well. I don't actually use wiringPi so I'm not familiar with the build process. You should be able to find build instructions on http://wiringpi.com/ . At minimum, you will need to "sudo apt-get install git" if you haven't already.

[davenull]

I simply tried it, although not even Gordon had ever mentioned that the new function
wiringPiI2CSetupInterface()
would be available.

Strange, I already have asked him about i2c-0, but no hint at all....
.... weird. :-/

But it compiles well for i2c-1.
I now have to re-wire to i2c-0 and report!

[davenull]

yes !!!

it works on i2c-0 !!

finally everything is fine!

Code: Select all

int dev0=wiringPiI2CSetupInterface("/dev/i2c-0", 0x60);
int dev1=wiringPiI2CSetupInterface("/dev/i2c-1", 0x60);

myoung008, thank you very, very much for your help! [/b]

after all that unhelpful, unfriendly, arrogant, narrow-minded, and mainly rubbish like

(???)
I2C-0 Is not available for users
it is dedicated to the HAT interface
And what advice was given about using that configuration?
You're missing the point
I2C-0 is (now) reserved for hat use (and thus for those folks designing hats)
"go with the flow" not "against it"
Quite simply it's "reserved" via the firmware provided by the designers of the Pi.
The pins are reserved for use by HATs...the term 'reserved' is very common in computing to indicate that there is a 'standard' way of using something
i don't think wiringpi was written for this kind of use (2 concurrent i2c buses)
Your expectations are out of kilter with the real world
I would hope that...you would show a little more respect for people trying to help you, and respect for the work of others
(???)

you've been the only one who really provided precious help and reasonable hints which makes it possible to resolve this.

Thanks a lot again!

[6by9]

(Bored so generally browsing forums)

Just a friendly warning, do not expect to be able to use either the camera or Pi 7" display on your Pi.

To be slightly more accurate over above posts, the hardware peripheral behind i2c-0 (which can be assigned to multiple different pairs of gpios including pins 27&28 on the gpio header used by hats) is nominally assigned to the Gpu for various functions. Those include the camera, display, hats, and who knows what else in future.
You can not have both Linux and Gpu accessing the same peripheral concurrently - interrupts will potentially be serviced by the wrong processor and data lost or lockups.

Feel free to use i2c-0 for your own purposes as that is your perogative, but doing so imposes restrictions on what else you can do with your Pi. Novice developers don't comprehend the implications of doing so, hence the default setup is not to expose the peripheral through Linux.

[davenull]

well, I actually am just designing my own "HATs", based on 1-2 Arduino Dues, providing 50 digital pins, 10 DAC, 2 ADC, 1 extra i2c, 1 SPI, 3 UARTs, and a USB host each. costs: 13 EUR each, and not a fortune, and C/C++ available, not just that crappy Python....

I have plugged a HDMI monitor, so I wouldn't ever need another one (and I am actually curious why not everybody just uses HDMI monitors, they are from 3" to 60", and thus don't cost precious extra GPIOs), and as a camera - well... maybe yes, maybe not, maybe it will work then, or maybe not then, or I'll choose a Pixy cam, don't know yet, I'll see...
(and BTW, why don't you use SPI for the cam or the display, if any...??? it can be 100x as powerful as i2c by transmission speed! Most TFTs work with SPI out of the box, and also the Pixy cam has an SPI interface additionally!)

but what shall I do instead?
UART is already in use, I do need 1 quick i2c to interface my Arduino "HATs", and an extra, slower one for many different other devices, which may go slower but at least reasonable, and perhaps even when having to plug devices of the same i2caddr: that is most important to have for me.

But thank you for your advice, it's very much appreciated nevertheless!

kind regards!


("21 is only half the truth" )

[6by9]

well, I actually am just designing my own "HATs", based on 1-2 Arduino Dues, providing 50 digital pins, 10 DAC, 2 ADC, 1 extra i2c, 1 SPI, 3 UARTs, and a USB host each. costs: 13 EUR each, and not a fortune, and C/C++ available, not just that crappy Python....

No you're not designing a HAT, you're designing a Pi add on board. To call it a HAT you have to follow the HAT specification, and that requires an EEPROM attached to the pins 27&28 of the GPIO header which will load up a device tree fragment to configure Linux for your device. Omit that and it is not a HAT.
Yes pedantic, but HAT has a specific meaning, and that is why others have stressed the usage of pins 27&28 for HATs.

Choice of language is up to the individual. Personally I prefer C (not that "crappy" C++), but I'm an embedded developer often on very limited footprint devices.
Python is a very useful tool, and certainly makes integration into SQL databases or web pages a doddle. I've written a basic web page requester (I won't call it a client), and an SMNP client in pure C on an embedded device - not a trivial task to do efficiently, and I probably would do it differently now, quite possibly in Python.
Horses for courses.

but what shall I do instead?
UART is already in use, I do need 1 quick i2c to interface my Arduino "HATs", and an extra, slower one for many different other devices, which may go slower but at least reasonable: that is most important to have for me.

I2C muxes (eg TCA9548) are supported by the kernel (https://i2c.wiki.kernel.org/index.php/I ... ltiplexing), so get the device tree entries rightand you should be able to get Linux to show the outputs of the mux as independent i2c devices under /dev.
Note that the i2c bus defaults to 100kHz but is rated to run up to 400kHz (others have taken it beyond this). Clock stretching has issues though, so don't exceed your device max speeds.

Other options depend on your device. You mention SPI so that may be an option if your device can run as an SPI slave.

[davenull]

I apostrophied my "HAT"s surely knowing that it wouldn't be a HAT(™ or ®) ever - I also may have called it "shield" or "IO-Muxer".

And yes, I also LOVE ANSI C and evade C++ if possible (except when it's so easy and handsome like for Arduino Wiring Sketches, of course).

My point is: I dislike an open-source product "reserving" pins for 3rd party companies, if not even just for special products:
i2c is i2c is i2c, period.
It has to be open for all purposes from default, and other way round: for special purposes like HATs (™ or ®) it has to be enabled before, because then it becomes a restriction of the open design!
(no matter who wants that feature or bug finally, if majority or minority of the customers - and who knows if a majority will ever keep to be it, or if it once will be detached by a minority eventually... except you'll limit the possibilities so much that the minority will migrate to other competitors: if it's that what you wish or intend to get, well....)

Back from company policies and target groups to topic:

about SPI: that was a point to think about for you as the developing crew:
I personally am not capable of SPI programming, but you're supposed to be it though!
So why the heck do you reserve an i2c port for a display?
Surely fast or high speed i2c may be a bit faster than 100kHz, but what is that compared to 100MHz??
I am already running my Arduino TFTs (ILI9341) by 84MHz SPI in DMA mode!!
read again:
on an Arduino !! by 84 MHz!! and by DMA!!

And even HATs might benefit from SPI instead !! AND Cams !!

So drop this TFT and cam design for i2c and abandon the HAT reservation for i2c-0!
Free i2c-0 (and anything) by default !


"what do you get if you multiply 6 by 9 ?"

("21 is only half the truth" )

[6by9]

My point is: I dislike an open-source product "reserving" pins for 3rd party companies, if not even just for special products:
i2c is i2c is i2c, period.
It has to be open for all purposes from default, and other way round: for special purposes like HATs (™ or ®) it has to be enabled before, because then it becomes a restriction of the open design!
(no matter who wants that feature or bug finally, if majority or minority of the customers - and who knows if a majority will ever keep to be it, or if it once will be detached by a minority eventually... except you'll limit the possibilities so much that the minority will migrate to other competitors: if it's that what you wish or intend to get, well....)

It doesn't have to be anything. It may be a Linux system, but it's not open hardware.

Following your logic, you can enable access to the I2C bus on HDMI port that's used for reading EDID data from your monitor. Do you want that one enabled by default too? It will disable EDID and CEC in the process, so no remote control of your TV or resolution detection? Surely no one would want to use those features? How many of the >5 million Pi's sold might then use it as an extra i2c bus vs the number that want to use an HDMI monitor? (It's 5V tolerant too if you really want to go and use it - it is covered in the forums).

So why the heck do you reserve an i2c port to a display?
Surely fast or high speed i2c may be a bit faster than 100kHz, but what is that compared to 100MHz??
I am already running my Arduino TFTs (ILI9341) by 84MHz SPI in DMA mode!!
read again:
on an Arduino !! by 84 MHz!! and by DMA!!

Read up a little on the display.
It uses MIPI DSI to transfer the pixel data at up to 1Gbit/s per lane, and 2 lanes are exposed. Just a little bit faster than SPI - it's enough for 720P60 or 1080P30! DSI is also fed directly from the hardware video scaler so will run with on-the-fly composition, same as the HDMI output does.
The I2C connection is used for configuring the display, and also for the touchscreen controller.

So drop this TFT and cam design for i2c and abandon the HAT reservation for i2c-0!
Free i2c-0 (and anything) by default !

Firstly I don't work for Raspberry Pi, so I have no control at all over any policies. I worked at Broadcom before they laid off most of the team behind BCM2835 and BCM2836, so I know how the chip works, and provide support VOLUNTARILY because it is generally nice to help people.
You don't want the camera, but significantly more do. That requires an i2c connection controlled by the GPU (again for control as the data is on a MIPI CSI2 bus - another 2Gbit/s bus).
Likewise many beginners don't understand enough of Linux to set up device tree or similar when wanting to use add on cards, hence the HAT spec was produced to allow auto-configuration. Pi is aimed at those learning computing.

That's my final comment on this - you have your views and are expressing them in a way that is upsetting many.
You are now aware of why i2c-0 is not generally available. Feel free to use it, but don't go complaining when your use of i2c-0 means you can't add some random widget later.

> /dev/null

[davenull]

The pins we are talking about are exposed as i2c-0 and not as MIPI DSI,
and honestly: who needs MIPI DSI when already HDMI by full-HD 1920x1080 is exposed by an extra (standard) HDMI jack (which I expect to work via automatic plug-and-play just like for TVs and Sat tuners) ?

But instead, having just 1 i2c (and just 1 UART) is rediculously poor.... :-/

anyway...
> /dev/null

[jamesh]

The pins we are talking about are exposed as i2c-0 and not as MIPI DSI,
and honestly: who needs MIPI DSI when already HDMI by full-HD 1920x1080 is exposed by an extra (standard) HDMI jack (which I expect to work via automatic plug-and-play just like for TVs and Sat tuners) ?

But instead, having just 1 i2c (and just 1 UART) is rediculously poor.... :-/

anyway...
> /dev/null

I've been following this thread with a certain amount of distaste, and what it comes down to it....I want to use the device a certain way, and I demand it should be the default. Well, sorry, but a very large number of people disagree with that because they use the camera, or HAT's.

Well, I personally think the majority should hold the high ground here. And since you are a minority of one, the majority is not you.

So, please stop going on about it, you are wrong, and I will delete further posts on this subject, because a) They add nothing and b) this isn't a democracy.

[davenull]

sorry, I am not wrong, I just have another opinion, and I am a customer, and I have paid money for all my devices.
Please respect that.

As we say in Germany:
"Der Kunde ist König ! "
means: respect each customer as if he was a king!

notice: the customer, not the company.

But finally the TO question is resolved, I found the i2c-0 pins, and they work as expected, thanks to Gordon's wiringPi API and myoung008's helpful hints.