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: > 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 <[email protected]> > Folgendes geschrieben: > > > 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: > > 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 <[email protected]> > Folgendes geschrieben: > > > 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: > > 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 <[email protected]> > Folgendes geschrieben: > > > 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: > > 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: > > 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 <[email protected]> > Folgendes geschrieben: > > > 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: > > 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 <[email protected]> > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jallib/62993504-3109-4598-8403-ec920d7d63e9n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/62993504-3109-4598-8403-ec920d7d63e9n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/f1b63cef-cffd-4129-8704-6f35adcc0fbcn%40googlegroups.com.
