PWM2.

[hans]

A question from a friend. Attached is a test program for the use of the second PWM port C1. The results are opposite to the assignment. On is off and off is on. See the end of the file, the LED would go on for a long time but then it is just off

[hans]

as far as I understand from the database the second pwm is a mirror image of the first. In a circuit where both are needed, the first works as expected. We don't understand how to handle the second.

Op zondag 3 april 2022 om 15:18:54 UTC+2 schreef hans:

[Oliver Seitz]

Hi hans,

this is what the program should do if the LED is connected to RC1 and GND (with resistor):

The LED will slowly light up from off to 99% within one second,

then it will fade from 99% to 1% within another second.

The LED stays at 1% for half a second

PWM is disabled, so the LED will reflect the port pin, which is undefined by default, for half a second 

Then, PWM is reactivated and the LED will resume at 1% for 5 seconds, before starting over again.

That is not what you're seeing?

Greets,

Kiste

Am Sonntag, 3. April 2022, 16:10:38 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

A question from a friend. Attached is a test program for the use of the second PWM port C1. The results are opposite to the assignment. On is off and off is on. See the end of the file, the LED would go on for a long time but then it is just off

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com.

[hans]

Hi Kiste,

PWM2_off() sets the led ON and PMW2_on () sets the light off.. 

regards Hans

Op maandag 4 april 2022 om 09:21:03 UTC+2 schreef Kiste:

[Oliver Seitz]

Sorry, no. 

PWM2_off() does not set the LED off, it switches off the PWM module and passes control of the output pin back to the simple digital output. The digital output can be randomly set to "on", you did not set it to "off".

If you want to keep PWM running and switch off the LED, use

pwm2_set_dutycycle_percent(0)

pwm2_on() and pwm2_off() is not switching the *output* to on or off, it starts or stops the PWM module. If you want to set LED brightness, you don't want to ever stop the module. It's like waiting at the traffic lights: You're setting the car speed to zero (=duty_cycle(0)), but you don't switch off the engine (=pwm_off()). If the street's going downhill, a switched off engine will not surely prevent the car from moving. You need to use the right means for the purpose of stopping the car. 

Greets,

Kiste

Am Montag, 4. April 2022, 11:43:01 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com

.

[hans]

Thank s Kiste

. oops, I've now replaced all on/off's with set_dutycycle_percent(..)

 the program that I use works fine with PWM1 but not with PWM2.

 So there must be a difference.

 Where should I look now?

Op maandag 4 april 2022 om 12:04:31 UTC+2 schreef Kiste:

[hans]

Everything has its limits. We have tried to make a remote control for his two DAIKIN ACs. With PWM1, the case responds just fine with PMW2 not responding. The IR LEDs are controlled with an npn. (swapped) . We also tried the 16F877a, same result. On an AUDICITY we compared the IR results on a TSOP , the IR leds (swapped!)… Both look the same. The frequencies of the PMW varied from 35 to 40. No effect.

So that's the end of the story for us and then just fiddling with one PWM, which we then switch via hardware. Unless ……. Any of you have a different idea.

Attached program and picture

Op maandag 4 april 2022 om 13:52:34 UTC+2 schreef hans:

[Oliver Seitz]

Hi hans,

now as I know what it is for, I can give some hints ;-)

I've done remote signals a lot, and I did it this way:

- I keep the PWM running all the time, at 50% duty.

- I switch the LED on and off by setting the port pin to input/output (Works if the LED is directly connected or via bipolar transistor, not via FET)

If you're changing the duty cycle to switch the LED on or off, there can be a significant delay before the action takes effect. Switching the pin to input or output works instantaneous.

In the "procedure hal()" you're calling "command_send_kamer()", which is probably wrong?

You've got procedures for sending a bit, a byte and a full command. That is good for readability, but not so good for signal quality. You send a burst of 450µs, and the following pause codes the bit. If you're at the end of a byte, the bit procedure is ended, then the byte procedure is ended, then the loop in the command procedure is forwarding one step, the byte procedure is called, then the bit procedure is called, and just then there's the next burst. That's quite some time passing, which can make a "0" look like a "1". Better collect all the bits in a single variable, and send all 152 bits in one loop in one procedure.

And even if not, this is using time in bad places:

teller = 0

     for 19 loop

      if x == high then

        command_send_kamer(HEAT_kamer[teller])

       else

        command_send_kamer(HALT_kamer[teller])

        end if

       teller = teller + 1

     end loop

This would be better:

if x == high then

   for 19 using teller loop

      command_send_kamer(HEAT_kamer[teller])

   end loop

else

   for 19 using teller loop

      command_send_kamer(HALT_kamer[teller])

   end loop

end if

That way there's no "if" between the bytes.

Greets,

Kiste 

Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com

.

[hans]

Hello Kyle,

 Done but same result

. PWM1 works and PWM2 not. Now tested on 16F

How can i combine 19 bytes in one big word

Op dinsdag 5 april 2022 om 13:30:54 UTC+2 schreef Kiste:

[Oliver Seitz]

In procedure kamer (bit in x) is a call to command_send_kamer(HEAT_hal[teller]).

And also in procedure hal (bit in x) is a call to command_send_kamer(HEAT_hal[teller]).

The second should surely call command_send_hal(HEAT_hal[teller]).

As long as the wrong PWM is addressed, no fine-tuning helps.

Greets,

Kiste

