As I add new network interfaces, they will need to allocate some buffers, due to the limited free memory I assume I should not support multiple network interface (e.g. linux style). I’m starting with ESP8266 but plan to add support for a few different network interfaces.
Currently the buffers appear to be allocated in a special memory for the on-chip ethernet. I also want to be mindful of how this ports to non-LPC1769 hardware.
As far as memory use goes we could:
Pick one interface in settings file, others don’t work.
Pick Primary/Secondary in settings file - e.g. WiFi network not found on boot, enable ethernet. Use same buffer for both.
Ethernet+1, enable ethernet as standard, allow configuration of second interface. Requires 2x buffers.
Ethernet+1 shared. As above but try to put some scheme in place so network cards can share the memory. Likely performance and code complexity hit.
As far as ROM use, should we
Leave all drivers enabled by default, with the possibility of #defining them out
Leave them #defined out, requiring them enabled individually
I need a UART to myself so really not the debug/command UART0. Am I cool to reconfigure spi0 (P0.15, P0.16) as UART1 and use that (only if WiFi is enabled)? I tried to find a way for UART and LCD to coexist but cant see one. Too many pins are taken.
This sounds like something that should definitely be maintained in a separate fork of smoothieware.
As such you should very cleanly keep all your stuff in separate files to make your job easier merging with upstream changes as they occur.
If you don’t want to run out of memory you need to use AHB1 for any buffers.
We are already too short on flash, so much so that we cannot even compile with DEBUG=1 set, so you may want to disable compiling modules you do not want to use. Right now to compile with DEBUG the entire network stack needs to be disabled with NONETWORK=1.
I’d also recommend making as few changes to any other core smoothie component as possible, otherwise your job of maintenance will be a nightmare.
For instance using a different serial port will make merging with upstream very hard for you.
There is a list of third party forks on the wiki, so make sure you link it there so others who may need it can find it.
I guess the whole point really is to add WiFi in upstream So I guess I’m asking for the way that’s most likely to be accepted.
I’ll set the extra drivers #defined out by default for sure. The ESP8266 driver should be pretty small though so hopefully will fit without disabling anything else.
Whats the issue with reconfiguring P0.15, P0.16 as UART1 when the driver is enabled?
I do not think this would be accepted, it is not generally useful.
ESP8266 can already be used with no changes to smoothie at all. Simply load a 10 line script to it that forwards all data to the serial port and vice versa, connect to the uart and it works.
Its not just a dumb serial passthrough. I’m writing it so you can use esp8266 as a network interface, instead of ethernet. And load up the smootie web UI / upload files.
So I guess I’m asking for the way that’s most likely to be accepted.