I was wondering how a port for a given device controller is chosen and how it knows the values on address/data/control bus are for him.
Let's take the 8259A PIC for example, which is connected that way to the address/data/control bus:
8952A Programmable Interrupt Controller
I can see the active low CS (Chip Select) pin that is used to enable the PIC and be able to read/write on it, is connected to the address bus... But to what line? (That is the part I don't get). How does the address bus know when to activate the CS pin?
I believe that CS pin must be activated when the address bus is 0x20 or 0x21 (ports used by master PIC) and the CPU did not assert the M/#IO control line to read/write from/into I/O space (with the IN and OUT x86 instructions). But I don't get why the CS pin is connected to whatever address bus line since other ports are used by other devices controller.
Related
I am using a BeagleBone Black board (kernel 4.14.108-ti-r104) to create USB gadget using configfs/functionfs. I compose my gadget (using gadgettool) providing details about device configuration (function, vendor id, product id and ton of other params), run my userspace program that writes descriptors and strings to ep0 and connect the device to host. All works fine, I get BIND (when binding device to UDC) and ENABLE (when actually host is connected) events and my device can read from ep2 and write to ep1. Using wireshark I see the communication looks good, device and configuration descriptors as well as strings are exchanged.
The problem starts when I connect the device to another host. Unfortunately I have almost no control over that host, in particular I cannot run wireshark there, I don't even know the OS. The only thing I can do is to plug/unplug device, optionally see a message that device was detected and optionally a restart. What I see on the gadget side is that following BIND and ENABLE events I immediately get SUSPEND event and read on ep2 fails with 108 (ESHUTDOWN). Now the question is how to track the problem down.
I tried usbmon, but it seems it does not listen to traffic when device is in gadget mode. I have also seen https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/udc/trace.h file which seems to define some udc trace points, but I am not really sure how they can be used.
So the final question is simple: how do I get any information about traffic on USB bus having access only to gadget side? I don't need full trace, but al least some information which packets were exchanged would be super useful. Did it fail while exchanging device descriptors, configuration/interface/endpoint descriptors or strings or something totally different?
Small update:
The whole thing is about Android Open Accessory Protocol and I am trying to write a gadget that would connect to this accessory.
I have changed my gadget composition somewhat and now I know the gadget is being identified by host (it displays manufacturer/model) so I suppose the issue is not in device descriptor and strings. I have used two additional flags in descriptors (FUNCTIONFS_ALL_CTRL_RECIP | FUNCTIONFS_CONFIG0_SETUP) and when connecting to my computer I get setup event (request 51 as expected), but when connecting to my accessory I still get SUSPEND/ESHUTDOWN. This time though it looks like the time between ENABLE and SUSPEND is much greater (over 10 seconds) which looks to me as if the host send some message, but this message was not processed by my gadget and then the host timeout out and disabled usb device. Still don't know how to find out if the accessory sent anything to gadget and what it was...
i am using I2C base sensor. But that sensor is not having address(slave). So can i communicate with it without address. It will send ack and data?.
According to the The Slave Address chapter (p. 21, Figure 10, MMA7660FC datasheet), MMA7660FC has fixed (hardwired) slave address which is normally 1001100 (0x4C). It could be changed to another in range (0x08 to 0xEF) by request to factory.
So, this is normal I2C device (with address), you could communicate with it using 0x4C slave address.
Well, if you unsure what address the sensor has, try to poll sensor with different addresses in a loop. Sensor must answer to one of addresses.
In general, two communicate between bluetooth devices, first we perform a bluetooth pairing between two devices and then starts further communication between them.
My problem scenario is simply to transfer a hello packet from one bluetooth device to another bluetooth device.
For this i am planning to use sockets programming technique i.e. RFCOMM sockets.
I got some help about this from http://people.csail.mit.edu/albert/bluez-intro/x502.html
So, my query is do we require bluetooth pairing between two devices before initiating communication with RFCOMM socket connection.
Or does 48 bits device address is only necessary to transfer some data packet from one bluetooth device to other and bluetooth pairing could be avoided.
No, it is not.
Bluetooth device can be in one of the four modes:
Broadcaster
Observer
Peripheral
Central
In broadcaster mode device can only send advertisement messages. This includes name and HwID.
In Observer mode device can only receive advertisement messages.
Peripheral = Broadcaster + can take in connect requests
Central = Observer + can send out connect requests.
If you have an application which does not want to connect use first two modes above.
Please let me know if this addresses your question.
I have old DOS program which works with serial port. And I need to port it to linux. I've connected my serial device to linux via USB (using rs232 cable). It appears as /dev/ttyUSB0.
Can I use functions inb, outb (instead of DOS equivalent inp, outp) for reading or writing in device from my code? (inb and outb special function for lowlevel reading-writing bytes to specific port address). I don't understand how to determine proper port number.
Maybe there is another approach - for example open file '/dev/ttyUSB0'. But in this case I have a problem reading device registers such as modem control register (MCR) or line status register (LSR).
You can use inb/outb or mmap (eg. devmem, depends on architecture) for onboard standard serial port but it is not recommended in userland. You need root priviledges, you can cause conflict with kernel's driver and you have to be sure that your hardware (eg. 16C550) is full compatible with your code.
To trigger your program when serial port added can use udev rule or old hotplug. To determine port in case of USB serial port converter you can use USB bus id and port id. You can check the numbers via lsusb -t command.
serial port configuration: http://linux.die.net/man/3/termios
check if there are received data (LSR): select()
data inb / outb -> read() / write()
MSR (DCD, RI, CTS) / MCR (DTR, RTS if hardware flow control disabled) -> ioctl() or tty_ioctl
You can learn from picocom source code
Possible problem for realtime application: delays caused by USB bus polling and process/thread switching.
I have to write a Ethernet PHY loopback test in Linux. I've never done it before and had no clue where to start. After some researching, I came up with the plan for the test, and I wonder if anyone can help me to verify it and give me some pointers to my questions.
This is a external loopback setup. It connects the TX+/- to RX+/- pins for each internal PHY's on the Ethernet switch chip.
So the loopback high level packet path is as follow:
CPU->PHY0(chip)->Ethernet switch(chip)'s internal PHY->PHY0(chip)->CPU
For this test, I plan to
configure the internal PHYs on the Ethernet switch with specific MAC addresses,
pack the Ethernet test packet using CPU's MAC address as the source address and the
MAC address configured in step 1. as the destination address,
send and wait to receive the test packet,
compare sent and received data pattern.
Any suggestions? Also, I wonder if there are functions in Linux that I can use to generate the packets for step 2, and send the packets for step 3.
Thank you very much.
Most Phys can be switched to a test mode. We used the bootloader to write directly to the
Phy and switch to testing mode.
There is also an ioctl taken from documentation/networking/phy.txt
Ethtool convenience functions.
int phy_mii_ioctl(struct phy_device *phydev,
struct mii_ioctl_data *mii_data, int cmd);
The MII ioctl. Note that this function will completely screw up the state
machine if you write registers like BMCR, BMSR, ADVERTISE, etc. Best to
use this only to write registers which are not standard, and don't set off
a renegotiation.