We got our serial port working today, thanks to a mini weather station Tom rigged up. After some brief debugging we were happily sending commands and receiving data. I’ve since tested a number of cases: receiving manually requested data, reading unrequested data on a loop, requesting an reading data on a loop. All seems to work well, and we shouldn’t run into any problems with lost data as long as the interval between read checks is less than the interval between writes from the PIC. The magic numbers: port=2, and baudrate=57600.
The next question, at least in my mind, is how Freya and the big PIC are going to talk. The first part of this is:
Do we want the PIC to send one message per data field or one message per group of sensors?
- Advantages of one per data field:
- Each message could be cleanly keyed by a numeric ID corresponding to the data field, so parsing messages would be far simpler and cleaner on the TS 4200 side
- Dealing with once-per-ten-seconds data fields would be easily solved by having all 6 have distinct IDs
- Each data field could have just one identifier which could also be used to specify its place in the database
- Advantages of one per group:
- The timing would be much more forgiving because there would be fewer strings/minute
- Less demand on big PIC, more on group PICs
On the balance of things, I’m thinking one message per group would be simpler probably on both sides of the port. In the configuration file, there’ll have to be a two dimensional array keyed by (group, number) referencing a callable, and perhaps another referencing its location on the final datastring. The callables for each field should be defined in their own file. My ideal would be that the main program will not have to be altered when a sensor is added; an entry would be added to the table(s) in the config file and a function containing how to process its raw data would be defined in the data processing file. Constraints: sensors would have to be added to the end of their group numerically, but that’s the simplest way to do it anyway. For tomorrow: start writing the core of the program.
I think that the main program will be quite simple. Almost all error handling can be dealt with in the data processing file, and auto-control logic can be dealt with in its own file.
Another thing to be thinking about is how to create a UI of some sort for Tom to use to remotely talk to instruments — shouldn’t have two access points to freya running at once, so maybe we’ll have to route that through the Mac.
–Soren