Wifi access

Is there any development on a better BSP for this board to support the initialisation of the esp32 solo ?
The only development I found is

  • the promose of a better driver somewhere in 2019
  • some reverse engineerings that don’t even use the metal library.
  • there is zephyr, but there as soon as you enable communication support the board does not have enough RAM. Strange, I thought the board did have enough memory.

Very strange to add a wifi chip and not being able to use it and no examples provided showing howto’s.
If this were there this is a very promising board for me.
I want to use C or C++

Yeah, it’s very strange and sad. New features not properly supported, and features such as using the Arduino IDE and libraries that worked great on the original HiFIve1 not supported.

I bought two rev Bs because the hardware looked great and I had ideas for using the WIFI but in the end I’m still using my original HiFive1 bought in December 2016 for everything.

I found this one GitHub - kjarvel/hifive1revb_wifi: SiFive HiFive1 Rev B ESP32 - WiFi connection demo
I tried doing it myself before using this, but it is almost impossible to communicate with the board. And even more strange, id works only if you move the elf file directly to the board and not if you start the debug in FreedomStudio.

Yes that is the reverse engineering I was referring to. The code was created by using a logic analyser and watching what happens at startup of the board, because then there is also some message exchange with the esp32-solo. I read all the documents about esp32 and I cannot map the code to the documentation. Again strange.
Some information I found on esp32 is in chinese. needless to say that this is not helpfull for me.

I tried also by using the same pattern of messages explained in the example, both with metal library and direct register programming, but it just didn’t work
I expect some doc will be released in a near future, it’s absurd you’ve got a feature and you can’t even use it

Hello!

I’ve managed to successfully send data over wifi with Rust. I’m basing my work on the RISC-V Rust quickstart repo, specifically the spi_wifi.rs example. I built a small REPL using some code I wrote to read user input and the code in that example to read the responses from the ESP32. I also referenced the ESP32 AT Instruction Set manual pretty heavily, especially the documentation for the AT+CWMODE, AT+CWJAP, AT+CIPSTART, and AT+CIPSEND commands. Something that I didn’t realize when starting working with the chip is that it’s chattier than I expected: I needed to make multiple calls to the recv() function in the spi_wifi.rs example to empty the response buffer from the ESP32. Further, chapter 9 of the ESP32 manual is especially helpful: it contains sample conversations for several basic tasks.

I’m including my successful conversation log below, and should eventually have something more polished up on github for folks to play with. I want to point out that what I have is very hacky and ugly, but it works. I call recv() three times, as that seems to be enough to cover all the different cases. The right way to approach this would be a state machine, and I’ll look at building one for this when I put code up on github.

OK
AT+CWMODE=0-->AT+CWMODE=0
OK

wifi> AT
Ok("AT\r\n")
Ok("\r\nOK\r\n")
Err(WouldBlock)
wifi> AT+CWMODE=1
Ok("AT+CWMODE=1\r\n")
Ok("\r\nOK\r\n")
Err(WouldBlock)
wifi> AT+CWJAP="SSID","PASSWORD"
Ok("AT+CWJAP=\"SSID",\"PASSWORD\"\r\n")
Ok("WIFI CONNECTED\r\n")
Ok("WIFI GOT IP\r\n")
wifi> AT+CIFSR
Ok("AT+CIFSR\r\n")
Ok("+CIFSR:STAIP,\"IP\"\r\n")
Ok("+CIFSR:STAMAC,\"MAC\"\r\n")
wifi> AT+CIPSTART="TCP","REMOTE IP",1234
Ok("AT+CIPSTART=\"TCP\",\"REMOTE IP\",1234\r\n")
Ok("CONNECT\r\n")
Ok("\r\nOK\r\n")
wifi> AT+CIPSEND=7
Ok("AT+CIPSEND=7\r\n")
Ok("\r\nOK\r\n")
Ok("\r\n>")
wifi> hello
Ok("\r\nRecv 7 bytes\r\n")
Ok("\r\nSEND OK\r\n")
Err(WouldBlock)
wifi> AT
Ok("AT\r\n")
Ok("\r\nOK\r\n")
Err(WouldBlock)

I sent AT+CIPSEND=7 because the code I have for my REPL appends \r\n to everything sent to the ESP, and the board reads everything you send after as what to send up to that number of bytes, so I had to account for the two extra bytes after the obligatory hello string (I did mention the code is ugly and hacky). The Err(WouldBlock)s here indicate superfluous recv() calls, as I described above. To receive data, I used nc -kl 1234 on my Mac. Usually, nc quits after the first connection, but -k keeps the program listening after clients disconnect. Helpful when debugging a client!

4 Likes