Frequency, IRIN and PWM

WhiteSpace

Well-known member
I see from the manual that, for IRIN
“Effect of Increased Clock Speed:
This command will automatically use the internal 4MHz resonator for correct operation” (Manual 2, page 128)
and, for PWM,
“pwmout is dependant on the clock frequency. On some X1/X2 timing sensitive commands, such as readtemp [and IRIN, if I understand page 128 correctly], the command automatically drops to the internal 4MHz resonator to ensure timing accuracy. This will cause the background pwm to change, so pwm should be stopped during these commands.” (page 175)
I assume this means that this applies at all times when PWM is running in the background, and not just while the initial pwmout or subsequent pwmduty commands are being sent? So essentially it means that for a project with PWM running more or less constantly and very regular IRIN commands to drive the vehicle, I’m limited to 4MHz? I couldn’t find anything specific on the forum. Maybe it’s too obvious!
Are there any cunning workarounds to get higher frequencies while using IRIN?
Thanks very much.
 

hippy

Technical Support
Staff member
I assume this means that this applies at all times when PWM is running in the background, and not just while the initial pwmout or subsequent pwmduty commands are being sent?
That is correct. If you set the PWMOUT running at a certain rate at 8MHz or above, when you execute IRIN the PWM output will slow down while the IRIN is executing then speed up again afterwards.

The slow down is in frequency only, not the duty ratio of high to low lengths, so that slow down can be acceptable and not even noticed in some cases.

If that's not acceptable, and one needs to run PWM at higher frequencies, then one can move IRIN handling to another chip, such as an 08M2, which can always run at 4MHz or drop speed without affecting anything, which passes serial data to the main controller, which can continue to run at whatever speed it is running at.
 

WhiteSpace

Well-known member
Thanks @hippy for the prompt solution as always! I hadn’t realised that you can connect two chips. That raises all sorts of interesting possibilities. So you would put one set of code on the 08M2 (for example) that reads IRIN into a variable and then just sends it to the main controller by serout and the main controller receives it as serin? It would then also be possible to have the “IRIN chip” doing a bit of checking before sending it on, while not slowing down the main chip. I think first though I will try running the chip faster (I have now moved the receiver/vehicle to a 28X2 so am I right in think that is a max 16MHz internally), perhaps changing the normal PWM frequency to 4 times faster than I currently have it, so while it’s receiving IRIN it runs at the current speed.

I’ve been working on putting an OLED display on the vehicle, showing motor current and battery voltage, which l’ll post shortly in case it’s of interest. It has slowed things down a bit though, hence the wish to increase the frequency.
 

hippy

Technical Support
Staff member
So you would put one set of code on the 08M2 (for example) that reads IRIN into a variable and then just sends it to the main controller by serout and the main controller receives it as serin?
Exactly that, though it is best to use HSERIN on the receiving PICAXE so the two don't need to be synchronised. But synchronised isn't too hard to do, just two-wires plus power are enough; "I have data", "Please send me that data". The "I have data" line can be re-used to send the actual data.
It would then also be possible to have the “IRIN chip” doing a bit of checking before sending it on, while not slowing down the main chip.
Again, exactly that. For example you might want to check you have two consecutive IR commands the same before passing the command on to the main PICAXE.

It also means you don't have to worry about timeouts and stuff like that. The receiver can do whatever it does at its leisure and the main PICAXE won't care at all.

It's not perfect, needs another PICAXE, but an additional 08M2 is a small price to pay for the gains it actually gives. It generally shouldn't complicate the program any more than having an IRIN command would, and can often be even simpler than handling timeouts.
Code:
IrReceiver:
  High TX
  Do
    IrIn b0
    SerOut TX, T4800, ( b0 )
  Loop
Code:
MainPicaxeM2:
  HSerSetup B4800, %10000 ; <- HSEROUT not used, allows SERTXD
  Do
    If time <> w1 Then
      w1 = time
      SerTxd( #w1, " " )
    End If
    b1 = 1
    HSerIn w0
    If b1 = 0 Then
      SerTxd( "IR=", #b0, " " )
    End If
  Loop
And the syncronised version which can use SERIN and doesn't need to use HSERIN ...
Code:
IrReceiver:
  Low I_HAVE_DATA_OUT
  Do
    IrIn b0
    Do : Loop until PLEASE_SEND_DATA_IN = 0
    High I_HAVE_DATA_OUT
    Do : Loop until PLEASE_SEND_DATA_IN = 1
    SerOut I_HAVE_DATA_OUT, T4800, ( b0 )
    Low I_HAVE_DATA_OUT
  Loop
Code:
MainPicaxeUsingSerin:
  Low PLEASE_SEND_DATA
  Do
    If time <> w1 Then
      w1 = time
      SerTxd( #w1, " " )
    End If
    If DATA_AVAILABLE_IN = 1 Then
      High PLEASE_SEND_DATA
      SerIn DATA_AVAILBLE_IN, T4800, b0
      Low PLEASE_SEND_DATA
      SerTxd( "IR=", #b0, " " )
    End If
  Loop
Code:
                     ___
IR RECEIVED      ---|___|--------------------------------
                           ______   _ _ _ _ _ _ _ _ __
I HAVE DATA OUT  _________|      |_|_|_|_|_|_|_|_|_|  |___
                               ________________________
PLEASE SEND      _____________|                        |__
                                 ____________________
READ DATA        ---------------|____________________|----
Note that the "I have data" signal can drive an interrupt so the main PICAXE doesn't even need to poll to check when data arrives.
 
Last edited:

WhiteSpace

Well-known member
Thanks very much - very useful. I’ll first try the increasing the frequency on the receiver and refreshing the display perhaps only every 5th IRIN, so that it can run IRIN updates more frequently. I have also been getting the odd rogue value for IRIN, shown on the serial terminal, and eg. suddenly reversing the motor direction, when the transmitter is steady. I’m not sure yet whether the signal is being corrupted mid-air or whether eg. a momentary wiggle of a breadboard connection at the transmitter end is possible. I’ll need to check the various values and put in some checks. If that doesn’t work, I’ll try the 2 Picaxe route. Thanks.
 
Top