Maybe someone had this problem.
"Send(AT)"
OK
"Send(AT+NAME?)"
+NAME=?
OK
"Send(AT+NAME1234)"
+NAME=1234
OK
"Send(AT+NAME?)"
+NAME=?
OK
Cant get this BLE HM-10 to remember name.
I was using FTDI and ch340, arduino monitor and realterm
Update!
After reset to defaults it started working Now i now its a genuine HM-10 and i have CC41-A
Command Description *
---------------------------------------------------------------- *
AT Check if the command terminal work normally *
AT+RESET Software reboot *
AT+VERSION Get firmware, bluetooth, HCI and LMP version *
AT+HELP List all the commands *
AT+NAME Get/Set local device name *
AT+PIN Get/Set pin code for pairing *
AT+PASS Get/Set pin code for pairing *
AT+BAUD Get/Set baud rate *
AT+LADDR Get local bluetooth address *
AT+ADDR Get local bluetooth address *
AT+DEFAULT Restore factory default *
AT+RENEW Restore factory default *
AT+STATE Get current state *
AT+PWRM Get/Set power on mode(low power) *
AT+POWE Get/Set RF transmit power *
AT+SLEEP Sleep mode *
AT+ROLE Get/Set current role. *
AT+PARI Get/Set UART parity bit. *
AT+STOP Get/Set UART stop bit. *
AT+START System start working. *
AT+IMME System wait for command when power on. *
AT+IBEA Switch iBeacon mode. *
AT+IBE0 Set iBeacon UUID 0. *
AT+IBE1 Set iBeacon UUID 1. *
AT+IBE2 Set iBeacon UUID 2. *
AT+IBE3 Set iBeacon UUID 3. *
AT+MARJ Set iBeacon MARJ . *
AT+MINO Set iBeacon MINO . *
AT+MEA Set iBeacon MEA . *
AT+NOTI Notify connection event . *
AT+UUID Get/Set system SERVER_UUID . *
AT+CHAR Get/Set system CHAR_UUID . *
-----------------------------------------------------------------*
Note: (M) = The command support slave mode only. *
For more information, please visit http://www.bolutek.com *
Copyright#2013 www.bolutek.com. All rights reserved. *
+VERSION=Firmware V3.0.6,Bluetooth V4.0 LE
Type to get value (Same is with other commands):
AT+NAME
Type to set value:
AT+NAMEnewName
You can try equal sign for set a value
AT+NAME=newName
edit for code prefix
try a shorter name. I had the same problem.some version do not accept long name
Related
i want to use this data type for notifying hd_digital_signal_exist and level of information to be imported
The question is in the description of this signalstrength - " Despite the name, this is not a signal strength.The purpose of this field is primarily informative." what does this mean?
/**
* Signal quality measured in 0% to 100% range.
*
* Despite the name, this is not a signal strength.
* The purpose of this field is primarily informative.
*/
uint32_t signalStrength;
After I updated the voice SDK for Unity to 3.6.1 (previously 2.4) I tried to add the new parameter "filePath" at GetAudioMixingDuration instead of using the usual method with no parameters. For some reason, the same file played and then called GetAudioMixingDuration(), in the new method with the "filePath" parameter always returns -7.
What I did is to point to the very same path of the file in the "filePath" parameter instead of playing it and then call the no parameter method, but for some reason, it's not working.
I also tried both relative and absolute paths, point a file inside and outside the Asset folder, and check if Agora is connected to a channel.
I really don't know what is wrong and the documentation doesn't help at all.
This API is deprecated. Please check the code header for its documentation, especially look for the comment about Android if that's what you are running on. Quoted here:
/**
* Gets the total duration of the music file.
*
* #deprecated Deprecated from v3.6.1.1. Use {#link agora_gaming_rtc.IRtcEngine.GetAudioFileInfo GetAudioFileInfo} instead.
*
* #note Call this method after joining a channel.
*
* #param filePath The absolute path (including the filename extensions) of
* the local music file. For example: `C:\music\audio.mp4`. Supported audio
* formats include MP3, AAC, M4A, MP4, WAV, and 3GP. For more information,
* see [Supported Media Formats in Media Foundation](https://learn.microsoft.com/en-us/windows/win32/medfound/supported-media-formats-in-media-foundation).
* When you access a local file on Android, Agora recommends passing a
* URI address or the path starts with `/assets/` in this parameter.
*
* #return
* - ≥ 0: A successful method call. Returns the total duration (ms)
* of the specified music file.
* - < 0: Failure.
*/
public int GetAudioMixingDuration(string filePath)
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.
I use I2C-tools to test firmware (HAL-based), I2C, STM32L0 MCU. When I send command to MCU (via i2cset utility), it sends an answer (received in i2cget). It works fine. If I call i2cget twice after single i2cset, it fails (which is expected behaviour). But if I execute i2cset after that error, then it also fails. So, the receive-transfer becomes broken (no callback is activated). How can it be fixed?
At the moment, HAL_I2C_Slave_Receive_IT() is called in HAL_I2C_SlaveTxCpltCallback(). HAL_I2C_SlaveRxCpltCallback() calls HAL_I2C_Slave_Transmit_IT(). Should I put HAL_I2C_Slave_Receive_IT() in two callbacks (receive/transmit related)?
I don't know if you've solved this question. However, it is more accurate to define a flag that states that the HAL_I2C_SlaveTxCpltCallback, HAL_I2C_SlaveRxCpltCallback, and HAL_I2C_ErrorCallback functions have completed transfers or an error occurred.
maybe the following codes may be useful. You can reinit after making deinit.
/**
* #brief Initialize and setup GPIO and I2C peripheral
* #param obj : pointer to i2c_t structure
* #retval none
*/
void i2c_deinit(i2c_t *obj)
{
HAL_NVIC_DisableIRQ(obj->irq);
#if !defined(STM32F0xx) && !defined(STM32L0xx)
HAL_NVIC_DisableIRQ(obj->irqER);
#endif // !defined(STM32F0xx) && !defined(STM32L0xx)
HAL_I2C_DeInit(&(obj->handle));
}
void LDC_I2C_ReInit(void)
{
HAL_I2C_Init(&hi2c1);
}
and it has a fine example in these links.
https://github.com/stm32duino/Arduino_Core_STM32/blob/c392140415b3cf29100062ecb083adfa0f59f8b1/cores/arduino/stm32/twi.h
https://github.com/stm32duino/Arduino_Core_STM32/blob/c392140415b3cf29100062ecb083adfa0f59f8b1/cores/arduino/stm32/twi.c
Question:
I'm trying to find a way to retrieve the dev object for an mdio_bus that has been added to the device tree. I'm sure I'm going to be rapidly applying my palm to my forehead when I get past this, but for the life of me, I can't find the answer anywhere. I've seen how to find objects on the bus itself using bus_find_device_by_name(), but I can't seem to find how to get the bus itself.
Background:
We are providing network access to our host using a Micrel KSZ8863 Ethernet switch attached to the MACB on an at919g20. Rather than using the fixed PHY option, I've spoofed MDIO address 0 to be a "fake" PHY representing the fixed MII link to the switch. I'm writing a driver for the switch to receive its interrupts and monitor the outward facing PHYs and control the link state of the "fake" PHY to the host. In order to configure the switch beyond basic MIIM configuration, you need to use SMI on the MDIO bus to access the full array of registers in the switch. Through further tweaking of the mii_read/write functions in the MACB, adding a header to the reg address, I believe I can use the MACB's MDIO/MII controller to do the right thing for SMI requests. Because the bus no longer gets addressed by PHY:REG, I need to be able to issue raw read/write commands straight to the bus from the switch driver. And that brings me back to my question: How do I request the dev object of the mdio_bus from the device tree by name?
Thanks,
Brian
After hunting around, fruitlessly, for a way to retrieve a device pointer to an mii_bus object, I ended up coming up with the following solution. I'm not sure its the best way to go about it, but it seems pretty clean. I basically ended up adding a helper function to mdio_bus.c that allows another driver to search for a bus by name using class_find_device(). I'm sure there is better way to do this, that doesn't involve adding onto the bus' driver, but it doesn't seem like the worst way either.
-Brian
Here are the functions I added to mdio_bus.c:
/**
* mdiobus_match_name - compares specified string to the device name
* #dev: device object to be examined
* #data: pointer to string to compare device name to
*
* Description: matching function used in call to class_find_device() to find
* a device with the specified name
*/
static int mdiobus_match_name( struct device * dev, void * data )
{
const char * name = data;
return sysfs_streq( name, dev_name( dev ) );
}
/**
* mdiobus_find_by_name - Convenience function for retrieving an mii_bus pointer
* by name
* #name: name of the bus being searched for
*/
struct mii_bus * mdiobus_find_by_name( char * name )
{
struct device * dev;
/* search devices registered for with the mdio_bus_class using the device
name as the matching criteria */
dev = class_find_device( &mdio_bus_class,
NULL,
(void *)name,
mdiobus_match_name );
/* return the mii_bus pointer or NULL if none was found */
return dev ? container_of( dev, struct mii_bus, dev ) : NULL;
}
EXPORT_SYMBOL( mdiobus_find_by_name );