Faster Interface between Picaxe and PC?

[Chris DeHut]

Hi Group,

I have an application in mind that I think will work with PICAXE chips. Everything I need to do is going to require very high speed so I will have to overclock to 16MHz and or use the assembler function output.

I also need to have high speed communications between a PC (Windows) and the PICAXEs. While I could get 19200 Baud with the overclocking, I really believe I need much faster than that (at least my preliminary research is showing that).

So, faced with this, what are my options at this point.

I need high speed communications between several PICAXEs and a PC. The software on the PC is under my control (I am writing that software in VB6) so I have a bit of flexibility there. The PICs on the other hand I am stumped?

Chris

 

[MartinM57]

I'm getting into the Atmel AVR family now, which are the 'next step up' from PICAXEs (IMHO) - and very good too!.

I've been playing with high speed RS232 and the problem is that you need proper hardware flow control to stop buffers overflowing/characters being missed while (particularly) the PC app is doing sommething else at the same time as data arrives at very high speed.

So you need more than the Rx/Tx pins to acheieve reliable high speed serail comms. Maybe worth looking at RS-485?...but I don't really know much about it.

HTH, Martin

 

[Bloody-orc]

if i may ask, why the hell do you need to send data so fast? sending video with picaxe?

 

[Chris DeHut]

High speed robot application. I need to control 5 servos along with a whole host of other I/O. The "Controlling" application has to be Windows software, however, I can use just about any hardware in between the computer and the robot.

I don't want to go for parallel port control from the PC, far too limitted for the amount of data I need to deal with.

This will be one of those "OH my, what did I get myself into now" projects ;-)

Chris

 

[Bloody-orc]

well all robots i have are working just fine with 4600Baud. no need for hyperfast things. of cource i dont send every single data byte to PC aswell. it would be stupid. i pack them up and send only few of them to my PC. most of the sensors are being monitored by picaxe and they wont get to the PC ever.

 

[hippy]

There comes a point where you are not just sending data that mechanical devices can't keep pace with, but where the controller can't handle it either.

At 19200 baud that's one byte arriving every 520uS which has to be processed on-the-fly or stored and handled later. That could be pushing a PICAXE over its limit even when over-clocked. If you really need such high rates I think you will need to look at processors other than the PICAXE.

The trick with using any constrained device in a real time system is to give it a small and simple job to do and only update it as necessary. Comms to and from any part are kept to a minimum so while the whole system may be extremely busy, the individual parts are able to stroll along at a liesurely pace.

It's probably worthwhile reviewing your system architecture. It's tempting to have each module do as much as it can ( if it supports 8 servos we'll drive 8 servos ), but sometimes 8 separate units each driving one servo makes for a much easier system. I'll accept there's an issue of cost here.

Key to any distributed system is its comms, and a means to leave a unit alone while communicating with others is a necessity to maximise each units capabilities. That can be done by routiing comms down channels to each unit ( star ) so each only ever sees data for itself or by a multi-drop with meta-data ( header ID's etc ) so the unit can ignore what's not for it. Unfortunately the PICAXE isn't ideally suited to either.

 

[andrewpro]

Instead of speeding up your communication, why not lower the amount of data that you need to send? You can do 256 different things per byte sent, so why send 256 bytes when you can send only one? Cut down everywhere possible.

As far as high speed comms go...I use AVR's all the time and going between them and the PC still cant go faster than 115k, and even then that's rediculously fast for most things. The only thing I've ever found that requires those speeds are my data acquisition systems for my radio telescopes, and even then I still dont use all the bandwidth.

Theres also nothing wrong with using a parallel port. You can shove alot mroe data through it than you can through the RS232 serial port. It requires more overhead, though. If all your going to do is input data at high speeds, or output data at high speeds, it's a great alternative. You need a big picaxe to pull it off, though. Youd barely squeak out a 4x overclocked picaxe if all you did was send data over and over again with a non overclocked picaxe, but you wouldn't be able to do anyhitng in between there.

you could also look into using FIFO's and UARTS external to the picaxe. You could then clock ina nd out to your hearts content as needed...think of it as a buffer. load it up with data and take it out as needed, rather than needing to poll and track the comms directly. It helps to reduce the software timing overhead.

I'm with everyone else, though...why do you need to communicate so fast? Even if you could communicate with a picaxe that fast, you woudln't be able to do anyhitng with the data fast enough to keep up with the comms...


--Andy P

 

[Jeremy Leach]

I once cut down the comms bandwidth requirements in a system by devising a method of predicting data. Both send and receive units predicted, and the send unit only sent when it knew a mistake would be made. Not saying this will help - but there's lot's of ways of designing a system ;-)

 

[BeanieBots]

Very crafty idea Jeremy. At first, I thought that would only apply to very few systems, but thinking about it further, many systems are actually really quite predictable.
Another approach to reducing data transfer is to only send difference data. Combining both methods could result in a very small data set. Might cause a large computing overhead though.

 

[Jeremy Leach]

What prompted me is that servo behaviour might be quite predictable. Perhaps the rate of change of the position. Depends on how the servos are being used though.

 

[Jeremy Leach]

Actually I think the proper term for what I'm talking about is 'predictive encoding'. This site gives some general info on encoding techniques ...

<A href='http://www.cise.ufl.edu/~nemo/cen4500/coding.html' Target=_Blank>External Web Link</a>

Although I think as Beaniebots mentions, the drawback with anything fancy is the processing overhead.

Predictive encoding is fascinating though, and makes you start to think of possibilities. For instance in transmitting text, it's quite easy to start thinking of ways to predict the next letter.

 

[sparkietrain]

For my major engineering project I built a weatherstation that measured wind speed &amp; direction, rainfall and temperature. I was going to use a 40x, but found it a hell of a lot easier (and more accurate) to incorporate 3 (which in retrospect was prob overkill) to cope with the inputs and not miss count inputs. I then used a very basic program in an 08 to string it all together and send it on, and the string (which was just a qualifier then an encoded byte that the exchange picaxe encoded), totalling my individual poll of the weatherstation to 2 bytes. Using Qbasic (DOS version of VB code-wise) the 386 i was using never skipped a beat. A distributed system as was suggested before certainly takes the load off both the single PIC and the serial data line! It also has the advantage that if something else fails, not everything will fall over.

 

[sparkietrain]

--- Sorry, just to qualify, that was 2 08's and an 08M (for ADC), not three 40X!

 

[Chris DeHut]

Thanks everyone. Perhaps I jumped the gun on this subject. I have been doing some calculations and such and I believe I am in far better shape that I originally thought. Using a few simple &quot;tricks&quot;, I believe I can reduce my &quot;data traffic&quot; by 90% or more. I also found some specialized ICs that can do the vast majority of the work for me which will also help to eliminate a substantial amount of communications. This is looking more and more like a &quot;Go&quot; everyday that I think about it.

Thanks again!

Chris