Go Down

Topic: Arduino serial communication: introducing Yaspie (Read 278 times) previous topic - next topic

hewi

All,

automating my home, I have looked into several (read all) possible serial communications protocols, none of which satisfies my needs.  Biggest problem is the arduino UART taking over the processor while 'communicating'.  Also any use of these low level protocols is quite 'difficult' for many computer/programmer illiterate.

Users should be able to plug an arduino micro into their wall socket, attach a switch, upload below code and be up and running ...

So I decided, you guessed it, to come up with my home made solution: YASPIE yaspie: yet another serial protocol inthe ether

I would like this protocol to be 'user friendly'.  So one could invoke the following functions:

slave
Code: [Select]

#include "yaspie.h"

void setup() {
  YSP_init();
}

void loop() {
/** function YSP_listenToPinSwitchOnOff
 *
 * listens to a(n arduino) pin input defined in first param,
 * sends message defined in second param if previous pin
 * was switched on and off, in this particular order

 * @pre: listening pin is input and off, low, negative, 'at rest'
 * @pre: messaging 'bus' is free
 * @param: pin_to_listen_to: integer from 0 to 12
 * @param: message to send: string, character pointer,
 * @side-effect: sends a message on the 'bus'
 * @return: error if wrong params where provided
 * @return: warning if message was not sent
 * @return: succes if message was sent succesfully
 */
  YSP_listenToPinSwitchOnOff(8, "kitchen.lights.switched")
}


master
Code: [Select]

#include "yaspie.h"

void setup() {
  YSP_init();
}

void loop() {
  /** toggles a pin high low on receiving a certain message*/
  YSP_togglePinOnMessage(8, "kitchen.lights.switched")
}


The relation to the OSI model:

Layer 1: Physical layer:for now, the physical layer is divided between a input pin and an output pin, using the arduino's 5V high and common ground.  Receive pin is neutral high, send pin is neutral low.  Any message, being a sequence of bits, high low changes, is called 'signal' from here on.
The signal, being transmitted or received, will be a sequence of voltage changes, in the arduino instance between 0 and 5V.
The signal will be duplicated onto the arduino itself, where an input pin being receive will be bridged into an output pin and similarly one output pin being transmit will be bridged into an input pin.  All this is to deal with error checking and collision detection and avoidance.
The signal will be duplicated by all the nodes in the network using the catch-phrase:"it wasn't me".  If a node detects a signal transmitted, it will copy paste the signal from it's receive pin to it's send pin.

All the above will be changeable by setting the appropriate flags, eventually to also be able to link different protocols, physical layers, wire sets, media use, ...
simplest form: we fire a one into space and don't care about the rest
most complex form: time, voltage and frequency multiplexing signals are sent through all sorts of possible media, using all sorts of protocols, the signals are error checked back and forth, in and out, into four dimensions
  
Layer 2: Data link layer
  


There is a lot more to say about the error checking, serial communication, practical implementation and so on, but my basic question is:

has this been done already?

trying to prevent re-inventing the wheel here :)

terryking228

Hi,
Various Power Line communications schemes have been designed and built.  That seems like to more difficult than a protocol.  Give us some details of the physical/electrical layer of Yaspie...
Regards, Terry King terry@yourduino.com  - Check great prices, devices and Arduino-related boards at http://YourDuino.com
HOW-TO: http://ArduinoInfo.Info

westfw

Quote
Biggest problem is the arduino UART taking over the processor while 'communicating'.
Except that in most of the Arduinos, the uart is interrupt driven and does NOT "take over the processor."   Instead, you get a couple of microseconds worth of interrupt service routine every millisecond or so.

hewi

I have updated the original post, including the physical layer description

Robin2

I have updated the original post, including the physical layer description
It would be a great help to the reader of this Thread if you can reinstate your Original Post and add the new information in a new Reply in the proper chronological order. That way the Thread will make sense when read from top to bottom.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rockwallaby

I've dabbled in serial communications for many years now, starting with Signetics 2650 and then moving to more advanced serial routines all written in assembler for the Zilog Z80 way back in the eighties, so, when I read what hewi writes on serial communications:
Quote
simplest form: we fire a one into space and don't care about the rest
I must say, I am lost as to what is the meaning of such a statement. Do I use a canon to fire a large cut-out of the number '1' into space, pointed to say, little Pluto ? And, should I not care about the rest, the rest of what ?

Maybe I shouldn't start on:
Quote
most complex form: time, voltage and frequency multiplexing signals are sent through all sorts of possible media, using all sorts of protocols, the signals are error checked back and forth, in and out, into four dimensions
Hewi, can I suggest you state clearly of what you mean, rather than saying 'all sorts', be specific.
If you say 'all sorts of protocols', that doesn't give any information at all.

The OSI model has been clearly defined many years ago now, though I am unsure exactly how your reference to it relates, maybe you could explain more clearly what you mean ?

