The already installed software includes a web server which allows the interfaces on the PIC chip (PIO, analogue inputs, PWM outputs etc. etc.) to be controlled from the web. The provided stack also allows control via UDP packets. Finally, it includes a bootloader which allows the remainder of the software to be updated over the network, and which hopefully runs even if you "brick" the board.
Also provided are the source code of the software, and instructions for building it using free tools available from Microchip. This meant I could easily modify the software for my purposes. Much more information can be found on the Modtronix site.
Modtronix also produce various boards and enclosures which make using the module even easier.
2. Design Decisions
Having selected the SBC65 for my application, a number of decisions needed to be made. Firstly, should I use the existing software as provided and control the various inputs and outputs via web access or UDP packets. Neither of these options seemed particularly attractive, so I moved on to looking at developing my own software. Should I scrap all the provided stuff and start from scratch? That seemed like far too much hard work, so I decided to start with the supplied software and then modify it as required, adding my own module to communicate with the main PC and deal with the inputs and outputs. A large proportion of the changes consisted of cutting out the parts of the Modtronix stuff that I didn't want. This had to be done carefully, to make sure I didn't break something I needed, for example the bootloader client uses the UDP interface to reset the board so that it runs the bootloader server (Have I got client and server the wrong way round here?) so when I cut UDP out completely this stopped working. Luckily the bootloader runs just as well after a power-on reset so I was soon back in control!
2.1 UDP or TCP
A difficult decision was the choice between using UDP and TCP for communications between the server PC and the ETHPIC node, and I'm still not convinced I got it right.
My requirements for the communication are that it is certain that messages have been delivered, so my thinking was why write a command/response protocol to run over UDP when I can get TCP to do it for me? So TCP was chosen, and it seems to work fine, but there are some disadvantages which make me wonder if UDP might have been better. In particular, if the network "goes away" for some reason, a TCP connection will stay up indefinitely as long as neither end tries to send a message. So I had to add some regular poll messages in order to discover that communication has been lost.
2.2 Who connects?
Having decided to use TCP, the next question is which end should establish the connection? The server could know the addresses of the nodes, and attempt to connect to them at regular intervals until a connection is established; or the nodes could know the address of the server, and attempt to connect to it at intervals. I chose the latter, because it seems to have one significant advantage - During the testing phase of a new node, I can configure it with a different server address and it will connect to a test server rather than the live one. Once testing is completed I just point the node at the live server. Nodes can be moved back to testing and returned to live operation without making any changes to the live server's configuration.
3. The ETHPIC Protocol
All messages are formed of a name octet followed by zero or more octets of data. Some messages are of variable length in which case one of the data octets will be used to indicate how long the message is - There is no "terminator" to mark the end of a message.
For example, the simplest message in the protocol is "Poll": This consists of a name of 00 and nothing else.
An example of a more complex message is "Temperature Sensor Readings" sent from a node. This consists of a name (04) followed by a byte indicating how many temperature sensors are present, followed by a word value for each sensor.
4. Construction Of A Node
For details of a typical node, ETHPIC5, see the separate page.
5. An Aside - A Bug In The Stack
If all the above seems simple and straightforward then let me tell you a tale of the problems I had early on in the development. I connected my first trial node to a test PC running the server software and the connection came up beautifully. I requested a change to an output and the message was passed and obeyed. All was looking fine until I turned away for a minute and the connection dropped. The timer I had included protecting the connection expired, and the node reconnected. And about a minute later it dropped again.
A careful study of my software failed to reveal any reason for this unsatisfactory behaviour, so it was out with the Wireshark and a book on the TCP protocol. And it was soon clear that something wasn't right in the node. After successful transmission and acknowledgement of a message, the SBC65 kept sending the last ACK over and over again, at increasing intervals (Which would be the correct action if it didn't think the other end had received the ACK.) Eventually the node gave up and closed the connection. (Again, the correct action if the server hadn't responded to the ACK.)
As I said above, all the source code is provided, so my next move was to study the IP stack software. And it didn't take too long too work out what was happening - The retransmission timer was being restarted even when there was nothing to retransmit - and I was soon able to find a tweak to fix the bug. Further research showed that Modtronix use an IP stack provided by Microchip, and on visiting Microchip's site I found a newer version of the stack which fixed the bug.
No comments:
Post a Comment