I'm using lcd (5x8DOTS/5x10DOTS) via SPLC780C and PCF8574 by I2C protocol , from MSP430 MCU.
The SW command describe in datasheet of SPLC780C but the protocol not.
How is 4-bit protocol used ?
How the RS RW EN is written ?
I found some LiquidCrystal_I2C code, but it is not clear which pins is using in SPLC780C to lcd ?
Thanks
I try some options but it not working
Related
So I am trying to connect and then launch the SD card reader to Raspberry Pico using SPI1 and not the default pico one because the default one is taken by a LoRa module.
I am using the arduino core.
SPI1.setRX(12); // 16 12
SPI1.setTX(15); // 20 15
SPI1.setSCK(14); // 19 14
SPI1.setCS(13); // 17 13
I figured out this the way to define my SPI1 pins, but I still have no clue how to launch the SD card library on SPI1 and not the default SPI0.
I know that the defining code is right because I tested the SD card module on alternative SPI0 pins and it worked. I also asked the wise man that created the core how to do it and that's what he replied:
"There are 2 SPI port, SPI and SPI1. You can use the 2nd port, SPI1 at the same time as SPI. I don't think it's safe from the SPI protocol to change pins between transactions (glitches/etc. might upset the devices)."
But I still have no clue on how to run a SPI device on SPI1.
We're currently using STM32F373CC micros in several of our designs. Part of our standard design has an EEPROM connected via I2C. We have our own hardware layer that is tried and proven over the decades. However, it relies on the I2C port pins having pull-ups connected externally.
On some of our new designs we have designed out the pull-up on the SCL line and have set the port pin to Push-Pull mode. In theory, this should be no problem. However, what we've found is that the micro seems to be treating the port pin as open-drain regardless of the setting. For this particular design, we're using PF6 and PF7 as SCL and SDA respectively. With no pull-up connected, the SCL line is flat-lined. With internal pull-up enabled, the SCL line is pulsing, but the rise time is so long it's not working.
Nothing in the reference manual or the datasheet says anything about this issue. In the errata sheet we have (V4), there's quite a bit about the GPIO and I2C, but nothing that seems to relate to this.
For what it's worth, I'll copy and paste the relevant bit of the initialisation:
switch( kasPinMap[eSCL].lwI2CNum )
{
case 1: RCC_APB1ENR.I2C1EN = TRUE; nI2CEEpsRegisters = (void*)&I2C1_CR1; break;
case 2: RCC_APB1ENR.I2C2EN = TRUE; nI2CEEpsRegisters = (void*)&I2C2_CR1; break;
}
//configure the pins
DIO_vConfigure( kasPinMap[eSCL].ePort, kasPinMap[eSCL].lwBit, DIOkeM_Alternate, DIOkeD_PushPull, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSCL].lwAFN );
DIO_vConfigure( kasPinMap[eSDA].ePort, kasPinMap[eSDA].lwBit, DIOkeM_Alternate, DIOkeD_OpenDrain, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSDA].lwAFN );
//reset and enable the peripheral
nI2CEE_vReset();
In the debugger, GPIOF looks like this:
AFR values are set to 4.
The I2C registers look like this:
And the RCC registers look like this:
Our Technical Director mentioned that to comply with the I2C standard and allow for multi-master mode, both SCL and SDA should both be open-drain. However, all we have here is the F3 and the EEPROM.
Any thoughts on why we might not be getting the push-pull action out of the SCL line would be appreciated.
Using CubeMX and CubeMxIDE an example for reading a button if using HAL drivers works.
https://karedox.com/?p=193 .
However, I need to read a GPIO pin using low-level drivers.
But apparently, LL_GPIO_ReadPin(SW_GPIO_Port, SW_Pin)
is not implemented
whereas
LL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin) does not give an error.
Is there a low-level driver solution for GPIO_ReadPin?
why just not:
!!(SW_GPIO_Port -> IDR & (1 << SW_PIN))
I am having troubles using an I2C sensor with the Beagle Bone Black (BBB). The BBB is running a newly flashed 18.04 Ubuntu image specifically for the BBB.
I wired the sensor (VIN, GND, SCL, SDA) to the corresponding I2C2 pins (4, 2, 19, 20) on the BBB using the below pinout.
The sensor is supposed to be using address 0x40, but scanning I2C2 (using i2cdetect -r 2) does not show the sensor.
I have tested this with two separate sensors as I thought at first I may have fried the original sensor somehow, but the results are the same. In fact, running the I2C2 scan command yields the exact same results when nothing is connected at all.
I have read in many places that I2C2 may not be enabled by default, but I assume it is enabled in my case as I can scan I2C2 without getting an error. Is this assumption incorrect? Again, this is a freshly flashed BBB, and I have not enabled/disabled anything - it should be in the default state.
I have also verified the connectivity of my wires between the sensor and BBB. The voltage between VIN and GND on the chip is 3.3V, so it is definitely being powered.
Why can't I connect to my I2C sensors using the BBB?
it could be that the source you are using is outdated or not a viable entry for i2c.
Also, you could use this command to make sure i2c2 pins are available:
config-pin p9.21 i2c
config-pin p9.22 i2c
This may work, also. If this does not work, please reply with your entire source.
Seth
P.S. Also, if you have time, you may want to get an i2c library to use if your software falls short of setting up your own i2c library. They have smbus2 you can install with pip and other i2c libraries out there still.
Here are a few things you should check (in random order).
List all I2C buses wich i2cdetect -l and try them all. Depending on the platform, the i2c bus number in Linux may be different from the peripheral number used in the datasheet and pinout. E.g. "I2C2" might be bus i2c-1 or i2c-3 in Linux).
Use an oscilloscope or logical analyzer to see if the SCL and SDA lines are being driven. If they aren't check the bus number as above. If they are, then check whether the device gives an ACK; if it doesn't, anything else will never work: double-check the chip slave address. There are cheap logical analyzers that you can buy and user with pulseview.
Simply load the Linux driver for your chip (see the kernel docs on how to do it from userspace for a quick test). Then see check if the device appears or use dmesg to see any kernel error messages while probing.
I checked the sysfs of GPIO, it only supports to configure the direction (in, out), active_level, edge.
I don't see it supports to change mode between GPIO and interrupt. Do any you know it ? Or any suggest.
Example:
Some GPIOs can supports either GPIO or IRQ. So I would like to change mode it under Linux via sysfs.
Thanks in advance.
The GPIO controller (and thus driver) will provide that support if any. In that case GPIO controller is registered as an interrupt controller. There are a lot of examples, like gpio-intel-mid.c where you have:
retval = gpiochip_irqchip_add(&priv->chip,
&intel_mid_irqchip,
irq_base,
handle_simple_irq,
IRQ_TYPE_NONE);
if (retval) {
dev_err(&pdev->dev,
"could not connect irqchip to gpiochip\n");
return retval;
}