@Moonshiner said in i2c RTC on 0x68 can find in system: May be we must to change platform to somethink else... orangePi, nanoPi.. Yes that's good Idea, debian's type OS' have *-kernel-headers to compile dynamical kernel modules. The driver's subsystem in Linux is very inconvenient at all as compared with Windows. I think you encounter many hardware problems there, like Interrupts, DMA, memory management, kernel-space coding etc. If you no-system coder, don't start to be one. OrangePi computers are very fast for a simple projects, I prefer C++ language, programs work too fast )). I choose Omega by the lowest prize and stable OpenWRT OS in. Last time I used to MCUs only, but they are poor for multimedia projects (TFT-diaplays, sound, touchscreen input) or database using (SQLite), also mini-computers allow service tools inside and third-party packages. But they have difficult way to append any hardware driver. In fact a hobbyist can only use system "in-box", I mean that's already not very bad. I think Omega should upgrade board Dash to Dash2, with the next hardware on: support some SPI displays (like 2.4"...3.5") and Qt library (package) support set of touchscreen drivers for the displays set sound (the best is codec WM8960 with microphone), rtc Ethernet connector with PoE (external shield). (external shield) USB-hub with 3-4 connectors (one slot must be always free for service using). (external shield) PCI-E controller SATA for 2.5" hard drives. There is base powerfull computer board for the most multimedia projects.

Yes, those work perfectly and are used to determine the device is there. But there is no way to read the actual range data without a lot of i2c back-and-forth with their custom protocol. There are python libraries to handle this, but none of them work on the Omega (yet)

@jose-r You don't have to do anything with an Onion ADC Expansion Board: the power supply voltage of the ADS1115 is 5V each I2C bus line has a usual 5V-to-3.3V MOS-FET bidirectional logic level shifter

I hadn't finished and it submitted somehow. The Python code is: bytes = [0xAA, 0, 0] try: i2c.write(0x18, bytes) except: print "write failed" time.sleep(0.01) y0 = i2c.read(0x18,4) print y0 This returns a status byte, but zeros for the pressure data. The i2c waveforms which I captured from an oscilloscope look different enough to matter. Can I upload them here somehow? The command bytes to read the pressure [0xAA, 0x00, 0x00} for Arduino and Onion: And the two responses showing that the sensor only returns zeros on the Onion The oscilloscope interprets all of the i2c bus traffic correctly, but it appears that the sensoe is never getting triggered by the [0xAA...] command to start digitizing. So it only sends back zeros. Does anybody know why the i2c waveforms are different and how to make the Onion i2c library behave as the Arduino does which works properly. I am not having any trouble with other i2c communication from the Onion, only this sensor. Thanks to anyone who is up on this. Stay safe! Y.

@cmelnick It's possible the onion-i2c:: debug readings aren't 100% correct. Can you try changing your code when you read to this: val = i2c.readBytes(0x5a, 0x5d, 1) print(val)

@Victor-Lucio Please take a look at this: Official Onion Omega2 Documentation I2C Python Module. '/usr/lib/python2.7/OmegaExpansion/onionI2C.so' is not empty - it's an ELF binary file. The source code can be found in the Onion i2c-exp-driver GitHub Repo. An example of how the onionI2C library is used can be found in the i2c-exp-driver repo. The example code programs the Relay Expansion (an MCP23008 8-bit, general purpose, parallel I/O expansion IC for I2C) directly. Good luck.

Thank you for responding, the real direction is 0x70 using 7 bits. In other words is 111-0000. If I include the bit of R/W, this will be 0 if i want to write a data in the slave(sensor). .111000-R/W ----------> 11100000 11100000 Is E0 in hex. For this reason, I have several concerns about this module, but I hope to solve it later. Thans again for taking my doubt. I will try to send you 6 bits as data and include the CRC byte. It is likely that when I insert the writeBytes command, the R/W bit is inclued internally without me noticing.

Thanks. I'd seen that before, ran into bigger problems with the pigpio build (eg no ldconfig available for the omega). That said, I found a method to use with the smbus2 package that allowed me what I needed.

It looks like this was an error in the library that I was using as the libraries author has confirmed they are seeing the same thing when they tried to read from the same kind of sensor.

readValue needs to be passed as a reference, since the contents will be modified by the i2c_read function. That's likely causing the segmentation fault. Or change readValue to a point and allocate two bytes before passing it to i2c_read See the documentation for the i2c_read function for more details: http://docs.onion.io/omega2-docs/i2c-c-library.html#i2c-c-read-multiple-bytes

@Matt-Gessner-0 while it is technically possible to do some development on the omega, it is quite impractical. You will quickly run out of capacity and patience and you'll end up using a more suitable build environment. Save youself the time and heartache. Take a look at the cross compiling docs it is easy to set up a build environment and use the better resources of a proper development platform

=== Version Info === Omega firmware: v0.2.1 b199 onion-os - 1.0.5-1

Wow, thank you so much! This is exactly what I was looking for.

If you have a build systen installed You can tweak the kernel setup by using "make kernel_menuconfig" Look under Device Drivers -> I2C Support, there is a several debugging options you can set in order to assist with debugging i2c.

With raspberry pi1 (the 2011 model) the screen are working but not with omega that not recognize them. I will probably resell my omega and various accessories because the assistance is not very helpful

@Michal-Dobrzynski Please do not forget to remove the pin3-pin4 short circuit if you want to plug the Oled Expansion to any genuine Onion Omega Expansion Board Header directly because Omega2(+) may be damaged if you set GPIO11 to Low. There are I2C level shifters on the OLED Expansion. Pin4 of the Expansion Header provides the voltage to the lower voltage section for those level shifters. But pin4 of the Expansion Header is connected to GPIO11 on the Omega2(+) board. So @Onion must set GPIO11 to High (~3.3V). It's a hidden simple hack that @Onion forgot to mention for example here. You could find some further technical details here.