I have managed to port over the FREERTOS+TCP for the STM32F429
Glad to hear that.
am now going to implement your new webserver
The HTML/FTP servers depend on the new +FAT library. +FAT can either use a RAM disk or an SD-card (or any other memory).
At this moment the HTML server is quite simple: it only serves the GET requests. The FTP server, on the contrary, is very complete already.
GET /tcp_info?dhcp=? HTTP/1.1
which may trigger a typical JSON answer like this:
The FTP and HTML server are extremely ‘cheap’ in the sense that they do not create any new task. They have a common “work” function which can be called like this:
const TickType_t xInitialBlockTime = pdMS_TO_TICKS( 200UL );
for( ;; )
FreeRTOS_TCPServerWork( pxTCPServer, xInitialBlockTime );
overall I find FreeRTOS+TCP much easier to use than my old lwip setup.
+TCP has a big advantage, it is based on FreeRTOS. LWIP has the difficult task of being compatible with any OS on any platform.
The dependencies of +TCP are much smaller: it uses the standard types (uint32_t and so), and it uses all great features of FreeRTOS (queues, events, semaphores).
In fact there are only two dependencies on the hardware:
- send and receive Ethernet packets, as implemented in:
- endianness: big or little endian, which is just a switch defined as:
#define ipconfigBYTEORDER pdFREERTOSLITTLE_ENDIAN
All other dependencies are already “covered by” FreeRTOS.
if the DHCP is to be run I set the default IP address to 0.0.0.0
I’m trying to get clear what it is that you want to add?
As you will understand, xNetworkAddressing.ulDefaultIPAddress will be used as The IP address in case DHCP has failed.
I made an embedded device which has these user options:
1) Use DHCP
2) Use DHCP as an advice
3) Do not use DHCP at all
Most people make the easiest and safest choice 1). DHCP dictates all data and the device just follows. The device will always store the latest:
- IP address
Now in case a device boots and does not get a DHCP response, it will use the last known settings. This works very well in most cases.
Option 2) the device gets a fixed IP address and netmask. Now only if the DHCP offer is incompatible with the currently used settings, the offer will be used.
This will happen if the IP address is 192.168.1.xxx and DHCP comes with a 10.x.x.x address.
Option 3) use fixed settings. That would be OK if the situation never changes, each devices has its fixed place and IP address.
I must say that I miss a possibility to stop the DHCP negotiation. In the third case (ignore DHCP), there is no way to avoid the DHCP negotiation.
In the seconds case (advisory), I would like to have a callback, in which my application is asked for a confirmation:
BaseType_t xApplicationDHCPConfirmHook( struct XDHCP *pxData )
I keep on stressing, if possible: give your embedded devices a FIXED name and a VARIABLE IP address.
I make audio amplifiers with a HTML interface. The amplifier on my desk has 2 nicknames: e.g. “amplifier” and “ampli_lab”.
Enable two protocols in your “FreeRTOSIPConfig.h”:
#define ipconfigUSE_LLMNR ( 1 )
#define ipconfigUSE_NBNS ( 1 )
and define a callback:
BaseType_t xApplicationDNSQueryHook( const char *pcName )
stricmp( pcName, "amplifier" ) == 0 ) ||
stricmp( pcName, "ampli_lab" ) == 0 );
With this your devices can be found by ping, FTP-clients and browser. Windows XP will only use NBNS, whereas Linux and Win7 prefer to use LLMNR.