heinbali01 wrote on Saturday, April 25, 2015:
Hi Alan,
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.
An update of the HTML-server is planned quite soon: it will be extended with HEAD/POST/PUT and also there will be support for (CGI-style) requests from JavaScript.
For example:
GET /tcp_info?dhcp=? HTTP/1.1
which may trigger a typical JSON answer like this:
/tcp_info?dhcp={"ip":"192.168.2.100",
"netmask":"255.255.255.0","gw":"192.168.2.1"}
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:
FreeRTOS-Plus-TCP/portable/NetworkInterface//NetworkInterface.c
- endianness: big or little endian, which is just a switch defined as:
#define ipconfigBYTE_ORDER pdFREERTOS_LITTLE_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
- Netmask
- Gateway
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 )
{
return
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.
Regards, Hein