In an existing networking library I've been tasked to work on there is a call to setsockopt which I don't understand
Here you can see a TCP socket begin created:
[socket] fd(11) domain(2:AF_INET) type(1:SOCK_STREAM) protocol(0:default)
Immediately afterward, a call to setsockopt is made for option SO_BROADCAST at the IPPROTO_TCP protocol level, with option value 5
[setsockopt] fd(11) level(6:IPPROTO_TCP) option(6:SO_BROADCAST) ret(0) option:
0 0500 0000 ....
According to Beej's guide to networking this "Does nothing—NOTHING!!—to TCP stream sockets! Hahaha!"
Questions:
What exactly are they doing here?
Does this make any sense?
If anything, surely it should be option_value=1, so what is the 5 about?
I think your setsockopt decoder is wrong. Are you sure it isn't one of these?
#define TCP_NODELAY 1 /* Don't delay send to coalesce packets */
#define TCP_MAXSEG 2 /* Set maximum segment size */
#define TCP_CORK 3 /* Control sending of partial frames */
#define TCP_KEEPIDLE 4 /* Start keeplives after this period */
#define TCP_KEEPINTVL 5 /* Interval between keepalives */
#define TCP_KEEPCNT 6 /* Number of keepalives before death */
That isn't a full list. See /usr/include/netinet/tcp.h for everything.
Related
The default network socket timeout in DCMTK is 60 seconds.
How to change it to 30?
I could see the code written as below, but could not change it to 30:
extern DCMTK_DCMNET_EXPORT OFGlobal<Sint32> dcmSocketReceiveTimeout; /* default: 60 */
As far as I understand your question, you want to set the timeout programmtically.
You can check how to do this in the dcmtk tools like echoscu -- basically you have to call:
#include "dcmtk/dcmnet/dcmtrans.h"
dcmSocketReceiveTimeout.set(OFstatic_cast(Sint32, new_socket_timeout));
and the global timeout will change accordingly.
The same is true for setting the send timeout, where you use dcmSocketSendTimeout instead.
I'm using iMX8MM with Yocto. I'm trying to figure out the reason cause reboot with Watchdog.
I find out watchdog.h and there are a lot of FLAGs:
#define WDIOF_OVERHEAT 0x0001 /* Reset due to CPU overheat */
#define WDIOF_FANFAULT 0x0002 /* Fan failed */
#define WDIOF_EXTERN1 0x0004 /* External relay 1 */
#define WDIOF_EXTERN2 0x0008 /* External relay 2 */
#define WDIOF_POWERUNDER 0x0010 /* Power bad/power fault */
#define WDIOF_CARDRESET 0x0020 /* Card previously reset the CPU */
#define WDIOF_POWEROVER 0x0040 /* Power over voltage */
#define WDIOF_SETTIMEOUT 0x0080 /* Set timeout (in seconds) */
#define WDIOF_MAGICCLOSE 0x0100 /* Supports magic close char */
#define WDIOF_PRETIMEOUT 0x0200 /* Pretimeout (in seconds), get/set */
#define WDIOF_KEEPALIVEPING 0x8000 /* Keep alive ping reply */
But when I check with command, I get only 4 FLAGs:
$ wdctl
Device: /dev/watchdog
Identity: imx2+ watchdog [version 0]
Timeout: 60 seconds
Pre-timeout: 0 seconds
FLAG DESCRIPTION STATUS BOOT-STATUS
KEEPALIVEPING Keep alive ping reply 1 0
MAGICCLOSE Supports magic close char 0 0
PRETIMEOUT Pretimeout (in seconds) 0 0
SETTIMEOUT Set timeout (in seconds) 0 0
How do I get more of FLAG to use?
The macros(flags) you are seeing in the watchdog.h is the complete list. However, the application utility (here wdctl) is reading the driver capabilities implementation from the kernel.
Another flag you are seeing WDIOF_OVERHEAT and others should be supported by the kernel driver then and then only it will be available to the wdctl list.
Looking at the source code of the wdctl is working in the following way. It is calling the read_watchdog_from_device API to get the implemented flags(Environmental monitoring).
Please check for the flags in the corresponding driver from the i.MX8MM watchdog imx2_wdt.c.
References: https://github.com/karelzak/util-linux/blob/master/sys-utils/wdctl.c
https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt
This is how I solve the issue above.
Find all file concert about imx2+ watchdog package.
Modified by adding more flags as watchdog.h file.
Access menuconfig in Yocto and turn on some options in Watchdog sections. This action makes sure that bitbake recognize the changing in driver.
Rebuild and generate OS image.
after stumbling upon very strange thing I would like to find out if anyone could provide reasonable explanation.
I have SHT31 humidity sensor running on I2C and after trying to run it on STM32F2 it didn't work.
uint8_t __data[5]={0};
__data[0] = SHT31_SOFTRESET >> 8;
__data[1] = SHT31_SOFTRESET & 0xFF;
HAL_I2C_Master_Transmit(&hi2c3,((uint16_t)0x44)<<1,__data,2,1000);
I have opened the function and saw:
/**
* #brief Transmits in master mode an amount of data in blocking mode.
* #param hi2c Pointer to a I2C_HandleTypeDef structure that contains
* the configuration information for the specified I2C.
* #param DevAddress Target device address: The device 7 bits address value
* in datasheet must be shifted to the left before calling the interface
* #param pData Pointer to data buffer
* #param Size Amount of data to be sent
* #param Timeout Timeout duration
* #retval HAL status
*/
HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
/* Init tickstart for timeout management*/
uint32_t tickstart = HAL_GetTick();
if (hi2c->State == HAL_I2C_STATE_READY)
....... and it goes ....
So I followed the comment and frustration from my scope (looking why my bits are not going on the wire) and did:
HAL_I2C_Master_Transmit(&hi2c3,((uint16_t)0x44)<<1,__data,2,1000);
Finally my bits are going out and device ACKs me back - voila it works!
But why?? What would be the reason behind putting burden on the programmer to shift the address?
Because the programmer should probably be made aware if he wants to read or write data to or from the I2C slave device.
In common I2C communication the first seven bits of the "address byte" contains the slave address, whereas the last bit is a read/write bit. 0 is write and 1 is read.
In your case, you want to write data to the device (to perform a soft reset) and therefore a simple left shift will do the trick.
It has never been agreed whether an I2C address is to be specified:
such that it needs to be shifted for transmission, or
such that it does not need to be shifted for transmission.
Therefore some device datasheets specify it in variant 1 and some in variant 2. Similarly, some I2C APIs take the address in variant 1 and some in variant 2.
If the device and the API use a different variant, it's the programmer's burden to shift the address.
It creates a lot of confusion and is quite annoying. I doubt it will every be clarified.
Sorry for the late reply, I just bumped my head against this myself. This should be considered a bug but ST refuses to acknowledge it as such. If you research the reference manual for the I2C section, the OAR1 register states that the address is stored in bits 7:1 for 7 bit mode. Bits 0, 8 and 9 are ignored. The HAL routine that sets the address should then shift the 7 LSB's so that bits 6:0 of your address get written to bits 7:1 of the OAR1 register. This doesn't happen. Essentially, because the code was released, it is now a "feature" and not a bug. Another way to look at it is that the address byte that you send to the HAL is left aligned. This is extremely irritating as it is not consistent for 7 and 10 bit addresses.
2 STM32 μc (NucleoF767ZI and Nucleo F446RE) should communicate via SPI. The first µc is programmed with Simulink using the Nucleo Support Package. As it stands, the μc with the Support Package can only work as a master. Now I just want to send a number from 0-255 to the slave μc for testing. And see the message with debugging mode. According to the Simulink block parameter, the Slave address register must be entered.
Then i am going to measure the the Duty Cycle of a PWM signal and send to via spi to the Master µc in Simulink, so the µc will function as a Sensor.
/* USER CODE BEGIN 0 */
uint8_t Rx[2];
/* USER CODE END 0
/* USER CODE BEGIN 2 */
__HAL_SPI_ENABLE(&hspi1);
/* USER CODE END 2 */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_SPI_Receive(&hspi1,Rx,1,10);
HAL_Delay(50);
}
/* USER CODE END 3 */
}
So my question, is it possible that my SPI of the slave µc (e.g., SPI2) has an address?
sIMULINK-SPI
Defined in the Bluez bluetooth stack in hci.h is the following:
/* HCI Socket options */
#define HCI_DATA_DIR 1
#define HCI_FILTER 2
#define HCI_TIME_STAMP 3
I've only seen HCI_FILTER being used to set HCI event filters for the host. I have been unable to find any resources that explain what the other two options (HCI_DATA_DIR and HCI_TIME_STAMP) are used for and what is expected for option_value when calling setsockopt().
Is there any sort of documentation that goes over these details?