I know it's been quite old but, I come across the same situation when I use MPU9250 spi with long wire, and read Ak8963 by the MPU9250 Aux I2C. Oscilloscope on SPI SCLK and Aux SCL shows that when there is a SPI reading and I2C reading happen at the same time, the I2C would hang and halt, I can see crosstalk spikes on I2C signal whenever there is SPI CLK ...
I'd recommend using an MCU (and some external driver circuitry) for this. Each of your displays should be mounted onto a tiny board containing the 4-digit display and one MCU + circuitry. The block diagram of functions would look something like this:
You need 64 bits of RAM for the (4) 16-seg display. That's easy to find in any MCU.
I have added a special &...
if you use just one:
HAL_I2C_Mem_Read(&hi2c2,144, 4, 145, (uint8_t *)&VT1,6, 100);
instead of 6 times, it read the correct 6 registers because AD7746 increases address automatically, but I can not find the HAL problem in addressing right register.
I use a 9 volt battery snap connector which connects the battery and barrel jack of the arduino uno(I am assuming that the arduino uno schematic is same as original one) as shown here. Raspberry Pi 3b(original schematic) has a USB type power connector and you cannot use a 9 volt snap connector like arduino. It is better to use a power bank or a wall ...
Every transaction requires you send nine clock pulses from the master, the month byte is for the ACK bit.
For the slave address transaction the data line is left high from the master so the slave can acknowledge the address if recognized.
If you are using the I2C hardware it will automatically send nine clock pulses. If being implemented in software you will ...
Thanks to @pjc50 answer and @MarkLeavitt comment, suggesting the use of FIFO stream mode I was able to reduce noise generated by unprecise time intervals between measures @1.6kHz, but still I couldn't reach 3.2kHz probably because with this strategy I need many reads via I2C to know how many values are in the FIFO and read them, and this takes time.
Anyway I ...
Yes, it's wrong. There are two things that went wrong when using 1kohm pull-up resistors connected to 5V supply for I2C.
The first issue is that you have devices on I2C bus that can only tolerate 3.3V voltage on their I2C pins. In this case the pull-ups must not be connected to 5V supply. If there are both 5V and 3.3V devices on bus, then there is a need to ...
The most interesting section is on the FIFO. See page 21:
The ADXL345 contains technology for an embedded memory management system with 32-level FIFO that can be used to minimize host processor burden. This buffer has four modes: bypass, FIFO, stream, and trigger (see FIFO Modes)
It sounds like you should set the FIFO mode to "...
Thanks for all feedback, ideas and support! They were really helpful!
I manage to solve the problem by:
Lowering the values of the pull-ups on the SDA and SLC close to the arduino (470 ohms each)
And I used a thin Cat6A cable - less than 4mm diameter - (with 28 awg twisted pairs inside and no shielding), instead of my previous 6 core wire with shielding.
I did a similar implementation a year ago. I used a VEML030 light sensor that was on a PCB and communicated with another PCB through I2C. On my experience, you would need level shifters to amplify the voltage on the cables, if not, you are risking the operation of the sensor. True that if you turn off the LED, the sensor will read properly, however, when you ...
A distinct idea: Graham Stevenson's question about the I2C clock rate prompted a thought that it's not the clock rate which makes the system suspectible to induced noise, but rather the chance that a current spike happens during the I2C signalling itself.
So what if you were to coordinate the I2C and your 490 Hz PWM, such that the PWM on/off transitions ...
Regarding the first two questions I believe they were aduately answered.
Regarding the third:
As others mentioned, pull-up values along with cable capacitance play a big role both in whether your devices are recognized and the speed you are able to achieve as they effectively form a low-pass filter.
For a recent project I had to drop the pull-up resistors ...
The best solution to a problem like this would be to put a small MCU at the sensor, and then send back something like a UART data stream via a differential transmitter. Something like an ATtiny would work well.
Additionally, it would be good to do the PWM switching at the location of the LEDs, and to bypass the supply for that with plenty of capacitance ...
You'll find that modern cars are essentiall 2.55m × 3m robots containing a human driver.
The guys producing millions of them have agreed to use CAN, because the combined cost of cabling + CAN-capable controllers + connectors is cheaper than the effects of having the unreliabilty of rolling something based on I²C or their own bus inventions. Use CAN.
Actually whether you need external pull-ups depends on how fast you want to communicate.
Based on your scope photo you are using about 200 kHz speed and the waveform is too slow, so yes, in this case, you definitely need external resistors. In fact, under normal use, the pull-ups are usually needed, but under special cases where communicatiom speed is slow ...
Yes, you need external pull up resistors. The typical pull up value for the STM32 microcontrollers is 40 k\$\Omega\$ (assuming they're even active). You can calculate a correct value, but if you just want to get working, a 4.7 k\$\Omega\$ resistor will get you started.
Yes you do, as the I2C peripheral uses open-drain pins (or very similar to open-drain) so all they can do is assert the lines low.
Also the pull-ups can be different values for different I2C speeds so they have to be external for that flexibility.
I usually start with 4k7 (as awjlogan suggested too) and you can adjust from there if needed.
If you don't get lucky with the other answers you could try this device from Analog Devices (it has two 1:16 devices and might be useful to you): -
It's a proper analogue multiplexer so if you only wanted digital signals you'd set the D input to high level (think of it as an extra enable pin if you wish).
I agree with the others that it's an I/O expander with I2C (or 'two-wire') input.
If you do a parametric search on Digikey for SMT I2C I/O expanders with exactly 16 outputs you'll get more than 100, counting SMT package variations.
The cheapest one is the NXP PCAL6416AHF,128. It also happens to be the one with the largest quantity they currently have in-...
When using the MPU6000 in I2C mode should CS be ground or VCC?
Consider the information you know:
In the datasheet it says (0=SPI mode) in the pin descriptions
Clearly, you would not want it to be tied to ground for I2C mode.
So the question then becomes, should it be floating or high?
The safe solution is to place a resistor footprint tying it high; you ...