PicForum

I know there are a number of (effectively unanswered) questions on the subject of using he Microchip WiFi hardware with the freeRTOS code but I thought I would ask here as I embark on what might be a fruitless quest.
freeTOS V8.1.2 (and possibly earlier) provides a 'freeRTOS+UDP' system that relies on the user writing code that interfaces their API to the appropriate MAC driver.
The alternative is to look at the Microchip TCPIP/WiFi code and see if it can be 'fitted" into a freeRTOS 'task'.
Therefore:
1) has anyone written anything that interfaces the freeRTOS+UDP to the MRF24WB0M* (or similar)?
2) has anyone successfully managed to get the Microchip code to work as a freeRTOS 'task'?
I know there have been many such questions going back over many years but I can't see anyone that says "here is what I did that works". I'm wondering if that is because it is a waste of time or if none has ever survived the attempt!
Susan

Actually it turns out to be very straight forward once you have the processor, the freeRTOS and the TCP/IP-Wifi stack correctly configured.
I have the freeRTOS 'tick' time set to 1 mSec and also I have removed some of the timeout checks in the WFDriverCom.c (those are the ones that typically cause the 'assert' problems) as the timer section has been re-written to use the freeRTOS "tick hook". For some reason the compiler seemed to generate code that complained when a tick difference of "5" was considered larger than the timeout value that was some 20 bits in length (can't remember the actual value)! As I have verified that the hardware was all working in a previous project, I simply let those parts of the code cycle until they completed which they do in very quick time.
I see there are some "delay" instructions, typically of 1mSec duration and typically in the setup parts of the code, in the code but for now they are still in there and do not seem to cause any problems.
Also the 'tick' code needs considerable work as it uses the same timer that freeRTOS uses by default. Rather than set up an alternative timer for the TCP/IP stack, I used the 'tick hook' mentioned able and altered many of the routines in the 'tick.c' file accordingly
Now on to the USB stack!!!!!
Susan

I read this "much over my head" post with great interest. Trying to think of how I can use this. If this were all working as you are getting it closer to doing, would I be able to get a "WiFi to RS232" connection? Here is the situation:
6 CNC machines with RS232 connections for transferring programs to. It gets harder and harder to find computers with actual serial ports on them. The apparent answer would be to use USB to serial and move on, but the outdated COMMS software doesn't know how to find the port if it is not COM1 or COM2. So for now I use an "in between" linux box.

When I read what you are doing, it makes me wonder if what it does is put a PIC on a WiFi. If so then it would be trivial to have the PIC talk to the machines. I could have one at each machine and they would be addressable!

Am I seeing this correctly?
-Bert

cncmachineguy wrote:.... The apparent answer would be to use USB to serial and move on, but the outdated COMMS software doesn't know how to find the port if it is not COM1 or COM2.

It's actually pretty easy to force a USB-Serial adaptor down to COM1 or COM2, assuming there isn't already something there.

In Windows, run Device Manager, open the "Ports (COM & LPT)" branch, and right click on the USB adaptor and select "Properties".
Select the "Port Settings" tab, then click on the "Advanced" button.
There should be a dropdown bottom-left, labelled "COM Port Number", and set to a high number.
Change it to "COM1" or "COM2". Ignore the "in use" labels.
When you click "Ok", it will warn you about selecting a COM port that is "in use". Just ignore this.