Cursory look over your code makes me think there might be a performance problem
with the way you have interspersed your file writing logic with your acquisition loop.
I am referring the fprintf statement in the acquisiton loop.
My hunch is OS provided file buffers are getting filled due to the repeated fprintf
and at some point fprintf blocks until the ...
1) Bit banging just means using software rather than hardware to implement a communications protocol. To bit bang I2C this means to control the SDA and SCL signals in software. SDA is connected to GPIO 2 (pin 3), SCL is connected to GPIO 3 (pin 5). Generally to bit bang you need to set the GPIO high (write 1) or low (write 0). All the Pi GPIO libraries ...
I wrote a C++ library called v3c-raspi.
You can download it from SourceForge.
I wrote an example program that tries to do just what you want, called "i2s".
Unfortunately it experiences a "program anomaly" anywhere from straight away to a couple of seconds after it starts - it looks like something else uses dma channel 0 and leaves rubbish in the block ...
You can toggle a gpio at around 25 MHz.
I expect you could get perhaps a tenth of that if you were to bit bang. Of course that really depends on what you are bit banging.
For general information see http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications
I do not remember why the limit is 250k rather than say 500k or 1000k. I expect there was a reason. It may simply have been there was too much jitter at the higher bit rates to reliably clock the data.
I suggest you have a look at the code and examine the consequences of changing the constant PI_BB_SER_MAX_BAUD to 1000000.
That LDAC signal is truly nasty.
I have read the datasheet and your messages a few times and I can't quite focus on a specific issue so I figure out you're just brainstorming. I will start from what I know from direct experience.
How should I write this communication to be as orderly as possible - should I write special C routines within my Python ...
A few thoughts:
Using dedicated I2C pins for your bit-banged I2C should be fine as long as you don't use smbus at the same time.
Improving GPIO timing in userspace can be done by increasing process priority (see man nice). Re-writing your bit-banging routines in C will help on average, but the worst case will be just as bad as with Python. The only way to ...
I2C device reading writing errors problem. How to solve it?
There are many reasons causing reading and writing errors. To name a few:
Wires too long (more than 30cm) and not twisted. A suggestion is to use twisted cable Cat 5 to reduce mains EMI noise picking up,
I2C speed too high. A suggestion it to start testing a low speed, such ...
UmaN the sparkfun product description says "RHT03 (also known by DHT-22)" So finding the information you require should be much easier.
adafruit's github repo Has the "driver" written in python. So you can use the sensor with your PI. They also have instructions on how to set it up.
Arduino library: https://github.com/adafruit/DHT-sensor-library
To avoid flickering of the segments, you really do need hard real time control of the multiplexing. Even small variations in the timing will be quite noticeable.
Using the timer on the CPU should work quite well, but as you observed it seems a lot of hassle for one simple thing. Perhaps it's worth doing if it's not just a one-off thing you are making.
I have never heard of this approach on the Pi.
If clock stretching is not a issue I don't see why it could not work.
I suggest you look at extending an I2C sniffer I wrote to test the idea.
Note that you can have multiple software I2C buses on the Pi (you need two spare GPIO per bus).
What do you mean by at once?
You can buy two TCA9548A I2C multiplexors which will allow you to connect 16 MPU6050 on the same bus (at the same bus address). However only one MPU6050 may be addressed at any one instant in time.
Using DMA bit banging it is possible to get accurately timed gap-less samples from the MCP3202. The same technique should work for the MCP3201 with the obvious change to the SPI command to request the data.
The MCP3202 (12-bit ADC 2 channels) command SPI tranfer is
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
SB SD OS MS NA B11 B10 B9 B8 B7 B6 B5 ...
the data acquired has unaccounted gaps in it
I think "accounting" for them is simple enough, it is arbitrary latency. If the units there are seconds, then that is a cause for consternation.
If they are centiseconds or smaller, that's the nature of the beast on a multi-tasking OS. You're not going to be able to guarantee yourself zero-latency, although ...
I have a very similar scenario as you:
A distributed domotic system all over the house with a central device (Raspberry PI) and a few satellite boards with I2C (PCF8574/PCF8591) and 1-Wire (DS18B20).
Everything is connected via ethernet cat5e cables. To allow long range I2C communications I'm using the P82B96 I2C bus expander. For 1-wire communication is ...
Are you sure that you have the right value for RGB_ADDR? Whenever I have seen a -82 error with pigpio it has been because the I2C chip is not responding. This is usually because you are using the wrong address. Another possibility is that SCL/SDA are swapped. Note that the data array expects a 7 bit address and pigpio automatically appends the correct ...
The Raspberry Pi isn't really suited for this application.
You'll need to use hardware timers and pin interrupts to do it right.
To receive a message on the bus, each part of it must be acknowledged or the transmitting node will give up and not send the rest of it. That means you can't read anything without writing a zero bit at precisely the right time.
If I understand correctly what you are trying to do then there is a simple software solution.
The following Python code should update multiplexed 7-segment LCDs in a flicker free way.
For testing purposes each LCD is updated for 100000 µs in turn. In a practical application a value like 1000 µs should be used. The period
is set by the REFRESH constant.