BUSnet

[graynomad]

I'm working on my fieldbus spec (see here http://www.picaxeforum.co.uk/showthread.php?t=15039), specifically on the high-level API and trying to make it Picaxe friendly.

Never having used Picaxes though I'm designing from the Rev-ed documentation which is very good but there's nothing like having experience with the chips.

There will be a BUSnet Interface Chip (BNIC) to handle all the protocol, it will talk to a Picaxe via an async 4800bps serial connection (two lines), essentially the BNIC sends a command to the Picaxe and gets a response.

However the BNIC and Picaxe are running asynchronously so the Picaxe never knows when a command is due. As the serin command blocks I don't think it's viable to constantly wait on a serin because nothing else would ever get done by the application.

I've spec'd the following (excerpt from one of the manuals)

The Picaxe family of processors has a serial input command called serin, however the use of this command causes all processing to stop so nothing will get done if the processor is constantly waiting for a byte from the BNIC. The BNIC helps with this by transmitting a null byte (00) followed by a delay before sending a command frame.

Thus the Picaxe should use the setint command to enable an interrupt on the pin used for serial input. The null byte will trip the interrupt at which time the processor should monitor the line waiting for it to return high. When it returns to the idle state then the serin command can then be used as the frame is imminent.

So my question is, does the above make sense in the Picaxe world?

Thanks
Graynomad (Rob)

 

[manuka]

as the frame is imminent.

Rob: I can't say I've heard that colourful phrase in datacomms work before! Your approach may well make sense, but assorted workarounds for the SERIN hangup blues have evolved anyway. Best you FIRST specify which PICAXE you are using- there are 17 of them & some recent offerings have SERIN timeouts. Stan.

 

[BeanieBots]

As stated by Manuka, there have been many postings about serin hangup workarounds.
However, the more recent additions (X range) to the PICAXE family have background serial which can tranfer incomming data directly into memory (scratchpad) and at the same time set an internal flag which in turn can trigger an interrupt.
Hence, there is no need for your host to do anything special with an appropriate choice of PICAXE.

 

[graynomad]

Thanks guys.

as the frame is iminent.

What can I say, too much time spent writing magazine articles and blogs

As for which Picaxe, maybe apart from excluding really old devices, I don't want have to differentiate. The background serial is perfect but I gather the X parts only go down to 18 pins, this may or may not be an issue but I'd like people to be able to use 8-pin chips, say on a Node with one or two IOs. Likewise for the timeout I guess, only available on larger/newer chips.

The background serial would still work with my proposed scheme, just ignore the first (null) byte when parsing the command.

I'll have a trawl through previous threads but it seems at least you're not telling me that it won't work. Even it it's not the best way I have to have a protocol that works with everything (non-Picaxe as well) without having different versions of interface chip.

I really want to make this Picaxe friendly as I see a strong community here of people building neat projects.

 

[manuka]

GM: I pen a few words myself & always admire those with "Gilbert & Sullivan/Eric Idle" style flair. Aside from your admirable armchair science pondering, can you confirm if in fact you've actually got to grips with any of our noble PICAXEs? I'm a learn by doing fan, and strongly recommend you roll up your sleeves & follow likewise- at least with a 08M.

Where are you in Oz. ? Stan (NZ)

 

[hippy]

The ideal mechanism would be for the BNIC to signal the PICAXE that data is ready and then wait for the PICAXE to ask for the data to be sent. This would allow both interrupt and polling and allow the PICAXE to have control over when it receives the data. The handshake mechanism should likely apply to all communications so the the PICAXE can take one byte, store it somewhere or process it, then tell the BNIC it's ready for another byte.

It should be possible to tie the 'send data' line high or use some other connection to let the BNIC know that it's connected to a PICAXE which accepts background receive data, and/or to connect 'I have data' to 'send data' so it's automatically sent. You might still want some handshaking even then.

Ultimately, to be widely successful, you need to make the BNIC easy and flexible to use with a variety of PICAXE, be able to work alongside a PICAXE program rather than dictate a single mechanism which has to be used. This will probably also apply to other micro devices a BNIC may connect to.

The PICAXE may not be able to respond when being downloaded to, waiting for a temperature reading or doing something else. Unless you simply throw the data at the PICAXE and don't care if that data is lost, corrupted or misinterpreted you'll need a handshaking mechanism.

This complicates the BNIC design and higher-level protocol because you need to decide what to do if a PICAXE doesn't respond to take data, or more data is received by the BNIC for the PICAXE before it responds. If the BNIC simply stops and waits for the PICAXE you can get knock-on and domino effects where the whole fieldbus grinds to a halt, waiting for something which won't ever happen.

It's also affected by data a PICAXE may need to send out ( which may also need a signalling and handshake system ) and particularly when the PICAXE is sending data and data arrives for it.

The best way to visualise it as a secretary for a PICAXE boss who will do as they please and not what the secretary would like, the secretary having to pass letters received to the PICAXE and take letters back while there's a queue forming with people wanting to send letters and demanding letters from the PICAXE which have to all be routed through the secretary. It can get quite complicated keeping everyone happy and if you try to simplify the protocol you run the risk of the system jamming up or becoming inefficient or with poor response times.

Another way to view the collective fieldbus system is as a telephone exchange with the BNIC's being the telephone lines to each PICAXE user.

 

[graynomad]

Stan: I have not used the Picaxe, these days I'm an AVR freak and in a previous life I used most offerings from Motorola and Zilog. For the moment I've got more than I can handle with the network design (using AVRs) but I do want to have general purpose IO chips that come preprogrammed to do standard things like parallel and serial IO, i2c, infra red etc. I was going to use AVRs for this as well but the more I think about it the more I reckon Picaxes would be better suited, mostly because they already do that stuff, all that is needed is an interface to the BNIC chip and some simple command parsing. So when I get the basics working I may have to get my hands dirty with Picaxes as you suggest. You can only learn so much from the docs.

