Define the available CC2538 devices and their features, and use them to
define the linker script memory regions. The .nrdata output section is
now always defined in order to trigger an error if it is used but no
memory is available for it. The CC2538 device used by Contiki is made a
configuration option, the CC2538SF53 device being the default.
This makes more sense than defining the flash memory address and size as
configuration options like previously, all the more not all values are
possible and all the features are linked by each device.
This change also makes it possible to:
- use the correct SRAM parameters for the CC2538NF11,
- know at build time if the AES, SHA, ECC and RSA hardware features are
available on the selected CC2538 device.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
After page loading has finished the number of free bytes left for page attributes is logged. It turns out that "usual" pages tend to get along with ~800 bytes while i.e. the Google search pages use all of the 2000 bytes of page attribute memory allocated by default (because of the long URLs with many parameters). So it seems that reducing this default isn't exactly the best way to reduce memory consumption...
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
When the client has already called webclient_close() it doesn't expect to have webclient_datahandler(NULL, 0) called just because the connection was closed by the server "at the same time". Rather it expects to always have webclient_closed() called.
Calling webclient_datahandler(NULL, 0) instead of webclient_closed() means that the web browser shows "Done" in the status line instead of "Stopped". So the user is mislead to think that he has already seen all of the page.
Note: webclient_close() is called by the client during newdata() so the already existing check for WEBCLIENT_STATE_CLOSE further above doesn't help.
The email and ftp programs aren't relevant anymore so support for them was removed from the cc65 builds. The explicit 80 column programs were added. The 80 colum web browser and Telnet server are built for all cc65 platforms as they are the largest and as such show best code increase issues.
Recently support for 80 column CONIO based on 320x200 graphics was added to the cc65 C library for the C64. This change leverages this for the IRC client and the web browser. Because not everybody prefers this 'soft80' display with its small 4x8 charbox the 40 column programs are still available as before (with the new programs called 'irc80' and 'webbrowser80').
So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