Am Dienstag, 5. April 2022, 16:13:19 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com

.

[Rob CJ]

Hi Hans,

I agree with Kiste. You should keep the PWM running and switch the PWM output to input to output a '1' or '0'.

But the issue with pwm2 remains a mistery. I will try it this weekend and use the test program to compare pwm1 and pwm2 since I did not see any difference in the code and at least I know if I would have the same problem.

Kind regards,

Rob

---

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: dinsdag 5 april 2022 18:09
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] PWM2.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1759365406.1110179.1649174971737%40mail.yahoo.com.

[Oliver Seitz]

Here's how I would send the data. I didn't compile it, may have errors. Also, I'm not sure if the protocol is right, just take it as an example:

var byte HALT_kamer_array[19] = {17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
 var byte HEAT_kamer_array[19] = {17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}

 var byte*19 HALT_kamer_long at HALT_kamer_array --these variables are very long and
 var byte*19 HEAT_kamer_long at HEAT_kamer_array --cover the existing arrays

 var byte HALT_hal_array[19] = {17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
 var byte HEAT_hal_array[19] = {17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}

 var byte*19 HALT_kamer_long at HALT_hal_array
 var byte*19 HEAT_kamer_long at HEAT_hal_array

 var byte*19 send_buffer_long
 var bit send_buffer_next_bit at send_buffer_long:0


 -- choose what to send

 send_buffer_long=HEAT_hal_long -- all the variable is copied to the output buffer

 -- now send all the bits

 LED=on
 _usec_delay(10000)     -- send a long burst to calibrate the receiver
 LED=off
 _usec_delay(2000)

 for (8*19) loop

    LED=on
    _usec_delay(450)    -- send a burst
    LED=off

    if send_buffer_next_bit == 1 then -- wait additional time if sending a "1"
       _usec_delay(840) -- the difference between 1190 and 350
    end if

    _usec_delay(350)    --you can reduce this a bit to compensate for the
                        --time needed for the shifting

    send_buffer_long=send_buffer_long >> 1 --takes a while to shift such a long
                                           --variable, but it always takes the  
                                           --same amount of time

 end loop

 LED=on
 _usec_delay(450)       -- send a final burst to end the last bit
 LED=off

Greets,

Kiste

Am Dienstag, 5. April 2022, 16:13:19 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com

.

[Oliver Seitz]

I do see a difference. In procedure hal(), PWM2 is addressed

on lines 141, 144 and 147. Then, on line 153 or 158 the procedure command_send_kamer() is called, which addresses PWM1. It must be command_send_hal() at that point.

Greets,

Kiste

Am Dienstag, 5. April 2022, 18:41:35 MESZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/DB6P195MB01835B837FCC857AF0C008ACE6E49%40DB6P195MB0183.EURP195.PROD.OUTLOOK.COM.

[hans]

Hi Kiste,
The case works !!!
What if I checked something hundreds of times and didn't see this miss?
“Thank you” is meager but sincere.
I'm going to look at the other clues at my leisure.
thanks again and regards
Hans

Op dinsdag 5 april 2022 om 18:44:46 UTC+2 schreef Kiste:

[Oliver Seitz]

Graag gedaan :-)

Do you know why I see that kind of errors? Because I had to find them a hundred times in my own programs ;-)

Greets,

Kiste

Am Dienstag, 5. April 2022, 19:29:10 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/62993504-3109-4598-8403-ec920d7d63e9n%40googlegroups.com

.

[hans]

Thoughtful about this matter.
When turning off PWM1 by applying PWM1_off() the output goes low. When I did the same with PMW2, the output turned out to stay high. Somewhere in the datasheet I had read something that PWM2 is a mirror image of PWM1,
This difference is something to know.
Hence my first question in this series with the custom Sample 16F73_PWM2
This problem can therefore be solved by simply letting the PWM continue to work and switching the ports to input or output.
To narrow things down a bit and then merge the series of bytes into one series of bits, I now wonder if using Matthew's bit array library would be suitable for this.
regards
Hans

Op dinsdag 5 april 2022 om 20:40:28 UTC+2 schreef Kiste:

[Oliver Seitz]

When you switch off the PWM module, the simple GPIO logic takes back control. If PWM is on pin C2, and you set pin_c2=high, C2 will go high when you turn off PWM. When the PIC is first started, the port pins are in undefined state. "undefined" is usually always the same state on a certain chip, but it can be different once in a while, and it can be very different on another chip, even of the same type.

You can use a bit array, but it's quite a slow thing that uses a lot of code space. You don't need an array, in which every bit can be randomly addressed. You're reading the bits always in the same order, from right to left. So, a shift register is the economic solution, and in JAL that means a simple integer variable. JAL can happily handle integer variables of arbitrary length (up to 256 bytes, depending on the chip. For PIC16F, the limit can be 80 or 64 bytes). I'm not sure how long access to a bit in a bit array takes, but I can estimate that shifting a 19 byte variable by one bit at 4MHz takes about 25µs.

You already used the shift scheme for the bytes in the existing program. Just enlarge the variable. It's no big deal, really.

Greets,

Kiste

Am Mittwoch, 6. April 2022, 09:25:00 MESZ hat hans <hansvanve...@gmail.com> Folgendes geschrieben:

https://groups.google.com/d/msgid/jallib/f1b63cef-cffd-4129-8704-6f35adcc0fbcn%40googlegroups.com

.