EMW3165 WiFi+Cortex M4, the ESP8266 KILLER!


#1

Have you seen this new tiny wifi+MCU module?
It is based on a STM32F4 and can run viper smoothly!

http://hackaday.com/2015/07/13/new-part-day-the-esp8266-killer/

Anyone has had the occasion to test it? 
Interested in porting Viper on It? Any volunteer?


#2

Today I got a WiFiMCU board (based on EMW3165 but more convenient for development). I wish to try my hand porting Viper on it. So Viper team, who will guide me?


#3

When I connected the WiFiMCU board to the VIPER IDE detects that as “Udoo”. Has the IDE interpreted the physical board correctly from the IDE implementation perspective? I checked the Udoo spec. It uses SAM3X8E (Cortex-M3). Whereas WiFiMCU contains STM32F411CE (Cortex-M4). I didn’t go further.


#4

Hello HemantJoshi!

I’m very glad you are willing to try a Viper port :blush: 

Viper board discovery algorithm simply checks the usb vendor:model and serial strings. On many boards, the usb port is not directly connected to the mcu, but via a ftdi chip (as in the case of Udoo and Arduino Due) or a proprietary bridge (as in the ST Nucleo boards). Most probably the usb chip used by WiFiMCU is the same used by Udoo.

As Viper grows the algorithm will change, but in the end, form many boards the IDE will be forced to ask the user what kind of board has been plugged in  :confused:

As for the porting, the github source code is quite behind the current release of Viper (0008 official, 0009 in development, and I believe github is 0004), mainly because we are working hard to release all the basic features and test them in Beta. Many asked for the current source, so I will update the github repository as soon as 0009 is out (beginning of october).

Also, before closing the beta, I will release a porting guide and a Viper low level programming guide (to mix Python and C seamlessly).

That said, you can still get a good understanding of the Viper hardware abstraction layer (VHAL) by checking the github repo. Porting to the WiFiMCU should only be a matter of modifying the mcuconf.h file, writing the pin mapping in port.c and probably fixing some drivers in the stm32f4 vhal subtree. For the mcuconf.h you can refer to the ChibiOS documentation, I don’t remember if a stm32f411 board is already included.

Feel free to post here for any doubt or question and I will try to answer.


#5

Oh, I forgot about the toolchain  :stuck_out_tongue:

The build system, uses the same tools distributed with Viper (under sys/your-platform/gcc/arm). You can try to modify the Makefile and point it to the correct tool directory.

Let me know!


#6

Hi Giacomo,
Thanks for your inputs. Today I got some time to debug the build. I tried for currently supported board (say arduino_due), because there is no point in trying to port, unless I build a correct image for a supported board.

Took the snapshot from https://github.com/viper-dev/Viper. Modified the Makefile. After giving “make BOARD=arduino_due”, the build process gave following error:
make: *** No rule to make target platform.c', needed bybuild/obj/platform.o’.  Stop.

So checked common.mk file where following line related to platform.c.
COMMON_SRC = commono/platform.c

However there is no directory “commono” or file platform.c anywhere in the entire source tree. So gave a quick and dirty try and commented the line. The build went through and generated viper.bin, viper.hex, … etc. The .bin file size is 76184 bytes. Also checked the VIPER IDE installation nest folder where size of the vm is about 90KB, assuming this is the VM which is flashed into the board. I am sure that my build results are wrong.
Please help.


#7

Hello,
sorry for the late replay, I was with the Viper Team at the Maker Faire in New York.

mmm…that “commono/platform.c” seems like a typo left in the makefle…
The .bin file you get is probably the right size for two reasons:
- the version on github doesn’t have dynamic linking, so all the hardware abstraction layer is compiled into the vm making it bigger than it is now in 0008. But if the compilation ends with output files, you can assume it worked  :slight_smile:
- the .vm files under nest are actually json files (you can open them in a text editor) with some additional vm info and the vm binary base64 encoded. That’s why it’s bigger than the .bin.

That said, I guess your temporary build environment is working.


#8

Thanks a lot Giacomo, for your confirmation.

Now I want to build for either Particle Core or Photon, sine both have WiFi module. The Photon in particular, since both Photon and WiFiMCU boards share the same WiFi module.
Although not latest (0008), does the current Github version of Viper include WiFi driver as well, such that Viper would work (at least basic connectivity etc) into Photon?


#9

For the Photon the matter is complicated: the wifi driver is provided by broadcom in their WICED sdk. I wrote an adaptation layer for Viper and it works nicely (testing version 0009). However the sdk is not open source and can’t be redistributed with Viper, only the compiled binary can. This is true also for Particle firmware, it only contains some broadcom headers, and everything else is released as binary. I’m trying to solve the issue today and it’s the main reason why 0009 is not public yet. 

As for the Core, CC3000 has ben added in 0007 or 0008,so no source on github at the moment. 

My suggestion is, try to build for the st_nucleo and try to understand mcuconf.h from chibios; that will be the first place to modify to port viper on the f411 (clock and flash configuration). 



#10

Got it.
As I understand what you suggest is two step approach for porting.
1. Port only basic (non WiFi) - The simplest is f401 to f411 (WiFiMCU)
2. Port (essentially linking WiFi) driver to the desired basic

Will also look forward to latest source releases.