How do I determine the General Purpose Interface Bus primary/secondary addresses using General Purpose Interface Bus commands?
If you want to see what addresses are in use on the bus you can send an unlisten. Then send an address to listen for each address on the bus, monitoring for the NDAC going low. You have to unlisten each device. The 488.2 spec has a command look for all Devices. There is also the 488.2 command *STB? To get the status byte from each instrument. But that requires all instruments to conform to 488.2. A serial poll with a check for each device then check the status byte.
The secondary addresses are private to each device. They are not necessarily addresses. They may be device specific commands. You’ll need the manuals.
Related
I'm controlling a couple of i2c slaves (PCA9505) using the I2C module of National Instruments LabVIEW. I need to improve the project so I can add new slaves to the bus without manually adjusting the address of the slaves. (pins A0 A1 A2 on PCA9505). As a consequence, hardcoding the addresses is not a option.
Also, PCA has only 3 pins, so I can add max 8 slaves. I need to go for 16.
How can I give the slaves dynamic addresses?
How can I expand to 16 slaves?
Thanks for your help!
PS: PCA9505 = 40-bit parallel input/output (I/O) port expansion for I2C-bus applications
Personally, I like to use a configuration file to set the parameters needed for an application. In this case, it would define the addresses for each device you need to talk to. Arrays also help a lot here for expandability.
As far as extending your I2C bus, you can use something like a PCA9544A I2C mux. This chip allows for controlling 4 different buses. You will have to control the mux as part of your addressing of the individual chips.
From a brief read of the PCA9505 datasheet it doesn't look as if there's any way of selecting the device's address other than using those address lines. You are either going to have to multiplex the bus as crossrulz suggests, so that each device is at the same address on a different I2C bus, and add code to control which one you talk to at any one time, or add some hardware that sets the address lines differently for each device.
Will the devices be added to the bus via some sort of connector? If so could you include the address lines in the connector, so that each connector on the master adapter sets a different address for the device that's plugged in to it? Or if you connect devices in a daisy chain, each device could add 1 to the address on its upstream connector and output the new address on its downstream connector?
I learned on OSDev wiki that Endpoint 0 is the default control pipe, allowing for bi-directional control transfers. This is used for device configuration, e.g. to retrieve device descriptors. The USB 2.0 spec explains this more thorougly in section 5.5 Control Transfers.
There are also a limited amount of endpoints available (2 for low-speed, 15 for full- and high-speed devices). Somewhere in the USB 2.0 spec, I have read that there must be at least one control pipe. This implies that there may be multiple control endpoints, but what is the use of it? Do you know any particular USB device or class that has an EP configured as control pipe?
Later, I found this in the spec, section 10.1.2 Control Mechanisms:
A particular USB device may allow the use of additional message pipes
to transfer device-specific control information. These pipes use the
same communications protocol as the default pipe, but the information
transferred is specific to the USB device and is not standardized by
the USB Specification.
If I understand it correctly, this means that non-EP0 cannot be used to configure the device (say, a standard request such as GET_DESCRIPTOR). But the setup/data/status stages seem still to be available ("[..] use the same communications protocol [..]"). Is this correct? Or is the use of standard/class requests forbidden for non-EP0?
Background: while working on an emulated USB device in QEMU, the need for a USB monitor for debugging purposes appeared. During inspection of the QEMU core USB code, I noticed that it only processed control commands for EP0. Other endpoints would be treated as data. There are some virtual devices (host-libusb) that always reject control transfers for those other endpoints. Hence the question whether this is the correct behavior or not (and if valid, whether there exist devices that really implement this).
As far as I can tell, there is no use for a non-EP0 control endpoint. I have developed several products that use custom control transfers on endpoint 0 as the main way to send device-specific requests and I have not encountered any fundamental problems with doing that.
If you did make a non-EP0 control endpoint I think your understanding is correct; you wouldn't be able to use it for standard requests but you would be able to use it for custom requests and the transaction sequences would be the same as on EP0.
I have an embedded system that controls a motor using pwm and some other things, I send commands through a serial connection, which is connected to a Fastrack Wavecom Supreme GSM Module. However, the module connected to the embedded system (the client), fails to send the message to the server module.
I have been able to send messages back and forth between the two wavecom modules, however, when I try and send from my PIC18F45k22 to the wavecom module, it fails.
Any ideas of what could be going wrong?
You did not specify what type of serial communication you are using. For instance, if you are using the PIC's SPI module you may be sampling on the wrong edge of the clock. There are at least 2 common SPI modes widely used and 4 all together. If you are using the PIC's UART there are "a whole bucket full" of setting that may be off. Speed, number of bits, in band signaling, out of band signaling, parity, ect.
I'm developing an embedded USB device which needs to be available to two different hosts.
The first is a normal PC, where it will be used as a MSC (mass storage) device, and the second is a specific hardware which the USB device needs to comunicate with a CDC profile.
during the enumeration, the USB device send descriptor table where it declares its capabilities.
Is there a way in the enumeration process to know to which host the device was connected to ?
The simplest solution perhaps would be to implement a "USB Composite Device", where the single device presented both the MSC and CDC class interfaces simultaneously. The host PC would see both interfaces, but you could simply leave one unused. The "specific hardware" would probably simply ignore the MSC class if it had no support for it.
Does anyone know how to create a raw socket to a USB device? Like you can create raw sockets to ethernet devices, I would like to send/receive arbitrary data to a USB device.
Depends on the platform - you need a low level USB library.
Either http://sourceforge.net/projects/libusb/ or http://sourceforge.net/projects/libusb-win32/ is a good place to start
ps. It isn't a socket as such, sockets are specific to networks
You can write to the EndPoint using a Raw Socket but a certain protocol needs to be followed for the device to physically accept and reply to commands.
Depending on how the protocol is written you may be able to use a a RawSocket and some Usb sniffer to replay the data to the EndPoint but most devices employ a Timestamp and handshake process which needs to be performed dynamically for each connection and usually involves querying the device state and using the information to complete the handshake along with other information depending on the protocol of the device in question.