I'm trying to get the microchip example code for WINCS02 found here:
https://github.com/Microchip-MPLAB-Harmony/wireless_apps_rnwf/tree/master/apps/wifi_ap

To run on an STM32 microcontroller using the STM32CubeIDE. Their developer guide says its possible but I'm at a loss as to how to do so. Any help would be greatly appreciated.

 

Sure, it's possible but it's not a trivial programming task to port code from one IDE to another completely different one.

Show us what you've already done on this project.

 

Honestly I have nothing done. So far all I've done is copy and paste the files from git into the STM32 project. Trying to figure out which files I need to keep and which I can delete

 

Honestly I have nothing done. So far all I've done is copy and paste the files from git into the STM32 project. Trying to figure out which files I need to keep and which I can delete

Interfacing a SPI interface wifi chip is a complicated task on the Microchip IDE side, transferring that code to STM32CubeIDE requires real expertise in both. IMO you are asking for more for more than a little help here.

 

I'm trying to get the microchip example code for WINCS02 found here:
https://github.com/Microchip-MPLAB-Harmony/wireless_apps_rnwf/tree/master/apps/wifi_ap

To run on an STM32 microcontroller using the STM32CubeIDE. Their developer guide says its possible but I'm at a loss as to how to do so. Any help would be greatly appreciated.

There is only one way for you to approach this problem: divide and conquer. It may take you years to achieve your goal and you will either get there or give up in frustration. Only you can decide when you've had enough. If you learn anything in the process, then you will not have wasted your time. Otherwise, I can only imagine the irritation involved in realizing that the journey was not worth the effort.

 

Interfacing a SPI interface wifi chip is a complicated task on the Microchip IDE side, transferring that code to STM32CubeIDE requires real expertise in both. IMO you are asking for more for more than a little help here.

I didn't realize that. The Microchip WINCS02 Application Developer's Guide made it seem like all I had to do was change some files.
https://onlinedocs.microchip.com/ox...UID-484202C2-D3BB-4B7D-978A-A66E6E231BFE.html

 

There is only one way for you to approach this problem: divide and conquer. It may take you years to achieve your goal and you will either get there or give up in frustration. Only you can decide when you've had enough. If you learn anything in the process, then you will not have wasted your time. Otherwise, I can only imagine the irritation involved in realizing that the journey was not worth the effort.

This project was supposed to be delivered in about 2-3 weeks.

 

I didn't realize that. The Microchip WINCS02 Application Developer's Guide made it seem like all I had to do was change some files.
https://onlinedocs.microchip.com/ox...UID-484202C2-D3BB-4B7D-978A-A66E6E231BFE.html

The devil is in the details: Not a trivial job: porting device-specific peripherals and driver functionality.
https://onlinedocs.microchip.com/ox...UID-95500656-D2E0-4D31-A6A5-EB8172EEB69E.html

https://github.com/Microchip-MPLAB-Harmony/wireless_wifi/tree/master/driver/wincs02
https://onlinedocs.microchip.com/ox...UID-A174C46A-915D-4904-AC7F-D6350A6994A3.html

You need to understand how that works at a low-level on both microcontrollers for SPI, understand the C source library MCU-specific tool chain differences between platforms, C implementation MCU-specific tool chain differences between platforms, etc ...

4.1.3 Non-Microchip MCU Support
Each microcontroller has its own development tool and documentation. User must use their MCU-specific tool chain documentation.
The user needs to modify the WINCS02 services with the respective MCU functionality.
For example, SPI communication configuration can be migrated to non-microchip MCU by modifying the plib_port.c file in the <project_path/firmware/src/config/sam_e54_xpro_wincs02/peripheral/port/>plib_port.h/plib_port.c, directory and porting device-specific peripherals and driver functionality.

That's the easy part. You could just dummy up the plib_port.c source to compile and return test data in the beginning of the porting process until the rest of the C application code compiles and runs on the new controller. Then you can actually implementate the plib_port.c source to talk to the wifi chip correctly.

 

I'm trying to get the microchip example code for WINCS02 found here:
https://github.com/Microchip-MPLAB-Harmony/wireless_apps_rnwf/tree/master/apps/wifi_ap

To run on an STM32 microcontroller using the STM32CubeIDE. Their developer guide says its possible but I'm at a loss as to how to do so. Any help would be greatly appreciated.

What are you seeking to "port" the code that manages the WIFI device hardware or the "apps" that are in the various demos?

I agree with @nsaspook this is likely to be a formidable undertaking if trying to get these WIFI devices operating with STM32 using that code as the starting point.

WIFI is WIFI is WIFI, so why not see a WIFI module that already has lots of support for STM32?

Look at the ESP8266 for example, it's a bit dated now but easy-ish to manage using simple serial commands. I'm sure it is possible but really would require a lot of skilled expertise to deliver.

 

+1

It's a chore even when you're very familiar with the programming process for one type of processor and the system of code generation.

Need to tweak the contrast setting a bit with this abused GLCD.

Much better.
wfi32e01pe is a PIC32MZ1025W104132 Soc with WFI module. This one of my custom boards that has support for a GLCD running with a 15 MHz SPI clock and a MURATA SCL3300 Inclinometer with a 4 MHz clock. https://www.murata.com/en-us/products/sensor/inclinometer/overview/lineup/scl3300

SCL3300-D01
3-axis inclinometer with angle output
and digital SPI interface
Features
 3-axis (XYZ) inclinometer
 User selectable measurement modes:
3000 LSB/g with 70 Hz LPF
6000 LSB/g with 40 Hz LPF
12000 LSB/g with 10 Hz LPF
 Angle output resolution 0.0055°/LSB
 −40°C…+125°C operating range
 3.0V…3.6V supply voltage
 SPI digital interface
 Ultra-low 0.001 °/√Hz noise density
 Excellent offset stability
 Size 8.6 x 7.6 x 3.3 mm (l × w × h)
 Proven capacitive 3D-MEMS technology

Very sensitive to good vibrations.

It securely connects via WiFi to a remote MQTT server to deliver 3 axis vibration data and tilt data with time-stamping in sync to a remote NTP server. It also has a CANFD interface for local networking of additional devices.



My Prototype.

Only one jumper correction for the production revision.

MQTT client subscriber of the JSON encoded data with the Serial of the IMU chip as the unique data identifier.

https://forum.allaboutcircuits.com/threads/wfi32e01pc-wireless-mqtt-node.197612/post-1869887


All of that data goes into a MySql database for later processing.

3 axis vibration analysis.

There is plenty to do without the task of porting the controller code to another processor family. It's much better just to restart the controller design and programming task with a supported device for that processor family library.