I want to setup WiFi direct on my target.
Output of iw list
Supported interface modes:
* IBSS
* managed
* AP
Band 1:
Band 2:
software interface modes (can always be added):
valid interface combinations:
* #{ IBSS, managed, AP, P2P-client, P2P-GO } <= 4,
total <= 4, #channels <= 2, STA/AP BI must match
Looking at the above output I have following doubts:
How can I confirm whether my device supports WiFi direct feature or not.
What are software interface modes (can they be configured to WiFi Direct)
I tried the steps mentioned in particular link
http://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_NLCP_WiFi_Direct_Configuration_Scripts#P2P_usecases
But when I run p2p_find under wpa_cli terminal it every time it returns FAIL
Please guide where I am going wrong and how can I setup and configure WiFi direct in my target.
Thanks in advance.
Wi-Fi Direct feature was disabled in the driver installed, so I was not able to configure my device for Wi-Fi direct.
So to answer my questions, this is the output of iw list after enabling the Wi-Fi direct bit in driver module.
Supported interface modes:
* IBSS
* managed
* AP
* P2P client
* P2P Go
Band 1:
Band 2:
software interface modes (can always be added):
valid interface combinations:
* #{ IBSS, managed, AP, P2P-client, P2P-GO } <= 4,
total <= 4, #channels <= 2, STA/AP BI must match
What are software interface modes (can they be configured to WiFi Direct)?
Software interface modes suggests the different interface modes supported by the driver but all may not be enabled at present.
All the enabled interfaces are listed under Supported interface modes:
Related
I'm working on a minimal hobby operating-system. I want to write a driver for xHCI in order to support USB keyboards and mouses. I'm using QEMU for virtualization. I'm passing the -device qemu-xhci parameter to qemu so that it emulates the xHCI. I was wondering if the modern operating-systems use the MCFG ACPI table to find the configuration space of PCI (and the registers of the xHCI)? I was also wondering how to enable PCI-Express in QEMU so that I can find a MCFG table in RAM so that I can support the latest technology in my hobby OS.
To find all xHCI controllers you search PCI configuration space for devices ("functions") with matching "class/subclass/progID" values (see note 2); which means that you have to find a way to access PCI configuration space first.
On 80x86; there are 3 possible ways to access PCI configuration space - 2 that use IO ports ("mechanism #1" and the deprecated "mechanism #2"), and one that maps PCI configuration space into the physical address space (called "Enhanced Configuration Access Mechanism").
If the Enhanced Configuration Access Mechanism is supported; the MCFG ACPI table describes how PCI configuration space is mapped into the physical address space. Primarily; PCI buses are described as "groups of buses", where each group (defined by a "starting bus number" and "total buses in this group" pair) has a base physical address, and the correct physical address for a PCI function is determined by finding information for the relevant group of buses for the requested bus number, then doing a calculation like:
physical_address = base_physical_address_for_group +
(bus_number - starting_bus_number_for_group) << 20 +
device_number << 15 +
function_number << 12 +
offset;
Note 1: because most operating systems use virtual memory it's possible for an OS to create a nice "virtually linear" mapping of the ("possibly physically disjoint") physical memory areas described by MCFG ACPI table (while using the same page full of zeros mapped as read-only to fill any gaps in the "virtually linear mapping"); so that the OS can use a simplified approach (with no need to find information for the relevant group of buses) like:
virtual_address = PCI_config_space_base_virtual_address +
bus_number << 20 +
device_number << 15 +
function_number << 12 +
offset;
Note 2: An OS doesn't/shouldn't literally search PCI configuration space each time it wants to start a device driver for one specific type of device. Instead an OS typically enumerates PCI buses once during boot (and possibly after boot in response to a notification if "hot-plug PCI" is supported) and starts device drivers based on the results of that enumeration. In other words, it's more like "I found an xHCI controller and need to start the appropriate driver" and not like "I want to start an xHCI driver and need to find the appropriate device/s".
For a fast ADC sampling USB device, I am using the USB 2.0 High Speed capable STM32F733 with the embedded USB-HS PHY. In USBView, I can see that the device is enumerated, the libusb code opens the device and claims interface, but when I try to receive data with libusb_bulk_transfer, the operation times out (return code -12). Things I have tried: I have confirmed than when I request data with libusb_bulk_transfer, the device is interrupted. Note: I have DMA enabled in my class configuration C file and it is not clear to me how that is triggered. I have verified that the transfersize and packet count registers are being set correctly by the LL library function, and that when I request data from
Any tips on debugging such problems will be much appreciated - this board is my undergrad thesis due in under two months!
Desktop sequence:
libusb_get_device_list, libusb_get_device_descriptor, libusb_open, libusb_get_string_descriptor_ascii, libusb_free_device_list, libusb_bulk_transfer(devh, fat_EPIN_ADDR, inframe, fat_EPIN_SIZE, &gotBytes, 100). Where gotBytes is integer, and inframe is a large array.
Device firmware:
MX_USB_DEVICE_Init();
uint8_t txBuffer[10*fat_EPIN_SIZE];
while (1)
{
USBD_LL_Transmit(&hUsbDeviceHS, Custom_fat_EPIN_ADDR, txBuffer, Custom_fat_EPIN_SIZE);
HAL_Delay(1);
}
Custom_fat_EPIN_SIZE is 0x200 and the endpoint address is 0x81 (EP IN 1)
Installed driver for device is WinUSB (verified in Device Manger to be winusb.sys), and I am linking libusb-1.0 into my desktop program. You can find my source code at https://gitlab.com/tywonemi-school-stuff/silicon-radar-fun, the firmware is My SW/v1 and the desktop software is a Qt Creator project in My SW/Viewer, of note is usb.cpp. You can also compare with testing project/HIDTest, which is code that I tested with STM32F303 nucleo dev board where I was able to read an array through IN bulk endpoint with the Viewer application. However, F3 has the USB peripheral, while F7 has OTG_USB, and I am now attempting USB 2.0 compliant HS so there may be more protocol-based pitfalls. You can also find the output of the device descriptor etc from USBView in my SW/USBView_broken.txt
EDIT 1: I have found finally some concrete error in the STM32 behavior. The DMAADDR is set for EPIN 0x81, and never increments, despite the DMA being enabled. I have went through literally every occurrence of the word "DMA" in the USB_OTG periphery.
I thought it might be that my linker script makes my array be stored in DTCM or similar, and the OTG DMA can't access it, but the address of txBuffer is 0x2003EBEC which is in SRAM2. The AHB matrix in the reference manual clearly shows, that the USB OTG HS DMA is master for a bus that SRAM2 is a slave of. And DTCM is connected too. I will look for application notes for USB OTG HS DMA - it just seems to be refusing to copy data!
I have fixed my issue by disabling the DMA setting. I have re-read the relevant portions of the reference manual and still don't know how exactly the values propagate into the Tx FIFOs. It is possible that DMA-less operation will be a major bottleneck in my project, I might return to this later.
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 am using a USB port port operating as a virtual COM port to achieve serial communication with an external device using MATLAB or Visual Basic 6. I am facing baud rate limitations depending on the software I use to communicate with the device. MATLAB (2018a) has no problems because it can set high baud rates. Visual Basic 6 on the other hand faces limitations on the baud rates that can be set in the software. In terms of solutions, I have looked into this to set a higher baud rate in Visual Basic 6: https://www.mev.co.uk/pages/Support/VB-Baud.html
The drivers for the virtual COM port are made by FTDI and can be found here: http://www.ftdichip.com/Drivers/VCP.htm . After configuration in the Device Manger, the device I am communicating with appears under 'Ports (COM & LPT)' as 'USB Serial Port (COM4)' in the Device Manager.
The device requires a baud rate of 1000000 and 2 stop bits for successful communication (if you need any more information, please let me know). As far as I am aware, the baud rate set in the software to communicate via the serial port has to be 1000000 to match that of the external device I am using. I think my problem might require a bit an explanation of how serial communication works when a USB port is acting as a virtual COM port because I worry that it differs from communication using a 'real' serial port, if possible. The FTDI driver appears to be very flexible so I do not understand why Visual Basic cannot tap into this flexibility. Is it impossible to set a baud rate of 1000000 in Visual Basic 6? If it is impossible, are there any methods to overcome this limitation?
The VB6 code for baud rate setting is found below, where 'Port' is the address of COM port e.g. COM4, COM3:
MainForm.MSComm1.CommPort = Port
MainForm.MSComm1.Settings = "9600,N,8,1"
If anyone can help me understand how serial communication works in this setting and if I can overcome the constraints of Visual Basic 6, I would be very grateful.
It seems that you are using MSComm32.ocx, not VB6 directly.
The maximum speed you can set for this is 256,000 bps.
How to send to the serial port by using Mscomm32.ocx
The following baud rate values are valid: 110, 300, 600, 1200, 2400, 4800, 9600 (default), 14400, 19200, 28800, 38400, 56000, 57600, 115200, 128000, 256000.
If you want more speed, please use Win32 API directly with the following library etc.
Serial port programming VB6 via Win32 API
Serial Port Communication
Serial port programming on Visual Basic with Windows API
grricks/vb6SerialAPI
Or, can it be used if the library provided by FTDI is defined by Declare Function like the above library?
D2XX Programmer's Guide
6.9 FT_W32_SetCommState
Example
FT_HANDLE ftHandle; // setup by FT_W32_CreateFile
FTDCB ftDCB;
if (FT_W32_GetCommState(ftHandle,&ftDCB)) {
// FT_W32_GetCommState ok, device state is in ftDCB
ftDCB.BaudRate = 921600; // Change the baud rate
if (FT_W32_SetCommState(ftHandle,&ftDCB))
; // FT_W32_SetCommState ok
else
; // FT_W32_SetCommState failed
}
else
; // FT_W32_GetCommState failed
What is the Difference between BGAPI and BGScript ?
And if we write any code for BG profile than how can we burn it in BLE 112?
The BGAPI interface defines the protocol used to talk to the module over USB or serial link.
BGScript is something which runs on the module processor itself, when the USB or serial link is not used.
I have the dongle, BLED112, which is the same thing as BLE112 with a USB connector on it, and the code is "burned" to it using standard USB DFU interface.
The downloading of the code to BLE112 can be done using several methods:
(1) Bring out the DD, DC debug interface pins from your module and use the CC-Debugger (digikey part 296-30207-ND, $55). This works every time. If you have the DKBLE112 kit, the CC-Debugger fits on the 10-pin .050 connector in lower right corner. You can "burn" any firmware and any stack this way. Works awesome.
(2) Hope that the current firmware on the CC2540 has serial bootloader, and load the new firmware (hopefully also containing serial bootloader) using UART. TI has the tools, but it sure seems quite convoluted to me, and I did not try it.