We have created udev rules to make the device naming consistent for the cdc-wdm devices, no matter in what order our lte usb devices are registered at the usb bus. We had the issue that we could not rename the cdc-wdm devices, which I understand is some limitiation of the usbmisc driver. So we ended up creating symlinks
ACTION!="add|change", GOTO="mm_naming_rules_end"
# only rename the interfaces if the names are wrong
SUBSYSTEM=="usbmisc", ACTION=="add", KERNELS=="1-1.1.2", KERNEL=="cdc-wdm*", SYMLINK+="cdc-lte0"
SUBSYSTEM=="usbmisc", ACTION=="add", KERNELS=="1-1.1.4", KERNEL=="cdc-wdm*", SYMLINK+="cdc-lte1"
LABEL="mm_naming_rules_end"
But ModemManager does not recoqnize those devices when we use that in our nmconnection file
[connection]
id=wwan0
uuid=280d17ff-f4d4-4f47-a6e6-75ba32bc57c2
type=gsm
interface-name=cdc-lte0
permissions=
[gsm]
#apn=internet
[ipv4]
dns-search=
method=auto
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto
[proxy]
Related
I am running gem5 version 22.0.0.2. I operate Garnet in a standalone manner in conjunction with the Garnet Synthetic Traffic injector. I want to emulate a routerless NoC so I guess I need to connect an end point (e.g, Cores, Caches, Directories) to more than one "local" router. I just use a python configuration to configure the topology. But when I do this, there is a runtime error:
build/NULL/mem/ruby/network/garnet/GarnetNetwork.cc:125: info: Garnet version 3.0
build/NULL/base/stats/group.cc:121: panic: panic condition statGroups.find(name) != statGroups.end() occurred: Stats of the same group share the same name `power_state`.
Memory Usage: 692360 KBytes
Program aborted at tick 0
Here is a description from the gem5 documentation: "Each network interface is connected to one or more “local” routers which is could be connected through an “External” link." Here is the link:https://www.gem5.org/documentation/general_docs/ruby/heterogarnet/
Here is the constructor of Stats::Group
Group(Group *parent, const char *name = nullptr)
Here is a description from the gem5 documentation: "there are special cases where the parent group may be null. One such special case is SimObjects where the Python code performs late binding of the group parent."
Here is the link:https://www.gem5.org/documentation/general_docs/statistics/api.
I guess the error may be related to this, but I don't know the exact reason.
Any help would be appreciated.
Thank you.
Looking through tinyusb, am a bit confused on the meaning of RHPort - cannot find much on Internet, grepping through source gives me results like:
tinyusb/docs/info/changelog.rst:- Add rhport to hcd_init()
tinyusb/docs/info/changelog.rst: - Support multiple usb ports with rhport=1 is high
...
tinyusb/examples/device/cdc_dual_ports/src/tusb_config.h:// RHPort max operational speed can defined by board.mk
...
tinyusb/examples/device/cdc_dual_ports/src/tusb_config.h:// Device mode with rhport and speed defined by board.mk
...
tinyusb/examples/device/cdc_msc/src/tusb_config.h:// RHPort number used for device can be defined by board.mk, default to port 0
...
... and trying to think of what could "RH" possibly stand for as an acronym, the only thing that pops in my head is "Right Honourable" :)
So, what is the meaning of RHPort in (tiny)USB?
Ok, I think I found at least some sort of an explanation ...
Anyways, https://docs.tinyusb.org/en/latest/reference/getting_started.html says:
Port Selection
If a board has several ports, one port is chosen by default in the
individual board.mk file. Use option PORT=x To choose another port.
For example to select the HS port of a STM32F746Disco board, use:
$ make BOARD=stm32f746disco PORT=1 all
A bit tricky to find where that PORT is used, then - but for the above example, it is most likely in https://github.com/hathach/tinyusb/blob/master/hw/bsp/stm32f7/family.mk :
...
CFLAGS += \
...
-DBOARD_TUD_RHPORT=$(PORT)
...
... which then gets used in e.g. https://github.com/hathach/tinyusb/blob/master/examples/device/dfu_runtime/src/main.c :
...
// init device stack on configured roothub port
tud_init(BOARD_TUD_RHPORT);
...
... which reveals, that "RH" in "RHPort" most likely stands for "Root Hub".
So, my guess is, that for boards that have multiple physical USB port connectors, the RHPort determines which of those ports is tinyusb targeting?
I'm learning Vulkan by API spec (http://vulkan-spec-chunked.ahcox.com/ch02s09.html), and I'm little confused about how physical devices are in Vulkan. I do have only one intel physical video card device, but vkEnumeratePhysicalDevices returns count of 2. The devices are identical, but the queue flags seems differ, and the queue flags are undocumented (actually they are, but only to flag 8, in second queue I do have the flag values 16 and 32).
typedef enum VkQueueFlagBits {
VK_QUEUE_GRAPHICS_BIT = 0x00000001,
VK_QUEUE_COMPUTE_BIT = 0x00000002,
VK_QUEUE_TRANSFER_BIT = 0x00000004,
VK_QUEUE_SPARSE_BINDING_BIT = 0x00000008,
} VkQueueFlagBits;
here is the output of my vulkan code:
GPU count: 2 ( physical devices )
Physical Device 0:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 7
Count: 1
ts Valid Bits: 24
Physical Device 1:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 49
Count: 0
ts Valid Bits: 1
Someone can help me understand why there is 2 physical devices for the same real device and the missing flags ?
The count=0 of the second device is curious. More seriously, its flags and tsVB values are corrupted (49 is not an valid value for flags and 1 not valid for tsVB).
This pretty much boils down to there being one extraneous *.json file on your system.
These *.json files store informations about ICDs present on the machine. They are stored in standard location(s).
vkEnumeratePhysicalDevices+vkGetPhysicalDeviceProperties are relatively dumb commands doing nothing much else than reading said *.json file(s) and returning its contents. I think though that calling something "real" like vkCreateDevice would not work on the badly installed driver.
What exactly happened to creare this problem is up to your curiosity to explore. For starters I believe on Linux distros there is a command to map a file to its originating package. It will probably be something about bad cleanup of previous driver, or possibly bug in the installation script of the new one. At least one person had this problem before.
Based on what I explained here, I believe this is relatively benign bug. The first device should work just fine. And you can just ignore the second one. Or simply delete its *.json manifest to prevent it from showing up in vkEnumeratePD.
I am trying to establish a bluetooth serial communication link between a Raspberry Pi Zero W, running Raspbian Jessie [03-07-2017], and an Arduino (UNO).
I am currently able to write data to the Arduino using bluetoothctl.
The application requires that we are able to write data to a particular BLE Slave. There are multiple [HM-10] Slaves to switch between, the Slave needs to be chosen during the program execution.
There is no BAUD rate preference. Currently, we are using 9600 universally.
Functions have been created that automatically connect and then write data to an "attribute", this shows up as data on the Serial Monitor of the Arduino.
Python Code - using BlueZ 5.44 (manually installed):
import subprocess
from subprocess import Popen, PIPE
# Replaces the ':' with '_' to allow the MacAddress to be in the form
# of a "Path" when "selecting an attribute"
def changeMacAddr(word):
return ''.join(c if c != ':' else '_' for c in word)
# Connects to a given MacAddress and then selects the attribute to write to
def connBT(BTsubProcess, stringMacAddr):
BTsubProcess.stdin.write(bytes("".join("connect "+stringMacAddr +"\n"), "utf-8"))
BTsubProcess.stdin.flush()
time.sleep(2)
stringFormat = changeMacAddr(stringMacAddr)
BTsubProcess.stdin.write(bytes("".join("select-attribute /org/bluez/hci0/dev_"
+ stringFormat +
"/service0010/char0011" + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Can only be run once connBT has run - writes the data in a list [must have numbers 0 - 255 ]
def writeBT(BTsubProcess, listOfData):
stringList = [str('{0} ').format(elem) for elem in listOfData]
BTsubProcess.stdin.write(bytes("".join("write " + "".join(stringList) + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Disconnects
def clostBT(BTsubProcess):
BTsubProcess.communicate(bytes("disconnect\n", "utf-8"))
# To use the functions a subprocess "instance" of bluetoothctl must be made
blt = subprocess.Popen(["bluetoothctl"], stdin=subprocess.PIPE, shell=True)
# blt with then be passed into the function for BTsubProcess
# Note: the MacAddresses of the Bluetooth modules were pre-connected and trusted manually via bluetoothctl
This method works fine for small sets of data, but my requirements require me to stream data to the Arduino very quickly.
The current set up is:
Sensor data (accelerometer, EEG) via USB serial is received by the Pi
The Pi processes the data
Commands are then sent to the Arduino via the in built bluetooth of the Pi Zero W
However, while using this method the bluetooth data transmission would delay (temporarily freeze) when the sensor data changed.
The data transmission was flawless when using two pre-paired HM-10 modules, the Pi's GPIO serial port was configured using PySerial.
The following methods have also been tried:
Using WiringPi to set-up a bluetooth serial port on the /dev/ttyAMA0
using Python sockets and rfcomm
When attempting to use both of these methods. The Python code compiles, however, once the Serial Port is opened the data is seemingly not written and does not show up on the Arduino's Serial Monitor.
This then cripples the previous functions. Even when using bluetoothctl manually, the module cannot be unpaired/disconnected. Writing to the appropriate attribute does not work either.
A restart is required to regain normal function.
Is this approach correct?
Is there a better way to send data over BLE?
UPDATE: 05/07/2017
I am no longer working on this project. But troubleshooting has led me to believe that a "race condition" in the code may have led to the program not functioning as intended.
This was verified during the testing phase where a more barebones code was created that functioned very well.
I have an atmel UC3-L0 and compass sensor. Now I install AtmelStudio and download some demo code into the board. But I have no idea where the function printf in demo code will appear the data. How should I do to get the data?
The printf function outputs to stdout.
Usually on a "naked" processor with no operating system you need to define how a character is sent or received from a physical interface (usually an USART, console port, USB port, 4-port LCD interface, etc.). So typically you may want to use the USART port of your processor board to connect to a PC running Hyperterm, PuTTY or similar using a serial cable.
In essence you will need to
create FILE streams using the fdev_setup_stream() macro and
provide pointers to functions get() and put() that tell the printf() function how exactly to read and write from/to that stream (e.g. read/write to a USART, an LCD display, etc.).
you may have libraries - depending on your hardware - that already contain such functions (plus the correct port initialisation functions), like e.g. uart.c/.h, lcd.c/.h, etc.
In the documentation of stdio.h (e.g. here) look for the following:
printf(), fdev_setup_stream()
If you have downloaded Atmel Studio you may look into the stdiodemo.c code for further insight.
In order to use printf in ATMEL studio you should check the following things:
Add and Apply the Standard serial I/O module from Project->ASF Wizard.
Also add the USART module from the ASF Wizard.
Include the following code snippet before the main function.
static struct usart_module usart_instance;
static void configure_console(void)
{
struct usart_config usart_conf;
usart_get_config_defaults(&usart_conf);
usart_conf.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
usart_conf.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
usart_conf.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
usart_conf.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
usart_conf.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
usart_conf.baudrate = 115200;
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &usart_conf);
usart_enable(&usart_instance);
}
Make Sure you call the configure_console after system_init() from the main function.
Now go to tools->extension manager. Add the terminal window extension.
Build and Run your program and open the terminal window from view-> terminal window. put the correct com port to which your device is running on and set the baud to 115200 and hit connect on the terminal window.
You should see the printf statements now. (Float doesn't get printed in Atmel studio)
I was recently puzzling over this myself. I has installed Atmel Studio 7.0 and was using the SAMD21 Dev Board via an example project in which a call to printf was made.
In the sample code I saw that there was a configuration section:
/*!
* \brief Initialize USART to communicate with on board EDBG - SERCOM
* with the following settings.
* - 8-bit asynchronous USART
* - No parity
* - One stop bit
* - 115200 baud
*/
static void configure_usart(void)
{
struct usart_config config_usart;
// Get the default USART configuration
usart_get_config_defaults(&config_usart);
// Configure the baudrate
config_usart.baudrate = 115200;
// Configure the pin multiplexing for USART
config_usart.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
config_usart.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
config_usart.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
config_usart.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
config_usart.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
// route the printf output to the USART
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &config_usart);
// enable USART
usart_enable(&usart_instance);
}
In windows device manager I saw that there was an "Atmel Corp. EDBG USB Port (COM3)" listed under "Ports". However, the one of the "Properties" of this port was listed as 9600 Bits per second. I changed this from 9600 to 115200 to be consistent with the config section above.
Finally, I ran PuTTY.exe and set the Connection-->Serial setting to COM3 and 115200 baud. Then I went to Session, then clicked the Serial Connection Type, then clicked the Open button. And, BAM, there's my printf output via PuTTY.