I am writing MIPI csi-2 camera driver on Linux but I have a problem about communication enable signal. I have the technical data sheet in my hand but the communication enables register or another info about how to set or get this signal is not mentioned. I think this signal is getting from device tree I don't know. This signal called datasheet as an XCE signal and these are the information about that;
XCE: Communication enable 4-wire: XCE pin and I2C: Fixed to High
The pin for 4-wire serial communication and I2C communication is shared, so the external pin XCE must be fixed to power supply side when using I2C communication
these are some information about that other information of XCE is about how to use it while configuring the camera.
I need some advice or any idea to figure out how to solve this issue.
Thanks.
Best Regards
Related
The data sheet for the coral som states
The following pins are configured for general purpose input/output, by default. Additionally, you can reconfigure other pins
(SAI, SPDIF, SDIO, I2C, UART, SPI, and PWM) to behave as GPIO, using a device tree overlay
Can anybody provide some insight on how to do this? Looking at the imx8mq.dtsi I only see gpio1-5 so I don't even know where the other existing gpio pin definitions are coming from.
I have a PCIe connected to my linux server and want to use SMBus pins to communicate via I2C to a slave uC (atmega128). This slave will, similarly, read some temperature also via I2C (the wires are multiplexed by a signal controlled by the uC, so it can be slave/master depending on the state of this signal). In master mode, the uC can get all the information from the sensors attached to it. In slave mode, the linux server will be seeing this device and will be able to ask for the information. Now, my question is:
How can I get my device to appear in the list shown when we write "sensor" in the console with the library lm_sensors installed? I have no idea what is the format in which the data is sent to this library, or whatever I would need to do. Would really appreciate some help!
Thanks!
I'm trying to connect a mass flow sensor, SFM-3000 by sensorion, to labview on PC using USB device, NI-8452, which provide I2C interface.
I followed the user manual of the sensor and used I2C example by labview but I cannot establish communication between them
I get the error message:
Error -301744 occurred at NI-845x I2C Run Script.vi:6110001,
Possible reason(s):
NI-845x: The I2C master lost arbitration and failed to seize the bus during transmission of an address+direction byte.
I'm using NI-8452 that include pull up resistor and I make sure to enable them by enabling 'Use Internal I2C Pullup Resistor' filled in 'NI-845x Device' property node.
I set I/O voltage level to 3.3,
I double check the address, I have 7 bit address defined in user manual of my device, 64 dec or 1000000 binary.
As specified in my device user manual, I provide it Vdd of 5v from NI-8452 pin 40 and also GND in pin 7.
Off-course SDA in pin 5 and SCL in pin 9.
I think I might have a problem with pull up reference voltage because the sensor specified it need to be 5v but NI-8452 use up to 3.3V.
but the low limit for high signal is 2.5v so it should work
My diagram:
another option i tried is using I2c script blocks
I tried similar solution also for pressure sensor, hdi0611arz8p5 by First-Sensor, but also got the same error.
After re-wiring it's started working, maybe some bad connectivity between wire and port. i hope this thread could help people that wish to connect sfm3000 using labview.
People,
I have always seen references about how to use a SPI interface to operate a SD memory card.
This is not what I want. I need to do exactly the opposite.
I want to be able to use the SDIO controller (through SD slot) in my "host" (any PC having a SD-card interface) to talk to my devices (basically microcontrollers) that can only "speak" SPI.
If my understanding is not too wrong, I cannot simply tell my SD controller to talk in a raw SPI mode but I can teach my microcontrollers to behave as a SDIO device that can be controlled by my host.
This way I still have two challenges left:
Correctly implement a generic SDIO device in my microcontroller.
Implement/configure the correct drivers in the host to be able to interact with my devices.
Implement the SDIO device seems to be a matter of following the spec.
The host-side driver, though, is something I hope I can accomplish with a user-space driver in Linux using some already existing kernel-space driver to SDIO.
That's the point that I come to ask for help.
Can anyone please point me any samples, documents or any kind of resources that can help me in my task?
On the PC side, this is all you need: http://sourceforge.net/projects/sdio-linux/
This may be useful for reference: http://www.varsanofiev.com/inside/WritingLinuxSDIODrivers.htm (although, I don't think you would be writing a driver)
On the microcontroller side, use "bit-banging" to implement the SDIO spec.
However, first consider why do this. SDIO and SPI are just serial protocols, so is USB; wouldn't you rather make an SPI-to-USB bridge? USB is much more user-friendly on the host side, as well as being more standard/more common. And if you do want a SPI-to-USB bridge, turns out it already exists, the SPI Shortcut (probably other options, this is just the first one that comes to mind)
EDIT Or, you could bit-bang I2C on the micro, if the host supports I2C (many do). Actually, go through every serial protocol the host supports, and see if you can support it easily from the micro side (by bit banging, since the micro is likely to not have a slave mode for that protocol built-in). RS232 (with level shifter), I2C, and SPI are likely to be the preferred choices. SDIO is pretty much the last choice, I think.
SDIO is very tightly specified. Unless your microcontroller has an SDIO block that is designed to act as a device rather than host, I don't think this will be possible. I know of a few special purpose communications controllers that implement an SDIO device, but I haven't come across any general purpose microcontrollers.
You would need a fairly fast microcontroller to be able to bit-bang SDIO initialization at up to 400 kHz. If running an STM32F4 at 180 MHz, this gives you only microcontroller cycles between SDIO clock cycles. If the host turns up the clock speed to the maximum of 25 MHz after initialization, then you're down to 7 cycles between SDIO clocks.
For perspective on the SDIO spec, the one you linked is a simplified spec that doesn't cover the signalling and timing of the bus. The full spec is many times larger.
As Alex I mentioned, there may be better alternatives for what you need. If your SDIO host supports SPI mode, most microcontrollers do have SPI peripherals that can act as slaves rather than hosts, so this may be an avenue without a peripheral. If your data rates are low enough, a simple UART may suffice (you can reasonably hit 1 Mbit over short distances).
I dont know if this questions is relevant here or superuser, but ask anyway.
I have below mentioned setup- A Linux Desktop PC system. To this is connected one custom FPGA development board.In this FPGA there is an Ethernet Network Card IP realized and executing. This board is connected to the FPGA development board using USB ports-USB cable, and Serial cable. Essentially this whole setup tests the FPGA based Network card and the associated ethernet drivers realized thereon.
There are many applications which run on the host linux pc and send the data to the FPGA based Ethernet n/w card, which accepts it, does the necessary processing and sends to the physical layer realized on the FPGA which then sends it out over the ethernet network to some other node/device on the network.
This setup works fine, even when multiple applications from the host-pc send data to the FPGA network card. As one of the applications, i use a Linux based VLC player(its a multimedia player) to play some multimedia streams from the Linux-host and that data is sent to the FPGA network card. In the VLC player, i seek (reverse/ forward) the stream using the vlc player controls. When i do this seek operation continuously, it makes the linux host pc. hang/freeze. No i/o device work, only reboot works.
Now i tried to see the logs in the linux host pc /var/log (dmesg) to see if i get a clue about what process/application caused the freeze, but i could not get any input from it.
How do i proceed to isolate different components(Software , Hardware, ) involved in this whole setup of mine to narrow on the problem root cause?
Is there any way to communicate to the frozen linux-host via some means(Serial cable or some other connection to get any data from it when it hangs?
What steps i should follow? How can i tell if the VLC application is a problem or the FPGA network card driver is a problem, or the something else ?
Any pointers will be useful.
Thanks.
-AD.
You mention that the Linux host is frozen. I would first determine if it is actually locked up in the kernel or if there is some user space process(es) consuming too much CPU.
Can the host be pinged (preferably on an interface separate from your FPGA Ethernet card)? If it replies, the kernel is not locked up.
Hardware Problem?
If possible, can the setup be temporarily changed to remove the FPGA Ethernet card and then reproduce the problem? I would do this to help isolate issues specifically related to the hardware (FPGA Ethernet).
User Space (Software) Problem?
If you remove VLC from the equation, can you still get the lockup/hang to happen by using another method to generate Ethernet traffic?
You might try creating a shell that runs at a higher priority in order to retrieve data when the system seems to hang. Perhaps by running top in this high priority shell you can determine who, if anyone, is using all the CPU. You can run this shell over the network (telnet/ssh) or via a serial terminal.
#include <errno.h>
#include <sched.h>
#include <stdio.h>
#include <unistd.h>
int main()
{
struct sched_param scheduling_parameters;
scheduling_parameters.sched_priority = 10;
if (sched_setscheduler(getpid(), SCHED_FIFO, &scheduling_parameters) < 0) {
printf("error is %d\n", errno);
}
execlp("/bin/bash", "bash",0, 0, 0, 0);
return 0;
}
Kernel (Software) Problem?
You can enable the magic sysrq key and examine the system state and go from there. Kernel developers use this interface to debug their software. The CONFIG_MAGIC_SYSRQ option has to be enabled at kernel compile time in order to use this functionality.
After empirically narrowing a bug down to a specific module, printk() is still a good resource.
It may also be helpful to enable the kernel debugger (KDB) and connect to it via a serial cable.
#Jscheimer: thanks for a detailed pointers on my problem. After lot of debugging & some discussions with other system developers at work place, i finally found the root cause. There is a DMA peripheral which comes into picture in this whole setup. The DMA was comfigured for aligned access, but somewhere in some data transfer it was receiving a unaligned address, as a result of not checking the buffer alignment by me in the code, which was causing the hang/freeze. And there was no pattern to this behaviour.