First issue:
I can get device id by send “i” photon or use particle-cli before flash user firmware,But after flash user firmware and not connecnted to wifi (led blink blue), I have to send “i” many many times until device id is returned.
In user firmware I have use serialEvent.
void serialEvent(void)
{
if (‘V’ == serial.read()) {
serial.printf(“vesrison is …”);
}
}
If I send “V”, “version is …” return at once,But I have to send “i” many many times until device id returned.
Second issue:
I think device id is the ID of stm32 when I first saw it.
But I find device id may change by change SSID,I must change SSID and send the right device id to server.
I have change SSID-xxxxx by dfu-util cmd several times,But device id return by particle-cli always the same.
The document is wrong?
./hal/src/photon/soft-ap.md
Soft AP Credentials
Open, unsecured AP
SSID is “photon-xxxxx” where xxxxx is part of the unique device ID
IP 192.168.0.1
Later, product creators might change the default SSID?
Later, SSID will be photon-N, where the device first scans for existing networks, and sets N to 1,2,3 etc… make the name unique?
Sorry Push wrong button just now
I change the user firmware to:
void serialEvent(void)
{
if (‘V’ == serial.peek()) {
serial.reak();
serial.printf(“vesrison is …”);
} else {
//not read serial
}
}
It is better,But sometime still need to send about 20 times until user CMD (V) or system CMD (i) return
I guess this has to do with your not flushing the serial buffer.
If you happen to have some data in the buffer your Serial.peek() will only ever see that first byte. And that it works after several tries indicates that you now have overflowed the buffer overwriting the non-V byte in the buffer you kept seeing all the time before.
Also be aware that serialEvent() is not actually running event driven, but only as a sync function between iterations of loop().
So if your code keeps execution trapped in loop() you need to wait till loop() finishes and allows serialEvent() to be called.
Additinally if your loop() code also uses Serial.read() (or the likes) this might consume the command bytes too.