-1

I'm thinking in developing a communication protocol for easy communication between embedded devices and computers to replace RS232 which is very old by now. I want to define the software stack and the electrical interface.

Where should I start? What should I present and to whom? How can I then make people adopt such protocol?

I know I'm probably shooting for the moon, but what the hell, I'll probably have fun while doing it :)

PedroD
  • 5,670
  • 12
  • 46
  • 84
  • You know there are numerous protocols other than RS232 in existence, right? I2C, CanBUS, SPI, etc. This also seems similar to this: http://stackoverflow.com/questions/1445387/how-do-you-design-a-serial-command-protocol-for-an-embedded-system. Are you looking at the hardware layer or the software layer? – roelofs Aug 11 '14 at 16:36
  • Yes I am aware of that. But I want to do it either way. And no, my goal is not the same one on that thread. – PedroD Aug 11 '14 at 16:37
  • Cool cool. That's why I asked whether you're looking at hardware or software layers (that thread was focussed on software, so it seems you're aiming at hardware?) – roelofs Aug 11 '14 at 16:39
  • Both. I want to develop the hardware and the protocol used to communicate with that hardware. This will probably imply that I also create an API/library/driver to easily install this protocol in any software application. For example for arduino I'll have a library that enables send and receive messages using that protocol. I may also create hardware convertors to convert it to USB for example, enabling communication with devices that don't have the required hardware. My goal is to create an interface very easy to use, both in hardware and software contexts. – PedroD Aug 11 '14 at 16:44

1 Answers1

1

I would begin by looking at other protocols in existence, and seeing where there are gaps in functionality and performance, as well as things that are 'must haves'.

Next I would look at the protocol specifications (where available) for ones that are close to what you want to do. This will help you judge scope, complexity, etc. for your own design.

At this point, you should start defining your own requirements. Are you focussing on home environments, or industrial environments? Do you want it to be fast or robust? Do you want to use existing hardware and bitbang a new protocol over that, or design completely new hardware? How much functionality resides in hardware, and how much in software?

Following requirements, would be specifications. This would include things like speeds, distances, RFI specs, error correcting, physical design parameters, etc.

At this stage, you should be at a point where you can start playing with proof of concept designs (hardware and software), and adjust your specifications based on results achieved.

As for actually convincing other people to use your design, unless it's absolutely mindblowing (and even then there are no guarantees - see VHS vs Betamax), you may have to seek professional advice from people who have done similar things.

I would also involve the embedded community when you start getting an idea of what you're aiming for. That should give you some idea of whether you're reinventing some existing wheel, or whether you may actually be filling a niche that nobody has had the guts to tackle.

Having said all this

Developing a robust hardware layer is an extremely time and resource intensive process, considering there are numerous good alternatives available. Maybe focus on building a useful software layer first, which you can always later adapt to a different (yours?) hardware layer.

roelofs
  • 2,132
  • 20
  • 25
  • @PedroD : I found this: http://www.embedded.com/design/connectivity/4023975/Serial-Protocols-Compared - it may be interesting reading. – roelofs Aug 11 '14 at 16:57