hsersetup and pwmout
- Thread starter Cunci
- Start date
I have seen the same recently when I tried to convert my Picaxe scope design to use background hserin (which would make some of my program much more elegant). Keeps messing up my PWM output which drives the sample logic. At least in my case the change seems to be a lowering of the PWM frequency by a factor of 4 when hserin receives a byte. It really seems related to hserin, because when I go back to serrxd for receive instead (while still using hserout for output) the scope works perfectly fine. I tried to fix this behavior but after several days of trying have given up for the moment. It probably would be a good idea to strip down the program to a bare minimum which shows the effect.
Some details: Picaxe 28X1, ran it at clock frequencues of 20 MHz and 16 MHz (external resonator) as well as 8, 4, 2, and 1 MHz internal oscillator. Tried it with several hserial data rates between 9600 baud and 112kbaud; PWM is running at 1 MHz and lower. The problem was there in all cases.
Wolfgang
Some details: Picaxe 28X1, ran it at clock frequencues of 20 MHz and 16 MHz (external resonator) as well as 8, 4, 2, and 1 MHz internal oscillator. Tried it with several hserial data rates between 9600 baud and 112kbaud; PWM is running at 1 MHz and lower. The problem was there in all cases.
Wolfgang
Last edited:
I think what fixed your problem was not using background recieve mode in hsersetup. I don't even use hserin in my application. All I have to do is receive some characters on the hardware serial port and the PWM get messed up. I wish I knew what was going on so that we can work around it. I have searched all the manuals for limitations on these commands and can't see where they might be conflicting.
retepsnikrep
Senior Member
I had a similiar problem with hpwm and the timer routine on a 28x1 using firmware A3. Firmware A4 and above corrected that issue it may be the same with this problem which sounds related.
http://www.picaxeforum.co.uk/showthread.php?t=10872&highlight=hpwm+timer+28x1
And from another thread with 28x1 I2c and pwm conflict
http://www.picaxeforum.co.uk/showthread.php?t=10872&highlight=hpwm+timer+28x1
And from another thread with 28x1 I2c and pwm conflict
The hardware pwm module inside the PIC chip used for the 28X1/40X1 creates a 'timer 2' interrupt by setting the timer 2 interrupt flag when the PWM module is active. This is unusual behaviour because, although timer 2 is used by pwm, it is not used in interrupt mode, hence the interrupt flag should not be generated. This also doesn't occur in other PICs we have used in the past.
Unfortunately this silicon issue can effect other commands that legitimately use interrupts - namely servo, timer, hardware i2c (slave mode) and hardware serial.
When we became aware of this limitation of the internal PICs hardware we changed the PICAXE bootstrap to 'workaround' this issue (A.4 onwards). So A.4 onwards chips should work for you.
Unfortunately this silicon issue can effect other commands that legitimately use interrupts - namely servo, timer, hardware i2c (slave mode) and hardware serial.
When we became aware of this limitation of the internal PICs hardware we changed the PICAXE bootstrap to 'workaround' this issue (A.4 onwards). So A.4 onwards chips should work for you.
BeanieBots
Moderator
Can we please have a detailed list of "interactions", fixes and known issues in the firmware.txt file?
szd51pilot
Member
I had problems at the weekend with hserin in background mode causing a PICAXE 28X1 to reset every few seconds. I wasn't using the PWM function.
This is a different situation. With background hserin and slave i2c receipt the chip will reset after 2.1 seconds if the background receipt of a data byte into the PICS hardware module does not fully complete for some reason - for instance a byte starting but then not receiving a valid 'stop' bit within the timeout period. Therefore this implies a fault within the system setup/communications.
The current firmware.txt file is attached.
szd51pilot
Member
Many thanks Technical -that sounds like the problem. I can now investigate further.