Maybe a point list detailing benefits and applications would help also.

I'll get back to writing my own serial protocols again  :)
Paul - VK7KPA
Paul - VK7KPA

MorganS

YASPIE yaspie: yet another serial protocol inthe ether
That Sourceforge page looks empty to me. There's no files. The summary page links back to itself. Do you see files there? Maybe you need to give us permission to read them. It's showing zero downloads at the moment.

There is a lot more to say about the error checking, serial communication, practical implementation and so on, but my basic question is:

has this been done already?

trying to prevent re-inventing the wheel here :)
1. Probably.

2. Don't invent the square wheel, please.

If you have more to say then say it. Or publish your source files.

I can't tell yet if this is a bit-oriented protocol or byte-oriented. The bit-based protocol has already been solved for Arduino with VirtualWire.  If you're byte-oriented then you're already at OSI layer 2, which you haven't described at all.

If all you're doing is physical layer and switching kitchen lights on and off, then maybe the Moteino has already done everything you want.

Except that in most of the Arduinos, the uart is interrupt driven and does NOT "take over the processor."   Instead, you get a couple of microseconds worth of interrupt service routine every millisecond or so.
True.
"The problem is in the code you didn't post."

hewi

That Sourceforge page looks empty to me. There's no files.
interesting, do you not see a 'root' tab in the projects home page?  This is the first time I share any project like this, so it is possible I need to adjust some flags.
And also, I am currently just implementing the YASPIE data structure, trying to identify how I could return function, their different parameters and possible errors.
stackoverlow function return type question 
the project is at it's very earliest stages of development and is not fully defined yet, thought the core idea is there.

1. Probably.
I would have assumed so, but can't find it :) obviously

looking into VirtualWire.
looking into Moteino

thanks for info

westfw

Quote
none of which satisfies my needs.
You have not described your needs.

Quote
Biggest problem is the arduino UART taking over the processor while 'communicating'.
No, it doesn't.

Quote
any use of these low level protocols is quite 'difficult' for many computer/programmer illiterate.
API issue unrelated to the actual protocols used.
Quote
That Sourceforge page looks empty to me.
There's some test framework code, and some .h files, but I didn't see anything about the protocol itself.
Quote
the core idea is there.
I couldn't find the core ideas.

Quote
Code: [Select]
  YSP_togglePinOnMessage(8, "kitchen.lights.switched")

This looks vaguely like the high-level APIs that BTLE seems designed to address, with its "Services" and "Characteristics."  Which it achieve at great complexity, over a relatively high-bandwidth radio links, making a typical BTLE-dedicated microcontroller use 100kB+ of flash memory space. :-(

Quote
we fire a one into space and don't care about the rest  ...
If a node detects a signal transmitted, it will copy paste the signal from it's receive pin to it's send pin.
And this sounds like you're after some sort of variably-timed self-clocking data transfer where you send a bit here and there, which everyone else eventually sees and you eventually realize has been sent as far as it will go.  A sort of bit-banged ring network.  That could be sort-of interesting, but I'm not sure its practical.  I'm pretty sure a uart-based serial ring would work a lot better, and that's been re-invented (at least at the bottom layers) any number of times (they wouldn't let me make one for my Senior Design Project back in 1980.)
I think you should step back and more clearly define your "requirements":
There are "network" requirements:
0) type of physical connection.  Wire?  What type, how long, what voltages, what noise immunity, etc.
1) Number of nodes on a network?
2) end-to-end throughput requirements?
3) Addressing
4) Broadcasts?   Multicasts?
And/Or API requirements:
1) do you really want to use text?  Who manages what text is "legal"?  What happens if someone says "Porsche.headlights.ignited=1" and you don't have a Porsche, and wouldn't want it's headlights on fire if your did
2) It almost sounds like, more than a communications protocol, you want a sort of "distributed database" so that all the connected devices know the pin states of each other, and you can do things like:

Code: [Select]
digitalWrite("BMW.seatwarmer", ON);
and have it work whether or not the box that executes the statement is actually in the BMW.  That's not a bad idea, but it can get pretty complicated, and it's also pretty independent of the actually physical layers involved.

Quote
the physical layer is ... The signal will be duplicated by all the nodes in the network using the catch-phrase:"it wasn't me".
And... you've gone past the "physical layer."
I key thought to keep in mind with OSI layering is that theoretically, you should be able to replace all the layers "underneath" a particular layer with "something else."    Your "it wasn't me" concept is at a higher level than the "voltage levels and etc" that ought to be part of the physical layer.
BACK to the drawing board with you!

MorganS

OK, I found the root tab.

It's not empty but it just looks like you hit "new project" in a reasonably complex IDE and then saved the result. There's no useful code there.
"The problem is in the code you didn't post."

Go Up