Spinneret Software Road Map
Timothy D. Swieter
Posts: 1,613
Community -
Last summer when I was piecing together my plan for the Spinneret software I had a couple design goals and thoughts. I wanted to take a moment and share those with the forum to get feedback. Perhaps some of the ideas below can still be implemented.
Software Pieces To Be Created
Of course there are a bazillion ideas that could be added above like implementing the various protocol, however I see the narrowed list above as a foundation upon which others can build. I believe that I have only provided a portion of the foundation, thus I hope that as a community or a few elite individuals can come together to finish the foundation that others will build on. Allow me to elaborate.
During my design sketching for this project I kept running into a mental block on how to implement the various protocols and W5100 driver. I wanted to design a software system that could have pluggable objects written by anyone that could easily use any driver. I wanted a system that easy to use, like the Propeller, a system that allowed individuals to write the code they are good at, without tieing the code to hardware.....thus my inspiration for a Network Services object.
The Network Services object would consist of at least a minimum of two pieces of software. Most likely this object would consume a minimum of two cogs. The first piece of software is the driver interface to the W5100 or other Ethernet IC. This driver would have a uniform API so that it would be easy for the Network Services object to use the SPI or Parallel interface - in other words the description of the ethernet hardware was generic - non specific.
The Network Services object itself is the layer that is in between the various protocol and application like a web server, mail server, DHCP, etc. The Network Services object has a memory buffer and an API that the procotol and applications would use. There would be a shared HUBRAM space where the applications would write commands or data to the Network Services and then the Network Services would execute and respond back through the shared HUBRAM. With this type of interface the designer of a system could then plug in that he wanted a web server and DHCP, but nothing else by simply including the code for those items as well as the Network Services and then starting each object with the proper pointers to a shared memory.
The challenge in the design would be to define a uniform interface between the Application objects and the Network services. I guess BSD Sockets is essentially what this and even though the W5100 looks like this, my view of the design was that to best use the multiple COGs and independent processing there needed to be a managed service between the Propeller W5100 driver and the applications and so that the Network Services could manage what application had what socket, and what needed sending and receiving. I wanted to stay away from ETHERNET.rxTCP and ETHERNET.txTCP having to be hardcoded into multiple application objects. I wanted a single COG with the driver to W5100 and then multiple other cogs to pass data to this object.
I hope I am making sense. Please feel free to chime in and let me know your thoughts. I am looking forward to what the other programmers and software designers here think and perhaps together we can come up with an idea and to start coding it together. Once there is a Network Services object with a common share interface, then all the application code like DHCP, web servers, etc and be plugged in and configured easily by the community at large.
Thanks for reading.
Last summer when I was piecing together my plan for the Spinneret software I had a couple design goals and thoughts. I wanted to take a moment and share those with the forum to get feedback. Perhaps some of the ideas below can still be implemented.
Software Pieces To Be Created
-
[*WIZnet W5100 SPI Driver (in ASM with portions in SPIN) - COMPLETE (or rather being vetted by the community with enhancements and bug fixes)
- WIZnet W5100 Parallel/Indirect Driver (in ASM with portions in SPIN - COMPLETE (ditto)
- Basic demos of the above - POSTED
- WIZnet W5100 SPI Driver (Completely in ASM, little to no processing in SPIN) - OUTSTANDING
- WIZnet W5100 Parallel/Indirect Driver (Completely in ASM, little to no processing in SPIN) - OUTSTANDING
- Network Service specification and demo driver - OUTSTANDING (see below for description)
Of course there are a bazillion ideas that could be added above like implementing the various protocol, however I see the narrowed list above as a foundation upon which others can build. I believe that I have only provided a portion of the foundation, thus I hope that as a community or a few elite individuals can come together to finish the foundation that others will build on. Allow me to elaborate.
During my design sketching for this project I kept running into a mental block on how to implement the various protocols and W5100 driver. I wanted to design a software system that could have pluggable objects written by anyone that could easily use any driver. I wanted a system that easy to use, like the Propeller, a system that allowed individuals to write the code they are good at, without tieing the code to hardware.....thus my inspiration for a Network Services object.
The Network Services object would consist of at least a minimum of two pieces of software. Most likely this object would consume a minimum of two cogs. The first piece of software is the driver interface to the W5100 or other Ethernet IC. This driver would have a uniform API so that it would be easy for the Network Services object to use the SPI or Parallel interface - in other words the description of the ethernet hardware was generic - non specific.
The Network Services object itself is the layer that is in between the various protocol and application like a web server, mail server, DHCP, etc. The Network Services object has a memory buffer and an API that the procotol and applications would use. There would be a shared HUBRAM space where the applications would write commands or data to the Network Services and then the Network Services would execute and respond back through the shared HUBRAM. With this type of interface the designer of a system could then plug in that he wanted a web server and DHCP, but nothing else by simply including the code for those items as well as the Network Services and then starting each object with the proper pointers to a shared memory.
The challenge in the design would be to define a uniform interface between the Application objects and the Network services. I guess BSD Sockets is essentially what this and even though the W5100 looks like this, my view of the design was that to best use the multiple COGs and independent processing there needed to be a managed service between the Propeller W5100 driver and the applications and so that the Network Services could manage what application had what socket, and what needed sending and receiving. I wanted to stay away from ETHERNET.rxTCP and ETHERNET.txTCP having to be hardcoded into multiple application objects. I wanted a single COG with the driver to W5100 and then multiple other cogs to pass data to this object.
I hope I am making sense. Please feel free to chime in and let me know your thoughts. I am looking forward to what the other programmers and software designers here think and perhaps together we can come up with an idea and to start coding it together. Once there is a Network Services object with a common share interface, then all the application code like DHCP, web servers, etc and be plugged in and configured easily by the community at large.
Thanks for reading.
Comments
I suppose you could look for a port then run the appropriate code block? Maybe I'm way off?
I am shooting to see how simple it can be for a novice to the Spinneret to be able to say, "I need a web server, DHCP and FTP capability" to then download the appropriate objects and with minimal code effort plug them together to work. Then another person comes along and says, "I need a web server and e-mail posting capability" and it is just as easy for this person to plug the blocks together.
I hadn't look at all the project out there, but I know from coding my own demos that I was struggling with how to expose the WIZnet drivers so multiple objects in separate COGs could access it. That is, the software I was writing had the application on top and the child object of the WIZnet driver. How to make them side by side so there could be two or three or more applications next to the WIZnet driver? Thus my idea for the Network Services object.