Embedding process control into database with the propeller

Wolfgang

It seems to me that the general interests in writing software for the combination of propeller and w5100 are in building little webservers that handle html.

I think that the easy to use parallel processing capabilities of the propeller for process control is the central point of interest when using the propeller chip. Driving sensors and actuators on the i/o ports with the easy to use combination of spin and assembly code and the interrupt free handling of fast parallel processing are the reasons for me to use the propeller chip instead of other controllers.

The combination with an Ethernet controller is the right thing to realize network communication above the global ram in the software stack but this should not lead to lose the focus on that what the propeller is made for.

So my intent would be to create a network communication layer for calling procedures that lay outside of the propeller chip but are easy to use for data processing on the propeller. An example would be a door opener with an RFID sensor realized with the spinneret webserver module that calls a procedure on a database server to verify the scanned key.

One central task would be to choose a communication protocol without the need of programming a driver that burns up the resources of the propeller. My idea is to use http (instead of a native protocol) based on the driver of Timothy D. Sweeter for the w5100. The advantage of http would be the simplicity and the compatibility to the server side but there could be a better protocol.

Would there be a general interest to realize this or are there already better solutions to this issue?

Mike G

I don’t fully understand your post, please bear with me.

The W5100 is a TCP/UDP hardware transport layer device with 4 sockets. The W5100 requires a host controller to operate. The host Propeller is loaded with a driver that configures and handles socket communication on the W5100.

Server Mode:
The host Propeller is notified of client socket connections through the W5100 interrupt register or status register. The host software reads the W5100 socket Rx buffer, processes the data, then submits the response to the W5100 Tx buffer.

The Propeller/W5100 (Spinneret) can also act as a client.

The data sent/received is up to the programmer. I like to use the HTTP application level protocol because it’s well established and in my wheelhouse.

Talking to a database directly, geez sounds like a monster task. It would be a heck of a lot easier to make an HTTP request to a server service and let the server deal with the database communication. If you write the service, You have control over the response format; JSON, XML…etc. The Spinneret simply parses the response.

Have you had a chance to browse the W5100 datasheet?

mindrobots

One of the great things about the IP stack is the wealth of robust, well tested protocols available. I think the Spinneret/W5100 combination has enough power to handle client or small server functions that it would be tasked with. For your suggested application, like Mike G. suggested, HTTP transactions against a web server/DB server would make the most sense. It's tried an tested and you have a wealth of tools to choose from on the server side to interact with a client request. The Spinner then can handle the returned data as needed.

My interests in the Spinner (at least on paper so far) have been toward expanding the Internet awareness of more traditional Prop based embedded micro-controller functions. The Spinner does give up I/O lines and program space to support the W5100 so I've been thinking of a dual Propeller arrangement with the Spinner network interfacing, monitor functions (debugging) and download/reprogramming support for the second Prop which would have almost a full compliment of I/O lines, COGS and program space to perform controller functions.

I've been looking at SNMP as the application layer protocol making the Spinner and its partner Prop look like a newtork device with lots of I/O lines and sensors on a remote Internet connection.

...at least, that's what I'm doodling on paper in my free time.

Rick

Wolfgang

Mike and Rick,

my native language is german so I have my problems with english. Sorry! I wrote: "My idea is to use http instead of a native protocol and the driver of Timothy D. Sweeter for the w5100." I meant: Of course I would use (and in the past I used) the driver of Timothy D. Sweeter with or without http but I am not shure if there is a better alternative to http. My actual position is that http is the protocol to use. Every web browser uses http and nearly every server application today uses a web server functionallity to communicate with clients. With "native protocol" I meant something like the Oracle TNS Listener protocol.

In the past I did not use http. For every propeller program that should communicate over ethernet I made a java program on a pc with a socket as software endpoint to communicate with the propeller board (enc28j60 or now w5100). In this case I did not need any protocol in the application layer (except of my own) so I had no overhead with it on the propeller. If there was a need to communicate with a database (example door opener) I had to implement database connectivity into my java program. In this way I used tcp and udp on the transport layer and had no problems on my way over firewalls, switches, routers and internet servers.

Now my idea is to abolish the java program. This would make the living much easyer if there would be no need for a multi tier application (propeller, java program, database). Client (propeller) and Server (Database) would do the work.

To illustrate this I attach some screenshots. In the pictures You can see the two importent ethernet frames of the tcp communication captured from the network cable and the (only) two necessary code snippets on the propeller and the database for the door opener example. The database is Oracle and the database procedure is pl/sql.

mindrobots

Wolfgang, please don't apologize for being able to carry on a technical discussion in anything other than your native language! 90% or more of Americans (including me) couldn't even attempt to do this. We often have problems communicating ideas when everyone speaks English!

I understand what you are doing and asking. I believe anytime you can make something simpler and eliminate the pieces between the client and server (especially in the micro-controller world), others will appreciate your work and find a use for it.

There is certainly a place for "lightweight" client side network aware objects on the Propeller side.

It's also interesting to me to see code with 'foreign' variable names. You are passing "this" the RFID into the database and getting back information about the person (the "with worker")....I had to look up zahl, just because I was curious....my guess was "string", of course.

Please keep working on this, posting and sharing!

Rick

Mike G

Wolfgang, I think we're on the same page except I still want to use a service. My whole intent with the Spinneret is to consume and expose RESTful services.

The idea is to create services that are available to the spinneret (or any system). Services like; What time is it?, What is my IP address?, What is the answer to this complex math problem?, Is this a valid login?

Wolfgang

Mike, RESTful services ist the keyword! I will spend some time to get deeper into the basics of RESTful web services.

Mike G

For those that are having a hard time finding information on RESTful services, checkout this MS article. http://msdn.microsoft.com/en-us/library/dd203052.aspx. I know it's Microsoft's WCF but the article outlines the idea pretty well.

In a nutshell, a RESTful services take advantage of all the HTTP methods [GET, PUT, POST, DELETE...] and the URL to pass state or intention to the service.

mindrobots

Mike,

Thanks for the link! RESTful services look very interesting. If we can pipe HTTP methods together and redirect URL output from server to server, we can chain RESTful services together like *NIX commands in a script. This may already be done....I'm not very web smart when it comes to the latest technologies.

Rick

Wolfgang

My conclusion is that I will principally use simply the http get method in the way shown in my post #4. If I want to pass more data than can fit into the url I will use the post method too. Analyzing the http status codes of the server answers will satisfy the wish to verify the data communication. All the stuff should be encapsulated by spin method blocks and put together into a library file.

The next more important thing is the security aspect. Even in private networks should be the possibility to encode the data to be transferred. I am thinking about to do this by writing my own code for the propeller (or is there one?). I will use RC4 because the algorithm fits to the propeller and I have it already coded in pl/sql for the server side.

Now what do I have:

I am able to call database procedures directly (client server) with variable parameters in the url (get) or in the message block (post). I get back an error message (http status) or the returned data from the database server. I have not to handle session numbers or other overhead in the communication. The resource cost on the propeller is acceptable and the driver for the w5100 is already there.

I can hold the binary of the propeller software in the database and change it on demand on the propeller. I can outsource data and procedures into the database.

And what do I have not:

I do not have a fast system. The communication brakes the abilities of the propeller if it must be part of the process control. If our example is not the door opener but a propeller network with realtime capabilities we have no chance. The main problem in this case is the w5100. It frees us on the one side from any work with the ethernet stack and does all the work autonomous but we pay for it with the sacrifice of speed.