I've also got a simple development system on the drawing board and this will allow me to verify that it works for Picaxes as well.

As for where I am, at present camped near a lake at Camooweal in western Queensland, heading to Western Aus where I think we'll stay for a couple of years before ambling back east so we can go west again. We live in a 6x6 ex-army truck and pretty much just follow the sun. (story here http://www.robgray.com if you're interested.)

 

[graynomad]

hippy: Thanks. I was thinking so much about the serin blocking that I completely forgot that other commands do it as well, most notably the 800lb gorilla of blocking, the 750mS tempertaure reading. So as you say I can't send a flag then follow up with data, I do need some handshaking.

As all this can be happening at both ends, ie one node sending to another so there's two application uCs, two BNICs and the MCU all in on the act, node response times may get quite long by network standards, luckily this is designed to turn on heaters in a hydroponic system or log battery bank voltages so I still think I can keep the latency down enough for such applications.

There is the very real chance though of the whole thing grinding to a halt and I have to spend a lot of time thinking about the end-to-end handshaking as well. The BNIC will never stop and wait, however to simplify things I'm prepared to say that a BNIC won't accept any new data for the node's application until the previous command is done with, therefore a sending application will just have to retry until it gets through. Also there's deadlocks to think about, what if A gets a command from B that causes it to ask for data from B but B doesn't respond because it's waiting for a response from A.

My head spins just thinking about it , maybe I should just hand the whole thing over to the secretary which is what most smart bosses do.

The hardware for something like this is trivial, it's the protocol that's a killer but without that you can't have a system that makes it easy to connect applications running on seperate nodes by writing just a few lines of code which is my goal.

Plus as you say it should work with all Picaxes of possible. I don't have any free pins on the BNIC and don't want to have several different versions to accomodate different handshaking so I may have to work to the lowest common denominator and if it's not as efficient as it could be on an X part maybe that's what has to be.

However I've already defined that the first thing the Picaxe does on power up is send a byte so I can time the bit rate, it could send another to tell the BNIC of the application processor's capabilities.

 

[manuka]

Rob: Your site makes for great reading! That pix with the stacks of retrieved wire was most impressive. Mmm- you haven't thought of "going wireless" within the vehicle have you? It may save some weight for starters!

No doubt folks up top will consider your style typical of us down under colonials however! I'm reminded of a prime time TV program that once aired in the UK, showing helicopter based deer hunting in NZ. It was so "can do" that most viewers assumed this the norm for Kiwi lifestyles, & for years afterwards UK relatives would quiz me on my deer tally that day. I fobbed them off by mis-hearing as "beer" tally.

Given your "get into it mate" background I strongly recommend grabbing a few PICAXEs & learning at the breadboard level. Grown men often weep with the joyful revelations that result! An email I received ~2004 sticks in my mind- the sender related that he'd done more in a few hours with a PICAXE-08M than he'd previously managed in a few months with other offerings. In your case I'd say you'll manage more in just a few minutes! Stan

 

[graynomad]

Thanks Stan, you're too kind. Wireless in the truck sounds good, I'm thinking a microwave link from the lounge room to the bedroom, as that would pass through the kitchen it would do double duty, just hold food up in the air to cook.

I've convinced myself that Picaxes are the way to go for pre-programmed IO application chips so I'll do more research and get some. It won't be right away though, as I said I've got so much to do just getting the network protocol working and it's a bit difficult for me to work with hardware these days as I don't have a workshop any more. My entire "workshop" has to fit into a box the size of a briefcase so it can be packed away quickly, even to have dinner I have to pack away whatever I'm working on.

BTW, I lived in NZ for a short period in the 70s, was a barman at the South Pacific hotel in Auckland. I google-earthed my old block of flats the other day, they're still there.

 

[graynomad]

hippy: After my last reply at 1 this morning I had a good think while sleeping and have come up with something like this.

When the Picaxe powers up, and after initialising whatever, it sends two bytes to the BNIC, the first is as I said last night, for timing the bit rate. The second can be to set the handshaking protocol to be used.

Low-end processors may have to have handshaking on every byte as you say, high-end chips probably just send the frame without asking at all or just a handshake for the frame not each byte.

As for data being sent from the application (ie the Picaxe), I think that will only be in response to a poll from the BNIC, that gets around any race conditions. So if data has arrived for the Picaxe and it also wants to send data it has to wait for a poll but will get a command with the new data first and will have to handle that before having its say. After that has been dealt with it will get a poll and can send its data.

There will be no pipelining or reconstructing of out-of-sequence frames etc. Way too hard. At the application level programs will block if necessary to get data from another node, there's no need to block when sending data unless you really need an acknowledge before continuing. If the write didn't work the network will detect that, a Node doesn't need to know unless it wants to.

 

[manuka]

Rob: A barman you say ? This could be perfect training for dealing with circuitry frustrations, as many micros have long been associated with driving the faint hearted to drink! To take the anaology further, consider that it's no good just TALKING about XXX(X)s, since it's only when you TASTE them do you appreciate why others sing their praises. Stan.

 

[graynomad]

I'm happy to taste some XXXX as long as you're buying, these days I home brew, can't afford to buy ready-made beer. (To our non-antipodean readers, XXXX is a common beer in Queensland, so called because Queenslanders can't spell "beer").

Meanwhile back OT, I've got a mate who's well into Picaxes, he's currently travelling through various deserts in central Aus but I hope to meet up with him shortly and then I can see how they work, checkout some working gadgets/programs etc.