Pass data between 2 18x

[Noidea]

Dear All,

Thanks for all the help with my last question, re: programming picaxe problems. I have now sorted that out.

I have a new requirement for my project.

2 picaxe chips and I want to pass a number between the two chips. The number would range between 1 and 9. I want to use one picaxe for my sensors and the other picaxe to control my motors via a L239D chip. I want the sensor chip (depending on sensor) to pass the number back so the motors can respond accordingly. This only needs onw way comm from sensors to motor board.

Not asking for the solution, but wouldnt mind a few pointers. Even if it is what part of the manual to read.

I am assuming based on what I have read that standard protocol would be to have motor control and sensor control running from two different chips. I will be then driving the motors in tank track config.

This is really a side question but thought I would pop it in anyways. Assuming I have the right chip written down (but I am using the right one) L239D how do I connect a high voltage to the chip? Is this done by attaching my + < voltage to pin 8, but where do I connect the negative from the second power source? I want to use 12V for the motors.

As Usual
(oo) NoIdea (oo)

 

[goom]

The common ground for the 12V and 5V power supplies connects to pins 4,5,12,13 (also used for heatsinking). 12V connects to pin8 and 5V to pin16 (power for the logic circuits). The datasheet is fairly clear on this.
If you only want forward/reverse/stop for each motor, you may well be able to use a single Picaxe to read the sensor(s), code the logic, and control the motors via the L293D.
If you want speed control, then you may need 2 Picaxes, each providing a PWM signal to one motor. If you feed the sensor signal(s) to both microcontrollers then you may be able to get away without any Picaxe-to-Picaxe communication at all.

 

[BeanieBots]

For the motor driving chip, have a good read of manual 3.

To send a value of 1 to 9 between PICAXEs, I'd use PWMout on the sender and pulsin on the receiver.
I'd use a multiplier and an offset to make it more reliable.
For example, take your number to send, multiply by 10, add 1.
At the receiver, divide by 10. (no need to subtract the 1, it will get lost with the divide by 10).

 

[westaust55]

You can use the SEROUT command ( Manual 2 page 173) to send a value to the second PICAXE
Then use the SERIN commands (page 169) to receive that value.

Since you are using 18X chips, there is no time out capability for the SERIN commands, so the receiving PICAXE will wait forever or effectively lock up.
A simple solution can be to incorporate some simple hand shaking and first have the sensor PICAXE make an “alert” output high then in your Motor PICAXE program scan an input for this signal (if pinx = 1 then . . . ) once per program loop or as desired. Once the “alert” signal is high go to a subroutine for the SERIN command and read in the value which can then be actioned back in the main program.

While only a simple solution, in the Sensor PICAXE you might need a pause between making the signal high and SEROUT to give the second chip time to react. Once SEROUT has been actioned, then set the alert signal low.

How elaborate you code needs to be is dependant upon the required action time, whether missing data when a sensor initiates a change is important, how many different values you need to send, the magnitude (0-255 or other) of the values to be transferred etc.

More information from you can provide a better response.

 

[hippy]

If the motor driving 18X is doing nothing but waiting for data, setting output lines and/or PWMOUT when data arrives, you can use SEROUT / SERIN very easily.

If waiting for SERIN is inconveneient, by altering internal SFR's it is possible to configure an 18X for single byte background receive using its on-chip AUSART. That's what I'd consider in such a case.

 

[kranenborg]

If appliccable (and it seems to me to be the case) I always recommend hippy's serial interrupts solution as it does not require more pins for handshaking and does not require the receiver to wait for a SERIN: http://www.hippy.freeserve.co.uk/picaxesi.htm
You may even not need to use two picaxes but let just one do everything ...

/Jurjen

 

[Noidea]

Thanks guys, will have to have a think as it seems there is almost a split camp between using one for everything vs two (one for sensors and one for engine).

I will crack on and try to get two chips talking anyways as it seems like a good challenge.

Will keep everyone posted on progress.

(oo)NoIdea(oo)

 

[Dippy]

If you want to use 2 PICAXEs and both need to be running code then look seriously at hippy's suggestion.

With respect, as I appreciate this is new to you, I would gather that you don't understand his idea at all.

Many PICs have a peripheral called a USART (or similar name depending on PIC).
Even calling it a 'peripheral' sounds silly doesn't it - as it's in the same chip. But that's another story for the nerds , which no doubt...

Anyway, this USART is basically a little shift-register type buffer where one or two serial data bytes can be stored and read at leisure by your code.
The nice thing is that the byte(s) can sit there while the code is running.
The nicer thing is that a flag is set when a byte (or bytes) is/are in this buffer.

So, your code can be running merrily and now and then look at this flag.
('Flag' being a nerdy word for a value set in a register)
Leaving interrupts to one side, your code can look for this 'flag' every so often.

If it has been set then it can pop into a subroutine and read it.

As in: diddly-diddly-diddly-look-ooh-some-data--read it--diddly-diddly-diddly.

Anyway, in theory, for your app with just a single byte it is the ideal solution. It is how I would do it with PICs.

Without reading the PIC Data Sheet I can't offer a method on how this is done in PICAXE BASIC. There are a few settings to make and things to watch out for.

I think hippy will have to provide the full code solution as I think you will struggle with understanding PIC Data Sheets.

 

[hippy]

Thanks guys, will have to have a think as it seems there is almost a split camp between using one for everything vs two (one for sensors and one for engine).

The decision on which is best comes down to what you are ultimately needing to do. If the motor drive PICAXE only waits for data and then sets the physical driver and stays like that until it receives further data, you may as well have, where the master PICAXE sends the data, set the physical driver itself as this is more simple than passing data over to a proxy.

If you are running out of program memory, I/O lines, or the motor driver needs to be doing something whilst the master is, then a split system makes a lot of sense and is the solution.

A split system can also make sense from a design and debugging perspective even if not absolutely required. The master only has to send speed/etc data and that makes the job of coding and debugging that easier. The motor driver only has to receive data and set its I/O, and that too is easier to code and debug. Such modularisation means two people can work on a project at the same time very easily.

It may be that a split system makes sense during prototyping, then when you have it all working and debugged you can decide which chips and how many are actually needed.