A new open project - everyone interested is welcome!
kiiid
Posts: 16
Guys, I just wanted to let everyone know that recently I started with setting up an open forum for some old idea of mine that I hope will see the light. It is not directly Propeller-related at the moment, although I hope someday in the future it might become. There isn't much at the moment - only the basic concept and there is a very, very long way to go.
Anyway, you are very welcome to come, have a look and join if you want.
The address is http://ssbgroup.freeforums.org
Thanks!
Anyway, you are very welcome to come, have a look and join if you want.
The address is http://ssbgroup.freeforums.org
Thanks!
Comments
Perhaps you should include here a title and short description of what your project is.
Welcome to the Parallax forums! Perhaps you could elaborate on the nature of your project. More information would likely entice more people to chime in or even join.
Paul
I am trying to create an open project that will produce some simple, reliable and easy to work with serial bus that will take from where the good old ones left before being killed by the USB demon. Although haven't had any posts here so far I've been reading here and playing with props for a long time and see there is a bunch of open-minded engineers around. That's why I thought someone might be interested.
There is always the need to input/output information and in many cases people just need something simple to work with. The hobbyists know that the most. I hope if more people like the basic idea of my bus and it reaches the level of development needed for that it can be included in chips in future.
I'm still not following you. What are you planning to improve? Are you talking about a physical layer or a higher level protocol?
I am talking physical (for now).
And yes, there is quite a few at the moment but they all have one thing in common - some flaw that makes them either old, too resource consuming, too unreliable, for internal use only, etc. I am trying to do something that will work well no matter on the board or cable and no matter how fast the devices individually are.
Mike, sure, without claiming I am always right here is what I think:
RS232 - slow; does not have tools for detecting and maintaining the connection; requires setup of a few parameters or don't work; can't be generally forund in today's equipment
RS485 - better but with different problems - generally not well accepted in consumer products; still requires setup for baudrate; still does not have tools for detecting connection present
SPI, I2C, one-wire, etc. - only for on-board use
USB - ridiculuosly difficult even for the simplest tasks; not network oriented; resource consuming
1394 - fast, clever, but not very suitable for small electronics and microcontrollers; expensive and huge chips; resource consuming
what else... I can't think of something else popular... were you referring to something particular?
I am trying to come up with something simple that will take as much as possible from the good side of these and leave the bad ones behind.
I enjoy playing around with communications protocols.
Once I even dreamed up a simple protocol myself to send
data back and forth using just the power leads to a remote
device. I got it working although it was no real improvement
over what had been done before....I just enjoyed tinkering
with it.
You seem very enthusiastic about this project and I do wish
you well and will keep an eye on the progress. Maybe later
when I get some time play with the stuff I want to instead
of having to slog through boring tasks day after endless day
I could even help somehow.
I'd like to try and use a prop to create a poor-man's multi protocol data
analyzer. It's not really fast enough to analyze something like USB2.0
but still there is a lot that could be done with the prop in a device of this sort.
A prop and a small 7" lcd plus a handful of cheap parts and I think you
could build something that could monitor everything between slow morse code
and pretty fast serial protocols. And since the prop has 8 cores you could
monitor more than one data stream at the same time.
It would just be fun :-)
Some corrections to your list:
SPI, I2C: Usually used for on-board communications. There's no reason why they can't be used for moderate distances (tens of meters) with proper design.
1-Wire: This is designed for moderate to long distances (hundreds of meters or more). There are repeaters available and it's already used for environmental control in large office buildings with large numbers of thermometers on a wire leg.
USB: This is designed for small complex networks with many very different kinds of devices with widely varying bandwidth, latency, and power requirements and the protocol has to allow for dynamic reconfiguration. Fortunately, most of the work is done by the single host controller. The clients can be much simpler.
IEEE1394: It is fast, clever, and was never designed for use in general small electronics or with simple microcontrollers. It was designed for use with high performance mass media (disc drives) and with digitized video (and audio) data.
Good luck with your project.
Anyway, my invitation stands for all at any time now and in future
Go for it Holly. This would be a very useful device for a broad range of applications.
The reason USB is ridiculously difficult is that it was designed to avoid most of the problems you list so it can be "plug and play". Once you add all that to any other communications protocol it will also become ridiculously difficult. The biggest problem with RS232 (other than speed and noise immunity) was that every company that used it on their equipment had some non-standard use for some pin or signal on the DB9/25 connector. I used to carry a bag full of adapters when I serviced mini-computers and PC's.
From a hardware perspective I think it will be difficult to come up with anything simpler than 2 wires twisted around each other to connect several devices in parallel. From a software and operational aspect I think there is a lot of room for improvement. First and foremost would be automatic baud rate detection (by measuring start bit or character length?) (start at a fixed rate and negotiate?), closely followed by auto address selection and assignment of devices on a bus.
I am skeptical, but would also be delighted to hear that you have come up with a simple, powerful, and elegant design for this. The first step would be to list all the good and bad characteristics of the existing protocols and look at how to keep the best points and avoid the worst ones. Easier said than done.
I wish you the very best of luck with this and hope you will update this thread as you go so I can follow your progress.
Soon I may try to implement the first specs of SSB into a Prop object. It will certainly require a few external components, but apart from that will probably work well.
kiiid, I hate to say it but after going over your latest spec, I think the "Simple" has gone from the "Simple Serial", particularly as far as the hardware is concerned. In particular the requirement for a -5V supply. While the software is nowhere near as complex as USB, it also leaves the "Simple" part in the rear view mirror. Virtually everything you are trying to do can be done with RS485 and some small changes in the data format. Sorry about that. I know you have put a lot of effort into this.
"Sorry but this board is currently unavailable."
Perhaps you could post this document in this thread as an attachment?
Sorry about that, I am playing a little with the forum settings and have disabled it while I finish. Attaching the file here. Still not final and there is one known mistake in the text, but much better from what was in the very beginning (thanks to the great efforts of JR)
Thanks for the interest.
kwinn, that's all right. I haven't had even the tiniest belief that everyone will sense what's new or accept it. I can only say you are wrong. Probably haven't understood the concept well? Thanks for the criticism anyway.
You might take a look at the Prop bootloader spec. It's pretty much baudrate-independent, being based on pulse-wdth comparisons. It enables programs to be uploaded to a device running at an uncertain RC-controlled frequency.
-Phil