Spinneret Web Server Software Architecture - need review and feedback
Timothy D. Swieter
Posts: 1,613
I need help thinking through the software architecture of the Spinneret Web Server. This thread should focus on architecture, not features of the software per se. Goals of the software design:
1. Simple (Isn't this always the goal?)
2. Expandable in the Ethernet Application Layer Protocols used - easy interface/API and easy to plug them into the code as needed by experimenters. I believe the community will want to add and expand upon the protocols.
3. Utilizes existing, proven, high performance objects when applicable like SD or RTC or serial control.
4. Well documented design for engineers, makers, experimenters and users to dissect, expand, etc.
For the Propeller Applications that I have worked on, there hasn't been much of what I would call inter-COG communication. That is, my past application architecture was more of a wagon wheel shape. There would be a main cog which would launch all the other cogs. Some of those other cogs would be stand alone functions that didn't require much intervention. Other COGs had perhaps a buffer in memory that one cog would fill and another cogs would empty as directed - think FullDuplexSerial.
When I think about the Spinneret module I think of all sorts of inter-COG communication. Let me give you an example. The Spinneret will server files off the SD card as web pages. In addition, the user/microcontroller interface through the command line/serial terminal should also have access to reading/writing files/directories for data logging, configurations recall/storage, etc. The HTTP application layer would most likely run in its own COG and the command line interpreter system would run in its own COG, yet each needs to have access to SD card. How is it best to do this?
Another example would be all the Ethernet Application Layer Protocols. Some protocols are persistence and alive all the time (HTTP) and others are momentary for carrying out a specific function (NTP or DHCP) and then disappear. The persistent protocols may live in a COG, the momentary protocols may live in a COG that is alive a short time or may live in-line with other code. All protocols would need a uniform and easy to access system to the W5100 driver. The W5100 driver is alive all the time and servicing four ports so multiple protocols can be engaged. I'm currently thinking some sort of shared HUBRAM that the W5100 and Application Layer Protocols access to add/remove sockets and point to buffer memory.
It is time to take my thinking up another notch in designing embedded firmware and I need the feedback and thoughts of the Gurus on the forum.
What are your thoughts about how to structure the software?
How have other large scale Propeller system glued all the pieces together, especially if there appears to be dual access needs like the SD or W5100 examples above?
What are the best practices or examples to follow?
I attached a PDF of how the software could be laid out, however I think it is still mostly a main cog gluing much of the system together. I'd appreciate any feedback to help structure the software better. I'd like to start coding the system pieces together, but first a few days of architecture discussion sounds appropriate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
1. Simple (Isn't this always the goal?)
2. Expandable in the Ethernet Application Layer Protocols used - easy interface/API and easy to plug them into the code as needed by experimenters. I believe the community will want to add and expand upon the protocols.
3. Utilizes existing, proven, high performance objects when applicable like SD or RTC or serial control.
4. Well documented design for engineers, makers, experimenters and users to dissect, expand, etc.
For the Propeller Applications that I have worked on, there hasn't been much of what I would call inter-COG communication. That is, my past application architecture was more of a wagon wheel shape. There would be a main cog which would launch all the other cogs. Some of those other cogs would be stand alone functions that didn't require much intervention. Other COGs had perhaps a buffer in memory that one cog would fill and another cogs would empty as directed - think FullDuplexSerial.
When I think about the Spinneret module I think of all sorts of inter-COG communication. Let me give you an example. The Spinneret will server files off the SD card as web pages. In addition, the user/microcontroller interface through the command line/serial terminal should also have access to reading/writing files/directories for data logging, configurations recall/storage, etc. The HTTP application layer would most likely run in its own COG and the command line interpreter system would run in its own COG, yet each needs to have access to SD card. How is it best to do this?
Another example would be all the Ethernet Application Layer Protocols. Some protocols are persistence and alive all the time (HTTP) and others are momentary for carrying out a specific function (NTP or DHCP) and then disappear. The persistent protocols may live in a COG, the momentary protocols may live in a COG that is alive a short time or may live in-line with other code. All protocols would need a uniform and easy to access system to the W5100 driver. The W5100 driver is alive all the time and servicing four ports so multiple protocols can be engaged. I'm currently thinking some sort of shared HUBRAM that the W5100 and Application Layer Protocols access to add/remove sockets and point to buffer memory.
It is time to take my thinking up another notch in designing embedded firmware and I need the feedback and thoughts of the Gurus on the forum.
What are your thoughts about how to structure the software?
How have other large scale Propeller system glued all the pieces together, especially if there appears to be dual access needs like the SD or W5100 examples above?
What are the best practices or examples to follow?
I attached a PDF of how the software could be laid out, however I think it is still mostly a main cog gluing much of the system together. I'd appreciate any feedback to help structure the software better. I'd like to start coding the system pieces together, but first a few days of architecture discussion sounds appropriate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
Comments
Each different copy of the file system then is completely seperate. However, since the SD card itself is one resource this means that there can be conflicts when writing information.
So...
You'll need to put in place a LOCK just for FS writing that will prevent cogs from trashing the SD card. Alot of the functions in my driver preform write operations behind the scene. In comming releases I will fix this problem... but for now I would look over my code and see which operations write data to the disk. File close is one of those operations.
Thus... I would reconmend that you use one lock for all the FS functions to prevent conflicts... As for file reading or writing you'll have to do some trickier stuff. I don't really have a short solution for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Any other thoughts community on the design I elaborated on?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com