I have look around everywhere and cannot find any documentation about the values to put in TransmitPortMask of IR_TRANSMIT_PARAMS structure for use with IOCTL_IR_TRANSMIT.
All the documentation says is that it is "A bitmask that contains ports to transmit on".
Thus, I first tried:
PORT1 = 0x1
PORT2 = 0x2
It did not work!
Then, on my computer, I tried all the values and found out that:
PORT1 = 0x4
PORT2 = 0x2
Which is kind of weird values... especially for PORT1.
Of course, if I put -1 (or ~0, or 0xFFFFFFFF) it transmit the data on all ports simultaneously. But I want to control individual ports.
Now I am receiving reports from some users saying that it does not work on their systems, even though they are having the same version of Windows.
Hence I ask, what are the values I should put in TransmitPortMask?
I am using Windows 7 RC 32-bits.
I am using a Microsoft IR Blaster (not merely a compatible one, the real Microsoft one) that came with a Microsoft Media Center Remote
I found my answer. I post it here for posterity
Ports are the least significant bits of the mask but the last port as the LSBit.
example with 1 port: ---- ---- ---- ---1 LSB
example with 2 ports: ---- ---- ---- --12 LSB
example with 3 ports: ---- ---- ---- -123 LSB
Related
Sometimes, you need to know the serial port number when developing MCUs. For example, I plug the USB cable of the board into the USB port of my computer, then one serial port number appeared in the Device Manager, such as COM6. Then I can use the programmer to upload my program (.elf or .hex) to the MCU, the premise is that I specify the serial port number, namely, the 6 in COM6, to the programmer through the command.
For example, in command prompt of CMD.exe, I use "dwdebug.exe com6,l
test.elf,qr" to flash the MCU, the dwdebug.exe is the executable program which used for programming, the com6 is the serial port number, and test.elf is the code to be flashed into the MCU, l means "load", qr means "quit dwdebug.exe after loading, and run mcu".
In addition, I can use the command "dwdebug.exe ls,q" to list all the serial port number available in CMD.exe, for example, after running dwdebug.exe ls,q in CMD.exe, the outputs displayed in the CMD window:
COM5 .Expecting break byte 0x00, but no bytes read.
ATmega328P on COM6 at 62537 baud.
Then I planed to write a Makefile, part of the Makefile is:
COM = 6
PRG = test
MCU_TARGET = atmega328p
CLK = 8000000UL
UPLOADER = dwdebug
flash:
dwdebug ls,q
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
debug:
$(UPLOADER) device com$(COM),l $(PRG).elf
From the Makefile above we can see that the variable COM at the beginning of the Makefile must assigned by the user, the serial port number, namely, the value of COM, is used by dwdebug.exe for flashing and debugging.
So, I think it's better to extract the number "6" behind "ATmega328P on COM", and assigned it to the variable COM:
flash:
dwdebug ls,q
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
debug:
$(UPLOADER) device com$(COM),l $(PRG).elf
The advantage of doing this is that the user no longer need to view the Device Manager, namely, the user will not assign the serial port number (the 6) to COM at the beginning of the Makefile too, let the code finish the work automatically.
After searching many web pages, now I can save the outputs of "dwdebug ls,q" in a .txt file, such as:
flash:
dwdebug ls,q > serial.txt
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
Now, the content of serial.txt is:
COM5 .Expecting break byte 0x00, but no bytes read.
COM6 ................
ATmega328P on COM6 at 61934 baud.
But how to extract the number "6" behind "ATmega328P on COM", and use the "6" in Makefile as the value of variable COM? It is a difficult point that I cannot be overcome, is there anyway to overcome this problem?
Best regards.
P.S.1 "ATmega328P on COM" is not changed.
P.S.2 My OS is Windows 10
Extract the serial port number, and assigned it to a variable in Makefile.
i have to try get a class-map bit rate traffic from router cisco ios xe
i get a oid from cisco
https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/119031-technote-router-00.html
the OID of postbitrate is give me only Gauge32
+-- -R-- Gauge cbQosCMPostPolicyBitRate(11)
so when my police traffic is under number : 4,294,967,295 , i get i correct value
but when the traffic go up of 4,294,967,295 bit
of example my real policy-traffic bps is :4,665,204,000
and when i try to get in by snmp i get value 376,176,704 (9 dig only)
snmpwalk -v2c -c ABCDED X.X.X.X iso.3.6.1.4.1.9.9.166.1.15.1.1.11
iso.3.6.1.4.1.9.9.166.1.15.1.1.11.1298180580.131072 = Gauge32: 376176704
so how to convert a Gauge32 correct value when my traffic is go up of 4,294,967,295 bps
i know is 32-bit only can Handle maximum 4,294,967,295
but in cisco mib . and for policy-map postbitrate , is only return Gauge32 ...
This is called the "SNMP counter wrap" condition (you can google it).
This is detailed in this Cisco page
https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/26007-faq-snmpcounter.html
The only way for a management app to detect it is if the counter is smaller
than previously retrieved, at least one counter wrap occurred and you add 2^32-1 to
the latest value.
The alternative is to find the 64-bit counter, usually defined in a newer MIB.
I am trying to understand how the Linux GPIO numbers get their values.
e.g. GPIO mapping for Joule.
I tried reading linux documentation on Pinctrl Subsystem and also looked at the code of GPIO driver being used in Intel Joule :
https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/intel/pinctrl-broxton.c
However going this way looks very platform-specific. I am looking for some generic industry standard. Please help or please direct me to some good article.
First of all, one has to get the difference between Global System GPIO number (GSGN) and relative to the certain GPIO controller. Earlier, before the era of GPIO descriptors, the GSGN had been used. After switching to the descriptor scheme the numbering scheme moves from (semi-)static GSGN to dynamic one and thus makes nonsense to the user. Instead the label of the pin, if any, or a pair of GPIO controller handle with a number relative to it became in use. This is being dictated by the resource providers, such as ACPI and Device Tree. If, by some reason, user wants to get the pair of the controller and relative number, the libgpiod library and tools gives the possibility to achieve this.
So, the link to Joule GPIO numbering scheme is really fragile, users are not suppose to know the GSGN. There are ways how to get the controller and relative number on a running system. But usually it's all related to the driver and ACPI tables and doesn't require any user involvement.
Example:
Take into consideration the pin UART_1_TXD (by some reason it's named in that document wrongly, should be LPSS_UART1_TXD). According to pinctrl-broxton.c this is pin 43 on a GPIO controller with ACPI _HID INT34D1 and _UID 1.
List all enumerated GPIO controllers (optional step):
# gpiodetect
gpiochip0 [INT34D1:00] (83 lines)
gpiochip1 [INT34D1:01] (72 lines)
gpiochip2 [INT34D1:02] (42 lines)
gpiochip3 [INT34D1:03] (31 lines)
gpiochip4 [INT34D1:04] (20 lines)
Find one with _UID 1:
# grep -w 1 /sys/bus/acpi/devices/INT34D1\:0*/uid
/sys/bus/acpi/devices/INT34D1:00/uid:1
# gpiodetect | grep -w INT34D1:00
gpiochip0 [INT34D1:00] (83 lines)
So, the interesting pair is: gpiochip0 43.
In the actual resource provider it will look like this (taken from meta-acpi project):
...
* pin name pin number led
* -----------------------------------------
* ISH_GPIO_0_LS 35 heartbeat
* ISH_GPIO_1_LS 33 sd-card
* ISH_GPIO_2_LS 31 wifi
* ISH_GPIO_3_LS 29 led-3
...
GpioIo (
...
"\\_SB.GPO2", // GPIO controller
0) // Must be 0
{
22, // ISH_GPIO_0_LS
23, // ISH_GPIO_1_LS
24, // ISH_GPIO_2_LS
25 // ISH_GPIO_3_LS
}
...
Here you see the reference to the Device object thru a full path, i.e. \_SB.GPO2.
You may find more examples in meta-acpi project.
If by any weird case user really wants a non-sense number, this is the way:
# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/pinctrl/INT34D1\:00/gpio-ranges
GPIO ranges handled:
0: INT34D1:00 GPIOS [429 - 460] PINS [0 - 31]
32: INT34D1:00 GPIOS [461 - 492] PINS [32 - 63]
64: INT34D1:00 GPIOS [493 - 511] PINS [64 - 82]
# echo $((43-32+461))
472
More details about GPIO library and subsystem can be found in GPIO in-kernel documentation.
I'm building a project based on Socket-IO-client from here https://github.com/timum-viw/socket.io-client
I need to turn off all serial data being printed except what I send to serial. I've tried removing #define USE_SERIAL and removing or changing USE_SERIAL to use Serial1 port also edited SocketIOClient.cpp to remove debug statements in there but still getting a lot of this...
[WS][0][sendFrame] sending Frame Done (4506us).
[WS][0][handleWebsocketWaitFor] size: 2 cWsRXsize: 0
[readCb] n: 2 t: 597463
[WS][0][handleWebsocketWaitFor][readCb] size: 2 ok: 1
[WS][0][handleWebsocket] ------- read massage frame -------
[WS][0][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0 opCode: 1
[WS][0][handleWebsocket] mask: 0 payloadLen: 1
[readCb] n: 1 t: 597478
[WS][0][handleWebsocket] text: 3
I want to receive a websocket Message and print that to serial so arduino mega can read that serial passed to it. I don't want to have to parse all the serial being printed to find the message I actually need.
I'm using a basic nodemcu esp8266 12E module, coding with arduino ide 1.8.5. I'm sure there is something easy I'm missing.
It is very simple actually. In socketIoClient.h you have a define like so:
#define SOCKETIOCLIENT_DEBUG(...) Serial.print(__VA_ARGS__);
You can change it to:
#define SOCKETIOCLIENT_DEBUG(...) do{} while(0);
or simply:
#define SOCKETIOCLIENT_DEBUG(...)
That should rid you of the debug messages but I reckon that esp8266 by itself prints some debug messages to UART too at some special events like connecting or disconnecting to an AP. You may need to follow this from espressif's API reference:
"os_install_putc1((void *)uart1_write_char) in uart_init will set os_printf to be output from UART 1, otherwise, os_printf default output from UART 0."
os_printf is used as default printing function by the OS as well as many applications. Arduino's Serial lib should use uart0 directly and not os_printf so doing the above would only rid you of the messages the OS produces.
I knew it was simple and I was overlooking something. Solomons answer makes sense but I solved it right before checking Stack Overflow and seeing his post. The solution was a combination of his answer or commenting out the debug statements in the .cpp file but also needed was to go in to Arduino IDE tools menu and set DEBUG PORT to "disabled" and DEBUG LEVEL to "None". I had already tried that before but a mistake in my code had made me think that turned off all serial communication. But revisiting that with new code produced the desired results of only printing my
Serial.print();
statements thanks for the help though.
After reading the AM3359 Technical Reference manual, I saw that you can edit the pad control registers(Pin Mux). I tried editing these registers using devmem2 and it says that it successfully writes to it but upon reading the value again it is exactly the same.
I used the command sudo devmem2 0x44E10818 w 0x7 and returns
Value at address 0x44E10818 (0xb6f2c818): 0x31
Written 0x7; readback 0x7
but then I read it again and it says the value is: 0x31.
All I could think is that maybe there is something underlying in the linux kernel that is setting the values. What is causing the pin mux to hold its value?
From AM335x TRM I can see that:
0x44E10000 is the address of Control Module registers bank (from section 2 "Memory Map")
0x818 is conf_gpmc_ad6 (from section 9 "Control Module")
From AM335x datasheet I see that:
GPMC_AD6 pad is R9 ball (for ZCZ SoC, which you have on BBB)
From BBB Rev. A6 schematics I see that:
R9 ball is connected to MMC1_DAT6 line
MMC1_DAT6 line is connected to eMMC flash
From your question (using TRM) I can conclude that:
by default this pin is muxed in mmc1_dat6 mode
you are trying to remux it to gpio1_6 mode
So from this investigation I can say that you shouldn't remux that pin (even if it was possible), because it's needed to be muxed as mmc1_dat6 for eMMC to be accessible from your SoC.
If you are really needed to mux it as gpio1_6, be sure to change mux mode for it in device tree file first (and replace dtb file on BBB with new one). In that case you won't be able to use 8-bit mode for your eMMC, so you probably need to change this mode to 4-bit in device tree file as well.
References:
[1] AM3359 SoC documentation
[2] BeagleBone Black (Rev. A6) documentation (schematics, etc.)