I'm kicking off a new project for a HVAC controller using a Microchip MCU which has both USB and Ethernet available. The controller is close enough to the PC that USB can be used. But I'm now challenging that and wondering about Ethernet connectivity instead. Seems like less potential future issues with drivers (there are none?) with Ethernet. I'm using MSFT Visual C# on the PC application side Any opinions on this appreciated, thx.

 

I'm also working on an HVAC controller, I chose Ethernet because the controller can then be web enabled. More autonomy than USB.
IMO PIC 18F67J60 is a good choice.

 

I manage a huge network of HVAC systems in our building although they're far older than you might think. Control is mainly true proportional pneumatics. Don't laugh - it was an extremely advanced idea in its days and I can make it do about anything I want - then again I've married some of my own custom designed electronics into parts of it.

By all means I'd use Ethernet for a number of reasons. It gives you total flexibility as to where your main controller interface is and allows for remote monitoring.

Nothing I'd love better than to be able to look at all my gauges on a day I'm home sick, or tweak the output to the CEO's office or a conference room via remote.

 

If you use a Power Over Ethernet injection module then USB truly holds no advantages over Ethernet, although local wiring and router considerations will have to be take into account.

 

Alright, thanks for input ... I appreciate it. Pushing forward with Ethernet: I want the data sent and received to the PC to be under programmatic control, not a browser interface. Looks like I would use Winsock in C# to accomplish it?

 

I'm not sure what you mean Instance, a web browser interface is fully capable of programmatic control, cross platform no less.

 

Or telnet, all depends on what you need.

 

Just bitwhack with UDP traffic.

Telnet is fairly involved since that means mapping the HVAC system to a terminal model.

What you want is closest to an internet enabled device driver like a network printers. That also sheds an opinion on the browser vs program interface question I think. But having said that - Java or other Web App language gives you programming options that might let you have both.

 

Sorry, that wasn't very clear. I just meant that I'm wanting utilize the existing code base that is written as a stand alone executable MSFT Visual C# application. Not run in a browser.

 

The simplest method would be what Potatoe said, use UDP, it's blind send and receive with no error correction or garuntee that packets will arive in the same order they were sent though.

 

Best effort netTx is not that bad on its own, but many UDP users implement their own ACK NACKs, error checking parse coding, segmentation and other features.

For the small byte length signals that I am thinking you would want, segmentation is not required, in fact you can do the simplest type of error correction and double send the data in each transmission if you think you will need less than half a Kb for the raw data. You simply receive to the clear(end) code then compare to the repeat.

That leaves ACK and NACK. That is just getting the Rx to say "Got it.", or "Didn't get that."
Then Tx repeats for any send that doesn't get a response (lost data), or gets a "Didn't get that." (corrupt data).

And if I don't think you needed segmentation then I really don't think you need sequencing. I just don't see needing two or more frames. That means that data order should not need to be recreated.

If you need help with those post a question.

If you want to use a full protocol with all the error handling, encryption etc. then you might look at using SMTP. Get your HVAC an email account.