Rule based languages are simply awesome once you get your brain to accept how they work, and you stop trying to program them how you would normally do with languages such as C. All the most complicated programs that simple worked great that I wrote were done with declarative languages such as Prolog. Yet they were very simple and easy to understand. Which is one reason I love Prolog. But Erlang with it's messaging capacity has so much more potential.
Glad to see that you are having fun with it, the beauty is that if written according to Erlang methods those modules could be in different PC's with different OS's and everything would work just peachy. Let us know when you update your website. Bob Cowdery wrote: > Well it's been a while but - now I'm having fun - although the last > month has been a roller-coaster ride. Many times, sometimes more than > once in the same day giving up seemed a really good option, then a small > breakthrough would spur me on a little further. I don't know how much > time I have spent on this because I do have a day job but I suspect more > time than I should have. > > I'm not going to make this technical. I will do a writeup later and post > it on my web site. Suffice it to say I am sitting here listening to my > Erlang distributed radio. It's not quite the architecture I envisaged at > the start but I like it... rather a lot. It's running in 3 nodes, two > are pure C using the Erlang ei library and the other is native Erlang. > Node 1 is a thin GTK+ UI. Node 2 is the application implemented with a > state machine and Node 3, the Erlang node, I have called the switcher. > Node 1 is completely dumb, it sends events and receives updates, it > absolutely never does anything of it's own accord. Node 2 knows what to > do to implement an event. Node 3 knows how to route messages and is the > message switching hub. > > I didn't want a hub topology as I had peer-to-peer in mind but in the > end after failing on my initial design it looked the best way forward. > Having done it I think it separates out the 'what to do' (Node 2) and > the 'where to get it done' (Node 3) quite nicely. My real fear was > performance, longer message path and potential bottleneck. The > performance has literally astounded me. My acid test is running the > pointer over the tuning digits which grow when the cursor is over the > digit. I can't beat the system it's absolutely as responsive as it was > when it was all C in the same executable. All running on my 2.4GHz m/c > DSP takes 2% and the rest is not measurable. If I scroll frequency up > and down fast or run over the digits I can get the UI to take 2%. I'm > not sending display data right now and that will be the teller but > indications are it shouldn't be a problem. > > Erlang is very stable, very fast and very concise. I'm well impressed. > My Erlang switcher is just over 50 lines of code. It's a start-up > monitor, a registry and a store and forward switch. It will cope with an > arbitrary number of nodes. In my books that's impressive in 50 lines. > Ok, it needs to grow up a bit, well, quite a lot but it does the job. > > The thing that kept me going was the possibilities that kept popping > into my head that this would open up. > > 1. Obviously the hardware controller and DSP can be placed at C nodes. > Currently these are directly attached to the state machine. You can of > course have multiple of these as the switcher only need resolve who the > messages are for. > 2. The UI can be distributed. There is no need for the UI to all run as > the same piece of code. Heck, the pieces don't even need to be the same > language or run on the same machine. There would be no overhead at all > in splitting the UI up. > 3. A ready made plug-in architecture. A bit of boiler-plate code and > pieces of UI can be made as separate nodes (or anything else for that > matter). How about a scanner, a memory bank, a special display or tuning > control. > 4. A prime candidate for a node is CAT. If the CAT sends change > frequency to the switcher, messages end up at the UI to update the > frequency and the controller to set the frequency because that's what > the state machine does when it gets that event. > 5. Another prime candidate is a scripting node. This would let you write > small programs preferably in Erlang to run the radio for special > purposes. The infrastructure is there, the API is there because it's > that same set of events the state machine can respond to. > 6. Easy to distribute across machines (of course). This is the next > thing I want to do. > 7. Everything is potentially cross-platform. Next but one thing to try. > 8. Can be expanded to spoke and hub topology to spread the switching > load should it become too high. > > I do believe I'm going to stop playing infrastructure now and work on > function (no - really, this time). I've only scratched the surface of > Erlang so I'm looking forward to learning what it can really do. It is > still first steps but I'm walking a little faster. Thanks to Frank and > Bob for pointing things in this direction. I was sceptical, and to be > honest remained sceptical virtually until I had it working, always > expecting that stopper than would render everything useless. Happily > nearly all the problems were self-inflicted. > > 73 > Bob > G3UKB SNIP >>>> >>> 73 >>> Bob >>> G3UKB >>> > > _______________________________________________ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com > -- Cecil KD5NWA www.qrpradio.com www.hpsdr.com "Sacred Cows make the best Hamburger!" Don Seglio Batuna _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
