from:"'Oliver Seitz' via jallib"

AW: Re: [jallib] English (function) question

2023-09-30 Thread 'Oliver Seitz' via jallib

Yes, otherwise you could use 1/16" or 1/32" which is near a mm, but it seems to 
be a bit of a strange unit for me.
byte*3 would suffice for the maximum range of 197000 mils, but I'm not sure if 
it's wise to use that... for 5000mm word is enough :-)
Greets,Kiste

Gesendet von Yahoo Mail auf Android 
 
  Am Sa., Sept. 30, 2023 at 11:49 schrieb Rob CJ:   Hi 
Kiste,
Thanks for the suggestion. Question about the mils. The modules resoluiton is 
limited (see screenshot below). What would 1/000 of an inch bring? Is it 
because of the standard terminology mils?


So your suggestion would be the following?function hcsr04_get_distance_mm() 
return dword is
function hcsr04_get_distance_mils) return dword is

Thanks.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: zaterdag 30 september 2023 11:21
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] English (function) question Hi Rob,
I wanted to suggest to name the functions after the return data type. I never 
use floats, so if I would have a function called "fine", it would return a 
length in mm (metric) or mils (=1/1000 inch imperial)
Even if you would return a length in micrometers, a dword would suffice for a 
range of over 4 kilometers, still by a smaller overhead than using a float.
Greets,Kiste
Am Samstag, 30. September 2023 um 11:11:37 MESZ hat Rob CJ  
Folgendes geschrieben:

Hi Vasile,
Thanks 
I just came up with another idea. Using a float value makes the library big in 
ROM size (it easily adds 600 byte of ROM or more) and I only need one decimal.
So I have another idea and that is return the distance in mm. In that case I 
only need a word as return value.
So now I have only two functions:function 
hcsr04_get_distance_mili_meter()return word isfunction 
hcsr04_get_distance_mili_inch()return word is
I only do not know if mili-inch is an English term. Would like to know that.
Or should I use tens_of_cm and tens_of_inch?
Thanks.
Kind regards,
Rob
Van: jallib@googlegroups.com  namens vasi vasi 

Verzonden: zaterdag 30 september 2023 10:51
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] English (function) question For a non-native English 
speaker like me, the function names are perfect!
On Sat, Sep 30, 2023 at 11:40 amrob...@hotmail.com  wrote:

Hi all.
I have a question for English native speakers. I am working on a library for 
the HC-SR04 ultrasonic ranging module.
I have functions that return the distance in cm and inch.
My question is the following. One of the functions returns a word so the 
distance is without a decimal, so 2 cm, 5 inch, etc. The other function returns 
a float so the distance is with a decimal, so 3.5 cm, 5.1 inch.
I am looking for a good name for these functions. I now have the following 
names but I am wondering if there is a better name for them:
function hcsr04_get_distance_cm_coarse()return word isfunction 
hcsr04_get_distance_inch_coarse()return word isfunction 
hcsr04_get_distance_cm_fine()return float isfunction 
hcsr04_get_distance_inch_fine()return float is
So I am looking for  a better name for these functions. Any suggestions? 
Thanks.
Kind regards,
Rob




-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/655e1cd1-adaf-49d9-b645-9ddcef475248n%40googlegroups.com.



-- 
Vasi

-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CABsDq%3D86Jh5W8jHyb8VdQvvOJbrin%2BEzLTHKnkOsfzbLsR7-XQ%40mail.gmail.com.


-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/GVXP195MB163796241C555E0C1AB38BDBE6C7A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.


-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1217217500.4864974.1696065700920%40mail.yahoo.com.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/GVXP195MB1637646CD40617176F

Re: [jallib] English (function) question

2023-09-30 Thread 'Oliver Seitz' via jallib

 Hi Rob,
I wanted to suggest to name the functions after the return data type. I never 
use floats, so if I would have a function called "fine", it would return a 
length in mm (metric) or mils (=1/1000 inch imperial)
Even if you would return a length in micrometers, a dword would suffice for a 
range of over 4 kilometers, still by a smaller overhead than using a float.
Greets,Kiste
Am Samstag, 30. September 2023 um 11:11:37 MESZ hat Rob CJ 
 Folgendes geschrieben:  
 
 Hi Vasile,
Thanks 
I just came up with another idea. Using a float value makes the library big in 
ROM size (it easily adds 600 byte of ROM or more) and I only need one decimal.
So I have another idea and that is return the distance in mm. In that case I 
only need a word as return value.
So now I have only two functions:function 
hcsr04_get_distance_mili_meter()return word isfunction 
hcsr04_get_distance_mili_inch()return word is
I only do not know if mili-inch is an English term. Would like to know that.
Or should I use tens_of_cm and tens_of_inch?
Thanks.
Kind regards,
Rob
Van: jallib@googlegroups.com  namens vasi vasi 

Verzonden: zaterdag 30 september 2023 10:51
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] English (function) question For a non-native English 
speaker like me, the function names are perfect!
On Sat, Sep 30, 2023 at 11:40 AM rob...@hotmail.com  wrote:

Hi all.
I have a question for English native speakers. I am working on a library for 
the HC-SR04 ultrasonic ranging module.
I have functions that return the distance in cm and inch.
My question is the following. One of the functions returns a word so the 
distance is without a decimal, so 2 cm, 5 inch, etc. The other function returns 
a float so the distance is with a decimal, so 3.5 cm, 5.1 inch.
I am looking for a good name for these functions. I now have the following 
names but I am wondering if there is a better name for them:
function hcsr04_get_distance_cm_coarse()return word isfunction 
hcsr04_get_distance_inch_coarse()return word isfunction 
hcsr04_get_distance_cm_fine()return float isfunction 
hcsr04_get_distance_inch_fine()return float is
So I am looking for  a better name for these functions. Any suggestions? 
Thanks.
Kind regards,
Rob




-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/655e1cd1-adaf-49d9-b645-9ddcef475248n%40googlegroups.com.



-- 
Vasi

-- 
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 
tojallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CABsDq%3D86Jh5W8jHyb8VdQvvOJbrin%2BEzLTHKnkOsfzbLsR7-XQ%40mail.gmail.com.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/GVXP195MB163796241C555E0C1AB38BDBE6C7A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1217217500.4864974.1696065700920%40mail.yahoo.com.

Re: [jallib] Releasing untested device files

2023-06-26 Thread 'Oliver Seitz' via jallib

Hi all,
If you would maintain a list of tested devices, all untested ones could have a
compiler warning in the device file. That way, users would be warned that
issues may arise, and they can be asked to inform Rob if no issues arise (and
the device can be added to the "tested" list).
Greets,Kiste
Am Montag, 26. Juni 2023 um 09:35:51 MESZ hat rob...@hotmail.com
Folgendes geschrieben:

Hi all,
When new PICs are released, I create new device files using the data provided
in MPLABX.
Normally I do a test of a device file by running the blink-a-led sample
program. For that I order free samples from Microchip.
Microchip seems to change this and now you must have a business (and a VAT
number) in order to get samples and it seems that it is no longer free. Since I
have no business and did not plan to buy all available PIC microcontroller I
plan to release all new device files untested.
In the years that I have taken over the device file creation from Rob Hamerling
I did not found any issues lately with device files since Microchip is doing a
better job than in the past.
The advantage of this is that I can release a device file as soon as it is
available in MPLABX and you do not need to wait for me to get a sample to test
it.
Let me know what you think.
Thanks
Kind regards,
Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/32e0d734-ab4e-455e-b66f-828dc78bd531n%40googlegroups.com.

Re: [jallib] Software PWM

2023-06-21 Thread 'Oliver Seitz' via jallib

 Yes, it was running at 64MHz, and what I called 1µs in the explanation in fact 
was 62,5ns. I did output two bytes to drive 15 rows simultaneously, and there 
were 8 multiplexed columns. To have some spare for colour calibration, I ended 
up driving values from 0 to around 900 if I remember correctly. The full 
display was refreshed at more than 1kHz, for some cameras and sensitive people 
do recognize flicker at 80Hz.
And yes, even though I only needed like 7 interrupts per cycle per column, I 
eventually had to make pauses in the input data stream, for (in the main 
program) the PIC couldn't throw away the data for fellow clients fast enough ;-)
My last paid-for project some years ago was building something that resembles a 
pinball machine :-D
Greets,Kiste
Am Mittwoch, 21. Juni 2023 um 11:33:08 MESZ hat pinhe...@gmail.com 
 Folgendes geschrieben:  
 
 @Kiste (Got it ;-)   )Clever way to do it !   I guess it took some time to 
figure that out, and get it running properly, specially if you further had to 
manage the LED multiplexing.Hats off !I guess the PIC is running at a fairly 
high speed to be able to achieve all that process ?
BTW: My nickname "Pinhead" is usually a term referring to a pinball freak 
(which I am).   Furthermore, I like horror movies, and Pinhead is the name of 
one of those bad guys we love to hate (in the Hellraiser franchise).   That's 
why ;-)
@RobThe resolution is not critical for dimming LED's in the way I intend: 127 
steps, as in your solution, are enough.   But why limit it with STEP_BRIGHT = 2 
?    
If, for example, I would like to use the ADC value of a LDR to set the 
duty_cycle, I'd simply use the 8 MSB's of the ADC value, and that would give me 
8 bits resolution...What was the requirement in your application to limit the 
resolution to 128 steps ?Also, is the PWM frequency critical ?  Otherwise, 
maybe you could get rid of the "pwm_period = PWM_PERIOD_TIME" line, isn't it ?
All in all, those two answers are food for thoughts, and I will certainly take 
your good advices.   Thanks for that !

Le mercredi 21 juin 2023 à 07:59:57 UTC+2, Rob CJ a écrit :

Hi David, Oliver,
What should be the resolution of the PWM? I sometimes made it in software using 
one timer and controlling several LEDS. In the example below I control one LED 
using 128 steps (step increment of 2 (STEP_BRIGHT)) but can be extended with 
more LEDs. Would that be sufficient for your application?
This was running on a 12F675 running at 4 MHz. The refresh rate was about 80 Hz 
to prevent flicker.  Below this program you find some calculations. Normally I 
used Timer 2 because of the automatic reload but this PIC did not have that.
; Interrupt routine for timer 0, handling the PWM signal in software.; This 
routine is called every 107 us (measured) and takes between 18-28 us.procedure 
timer_0_interrupt()is pragma interrupt
   if INTCON_T0IFthen         ; First preset the time for the next interrupt.   
   TMR0 = TIMER_0_RELOAD      INTCON_T0IF = FALSE
      ; Check the if we need to start a new period.      if (pwm_period== 
0)then         ; New period. Switch LEDs on and start a new duty cycle.         
pwm_period = PWM_PERIOD_TIME         pwm_timer = duty_cycle         ; Only turn 
LED on if it has a duty cycle to prevent flashing.         if (pwm_timer> 
0)then            LED = LED_ON         end if      else         pwm_period = 
pwm_period- 1      end if            ; If the timer of the LED is at the 
mininum brightness then time has passed.      if (pwm_timer>= BRIGHT_MIN)then   
      pwm_timer = pwm_timer- STEP_BRIGHT      else          LED = LED_OFF      
end if 
      end if
end procedure
Some constants I used.
; Specify the values for the minimum and maximum brightness of the LEDs and; 
the value to increase or decrease it. The minimum value is not zero since; we 
want to know if the device is on or off so there always has to be a; minium 
brightness when the device is switched on.const byte BRIGHT_MIN  = 10  ; Must 
be >= STEP_BRIGHT.const byte BRIGHT_MAX  = 254 ; Must be even and <= 254const 
byte STEP_BRIGHT= 2  ; This gives 254 / 2 = 127 steps.
; Timer reload value. The clock is 4 MHz so the timer clock is 1 MHz. Let's; 
use 80 Hz as PWM frequency for the LEDs. This means that the timer has to; run 
at 80 * 125 steps = 10.000 Hz or a period time of 100 us. With a prescale; of 2 
(minimum) the we need a timer value of 1.000.000 / 2 / 10.000 = 50.; Since we 
use the timer overflow the reload value becomes 256 - 50 = 206.; The measured 
value is 9.333 Hz, most like due to processing time.const byte TIMER_0_RELOAD= 
206.
; See timer init, 10.000 Hz / 125 gives 80 Hz. Measured is 74 Hz.const byte 
PWM_PERIOD_TIME= 125
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: woensdag 21 juni 2023 07:38
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] Software PWM Salut pinhead,
If I had to extend an existing controller with PWMs, I'd use e.g. PIC16F

Re: [jallib] Software PWM

2023-06-20 Thread 'Oliver Seitz' via jallib

Salut pinhead,
If I had to extend an existing controller with PWMs, I'd use e.g. PIC16F18313.
It has 8 pins, I2C and 4 independent PWMs at a cost of less than 1,50€. I
cannot tell however if the MCLR pin can be used for I2C. A safe choice would be
12F1572 which is even cheaper and has 4x 16bit PWM. You can use serial_software
for communication, as the PWMs run happily on their own.
Yes, the way you're describing you could dim LEDs, but each time something else
is happening, like new I2C-input is processed, all your LEDs would slightly
flicker.
When I did bitbang-dim 120 multiplexed LEDs, i did it binarily: If bit 7 is
set, light up the LED for 128µs. Then, if bit 6 is set, light up the LED for
another 64µs and so on. The brightness sums up in the eye of the beholder. I've
programmed a timer to generate an interrupt in succession after 128, then 64,
then 32... µs. However, 4,2 and 1 µs I did without leaving the ISR. I did not
use any "if" for that, I had an 8x8bit matrix with the dimming values, which I
rotated by 90°, so I had a byte full of "bit7" of each channel, a "bit6" of
each channel and so on. So, the ISR had nothing to do but move the "bit7"-byte
to the output port right before the 128µs interrupt delay, the "bit6"-byte
before the 64µs delay... That way I could dim 8 LEDs (all on e.g. PORTA) for
the price of one.
Oliver is my real name, but Kiste (=Carton(fr) =Doos(nl) =Box(en)) is my very
common nickname, even in real life.
Greets,Kiste
Am Dienstag, 20. Juni 2023 um 22:10:07 MESZ hat pinhe...@gmail.com
Folgendes geschrieben:

Hello Oliver,
Indeed, PIC18F27J13 could be a candidate. I overlooked this one too quickly (I
already ranted about the parametric search tool on the µchip site :-{ )I'll
check for the other characteristics.No internal OPAMP and internal VREF are a
bit annoying, but if it's the only missing parts, it's ok.
Anyway, what about a PIC that would be programmed as a I²C generator with
several independant channels, and I²C slave.
He would have nothing else to do than generating the signals.Consider one
channel:- A register contains the value of its duty cycle (from 0 to 255)- In
the main loop, a 8-bit counter is incremented.
- At each increment, its value is compared to the duty cycle register, and if
needed, the corresponding output is toggled.
You could generate as many PWM signals as there are IOs available.The I²C-slave
interface would be handled by the MSSP module with interrupts (yes, this could
cause glitches in the PWM signals if the time needed to process the I²C
processes is greater than the time it takes to increment the PWM counter by
one, but if it is only to dim some LED's, I think I could live with it)
The frequency could be adjusted by changing the oscillator frequency and/or
adding delays in the main loop when the main counter is incremented
Just for the sake of it, I think I will give it a try.

Hoping I am not overlooking a major impediment
Thanks for your suggestion, Oliver (or Kiste ?)

Le mardi 20 juin 2023 à 20:43:01 UTC+2, Oliver Seitz a écrit :

Hi!
A software PWM library isn't easy. Without a timer, it blocks everything. With
a timer, it's complicated and would only add a few channels. I've done software
PWM for 120 LEDs independently with a 28 pin controller, but it couldn't do
much more than that at 64MHz.
Have you had a look at, say, PIC18F27J13? It has 3+7 independent ccp modules
(with 3 TMR2-type timers).
Greets,Kiste
Am Dienstag, 20. Juni 2023 um 19:49:33 MESZ hat pinhe...@gmail.com
Folgendes geschrieben:

Hi,
I'm falling short of PWM outputs for a project.I need 6 independant outputs,
and the only way to get them is to use a 64-pin 18f, which is a bit
overkill for me, or use a second PIC, bond to the first (I²C or SPI) which is
also overkill but could be acceptable in the absence of another "clean"
solution.

It will only be used for dimming LED's, and I don't need particular features
like dead-band, half or full bridges, precise or stable frequency.
To my surprise, I didn't find a software PWM library in Jallib 1.8.Or do I
miss something ?
Have a nice day

--
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/923bd215-4855-49d9-b7e1-17e02482c219n%40googlegroups.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/9aad71fb-a1f2-47f3-8cc4-82a1110327c2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To

Re: [jallib] Software PWM

2023-06-20 Thread 'Oliver Seitz' via jallib

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/923bd215-4855-49d9-b7e1-17e02482c219n%40googlegroups.com.

Re: [jallib] PIC16F19176 use same function to check 2 input pins

2023-01-12 Thread 'Oliver Seitz' via jallib

 Sorry, Rob, little mistake:
You need to check the PORTC register. The LATC register contains the output 
pattern, not the input state of the port pins.
Otherwise a good idea :-)
Greets,Kiste
Am Donnerstag, 12. Januar 2023 um 19:11:43 MEZ hat flyway38 
 Folgendes geschrieben:  
 
 Hi Rob,
WOW, nice trick.Will check if works.Thank you very much.
Cheers,FS

On Thursday, January 12, 2023 at 6:06:35 PM UTC rob...@hotmail.com wrote:

Hi Filipe,
I never tried this but here is a thought.
The pin on a specific port can be found in the LATx register, example below for 
portc this is LATC.
You find this in your device file for e.g. pin_C2var volatile bit    LATC_LATC2 
               at LATC : 2var volatile bit    pin_C2                    at 
PORTC : 2
So if you have for example your buttons on port C you could pass a 'mask' as 
parameter to the procedure. Example below (not compiled):
function pin_active(byte in pin_mask) return bit   return (LATC & pin_mask)end 
function
So if you want to if test pin C1 is active (HIGH) or pin C7 is active (HIGH) 
you do:
    if  pin_active(0b_0010) then       -- Do something for bin C1   end if  
  if pin_active(0b1000_) then      --  Do something for pin C7    end if 
Kind regards,
Rob
Van: jal...@googlegroups.com  namens flyway38 

Verzonden: donderdag 12 januari 2023 12:07
Aan: jallib 
Onderwerp: [jallib] PIC16F19176 use same function to check 2 input pins Hello,
Need help to use same function wich cheks for an input pin as a buttn.But now 
need to implement new input pin as another button.How to pass to that function 
which pin to read?Can I use "byte in device" in its input parameters?Thank you 
very much.
Kind regards,Filipe Santos


-- 
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 
tojallib+un...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/f5fa42aa-c132-49d8-b5ae-5b141a9d927fn%40googlegroups.com.



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/404b1de4-c3cd-47b4-a12e-1f7dce577e91n%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1273200153.331767.1673548195785%40mail.yahoo.com.

Re: [jallib] AS5600

2022-12-26 Thread 'Oliver Seitz' via jallib

And just there my suggestion looses its worth: You can sink your AS5600 board
moisture-proof in a block of epoxy resin (including the wire ends). The magnet,
nickel plated, can be moisture-proof. Magnetic coupling is one of the few
environmentally independent means of data transfer.
Greets,Kiste
Am Dienstag, 27. Dezember 2022, 08:52:06 MEZ hat vsurducan
Folgendes geschrieben:

Hans, designing a thing to work at -20C+45C and IP67 (protected from dust and
rain from all directions) is a very difficult task, even if you'll use
something like Kiste pointed to ( I have the Japanese resistive version of that
position sensor in 2% linearity). One thing you should care about is the dew
point.
https://www.vaisala.com/en/expert-article/dew-point-temperature-what-does-it-mean-and-how-can-it-be-calculatedThat's
because you will have humidity even in a completely closed box. The most
dangerous temperature for dewpoint in my area is around +8C.
The only way you can avoid moisture problems is to immerse your PCB completely
in transformer varnish ( several times, not once) and dry it each time after.
Of course no more HW debugging after that.P.S: I think your wife is right.
:)best wishes,

On Mon, Dec 26, 2022 at 11:40 PM hans wrote:

Hi Tom/ Kiste, Thank you for your detailed response. Years ago I tried an
Arduino set, but I didn't get further than a few simple examples. After my C64
and C-basic period, I don't feel like tripping over all those small changes in
the language again. I'm happy to stay with JAL. I've had so much fun with it
already.
I made my anemometer about fifteen years ago. I read the 16 positions with 4
light barriers and one IC shows the LEDs along a cable to our living room. .
For the wind speed I adapted a bicycle spedometer.
Now there are some moisture problems and I want to make some adjustments.
I will take your experience with me in my adventure
What Kiste indicates is quite a nice thing, but according to my wife I am done
much too quickly. And she is often right.
Anyway, as soon as the Chinese package arrives, I can continue. Happy new year
and best wishes to all.
regards
Hans

Op maandag 26 december 2022 om 19:42:18 UTC+1 schreef Tom:

(resent with smaller photo files...)

Some answers to the several questions some of you have asked; hopefully they
are helpful.
First, most of my 8 bit work is with Arduino, and their IDE. I have used PICs
and JAL in the past, but not recently.

1. Cold weather:
- I do not know yet, although I believe it will work fine. The new device has
only been bench tested indoors so far. So many projects, so little time!
Also, the new device is for the weather station parts of our Little Free
Library (LFL, see https://littlefreelibrary.org/ for more info), located at the
end of our driveway. It was renovated this summer, and re-installed without
the weather station or the internal computer systems, since it was getting
colder, and the reno work had already taken too long. It is now more difficult
to add the items to the LFL, and to test them...
We have had a LFL for about 7 years, with Arduino Nano's, solar power,
batteries, and digital radio. The system has worked near perfectly all this
time, summer and winter, snow, rain, wind...
It is unfortunate I did not have this weather station outside this past week;
temperatures down to about -20C, winds gusting to about 100 kph! my location
is in southern Ontario, Canada. Some regions around us declared disaster
emergencies! We were fortunate not to lose power...

2. Outputs:
My testing has been done only with the I2C interface, and has worked very
well. I will include test code below. I have checked that the analog output
works okay, but I use only the I2C outputs for my application.

3. Wireless:
I have used the NRF24L01 transceiver module at both remote and in-house ends,
for data collection and some control, for years also. Again, has worked very
well. A nice system to connect with Arduino Nano. Uses SPI interface. Have
also built a NRF24L01 to Ethernet WiFi Gateway, using an ESP32 module, intended
for connection to a Home Automation system (not configured yet).

4. Software:
The library I used for testing is:
https://github.com/RobTillaart/AS5600.
I also made some use of the Seeed Studio Library:
https://github.com/Seeed-Studio/Seeed_Arduino_AS5600

The simple test software I used (a modification of a SEEED studio test app) is
attached as AS5600_MagDiag1.ino (open as simple text file, if you do not use
the Arduino IDE for anything). Allows easy data capture / graphical display
using the Arduino IDE Serial Monitor and Serial Plotter tools.

5. System:
I see the PDF I included in an earlier post, chopped a

Re: [jallib] AS5600

2022-12-26 Thread 'Oliver Seitz' via jallib

Hi Tom, Hans and all,
I do not have experience with that chip. I'm used to spend a little more money,
and use this device: TT Electronics / BI Technologies 6127V1A360L.5FS. It has
an analog output which interfaces easily to an ADC input, and the right magnet
is mounted in the right distance on the right axis. It pretty much resembles a
potentiometer without stop.
Of course it can be nice to stay on the digital side, but having the mechanics
already done for a few extra bucks can also be an advantage.
These days, the most important advantage is, if my preferred supplier has it in
stock ;-)
Greets,Kiste
Am Montag, 26. Dezember 2022, 09:15:35 MEZ hat Tom Crawford
Folgendes geschrieben:

(Resend to provide smaller attachment)

Hello Hans,
Yes, I have some experience with it.
I needed to replace a failing set of reed switches in a weather vane. I
replaced them with an AS5600 sensor, and did some testing with it.
I have attached a PDF file from a presentation I did in September, that may be
of interest. The overall project was the refurbishing of our Little Free
Library. The weather vane discussion (mainly photos) is in the 2nd half of the
PDF, showing the old reed switch / I2C installation, and the new AS5600 install
inside the 3D printed mounting. The upgrade is not outdoors yet, so not
weather tested...

Some things to be aware of:
- the rotating magnet and it's mount location are very critical. I originally
did not order the AS5600 (from Aliexpress) with magnets, since I have a large
collection of small salvaged magnets in my junk box. But only 2 of those
magnets had the correct orientation of magnetic field to adequately operate
the AS5600! See test graph for results; a proper magnet would produce even
better results. I have ordered additional AS5600's for other uses, and
included the proper magnets with that order.

Tom

On 12/25/2022 4:35 AM, hans wrote:

Hey
I need a position sensor that provides a rotation of 360 degrees. I found the
AS5600. Does anyone have experience with this?
regards
Hans
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/cb4a9866-829f-46cb-90dc-2b3bf14ae59en%40googlegroups.com.

| | Virus-free.www.avast.com |

Re: [jallib] Re: Variable Table Append

2022-12-13 Thread 'Oliver Seitz' via jallib

 Hi Filipe,
"So, I need to read the whole Modem answer (always bigger than 80 chars/bytes) 
and then extract the useful data part of it."
This is only partly true. Yes, you have to read it. But, to read it, you don't 
really have to store it. You can e.g. use a state machine which checks for the 
chars "+","C","M","G","L"... in that order, advancing the state each time the 
right char comes in. Only when the state reaches the value that indicates the 
start of the payload, you can start copying incoming chars to your buffer (if 
that is really needed). 
The 80-byte array limit is pic dependent: on PIC18F, arrays can be up to 256 
bytes. To be sure, if you want to store the whole message, better use 
large_array anyway.
About the modified library: Can be done, but I wouldn't do it that way. Mixing 
global variables between the main program and a library makes code maintenance 
hard. And, with such specific alterations, I wouldn't call it a library 
anymore. If I was going that way, I'd copy the library code to the main program 
and do the modifications there. 
Good luck :-)
Greets,Kiste
Am Dienstag, 13. Dezember 2022, 09:31:49 MEZ hat flyway38 
 Folgendes geschrieben:  
 
 Summing up this issue is;
This is what Modem answers to my AT command to read SMSs received:(As obvious, 
first line is SMS identifier and second line is information data in this SMS)
+CMGL: 1,"REC READ","+3510",,"2022/12/08,17:10:12+00"
GA6-B MODEM SMS TEST, ADC= 2.757... 
This part is enough to read from modem's answer, since my code will delete all 
received SMSs after reading the first one.
It has currently 93 chars but can change. From this will only need 2nd line 
part "GA6-B MODEM SMS TEST, ADC= 2.757" and this will also (very soon) change 
for sure.So, I need to read the whole Modem answer (always bigger than 80 
chars/bytes) and then extract the useful data part of it.
Cheers,FS
On Tuesday, December 13, 2022 at 8:02:14 AM UTC flyway38 wrote:

Hello Rob,
Thank you very much for your input.Will check your snippet code later on 
today.Then will back here with the outcome.
Thank you,
Cheers,Filipe Santos

On Tuesday, December 13, 2022 at 7:58:21 AM UTC flyway38 wrote:

Hello Vasile,
Thank you very much for your help.Will test your code later on today.
Have found already that the problem seems to be related to that 80byte limit in 
array vars.Particularly speaking about the RX buffer;if 
(defined(SERIAL_RCVBUFSIZE) == FALSE) then
   const   SERIAL_RCVBUFSIZE  = 80  -- 64 is the default size of receive buffer
end ifSo, maybe your code will overcome this issue.Thank you.
Cheers,FS
On Tuesday, December 13, 2022 at 5:53:04 AM UTC vasile wrote:

Assuming from received garbage you need only this: S_GA6-B_MODEM_SMS_TEST, ADC= 
2.757V_E, where S=start char, E=end char, 
meaning 35 characters of interest including start and end
you have to:1. make  a copy of your serial_hv_int_cts.jal library and rename it 
serial_hv_int_cts_modified.jal2. in the serial_hv_int_cts_modified.jalmodify 
the  _serial_receive_interrupt_handler() with the one below
3. in the main program include the modified library and:

var bit datapresent = falsevar byte chars_ok = 0 
var byte chars_sent = 35
include serial_hw_int_cts_modified
serial_hw_init()
forever loop
 if datapresent then ; read _serial_rcvbuf [i]  for i = 0 to 35 and print your 
relevant string
 end ifend loop

This should work if you will be careful with the position in the buffer ( not 
tested for your string, but tested in the past for other stuff).It might work 
without counting chars as well, but it needs to detect the end char E instead 
of counting chars ( even if counting is more safe).


procedure  _serial_receive_interrupt_handler() is; to be replaced in 
serial_hv_int_cts_modified.jal-
   pragma interrupt

   var  byte  x
   if  (PIR1_RCIF == TRUE)  then                -- UART receive interrupt
      
      if ((RCSTA_OERR == TRUE) | (RCSTA_FERR == TRUE)) then  -- frame/overr 
error
         x = RCREG                              -- flush hardware buffer
         while RCSTA_OERR == TRUE loop          -- overrun state
            RCSTA_CREN = FALSE                  -- disable UART
            RCSTA_CREN = TRUE                   -- re-enable UART
            x = RCREG                           -- \  flush hardware buffers
            x = RCREG                           -- /
         end loop                               -- until no more overrun
         _serial_offsetrcvtail = 0              -- \  flush circular buffer
         _serial_offsetrcvhead = 0              -- /
         serial_ctsinv = FALSE                  -- ensure CTS true

      else
         x = RCREG                                      -- data without errors

         if (! datapresent) then
          _serial_rcvbuf[_serial_offsetrcvhead] = x
           if x == "S" then ; relevant char found
;         if chars_ok == 0 then

Re: [jallib] USB_help

2022-12-11 Thread 'Oliver Seitz' via jallib

 Hi Hans,
to be really sure, put something like this to the beginning of your program:
for 10 loop  LED=on  _usec_delay(100_000)  LED=off  _usec_delay(900_000)end loop
Compare the flashes with a ticking clock: If there's one flash per second, 
you've checked that
1. the PIC runs at all2. the PIC runs at the speed the compiler assumes it to3. 
the crystal is fine
Like every other thing in the world, also crystals may break. But, if they 
break, they're usually not 1% or 2% off of their rated frequency, but 50% or 
more. You would see such a wrong frequency with this test.
If, however, the crystal oscillator is loaded with wrong capacitors (say, 
2x100pF instead of 2x27pF), there might result a frequency which "looks" right, 
but is out of spec for USB, which requires very small tolerances.
Greets,Kiste
Am Montag, 12. Dezember 2022, 07:15:49 MEZ hat Rob CJ  
Folgendes geschrieben:  
 
 Hi Hans,
If it is printed on the crystal you may assume that it is correct. 
Met vriendelijke groet,Rob Jansen From: jallib@googlegroups.com 
 on behalf of hans 
Sent: Sunday, December 11, 2022 7:56:54 PM
To: jallib 
Subject: Re: [jallib] USB_help Hi Rob,on the xtal is written 20.000, how can i 
know if this is true?regardsHans

Op zondag 11 december 2022 om 16:51:08 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
The USB driver should work for the 18F.
It is important that the PIC runs at 48 MHz for the USB to work correctly. In 
the sample program that you use, you have to connect a 20 MHz crystal in order 
to let the PIC run at 48 MHz.
Are you using a 20 MHz crystal?
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 11 december 2022 12:37
Aan: jallib 
Onderwerp: Re: [jallib] USB_helpHello Rob,
That's right. Turned off LVP and the blinkers work. The USB does not work. I 
will order a pair of 16F1455 in hopes that will work.
regards
Hans

Op zondag 11 december 2022 om 10:44:21 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
One of the differences is the use of Low Voltage Programming (LVP).
I think the Wisp does not support that, does it? Did you try programming it 
with a PICKit2 or PICKit3?
A few years ago all blink samples changed to LVP for those devices that support 
this.
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 11 december 2022 10:26
Aan: jallib 
Onderwerp: Re: [jallib] USB_helpBlink a led tested with an old sample, this 
works :
-- --
-- Title: Blink-a-led of the Microchip pic18f4455
--
-- Author: Rob Hamerling, Copyright (c) 2008..2011, all rights reserved.
--
-- Adapted-by:
--
-- Revision: $Revision: 2902 $
--
-- Compiler: 2.4o
--
-- This file is part of jallib  (http://jallib.googlecode.com)
-- Released under the BSD license 
(http://www.opensource.org/licenses/bsd-license.php)
--
-- Description:
-- Sample blink-a-led program for Microchip PIC18f4455.
--
-- Sources:
--
-- Notes:
--  - File creation date/time: 7 Dec 2011 14:14:17.
--
-- --
--
include 18f4455                    -- target PICmicro
--
-- This program assumes that a 20 MHz resonator or crystal
-- is connected to pins OSC1 and OSC2.
-- (unspecified configuration bits may cause a different frequency!)
pragma target clock 20_000_000     -- oscillator frequency
-- configuration memory settings (fuses)
pragma target OSC      HS               -- HS crystal or resonator
pragma target PLLDIV   P1           -- no divide
pragma target CPUDIV   P1           -- no Fosc divisor
--pragma target WDT      disabled     -- no watchdog
pragma target XINST    disabled     -- not supported by JalV2
pragma target DEBUG    disabled     -- no debugging
pragma target LVP      disabled     -- no Low Voltage Programming
pragma target MCLR     external     -- reset externally
-- These configuration bit settings are only a selection, sufficient for
-- this program, but other programs may need more or different settings.
--
enable_digital_io()                -- make all pins digital I/O
--
-- Specify the pin to which the LED is connected.
-- A low current (2 mA) led with 2.2K series resistor is recommended
-- since not all pins may be able to drive an ordinary 20mA led.
alias   led      is pin_A0
pin_A0_direction =  output
--
forever loop
   led = on
   _usec_delay(250_000)
   led = off
   _usec_delay(250_000)
end loop
--

Op zondag 11 december 2022 om 10:20:59 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
I am not at home the coming week so I am not able to test but I assume it 
should work since blink samples are at least tested once when a new device is 
added.
Maybe somebody is able to help you, otherwise I can test it next weekend on a 
PIC18F4550 (same family).
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 11 december 2022 10:07
Aan: jallib 
Onderwerp: Re: [jallib] USB_help Hi Matt,
I first tested with the 18F4455. It does not work with both the sample 
18F4455-blink_hs.jal and the

AW: Re: [jallib] PWM serial audio transmission

2022-11-17 Thread 'Oliver Seitz' via jallib

Oh, do I understand that right, that only the direct transmission from sender 
Pic to receiver Pic does not work while simultaneously recording audio? In that 
case, connect the receiver directly to the sender's output pin, no filter is 
needed here. Only a resistor in case the receiver runs on a lower voltage than 
the sender.
If the filter is loaded with an audio input, levels may go too low for the 
receiver. The receiver does not need any filtering at all, that's only for 
audio compatibility.
Greets,Kiste 

Gesendet von Yahoo Mail auf Android 
 
  Am Do., Nov. 17, 2022 at 13:33 schrieb hans:   The 
never ending story.
Now put the case on pcb and tested. Recorded signal looks strange. Directly 
coupled transmitter and receiver with audio works, but when the audio signal is 
branched off to audio-in PC it no longer works. The recording is made and then 
playback gives the receiver a good result.
SUGGESTIONS???
thanks

Op woensdag 16 november 2022 om 21:00:02 UTC+1 schreef hans:

Whoeps Vasile, that looks great.. now see what and how iThanks 

Op woensdag 16 november 2022 om 19:41:34 UTC+1 schreef vasile:

Hello senior contributor,there are at least two serious software for filter 
computing named Filterpro from TI and Elsie from Tone software,  both free at 
the time I've work with. Each is excellent just for a segment of filters...not 
for everything.

On Wed 16 Nov 2022, 10:21 AM hans 
Verzonden: dinsdag 5 april 2022 19:12
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionI have only made small 
changes in the code and improved the comments. I did not try this version, but 
I'm quite sure it should work. You only need a PIC, a resistor, a TTL-Serial 
converter with a computer and the sample audio file which i posted earlier to 
see it working.
(You can even omit the resistor, but you could fry the PIC then. Especially if 
you don't use the error LED and have no idea about what volume to set)
Greets,Kiste

Am Dienstag, 5. April 2022, 12:05:59 MESZ hat hans  
Folgendes geschrieben:

Hello Rob and Kiste,The next days i have a friend who can assist me. So (beside 
his AC project) we might find time to continue with this . So please give us 
the last info.Thanks againhans 

Op zondag 3 april 2022 om 15:57:03 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
I also tried it with a lower frequency, 3330 Hz for the low tone and 4030 Hz 
for the high tone so that the signal is strong enough when you record it.
If you want to know more, let me know.
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 3 april 2022 15:11
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmissionStill foggy, just wait a 
little longer with this case.

Op zaterdag 26 maart 2022 om 20:05:55 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
I hope you are getting well soon. Last update. I recorded the audio and played 
it back to see if it works.
And it seems to work but may need some fine tuning. In this video you see the 
device in operation: https://youtu.be/w-j0ekk975g
The yellow line on the oscilloscope is the audio signal and the blue line the 
trigger signal. This trigger signal is also visible by the Amber LED on the top 
right of the breadboard.
I recorded the low tone (it is a video recording but I am only using the audio) 
and switched from low tone to the high tone frequently. What you see is that 
the signal of the high tone is smaller but it still works. You also see that 
the refresh of the oscilloscope is a bit behind so the LED on the breadboard 
shows the real trigger. I also attached two screenshots. You see that the 
trigger response is quite fast (zoomed in) but with a high tone it is not 
constant (see zoomed out) but that can be solved in software and could be 
because the signal is smaller. Also I noticed that when no signal is present 
the output is also high but that stops as soon as the low tone is detected.
So still a proof of concept but seems to do something. I also attached the 
audio tone. Maybe lower tones would be better.
For recording I just used the output of the PIC using a resistor divider of 10 
k with 100 Ohm and connecting that to the line in of my computer. For playback 
I added an LM358 to amplify the input signal and I used the headphone output.
Kind regards,
Rob

Op donderdag 24 maart 2022 om 12:47:49 UTC+1 schreef rob...@hotmail.com:

Hi Marieke,
Thanks for the update. Let's hope Hans recovers soon.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: donderdag 24 maart 2022 07:37
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionAltijd met Rust...
It took me two weeks to think, code and test, and it will take more weeks for 
proper documentation. So no need for you to hurry ;-)
Greets,Kiste
Am Mittwoch, 23. März 2022, 22:36:19 MEZ hat hans  
Folgendes geschrieben:


Hello everyone,

My grandfather Hans has only one usable eye and has got an infection on it. We 
have read your

Re: [jallib] PWM serial audio transmission

2022-11-17 Thread 'Oliver Seitz' via jallib

 On 2022-03-23 I've sent a sample file which i could read without error. Did 
you try that? It contains a few lines of text. I think, too low of playback 
volume might lead to read errors, or too long strings without pause. Or, of 
course, using mp3 or the like at too low bitrate.
Greets,Kiste

Am Donnerstag, 17. November 2022 um 13:33:39 MEZ hat hans 
 Folgendes geschrieben:  
 
 The never ending story.
Now put the case on pcb and tested. Recorded signal looks strange. Directly 
coupled transmitter and receiver with audio works, but when the audio signal is 
branched off to audio-in PC it no longer works. The recording is made and then 
playback gives the receiver a good result.
SUGGESTIONS???
thanks

Op woensdag 16 november 2022 om 21:00:02 UTC+1 schreef hans:

Whoeps Vasile, that looks great.. now see what and how iThanks 

Op woensdag 16 november 2022 om 19:41:34 UTC+1 schreef vasile:

Hello senior contributor,there are at least two serious software for filter 
computing named Filterpro from TI and Elsie from Tone software,  both free at 
the time I've work with. Each is excellent just for a segment of filters...not 
for everything.

On Wed 16 Nov 2022, 10:21 AM hans 
Verzonden: dinsdag 5 april 2022 19:12
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionI have only made small 
changes in the code and improved the comments. I did not try this version, but 
I'm quite sure it should work. You only need a PIC, a resistor, a TTL-Serial 
converter with a computer and the sample audio file which i posted earlier to 
see it working.
(You can even omit the resistor, but you could fry the PIC then. Especially if 
you don't use the error LED and have no idea about what volume to set)
Greets,Kiste

Am Dienstag, 5. April 2022, 12:05:59 MESZ hat hans  
Folgendes geschrieben:

Hello Rob and Kiste,The next days i have a friend who can assist me. So (beside 
his AC project) we might find time to continue with this . So please give us 
the last info.Thanks againhans 

Op zondag 3 april 2022 om 15:57:03 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
I also tried it with a lower frequency, 3330 Hz for the low tone and 4030 Hz 
for the high tone so that the signal is strong enough when you record it.
If you want to know more, let me know.
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 3 april 2022 15:11
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmissionStill foggy, just wait a 
little longer with this case.

Op zaterdag 26 maart 2022 om 20:05:55 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
I hope you are getting well soon. Last update. I recorded the audio and played 
it back to see if it works.
And it seems to work but may need some fine tuning. In this video you see the 
device in operation: https://youtu.be/w-j0ekk975g
The yellow line on the oscilloscope is the audio signal and the blue line the 
trigger signal. This trigger signal is also visible by the Amber LED on the top 
right of the breadboard.
I recorded the low tone (it is a video recording but I am only using the audio) 
and switched from low tone to the high tone frequently. What you see is that 
the signal of the high tone is smaller but it still works. You also see that 
the refresh of the oscilloscope is a bit behind so the LED on the breadboard 
shows the real trigger. I also attached two screenshots. You see that the 
trigger response is quite fast (zoomed in) but with a high tone it is not 
constant (see zoomed out) but that can be solved in software and could be 
because the signal is smaller. Also I noticed that when no signal is present 
the output is also high but that stops as soon as the low tone is detected.
So still a proof of concept but seems to do something. I also attached the 
audio tone. Maybe lower tones would be better.
For recording I just used the output of the PIC using a resistor divider of 10 
k with 100 Ohm and connecting that to the line in of my computer. For playback 
I added an LM358 to amplify the input signal and I used the headphone output.
Kind regards,
Rob

Op donderdag 24 maart 2022 om 12:47:49 UTC+1 schreef rob...@hotmail.com:

Hi Marieke,
Thanks for the update. Let's hope Hans recovers soon.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: donderdag 24 maart 2022 07:37
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionAltijd met Rust...
It took me two weeks to think, code and test, and it will take more weeks for 
proper documentation. So no need for you to hurry ;-)
Greets,Kiste
Am Mittwoch, 23. März 2022, 22:36:19 MEZ hat hans  
Folgendes geschrieben:


Hello everyone,

My grandfather Hans has only one usable eye and has got an infection on it. We 
have read your contributions and he is very happy with them. Sorry but he can't 
work with it right now.

Regards Marieke

Op woensdag 23 maart 2022 om 17:22:42 UTC+1 schreef Kiste:

And here's the receiver, and a sample file. Mp3

Re: [jallib] PWM serial audio transmission

2022-11-16 Thread 'Oliver Seitz' via jallib

 Hi Hans, sorry for being late...
I had to find the drawings back, didn't know what I designed back then. The 
filtering of the sender is a ugly hack. C1 removes DC, so the voltage will 
swing form -2,5 to +2,5V. R1/C2 is a low pass filter which has a frequency well 
below the transmitted frequencies and shapes the square wave from the PIC to 
something similar to a triangle of about +/-1V. R2 sets the output impedance 
and limits the load on the filter. The two antiparallel diodes clip the 
triangle wave with their exponential characteristics to a voltage of about +/- 
0,7V with round tops, that way it is on a level which a line-in audio input can 
handle and it roughly resembles a sine wave.
For the receiver, if I do remember it right, I did not use any filters, I just 
recommended a resistor to protect both audio equipment and PIC.
Greets,Kiste
Am Mittwoch, 16. November 2022 um 09:21:00 MEZ hat hans 
 Folgendes geschrieben:  
 
 
Hello highly honored public,

I did some research in low/highpass filter science and found a lot of 
calculation programs.

In the contribution of Kiste 20Mar. 2022 13:22:10 an R value of 680 .. 1 K is 
indicated and a C value of 1uF.The system works with 5 and 8 kHz. When I run 
the found calculation tool on it,I get very different values. I must be 
completely wrong again, but thetransmitter and receiver do work, only with 
glitches.

My question is outside the JALLIBworld but I'll try anyway.

regards

Hans

Op maandag 14 november 2022 om 21:19:26 UTC+1 schreef hans:


Hi Kiste,

Sometimes I have to push things aside. So is this topic. Ihave taken up the 
matter again and on my pin board both the transmitter and thereceiver work with 
a 12F683 at 1200 baud. I did put a 100nF in series at theoutput according to 
your diagram. I also put a similar filter in the input ofthe receiver. 
Identical to your proposal but because I know absolutely nothingabout filter 
matters I don't know if I did this right.

I feed a separate uart signal as input and read out anotheruart with the 
receiver.

I recorded the signal with audicity and saved it as WAV.When playing back to 
the receiver I do get responses but there is quite a bitof junk.

My question : what should the inlet filter to the receiverlook like.

I know your box of thanks is already full, but I'll addanother one.

regards

Hans

Op zondag 19 juni 2022 om 12:46:36 UTC+2 schreef hans:

Hello all,
I've tried many things, but I always had problems. I have now received a 
handful of MT8880 from china and this time they all worked. Even when I apply 
this I regularly have malfunctions, but if I repeat every command 3 times and 
check then it works. I'm a bit further, only the person I was working for has 
unfortunately chosen something else. So this will go in the "you can't know 
box" for now.
We continue happily, it remains fun.
regards
Hans

Op dinsdag 5 april 2022 om 19:57:25 UTC+2 schreef rob...@hotmail.com:

Hi Kiste,
Nice solution. Hans has options to select from .
BTW. @hans. I made as small error in  my hardware receiver solution. Capacitor 
C3 should be 2nF (two 1nF in parallel) but if I where you I would try Kiste's 
solution first. If that works you are done.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: dinsdag 5 april 2022 19:12
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionI have only made small 
changes in the code and improved the comments. I did not try this version, but 
I'm quite sure it should work. You only need a PIC, a resistor, a TTL-Serial 
converter with a computer and the sample audio file which i posted earlier to 
see it working.
(You can even omit the resistor, but you could fry the PIC then. Especially if 
you don't use the error LED and have no idea about what volume to set)
Greets,Kiste

Am Dienstag, 5. April 2022, 12:05:59 MESZ hat hans  
Folgendes geschrieben:

Hello Rob and Kiste,The next days i have a friend who can assist me. So (beside 
his AC project) we might find time to continue with this . So please give us 
the last info.Thanks againhans 

Op zondag 3 april 2022 om 15:57:03 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
I also tried it with a lower frequency, 3330 Hz for the low tone and 4030 Hz 
for the high tone so that the signal is strong enough when you record it.
If you want to know more, let me know.
Kind regards,
Rob
Van:jal...@googlegroups.com  namens hans 

Verzonden: zondag 3 april 2022 15:11
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmissionStill foggy, just wait a 
little longer with this case.

Op zaterdag 26 maart 2022 om 20:05:55 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
I hope you are getting well soon. Last update. I recorded the audio and played 
it back to see if it works.
And it seems to work but may need some fine tuning. In this video you see the 
device in operation: https://youtu.be/w-j0ekk975g
The yellow line on the oscilloscope is the audio signal and the blue line the 
trig

Re: [jallib] Baudrate control

2022-10-17 Thread 'Oliver Seitz' via jallib

 Hi Bill,
I've used different baud rates, but I did not modify the serial libraries for 
that. I just calculated the register values by hand and poked the different 
values to the different registers. The baud rate calculation in the libraries 
is not a thing which is good to be done at runtime. For certain baud rates, the 
lib will refuse to compile and inform you, that your desired baud rate cannot 
be set due to a deviation from the desired value which is to large to reliably 
work. That can't be done at runtime for a start.
Greets,Kiste
Am Montag, 17. Oktober 2022, 15:39:54 MESZ hat Bill Beek 
 Folgendes geschrieben:  
 
 Hello everyone, Is there anyone who has a solution to my problem. I am working 
on a serial LCD now that I have this working, I want to select the baud rate 
before running the program. Unfortunately, the "const serial_hw_baudate" do not 
easily change. In the library "usart_common" I changed all the constants in a 
variable "var dword" but I keep getting error messages from this lib. Maybe I'm 
overlooking something, or is there a simple method to set the Baud rate under 
software control. Kind regards, Bill

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/2b1be8c6-547c-4f0c-97bb-43fc851e4bf4n%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1359606717.1850252.1666018036595%40mail.yahoo.com.

Re: [jallib] exit of master/slave?

2022-10-15 Thread 'Oliver Seitz' via jallib

Hi!
I agree to the later, but not to the first. (Well, could be done, but I don't
think that is enough in the long run.)
Yes, if we stick to the new nomenclature, we break backwards compatibility. If
we use our own fork of a namespace, we introduce new difficulties especially
for newcomers to learn how to use JAL (or to read datasheets).
If I'm digging out old projects, and they do not compile, I'd have to make
changes. If it's only changeing the obvoiusly differing library and function
names, that's easily done.
I was quite deep into DOS programming back in the 1990's, and I saw a real lot
of internal MS-Windows problems which had their origin in maintaining a 100%
backwards compatibility to MS-DOS. MAC-OS was by far more stable, consistent
and clean, by breaking backwards compatibility from time to time.
Greets,Kiste
Am Sonntag, 16. Oktober 2022, 06:31:28 MESZ hat vsurducan
Folgendes geschrieben:

What if you put these in the library header:-- alias master = host in
Microchip datasheet, please be aware-- alias slave = client in Microchip
datasheet, please be aware
A good practice would be that at the end of any project, ALL libraries, the
used compiler, schematic, PCB, machine files ( gerber excelon), all components
datasheet used in the project, source code (well commented) and the hex file to
be saved in two different places.

On Sun, Oct 16, 2022 at 4:27 AM Matthew Schinkel
wrote:

Hi, how many files are affected?
Is someone offended by this? If someone is offended we can change it, else it
seems like quite a lot will need to be changed and won't be backwards
compatible.
Matt.

On Saturday, October 15, 2022 at 10:34:00 AM UTC-4 rob...@hotmail.com wrote:

Hi Vasile,
We can keep the older version on GitHub. Not all files on GitHub are part of a
release, that is determined by the file TORELASE on GitHub.
On GitHub you also find a directory called 'Casualties' where some older stuff
is stored but you could also just remove it from the release (after some time).
Kind regards,
Rob
Van: jal...@googlegroups.com namens vasi vasi

Verzonden: zaterdag 15 oktober 2022 14:35
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] exit of master/slave? This will not be a workable
solution if you do not keep the old libraries at least in repository, even if
you do not release them anymore. You don't know how many valuable projects are
out there, is a real pain for new development teams to deal with old,
deprecated firmware, written in an alien language that does not have support
anymore... if you understand what I mean...

On Sat, Oct 15, 2022 at 12:31 PM Rob CJ wrote:

Hi Rob,
I agree that we should keep it in line with Microchip to keep consistency.
What we could do is the following:
- Copy the current libraries using the new terminology, so for example
spi_master_hw tospi_host_hw
- Keep the current libraries for now but add something like _warn "This
library will be deprecated, use spi_host_hw. In this way the library can still
be used and it gives the JAL users time to switch to the new library
convention. We could keep the old libraries for one release and remove them
from the next release.
- Modify all current sample files so they use the new libraries.
Would this be a workable approach?
Kind regards,
Rob
Van:jal...@googlegroups.com namens Rob Hamerling

Verzonden: woensdag 12 oktober 2022 19:36
Aan: jallib
Onderwerp: [jallib] exit of master/slave?
Hi guys,

Like similar changes in other places, I see in the Microchip datasheets that
the terms 'master' and 'slave' are being replaced by 'host' and 'client'. Seems
a positive and desirable change to me. I would like to suggest to follow
Microchip in this for Jallib. I'm afraid this is not a simple operation. It is
not only about file names, but also related 'includes' in samples. But it will
also have effects on existing user programs! What are your thoughts about
this?

Regards, Rob

--
Rob Hamerling, Vianen, NL

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/a87bb739-c320-a351-698e-3d5264087327%40gmail.com.

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/GVXP195MB16376C1A737B25302F0787A5E6279%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

--
Vasi

Re: [jallib] Procedures vs Functions

2022-08-21 Thread 'Oliver Seitz' via jallib

Hi Filipe,
I can tell you für 2): No. At compile time, the variable name is replaced by a
fixed memory address. There's no difference if the name is declared inside a
procedure/function or in the main program. There is, however, a little space
("access RAM") which contains a bit "faster" variables. So, it can make a
little difference if a variable is declared earlier or later in a program.
8-bit PIC controllers are a bit special, as in a sense they don't have RAM at
all, they merely have up to several thousand processor registers. Accessing
(simple, not array) variables is therefore very fast compared to other
processor architectures.
Greets,Kiste
Am Sonntag, 21. August 2022, 12:49:39 MESZ hat flyway38
Folgendes geschrieben:

Hi all,
Always had this doubt about efficiency in choosing Procedure or Function for
structuring my code. I know how to use them by experience in coding JAL for
many years.
Another doubt is declaring VARs inside Procedures or Functions will make them
slower or not..., so here goes the questions;
1) - Which is the fastest/ efficient at runtime (Procedure or Function) ?
2) - Declaring VARs inside Procs/Funcs will make them slower ?
Thank you very much
Kind regards,Filipe Santos

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/049c5097-750d-4cf7-845a-a89720963961n%40googlegroups.com.

Re: [jallib] Pic_program_eeprom

2022-07-20 Thread 'Oliver Seitz' via jallib

Hi all,
a pure resistor takes only "active power". Inductors and capacitors also take
"reactive power", both kinds of power combined are called "apparent power" (all
of the names translate similarly to dutch).
There are cheap devices, which do measure neither of the three but completly
wrong values when loaded inductively or capacitively. But, from what I read
before, the meter is provided by your utility company, therefore it must be a
device which correctly measures "active power". It could, however, also output
one or both of the other powers, or a number called "power factor" or "cos phi".
Greets,Kiste

Am Mittwoch, 20. Juli 2022 um 09:53:08 MESZ hat hans
Folgendes geschrieben:

Hi Vasile,my site www.tweeduuster.nl works fine. Sorry for the mistake
What do you mean with reactive energy? I shows in and out Kwhr and save the
data for some time.

Op woensdag 20 juli 2022 om 06:24:09 UTC+2 schreef vasile:

Hans, your site is down?Does your meter measure reactive energy too? Thx.

On Tue, Jul 19, 2022 at 8:48 PM hans wrote:

Hi Rob,
If you look at my site, www.teeduuster.nl, on the first page you will find
SMART METER READER. This animal did fine until last week, but our energy
supplier has placed another meter with something different. Hence. I'll see
what I can do with your tips. thanks again.
regards
HansOp dinsdag 19 juli 2022 om 18:42:33 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
This seems to be a very old library completely written in assembly.
I suggest you use the current library pic_data_eeprom.jal and replace the
following:
- Program_EEprom_Read --> data_eeprom_read_word

- Program_EEprom --> data_eeprom_word

- Program_EEprom_Write --> data_eeprom_write_word

You can use the same parameters in both procedures and functions. It should
then work again.
But please check this library and read the note about the EEPROM offset
(EEPROM_ADDRESS_OFFSET) since some PICs need it and I do not know which one you
are using.
Kind regards,
Rob
Van: jal...@googlegroups.com namens hans

Verzonden: maandag 18 juli 2022 21:23
Aan: jallib
Onderwerp: Re: [jallib] Pic_program_eeprom I used the pic-data-eeprom and the
the attached lib in a years_old_still_working-program but the attached is not
working anymore. I got errors in compiling.

Op maandag 18 juli 2022 om 18:48:43 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
Was your plan to program the eeprom separately or program eeprom from your JAL
program?
You can program eeprom with a PICkit3 (and I assume also a Pickit2) and for
programming it from your JAL program you can use pic_data_eeprom.jal.
Kind regards,
Rob
Van:jal...@googlegroups.com namens hans

Verzonden: maandag 18 juli 2022 17:23
Aan: jallib
Onderwerp: [jallib] Pic_program_eeprom Hello,
For a very old program I used the lib pic_program_eeprom, does it still exist
somewhere?
greetings
Hans

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/29887325-b407-44e9-b6b1-b886f076ab3bn%40googlegroups.com.

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/3b1192a6-c318-4916-aee8-48796ee17dacn%40googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/d0a1275f-7e87-4cfd-a916-1e588b63f5cen%40googlegroups.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/9437eff2-56c6-44eb-a398-c168d5142fa9n%40googlegroups.com.

AW: [jallib] Rasberry-pi

2022-07-11 Thread 'Oliver Seitz' via jallib

Hi Hans,
you're aware that all Raspberry Computer Boards are backlogged until next year? 
They're pure gold right now. Do choose whom to present the Boards 

Gesendet von Yahoo Mail auf Android 
 
  Am So., Juli 10, 2022 at 10:29 schrieb hans:   Hello 
all,
A while ago I tried to do something with raspberry-pi but it's all too complex 
for me. With jal I still succeed so much.. is there someone who can benefit 
from it, it is free.
It's a few pcbs and an LCD screen
regards
Hans


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/04e1908f-5751-4dc0-ae2c-2043409bb84an%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/331280995.1786346.1657526850820%40mail.yahoo.com.

Re: [jallib] sun power use

2022-06-29 Thread 'Oliver Seitz' via jallib

Hi Hans,
it's true, you don't need to worry about charging, but you do need to worry
about stopping discharging. LiPos may explode if overcharged or
over-discharged. The device you've bought has both- charge and discharge
controller. But, with your extra wires, you're discharging the LiPo directly
without the discharge controller. That is ok, if you're really sure the LiPo
will never go empty. If you're not so sure about that, you would need a way to
stop discharging at a certain voltage, like 2.6V. Really switching electronics
off to only keep drawing few nanoamperes is possible, but not always easy.
Greets,Kiste

Am Mittwoch, 29. Juni 2022, 12:34:35 MESZ hat hans
Folgendes geschrieben:

Hi Rob,
The set has both a solar panel and a lipo battery, so I don't have to worry
about charging. I'm just curious if the solar panel can keep up with the
consumption. I can also charge it via USB.
By the way very nice to see a project, most of the contributions are very
abstract.Kind regardsHans

Op woensdag 29 juni 2022 om 11:44:28 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
Don't make it more complex than it is. An MPPT (Maximum Power Point Tracking)
is used on solar panels to get the most out of it but you do not have to add
such a device.
If I am right a Lipo battery needs a certain way of charging and so you need a
special Lipo battery charger.
I made a Cat repellent some time ago using a small solar panel. And since I am
using three NiMh batteries (so 3.6 Volt) I use a small charging current for
keeping the batteries charged. The batteries are connected to the solar panel
only via a diode (Shottkey in this case because it has a low voltage drop).
For your info. You can find the schematic diagram here:
https://www.instructables.com/Cat-Repellent/
Kind regards,
Rob
Van: jal...@googlegroups.com namens hans

Verzonden: woensdag 29 juni 2022 11:22
Aan: jallib
Onderwerp: Re: [jallib] sun power useSuch a prompt response! I bought a solar
charger with a built-in 5000mAh battery. It delivers a beautiful 5 Volt but
with a minimum load of 150 mA. Opened the case and the lipo delivers 3.5 Volts.
So I soldered a few more wires to it. Hence my question. It's still so much fun.
Now i have to discover what a MPPT is.regardsHans

Op woensdag 29 juni 2022 om 09:59:30 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
Most PICs can operate at 3 Volt, below a screenshot from the datasheet. I only
use F versions.

Just check the datasheet for the PICs that you have.
I have done several projects using a PIC that is supplied by batteries so
operating at 3 Volt or lower.
What I do not know for sure if when you program the PIC if it should be at 5
Volt, maybe only if you use Low Voltage Programming, so I normally program the
PIC when it is connected to a 5 Volt power supply but in the application it can
run even on a supply voltage as low as 2 Volt.
If you have peripherals that work at 5 Volt you could always use a step-up
converter to step-up the power supply from 3 Volt to 5 Volt.
Kind regards,
Rob
Van:jal...@googlegroups.com namens vsurducan

Verzonden: woensdag 29 juni 2022 09:11
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] sun power use You may continue to use it at 5V if the
energy extracted from the PV is drawn via a MPPT ( maximum power point
tracking) IC and your solar panel assures the current needed for your
electronics. Many panels have 6V open at 0.3A or 0.5A short circuit current
Actually any actual PICmicro will run on 3.3V ( including those rated for 5V)
if the internal oscillator is set to maximum frequency intended only for 3.3V.
Most of the low power PICs ( LF series) will run down to 2.2V ( some down to
1.8V) so you may connect the solar panel directly on your LDO without MPPT or
PWM.best wishes

On Wed, Jun 29, 2022 at 9:57 AM hans wrote:

Hello all,
I don't want to reinvent the wheel. Until now I have always used 5 volts supply
voltage, but because of a solar panel I would like to work on 3 volts. Which
processors should I use and what should I pay attention to?
Thank you in advance,
greetings Hans

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/3220a563-f63f-435b-b0a6-c088cc777aaen%40googlegroups.com.

--
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
tojallib+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4quz-mvFLM7nuWmPg0YBcQCGNLDqw09bJMr%3DbKpmALa9TQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-19 Thread 'Oliver Seitz' via jallib

 ;-)
Glad I could help. I know the mistakes, I've made them all by myself. And the 
one I still don't cope with is confusing names.
Greets,Kiste
Am Donnerstag, 19. Mai 2022, 08:59:16 MESZ hat flyway38 
 Folgendes geschrieben:  
 
 Hi Vasile,
Yes, that progy does the miracle. :DIn my case, only TX needed to be inverted 
in FTDI configuration.
@Rob,My mistake (and sorry to Kiste) saying it was Vasile who spoted that OSC 
misconfigurations first time.In fact it was Kiste who spoted that mistake and 
helped me to solve that baud rate issue.
Anyways, thank you all.This community rocks big time.
Cheers,Filipe Santos.

On Thursday, May 19, 2022 at 3:32:35 AM UTC+1 vasile wrote:

Cool you find the programmer !
I've seen this issue once too. :) But it was my mistake, I've inverted in a 
wrong way in the PIC.thx.


On Wed, May 18, 2022 at 9:12 PM flyway38  wrote:

Hi Rob, Vasile,
@VasileNo complicated at all to invert signals using 
FT_prog;https://ftdichip.com/wp-content/uploads/2022/05/FT_Prog_v3.12.29.638-Installer.zipVery
 easy. Two clicks after installed and there you go.You can invert any of RS232 
signals, but only TX neeeded to be inverted.

@RobYes. Vasile had already noticed that mistake.It was already corrected and 
solved that baudrate divergence.All fine now. Including Serial_Hardware lib is 
working like a charm.
Never enough to thank you all !!!You guys rock.
Best regards,Filipe Santos.


On Wednesday, May 18, 2022 at 5:42:04 PM UTC+1 vasile wrote:

Hi, one possibility  is to use one single inverter gate like SN74LVC1G04, one 
digital transistor ( base resistor connected internally) and one resistor in 
collector or any other already explained. 
The FT232RL can invert the TX, however it seems so complicated ( it needs to 
program the internal eeprom, see AN121 FTDI accessing the eeprom user area) 
that it is much simpler to correct it in external 
hardware.http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

On Wed, May 18, 2022 at 8:45 AM 'Oliver Seitz' via jallib 
 wrote:

 Great, that error is fixed :-)
Now here's what the PIC sends, and what I presume the PC receives:

Seq. Lvl   Pic sends   PC receives (inverted)

-31idle    framing error   
-21    idle    framing error-11idle    framing error 0    0 
   startbit    idle 1    0    0*1+idle 2    1    1*2+startbit 3 
   0    0*4+1*1+ 4    0    0*8=2   1*2+
 5    0    0*1+1*4+ 6    1    1*2+0*8=7 7    0    0*4+
1*1+ 8    0    0*8=2   2*2+
 9    1    Stopbit 0*4+
10    0    startbit    1*8=b
11    0    0*1+    stopbit12    1    1*2+    startbit13    0    0*4+
    1*1+
14    0    0*8=2   1*2+
15    0    0*1+    1*4+
16    1    1*2+    0*8=7
17    0    0*4+    1*1+
18    0    0*8=2   1*2+
19    1    Stopbit 0*4+
20    1    idle0*8=321    1    idle    framing error
22    1    idle    framing error23    1    idle    framing error24    1 
   idle    framing error
You see, "b7 37" is exactly what to expect when the baudrate is correct, and 
the polarity is not. You just need to fix the polarity. For the transmission 
from the PIC to the PC you can either switch RX on the PC to non-inverted mode, 
or invert TX on the PIC like
BAUDCON1_SCKP=1
However, this PIC does not allow inverting its RX easily, so you need to switch 
the PCs TX to non-inverted mode or invert the signal by other means. That other 
means can be a transistor and two resistors, or a dedicated IC, even a NE555 
can do it. Or, as mentioned before, if you've got an unused pin on the PIC, you 
can use an unused peripheral of your PIC to invert the signal.

Greets,Kiste
    


Am Dienstag, 17. Mai 2022, 23:16:31 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi Kiste,
Thank you very much.That solved the baudrate issue.
But serial_hardware still don't work as it should.Still have Frame and Break 
error on PC side.
Now, your code;forever loop
   serial_hw_data=0x22
   serial_hw_data=0x22
   delay_1s(1)
end loop
Results;b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-17 Thread 'Oliver Seitz' via jallib

 Great, that error is fixed :-)
Now here's what the PIC sends, and what I presume the PC receives:

Seq. Lvl   Pic sends   PC receives (inverted)

-31idle    framing error   
-21    idle    framing error-11idle    framing error 0    0 
   startbit    idle 1    0    0*1+idle 2    1    1*2+startbit 3 
   0    0*4+1*1+ 4    0    0*8=2   1*2+
 5    0    0*1+1*4+ 6    1    1*2+0*8=7 7    0    0*4+
1*1+ 8    0    0*8=2   2*2+
 9    1    Stopbit 0*4+
10    0    startbit    1*8=b
11    0    0*1+    stopbit12    1    1*2+    startbit13    0    0*4+
    1*1+
14    0    0*8=2   1*2+
15    0    0*1+    1*4+
16    1    1*2+    0*8=7
17    0    0*4+    1*1+
18    0    0*8=2   1*2+
19    1    Stopbit 0*4+
20    1    idle0*8=321    1    idle    framing error
22    1    idle    framing error23    1    idle    framing error24    1 
   idle    framing error
You see, "b7 37" is exactly what to expect when the baudrate is correct, and 
the polarity is not. You just need to fix the polarity. For the transmission 
from the PIC to the PC you can either switch RX on the PC to non-inverted mode, 
or invert TX on the PIC like
BAUDCON1_SCKP=1
However, this PIC does not allow inverting its RX easily, so you need to switch 
the PCs TX to non-inverted mode or invert the signal by other means. That other 
means can be a transistor and two resistors, or a dedicated IC, even a NE555 
can do it. Or, as mentioned before, if you've got an unused pin on the PIC, you 
can use an unused peripheral of your PIC to invert the signal.

Greets,Kiste
    


Am Dienstag, 17. Mai 2022, 23:16:31 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi Kiste,
Thank you very much.That solved the baudrate issue.
But serial_hardware still don't work as it should.Still have Frame and Break 
error on PC side.
Now, your code;forever loop
   serial_hw_data=0x22
   serial_hw_data=0x22
   delay_1s(1)
end loop
Results;b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             
b7 37 00                                         ·7.             

Cannot understand what's going on.Anymore ideas?
Cheers,Filipe Santos.
On Tuesday, May 17, 2022 at 8:34:17 PM UTC+1 Kiste wrote:

 So, here it is:
pragma target clock 20_000_000   -- oscillator frequency
pragma target RSTOSC   HFINT32   -- power-up clock select: OSC
You're telling the compiler, the PIC would run at 20MHz, and you're setting the 
PIC to 32MHz. 

Make it
pragma target clock 32_000_000   -- oscillator frequency

and your baudrate will be as specified.
Greets,Kiste 

Am Dienstag, 17. Mai 2022, 21:12:10 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi again Kiste,
Here my code pragmas;
-- Pragmas/ configuration memory settings (fuses)
pragma target clock 20_000_000                   -- oscillator frequency
pragma target OSC      OFF                       -- HS crystal or resonator
pragma target RSTOSC   HFINT32                   -- power-up clock select: OSC
pragma target CLKOUTEN DISABLED                  -- no clock output
pragma target WDT      DISABLED                  -- watchdog
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-17 Thread 'Oliver Seitz' via jallib

 So, here it is:
pragma target clock 20_000_000   -- oscillator frequency
pragma target RSTOSC   HFINT32   -- power-up clock select: OSC
You're telling the compiler, the PIC would run at 20MHz, and you're setting the 
PIC to 32MHz. 

Make it
pragma target clock 32_000_000   -- oscillator frequency

and your baudrate will be as specified.
Greets,Kiste 

Am Dienstag, 17. Mai 2022, 21:12:10 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi again Kiste,
Here my code pragmas;
-- Pragmas/ configuration memory settings (fuses)
pragma target clock 20_000_000                   -- oscillator frequency
pragma target OSC      OFF                       -- HS crystal or resonator
pragma target RSTOSC   HFINT32                   -- power-up clock select: OSC
pragma target CLKOUTEN DISABLED                  -- no clock output
pragma target WDT      DISABLED                  -- watchdog
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED                  -- no clock monitoring
pragma target CSWEN    ENABLED                   -- allow writing OSCCON1 NOSC 
and NDIV
pragma target LVP      DISABLED                  -- no low voltage programming
pragma target MCLR     EXTERNAL                  -- external reset
-- The configuration bit settings above are only a selection, sufficient
-- for this program. Other programs may need more or different settings.
--
WDTCON_SWDTEN = OFF                              -- disable watchdog
--
_usec_delay (100_000)                            -- wait for power to stablilize
--
enable_digital_io()                              -- make all pins digital I/O
CheersFilipe Santos.
On Tuesday, May 17, 2022 at 7:05:54 PM UTC+1 Kiste wrote:

 Hi Filipe,

 
I suspect the baudrate problem in settings like
pragma target clock  ?
pragma target OSC ?
pragma target RSTOSC ?

OSCCON* = ?
What are these settings?

Greets,Kiste



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/6e0906ee-c9ec-4f45-94fb-3f99356d83aen%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1502497946.2497071.1652816047051%40mail.yahoo.com.

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-17 Thread 'Oliver Seitz' via jallib

 Hi Filipe,

 
I suspect the baudrate problem in settings like
pragma target clock  ?
pragma target OSC ?
pragma target RSTOSC ?

OSCCON* = ?
What are these settings?

Greets,Kiste

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1887950039.2466816.1652810752479%40mail.yahoo.com.

AW: Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-17 Thread 'Oliver Seitz' via jallib

 works better than timeout solution 
under serial_software lib usage.Unless some miraculous idea comes along.. :D
Anyways, later on, will redesign this project for a bigger board and use a 
bigger PIC.Thank you to all once again.
Kind regards,Filipe Santos.

On Sunday, May 15, 2022 at 4:44:36 PM UTC+1 rob...@hotmail.com wrote:

Hi Kiste,
I fully agree with you. Not worth to add a timeout.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: zondag 15 mei 2022 17:33
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] Help about serial_hardware library for the 16F18313Hi 
Rob,

the most critical thing when receiving asynchronous data, is to precisely catch 
the starting edge of the start bit, as all the timing in the following byte 
depends on it.
while serial_sw_rx_pin loopend loop
This is in fact only two machine instructions, and therefore reacts within 2Tcy 
or 2µs at 4MHz.
I did not count the machine instructions for subtracting a dword, but I think 
it must be more than 12 instructions, and another 12 for comparing to 0. Plus 
the 1µs delay,  plus the "&"... Will take at least 30µs at 4MHz. If that is 
more than half a bit, data corruption is more than likely. 1/60µs=1 baud is 
the speed beyond that a 4MHz controller will certainly not be able to follow 
anymore.
If the transmission starts right after the timeout is over, depending on the 
main program, corrupt data will be received (or a byte is completely lost).

Serial_software is a poor thing on the receiving side anyway. If you see it as 
an improvement, go ahead. I would under all circumstances avoid using 
serial_software for receiving, even more so with that timeout.
Greets,Kiste

Am Sonntag, 15. Mai 2022, 16:57:09 MESZ hat Rob CJ  
Folgendes geschrieben:

Hi Kiste, Filip,
An option would be to extend the serial_software.jal library with a maximum 
wait time for reading and when a timeout occurs return a '0' as data.
So something like.      -- See if a timeout is defined to prevent an endless 
wait      if defined(SERIAL_SOFTWARE_READ_TIMEOUT)then         var dword 
_serial_timeout = SERIAL_SOFTWARE_READ_TIMEOUT         -- wait for startbit 
with timeout         while serial_sw_rx_pin & (_serial_timeout >0) loop         
    _serial_timeout = _serial_timeout - 1            _usec_delay(1)         end 
loop      else          -- wait for startbit without a timeout        while 
serial_sw_rx_pinloop end loop      end if 
   -- When a timeout is defined and a timeout occcured return 0 as data.   if 
defined(SERIAL_SOFTWARE_READ_TIMEOUT)then     if (_serial_timeout ==0) then     
   data = 0      end if   end if 
Would that work?
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: zondag 15 mei 2022 15:46
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] Help about serial_hardware library for the 16F18313 Hi!
Well... 8 pin is a problem... I only have solutions which aren't that elegant...

- use a different USB UART, which uses the idle high mode (which in fact is 
standard on 3.3 and 5 volt levels)- if you have an I/O pin (other than RA4) to 
spare, use the comparator or a CLC to invert the signal, and connect the output 
and RX to that same pin via PPS- use external circuitry to invert the signal, 
like a MAX232, which is inverting since the 1970s and therefore in fact the 
reason for all the confusion ;-)- write a new library, which receives by timers 
and pin-change interrupts
Greets,Kiste
Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38  
Folgendes geschrieben:

Hi Kiste,
Understad your points.The main issue am trying to solve while using 
serial_software (wich makes my project runs good enough) is that loop while 
trying to receive data;"while !serial_sw_rx_pin loop".Because of this loop have 
to constantly send dummy data to allow PIC out of the loop.All other code runs 
fairly ok (somewhat sluggish, but good enough for the needs).
Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right 
now...On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote:

Hi Filipe,
that's an important information: seral_sw_invert defaults to "true". If you had 
to set it, you have set it to "false". That means, the line you are driving is 
in "idle low" mode. That mode is not supported by serial_hardware, as it is not 
supported by the classical USART hardware in PIC controllers.
You can not cure that problem by sendig serial_hw_data=!value , as that does 
not alter the polarity of start- and stopbits. 
With the delay of 300µs between bytes, you do not cure the framing error. By 
doing so, you mislead the receiver to recognise data bits as framing bits, so 
it's one error masking the other error. 
If you can use another PIC, like PIC18F14K22, the hardware can be set to "idle 
low" mode for sending and receiving, your 16f18313 can only use the 
transmission side in that mode. So, to make the receiving side work, you would 
have to use additiona

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-15 Thread 'Oliver Seitz' via jallib

 Hi Rob,

the most critical thing when receiving asynchronous data, is to precisely catch 
the starting edge of the start bit, as all the timing in the following byte 
depends on it.
while serial_sw_rx_pin loopend loop
This is in fact only two machine instructions, and therefore reacts within 2Tcy 
or 2µs at 4MHz.
I did not count the machine instructions for subtracting a dword, but I think 
it must be more than 12 instructions, and another 12 for comparing to 0. Plus 
the 1µs delay,  plus the "&"... Will take at least 30µs at 4MHz. If that is 
more than half a bit, data corruption is more than likely. 1/60µs=1 baud is 
the speed beyond that a 4MHz controller will certainly not be able to follow 
anymore.
If the transmission starts right after the timeout is over, depending on the 
main program, corrupt data will be received (or a byte is completely lost).

Serial_software is a poor thing on the receiving side anyway. If you see it as 
an improvement, go ahead. I would under all circumstances avoid using 
serial_software for receiving, even more so with that timeout.
Greets,Kiste

Am Sonntag, 15. Mai 2022, 16:57:09 MESZ hat Rob CJ  
Folgendes geschrieben:  
 
 Hi Kiste, Filip,
An option would be to extend the serial_software.jal library with a maximum 
wait time for reading and when a timeout occurs return a '0' as data.
So something like.      -- See if a timeout is defined to prevent an endless 
wait      if defined(SERIAL_SOFTWARE_READ_TIMEOUT)then         var dword 
_serial_timeout = SERIAL_SOFTWARE_READ_TIMEOUT         -- wait for startbit 
with timeout         while serial_sw_rx_pin & (_serial_timeout >0) loop         
    _serial_timeout = _serial_timeout - 1            _usec_delay(1)         end 
loop      else          -- wait for startbit without a timeout        while 
serial_sw_rx_pinloop end loop      end if 
   -- When a timeout is defined and a timeout occcured return 0 as data.   if 
defined(SERIAL_SOFTWARE_READ_TIMEOUT)then     if (_serial_timeout ==0) then     
   data = 0      end if   end if 
Would that work?
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: zondag 15 mei 2022 15:46
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] Help about serial_hardware library for the 16F18313 Hi!
Well... 8 pin is a problem... I only have solutions which aren't that elegant...

- use a different USB UART, which uses the idle high mode (which in fact is 
standard on 3.3 and 5 volt levels)- if you have an I/O pin (other than RA4) to 
spare, use the comparator or a CLC to invert the signal, and connect the output 
and RX to that same pin via PPS- use external circuitry to invert the signal, 
like a MAX232, which is inverting since the 1970s and therefore in fact the 
reason for all the confusion ;-)- write a new library, which receives by timers 
and pin-change interrupts
Greets,Kiste
Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38  
Folgendes geschrieben:

Hi Kiste,
Understad your points.The main issue am trying to solve while using 
serial_software (wich makes my project runs good enough) is that loop while 
trying to receive data;"while !serial_sw_rx_pin loop".Because of this loop have 
to constantly send dummy data to allow PIC out of the loop.All other code runs 
fairly ok (somewhat sluggish, but good enough for the needs).
Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right 
now...On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote:

Hi Filipe,
that's an important information: seral_sw_invert defaults to "true". If you had 
to set it, you have set it to "false". That means, the line you are driving is 
in "idle low" mode. That mode is not supported by serial_hardware, as it is not 
supported by the classical USART hardware in PIC controllers.
You can not cure that problem by sendig serial_hw_data=!value , as that does 
not alter the polarity of start- and stopbits. 
With the delay of 300µs between bytes, you do not cure the framing error. By 
doing so, you mislead the receiver to recognise data bits as framing bits, so 
it's one error masking the other error. 
If you can use another PIC, like PIC18F14K22, the hardware can be set to "idle 
low" mode for sending and receiving, your 16f18313 can only use the 
transmission side in that mode. So, to make the receiving side work, you would 
have to use additional hardware (or peripherals like CLC or comparators) to 
invert incoming data.
Greets,Kiste
Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38  
Folgendes geschrieben:

Hi Kiste,
Thak you very much for your input.Will test your code to check and answer 
you.Anyways, right now I can avoid the Framming Error but still receiving 
incorrect data while using serial_hardware library.
About framming Error, the problem was due to the way I sent data to transmit 
reg.I was sending two bytes with no delay in between (it works good like this 
using serial_software lib).But i

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-15 Thread 'Oliver Seitz' via jallib

 Hi!
Well... 8 pin is a problem... I only have solutions which aren't that elegant...

- use a different USB UART, which uses the idle high mode (which in fact is 
standard on 3.3 and 5 volt levels)- if you have an I/O pin (other than RA4) to 
spare, use the comparator or a CLC to invert the signal, and connect the output 
and RX to that same pin via PPS- use external circuitry to invert the signal, 
like a MAX232, which is inverting since the 1970s and therefore in fact the 
reason for all the confusion ;-)- write a new library, which receives by timers 
and pin-change interrupts
Greets,Kiste
Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi Kiste,
Understad your points.The main issue am trying to solve while using 
serial_software (wich makes my project runs good enough) is that loop while 
trying to receive data;"while !serial_sw_rx_pin loop".Because of this loop have 
to constantly send dummy data to allow PIC out of the loop.All other code runs 
fairly ok (somewhat sluggish, but good enough for the needs).
Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right 
now...On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote:

 Hi Filipe,
that's an important information: seral_sw_invert defaults to "true". If you had 
to set it, you have set it to "false". That means, the line you are driving is 
in "idle low" mode. That mode is not supported by serial_hardware, as it is not 
supported by the classical USART hardware in PIC controllers.
You can not cure that problem by sendig serial_hw_data=!value , as that does 
not alter the polarity of start- and stopbits. 
With the delay of 300µs between bytes, you do not cure the framing error. By 
doing so, you mislead the receiver to recognise data bits as framing bits, so 
it's one error masking the other error. 
If you can use another PIC, like PIC18F14K22, the hardware can be set to "idle 
low" mode for sending and receiving, your 16f18313 can only use the 
transmission side in that mode. So, to make the receiving side work, you would 
have to use additional hardware (or peripherals like CLC or comparators) to 
invert incoming data.
Greets,Kiste
Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi Kiste,
Thak you very much for your input.Will test your code to check and answer 
you.Anyways, right now I can avoid the Framming Error but still receiving 
incorrect data while using serial_hardware library.
About framming Error, the problem was due to the way I sent data to transmit 
reg.I was sending two bytes with no delay in between (it works good like this 
using serial_software lib).But if I use a delay of about 300us between the two 
bytes sent, Frame Error disppears, but as said above, received data by computer 
is incorrect.Less than that delay, I get Frame Error.
Can answer your question about "const bit serial_sw_invert". Yes, needed to set 
this var using serial_software.
Will back here with answer for your second quest.Thank you
Cheers,Filipe Santos.
On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote:

 That data is a bit complex for easy analysis, though I see that you've got a 
repeating value every five bytes in all of the samples. The baud rate therefore 
should not be the problem.
If you want to rely on my guess, insert after "seral_hw_init()"
BAUDCON1_SCKP=1If this helps for transmission, you can't use the USART directly 
for receiving, as it has no inversion option for RX. In that case, you can use 
a CLC or a comparator as inverter.

If you want to track down the error and learn how to do that, please answer my 
questions:
Have you set "const bit serial_sw_invert" with serial software?
What is the result if you just transmit a single character with pauses?
forever loop   serial_hw_data="@"   delay_1s(1)end loop

Greets,Kiste
Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hello Kiste,
I use Termite to check what flows in my comm line.Here's what I see and makes 
my project work good enough, using serial_software (small extract):
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..îï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1  íï*ñ..îï*ñ..îï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-15 Thread 'Oliver Seitz' via jallib

 Hi!
You're sending 0x40 ("@"), you're receiving (usually) 0x80, that's a bit 
weird... Thinking about it, in reverse polarity a single byte with only bit 6 
set should not be received at all. It was a bad idea to transmit "@". This 
would be more helpful:
forever loop   serial_hw_data=0x22   serial_hw_data=0x22   delay_1s(1)end loop
This would result in 0x84, followed by 0x8c with framing error when received in 
opposite polarity.

Am Sonntag, 15. Mai 2022, 13:29:25 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi again,
Here's what that code produces in Termite;
80                                               €               
80                                               €               
c0                                               À               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
c0                                               À               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
c0                                               À               
80                                               €               
80                                               €               
80                                               €               
80                                               €               
c0                                               À               
80                                               €               

Anyways, using BAUDCON1_SCKP=1 after "seral_hw_init()", I get undefined error 
at compiling. But I checked target file and exchanged it to;BAUDCON_SCKP=1and 
it compiles ok.This way I get Frame Error mixed with Break Error... in 
receiving software.

Thank you for help.Anymore ideas?Thank you very much.
Cheers,Filipe Santos.
On Sunday, May 15, 2022 at 12:06:52 PM UTC+1 flyway38 wrote:

Hi Kiste,
Thak you very much for your input.Will test your code to check and answer 
you.Anyways, right now I can avoid the Framming Error but still receiving 
incorrect data while using serial_hardware library.
About framming Error, the problem was due to the way I sent data to transmit 
reg.I was sending two bytes with no delay in between (it works good like this 
using serial_software lib).But if I use a delay of about 300us between the two 
bytes sent, Frame Error disppears, but as said above, received data by computer 
is incorrect.Less than that delay, I get Frame Error.
Can answer your question about "const bit serial_sw_invert". Yes, needed to set 
this var using serial_software.
Will back here with answer for your second quest.Thank you
Cheers,Filipe Santos.
On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote:

 That data is a bit complex for easy analysis, though I see that you've got a 
repeating value every five bytes in all of the samples. The baud rate therefore 
should not be the problem.
If you want to rely on my guess, insert after "seral_hw_init()"
BAUDCON1_SCKP=1If this helps for transmission, you can't use the USART directly 
for receiving, as it has no inversion option for RX. In that case, you can use 
a CLC or a comparator as inverter.

If you want to track down the error and learn how to do that, please answer my 
questions:
Have you set "const bit serial_sw_invert" with serial software?
What is the result if you just transmit a single character with pauses?
forever loop   serial_hw_data="@"   delay_1s(1)end loop

Greets,Kiste
Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hello Kiste,
I use Termite to check what flows in my comm line.Here's what I see and makes 
my project work good enough, using serial_software (small extract):
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..îï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-15 Thread 'Oliver Seitz' via jallib

 Hi Filipe,
that's an important information: seral_sw_invert defaults to "true". If you had 
to set it, you have set it to "false". That means, the line you are driving is 
in "idle low" mode. That mode is not supported by serial_hardware, as it is not 
supported by the classical USART hardware in PIC controllers.
You can not cure that problem by sendig serial_hw_data=!value , as that does 
not alter the polarity of start- and stopbits. 
With the delay of 300µs between bytes, you do not cure the framing error. By 
doing so, you mislead the receiver to recognise data bits as framing bits, so 
it's one error masking the other error. 
If you can use another PIC, like PIC18F14K22, the hardware can be set to "idle 
low" mode for sending and receiving, your 16f18313 can only use the 
transmission side in that mode. So, to make the receiving side work, you would 
have to use additional hardware (or peripherals like CLC or comparators) to 
invert incoming data.
Greets,Kiste
Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hi Kiste,
Thak you very much for your input.Will test your code to check and answer 
you.Anyways, right now I can avoid the Framming Error but still receiving 
incorrect data while using serial_hardware library.
About framming Error, the problem was due to the way I sent data to transmit 
reg.I was sending two bytes with no delay in between (it works good like this 
using serial_software lib).But if I use a delay of about 300us between the two 
bytes sent, Frame Error disppears, but as said above, received data by computer 
is incorrect.Less than that delay, I get Frame Error.
Can answer your question about "const bit serial_sw_invert". Yes, needed to set 
this var using serial_software.
Will back here with answer for your second quest.Thank you
Cheers,Filipe Santos.
On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote:

 That data is a bit complex for easy analysis, though I see that you've got a 
repeating value every five bytes in all of the samples. The baud rate therefore 
should not be the problem.
If you want to rely on my guess, insert after "seral_hw_init()"
BAUDCON1_SCKP=1If this helps for transmission, you can't use the USART directly 
for receiving, as it has no inversion option for RX. In that case, you can use 
a CLC or a comparator as inverter.

If you want to track down the error and learn how to do that, please answer my 
questions:
Have you set "const bit serial_sw_invert" with serial software?
What is the result if you just transmit a single character with pauses?
forever loop   serial_hw_data="@"   delay_1s(1)end loop

Greets,Kiste
Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hello Kiste,
I use Termite to check what flows in my comm line.Here's what I see and makes 
my project work good enough, using serial_software (small extract):
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..îï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1  íï*ñ..îï*ñ..îï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
Now here's what I see using serial_hardware: 

9a f1 81 80 f5 ef 92 f1 81 80 fd ef 9a f1 81 80  šñ €õï’ñ €ýïšñ €
f5 ef 9a f1 81 80 f6 ef 9a f1 89 80 fd ef 9a f1  õïšñ €öïšñ‰€ýïšñ
89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 f5 ef  ‰€þïšñ‰€ýïšñ‰€õï
92 f1 81 80 f5 ef 9a f1 81 80 f5 ef 92 f1 89 80  ’ñ €õïšñ €õï’ñ‰€
f5 ef 9a f1 81 80 f5 ef 9a f1 81 80 fd ef 9a f1  õïšñ €õïšñ €ýïšñ
89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 fd ef  ‰€þïšñ‰€ýïšñ‰€ýï
9a f1 89 80 f5 ef 92 f1 81 80 fd ef 9a f1 89 80  šñ‰€õï’ñ €ýïšñ‰€
fd ef 9a f1 81 80 fd ef 92 f1 89 80 fe ef 9a f1  ýïšñ €ýï’ñ‰€þïšñ
81 80 fd ef 9a f1 89 80 f5 ef 9a f1 81 80 fd ef   €ýïšñ‰€õïšñ €ýï
9a f1 81 80 fe ef 9a f1 81 80 f5 ef 9a f1 89 80  šñ €þïšñ €õïšñ‰€
f5 ef 9a f1 81 80 ed ef 9a f1 81 80 f5 ef 9a f1  õïšñ €íïšñ €õïšñ
89 80 fd ef 9a f1 89 80 f6 ef 92 f1 89 80 fe ef  ‰€ýïšñ‰€öï’ñ‰€þï
92 f1 89 80 fd ef 92 f1 81 80 fe ef 92 f1 89 80  ’ñ‰€ýï’ñ €þï’ñ‰€
f5 ef 9a f1 81 80 fe ef 92 f1 89 80 fd ef 9a f1  õïšñ €þï’ñ‰€ýïšñ
81 80 fd ef 8a f1 89 80 fd ef 92 f1 81 80 fd ef   €ýïŠñ‰€ýï’ñ €ýï
92 f1 81 80 fd ef 9a f1 81 80 ed ef 92 f1 89 80  ’ñ €ýïšñ €íï’ñ‰€
Finally, here's what I see using serial_hardware, inverted data in

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-15 Thread 'Oliver Seitz' via jallib

 That data is a bit complex for easy analysis, though I see that you've got a 
repeating value every five bytes in all of the samples. The baud rate therefore 
should not be the problem.
If you want to rely on my guess, insert after "seral_hw_init()"
BAUDCON1_SCKP=1If this helps for transmission, you can't use the USART directly 
for receiving, as it has no inversion option for RX. In that case, you can use 
a CLC or a comparator as inverter.

If you want to track down the error and learn how to do that, please answer my 
questions:
Have you set "const bit serial_sw_invert" with serial software?
What is the result if you just transmit a single character with pauses?
forever loop   serial_hw_data="@"   delay_1s(1)end loop

Greets,Kiste
Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38  
Folgendes geschrieben:  
 
 Hello Kiste,
I use Termite to check what flows in my comm line.Here's what I see and makes 
my project work good enough, using serial_software (small extract):
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..îï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1  íï*ñ..íï*ñ..íï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1  íï*ñ..îï*ñ..îï*ñ
09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef  ..íï*ñ..íï*ñ..íï
2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00  *ñ..íï*ñ..íï*ñ..
Now here's what I see using serial_hardware: 

9a f1 81 80 f5 ef 92 f1 81 80 fd ef 9a f1 81 80  šñ €õï’ñ €ýïšñ €
f5 ef 9a f1 81 80 f6 ef 9a f1 89 80 fd ef 9a f1  õïšñ €öïšñ‰€ýïšñ
89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 f5 ef  ‰€þïšñ‰€ýïšñ‰€õï
92 f1 81 80 f5 ef 9a f1 81 80 f5 ef 92 f1 89 80  ’ñ €õïšñ €õï’ñ‰€
f5 ef 9a f1 81 80 f5 ef 9a f1 81 80 fd ef 9a f1  õïšñ €õïšñ €ýïšñ
89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 fd ef  ‰€þïšñ‰€ýïšñ‰€ýï
9a f1 89 80 f5 ef 92 f1 81 80 fd ef 9a f1 89 80  šñ‰€õï’ñ €ýïšñ‰€
fd ef 9a f1 81 80 fd ef 92 f1 89 80 fe ef 9a f1  ýïšñ €ýï’ñ‰€þïšñ
81 80 fd ef 9a f1 89 80 f5 ef 9a f1 81 80 fd ef   €ýïšñ‰€õïšñ €ýï
9a f1 81 80 fe ef 9a f1 81 80 f5 ef 9a f1 89 80  šñ €þïšñ €õïšñ‰€
f5 ef 9a f1 81 80 ed ef 9a f1 81 80 f5 ef 9a f1  õïšñ €íïšñ €õïšñ
89 80 fd ef 9a f1 89 80 f6 ef 92 f1 89 80 fe ef  ‰€ýïšñ‰€öï’ñ‰€þï
92 f1 89 80 fd ef 92 f1 81 80 fe ef 92 f1 89 80  ’ñ‰€ýï’ñ €þï’ñ‰€
f5 ef 9a f1 81 80 fe ef 92 f1 89 80 fd ef 9a f1  õïšñ €þï’ñ‰€ýïšñ
81 80 fd ef 8a f1 89 80 fd ef 92 f1 81 80 fd ef   €ýïŠñ‰€ýï’ñ €ýï
92 f1 81 80 fd ef 9a f1 81 80 ed ef 92 f1 89 80  ’ñ €ýïšñ €íï’ñ‰€
Finally, here's what I see using serial_hardware, inverted data in 
serial_hw_write function ("TXREG = !data"):
82 90 e5 8e fe ff 82 90 e5 8e f6 ff 8a 90 ed 8e  ‚ åŽþÿ‚ åŽöÿŠ íŽ
fe ff 8a 90 ed 8e fe ff 8a 90 e5 8e fe ff 89 90  þÿŠ íŽþÿŠ åŽþÿ‰ 
e5 8e fe ff 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff  åŽþÿ‚ åŽöÿ íŽöÿ
82 90 ed 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e  ‚ íŽöÿŠ åŽöÿ‚ íŽ
f6 ff 8a 90 ed 8e fe ff 82 90 e5 8e f6 ff 81 90  öÿŠ íŽþÿ‚ åŽöÿ 
ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e fe ff  íŽöÿ‚ åŽöÿ‚ åŽþÿ
8a 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e  Š åŽöÿŠ åŽöÿ‚ íŽ
f6 ff 82 90 e5 8e fe ff 81 90 e5 8e fe ff 82 90  öÿ‚ åŽþÿ åŽþÿ‚ 
ed 8e fe ff 82 90 ed 8e fe ff 8a 90 ed 8e fe ff  íŽþÿ‚ íŽþÿŠ íŽþÿ
82 90 e5 8e fe ff 82 90 ed 8e fe ff 82 90 e5 8e  ‚ åŽþÿ‚ íŽþÿ‚ åŽ
fe ff 8a 90 e5 8e f6 ff 82 90 ed 8e fe ff 82 90  þÿŠ åŽöÿ‚ íŽþÿ‚ 
e5 8e fe ff 82 90 e5 8e fe ff 82 90 e5 8e f6 ff  åŽþÿ‚ åŽþÿ‚ åŽöÿ
82 90 e5 8e f6 ff 81 90 ed 8e f6 ff 8a 90 ed 8e  ‚ åŽöÿ íŽöÿŠ íŽ
f6 ff 82 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 89 90  öÿ‚ åŽöÿŠ åŽöÿ‰ 
ed 8e f6 ff 8a 90 e5 8e fe ff 82 90 ed 8e fe ff  íŽöÿŠ åŽþÿ‚ íŽþÿ
82 90 ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e  ‚ íŽöÿ‚ åŽöÿ‚ åŽ
It seems serial_hardware is not transmitting same data.Any help would be 
great.Thank you.
Cheers,Filipe Santos

On Sunday, May 15, 2022 at 6:57:39 AM UTC+1 Kiste wrote:

 Hi Filipe,
If serial_software works with "const bit serial_sw_invert = true", then 
serial_hardware should also work. serial_software supports the non-inverted 
mode, the uart hardware in newer PICs also supports the non-inverted mode, but 
the serial_hardware library does not yet support that mode natively.
Have you tried single chars with time in between?
forever loop   serial_hw_data="@"   delay_1s(1)end loop
This loop transmits a start bit and a single set data bit every second. From 
the results you're seeing on the PC, the error might be narrowed down.
Greets,Kiste

Am Samstag, 14. Mai 2022, 22:58:28 MESZ hat flyway38

Re: [jallib] Help about serial_hardware library for the 16F18313

2022-05-14 Thread 'Oliver Seitz' via jallib

Hi Filipe,
If serial_software works with "const bit serial_sw_invert = true", then
serial_hardware should also work. serial_software supports the non-inverted
mode, the uart hardware in newer PICs also supports the non-inverted mode, but
the serial_hardware library does not yet support that mode natively.
Have you tried single chars with time in between?
forever loop serial_hw_data="@" delay_1s(1)end loop
This loop transmits a start bit and a single set data bit every second. From
the results you're seeing on the PC, the error might be narrowed down.
Greets,Kiste

Am Samstag, 14. Mai 2022, 22:58:28 MESZ hat flyway38
Folgendes geschrieben:

Hi to all,
Have been using serial_software library with enough success until now.Am coding
for use a TTL-232R-5V-AI USB Cable to connect to computer.Using serial_software
library with invert bit activated, am getting good results.
It all works good enough sending data to computer
The problem with this library is while receiving data from computer. As soon as
this funcion is activated in PIC code, the library locks in a loop waiting for
data.So, started to migrate my code for use with serial_hardware library
instead, to avoid this lock.But now I get Frame Error from COMM PORT with not
usefull data, all the time. Even if I invert data received. Have also tried
different baud rates, etc...
Can anyone help about this issue?Thank you very much.
Kind regards,Filipe Santos.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com.

Re: [jallib] PWM2.

2022-04-06 Thread 'Oliver Seitz' via jallib

 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 
 Folgendes geschrieben:  
 
 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  
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(1) -- 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  
Folgendes geschrieben:  
 
 Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on 
16FHow 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

Re: [jallib] PWM2.

2022-04-05 Thread 'Oliver Seitz' via jallib

 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 
 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(1) -- 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  
Folgendes geschrieben:  
 
 Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on 
16FHow 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 loopelse   for 19 using teller 
loop      command_send_kamer(HALT_kamer[teller])   end loopend if
That way there's no "if" between the bytes.
Greets,Kiste 


Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans  
Folgendes geschrieben:  
 
 
Everything has its limits. We have tried to make a remotecontrol for his two 
DAIKIN ACs. With PWM1, the case responds just fine withPMW2 not responding. The 
IR LEDs are controlled with an npn. (swapped) . Wealso tried the 16F877a, same 
result. On an AUDICITY we compared the IR resultson a TSOP , the IR leds 
(swapped!)… Both look the same. The frequencies of thePMW varied from 35 to 40. 
No effect.

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

Attached program and

Re: [jallib] PWM serial audio transmission

2022-04-05 Thread 'Oliver Seitz' via jallib

 I have only made small changes in the code and improved the comments. I did 
not try this version, but I'm quite sure it should work. You only need a PIC, a 
resistor, a TTL-Serial converter with a computer and the sample audio file 
which i posted earlier to see it working.
(You can even omit the resistor, but you could fry the PIC then. Especially if 
you don't use the error LED and have no idea about what volume to set)
Greets,Kiste

Am Dienstag, 5. April 2022, 12:05:59 MESZ hat hans 
 Folgendes geschrieben:  
 
 Hello Rob and Kiste,The next days i have a friend who can assist me. So 
(beside his AC project) we might find time to continue with this . So please 
give us the last info.Thanks againhans 

Op zondag 3 april 2022 om 15:57:03 UTC+2 schreef rob...@hotmail.com:

Hi Hans,
I also tried it with a lower frequency, 3330 Hz for the low tone and 4030 Hz 
for the high tone so that the signal is strong enough when you record it.
If you want to know more, let me know.
Kind regards,
Rob
Van: jal...@googlegroups.com  namens hans 

Verzonden: zondag 3 april 2022 15:11
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmissionStill foggy, just wait a 
little longer with this case.

Op zaterdag 26 maart 2022 om 20:05:55 UTC+1 schreef rob...@hotmail.com:

Hi Hans,
I hope you are getting well soon. Last update. I recorded the audio and played 
it back to see if it works.
And it seems to work but may need some fine tuning. In this video you see the 
device in operation: https://youtu.be/w-j0ekk975g
The yellow line on the oscilloscope is the audio signal and the blue line the 
trigger signal. This trigger signal is also visible by the Amber LED on the top 
right of the breadboard.
I recorded the low tone (it is a video recording but I am only using the audio) 
and switched from low tone to the high tone frequently. What you see is that 
the signal of the high tone is smaller but it still works. You also see that 
the refresh of the oscilloscope is a bit behind so the LED on the breadboard 
shows the real trigger. I also attached two screenshots. You see that the 
trigger response is quite fast (zoomed in) but with a high tone it is not 
constant (see zoomed out) but that can be solved in software and could be 
because the signal is smaller. Also I noticed that when no signal is present 
the output is also high but that stops as soon as the low tone is detected.
So still a proof of concept but seems to do something. I also attached the 
audio tone. Maybe lower tones would be better.
For recording I just used the output of the PIC using a resistor divider of 10 
k with 100 Ohm and connecting that to the line in of my computer. For playback 
I added an LM358 to amplify the input signal and I used the headphone output.
Kind regards,
Rob

Op donderdag 24 maart 2022 om 12:47:49 UTC+1 schreefrob...@hotmail.com:

Hi Marieke,
Thanks for the update. Let's hope Hans recovers soon.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: donderdag 24 maart 2022 07:37
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmissionAltijd met Rust...
It took me two weeks to think, code and test, and it will take more weeks for 
proper documentation. So no need for you to hurry ;-)
Greets,Kiste
Am Mittwoch, 23. März 2022, 22:36:19 MEZ hat hans  
Folgendes geschrieben:


Hello everyone,

My grandfather Hans has only one usable eye and has got an infection on it. We 
have read your contributions and he is very happy with them. Sorry but he can't 
work with it right now.

Regards Marieke

Op woensdag 23 maart 2022 om 17:22:42 UTC+1 schreef Kiste:

And here's the receiver, and a sample file. Mp3 does work at 1200baud, but you 
shouldn't use less than 128kbit for encoding. At 80kbit I only got garbage. 
Volume must be reasonably high, slowly turn louder until the error LED is 
constantly off.
Don't send too much data back-to-back, have pauses of like 10 ms every second 
(but keep the tone on all the time)
Don't assume error-free transmission, send data multiple times and check when 
receiving.

Greets,Kiste



Am Sonntag, 20. März 2022, 13:22:14 MEZ hat 'Oliver Seitz' via jallib 
 Folgendes geschrieben:

Hi all,
here's my encoder. I looked for something similar to the 12F683 which Hans has 
in stock, and found some 12F629, which should be quite compatible.

C1: minimum 1µF, no need to be polarizedR1:680R..1kC2: 100nFR2:1k..4k7D1=D2: 
1N4148, 1N4001 or similar, silicon, not schottky
This gives a frequency which a line (AUX) audio input should be able to handle. 
The receiver will be the same kind of chip, but it must have a comparator and a 
reference voltage module. TMR0 will be used.

The transmitter will work on any 6 or 8 pin controller, as it doesn't use any 
peripherals.

Greets,Kiste




-- 
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 
tojallib+un...@google

Re: [jallib] PWM2.

2022-04-05 Thread 'Oliver Seitz' via jallib

 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  
Folgendes geschrieben:  
 
 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 
Verzonden: dinsdag 5 april 2022 18:09
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] PWM2. 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 
 Folgendes geschrieben:

Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on 16FHow 
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 loopelse   for 19 using teller 
loop      command_send_kamer(HALT_kamer[teller])   end loopend if
That way there's no "if" between the bytes.
Greets,Kiste 


Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans  
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 u

Re: [jallib] PWM2.

2022-04-05 Thread 'Oliver Seitz' via jallib

 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(1) -- 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 
 Folgendes geschrieben:  
 
 Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on 
16FHow 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 loopelse   for 19 using teller 
loop      command_send_kamer(HALT_kamer[teller])   end loopend if
That way there's no "if" between the bytes.
Greets,Kiste 


Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans  
Folgendes geschrieben:  
 
 
Everything has its limits. We have tried to make a remotecontrol for his two 
DAIKIN ACs. With PWM1, the case responds just fine withPMW2 not responding. The 
IR LEDs are controlled with an npn. (swapped) . Wealso tried the 16F877a, same 
result. On an AUDICITY we compared the IR resultson a TSOP , the IR leds 
(swapped!)… Both look the same. The frequencies of thePMW varied from 35 to 40. 
No effect.

So that's the end of the story for us and then just fiddlingwith one PWM, which 
we then switch via hardware. Unless ……. Any of you have adifferent 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

Re: [jallib] PWM2.

2022-04-05 Thread 'Oliver Seitz' via jallib

 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 
 Folgendes geschrieben:  
 
 Hello Kyle, Done but same result. PWM1 works and PWM2 not. Now tested on 
16FHow 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 loopelse   for 19 using teller 
loop      command_send_kamer(HALT_kamer[teller])   end loopend if
That way there's no "if" between the bytes.
Greets,Kiste 


Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans  
Folgendes geschrieben:  
 
 
Everything has its limits. We have tried to make a remotecontrol for his two 
DAIKIN ACs. With PWM1, the case responds just fine withPMW2 not responding. The 
IR LEDs are controlled with an npn. (swapped) . Wealso tried the 16F877a, same 
result. On an AUDICITY we compared the IR resultson a TSOP , the IR leds 
(swapped!)… Both look the same. The frequencies of thePMW varied from 35 to 40. 
No effect.

So that's the end of the story for us and then just fiddlingwith one PWM, which 
we then switch via hardware. Unless ……. Any of you have adifferent 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  
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  
Folgendes

Re: [jallib] PWM2.

2022-04-05 Thread 'Oliver Seitz' via jallib

 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 loopelse   for 19 using teller 
loop      command_send_kamer(HALT_kamer[teller])   end loopend if
That way there's no "if" between the bytes.
Greets,Kiste 


Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans 
 Folgendes geschrieben:  
 
 
Everything has its limits. We have tried to make a remotecontrol for his two 
DAIKIN ACs. With PWM1, the case responds just fine withPMW2 not responding. The 
IR LEDs are controlled with an npn. (swapped) . Wealso tried the 16F877a, same 
result. On an AUDICITY we compared the IR resultson a TSOP , the IR leds 
(swapped!)… Both look the same. The frequencies of thePMW varied from 35 to 40. 
No effect.

So that's the end of the story for us and then just fiddlingwith one PWM, which 
we then switch via hardware. Unless ……. Any of you have adifferent 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  
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  
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

Re: [jallib] PWM2.

2022-04-04 Thread 'Oliver Seitz' via jallib

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
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
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.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com.

Re: [jallib] main loop-isr bidirectional control issue

2022-04-04 Thread 'Oliver Seitz' via jallib

Hi,
perfect 50.00% is not reachable, in no way. You will come nearest to that
number by starting the A/D conversion very early in the only ISR, doing the
jittering stuff after the conversion is startet. You will not get less jitter
by moving the conversion to the main program, as the main program is suspended
while the ISR is running. Remember that it doesn't matter at what time you're
reading the ADC, it only matters at what time you're starting the conversion.
Or, depending on the chip you're using: e.g. the 18f27k42 has an "Auto
Conversion Trigger", which can start a conversion on a selected event, like
timer rolling over or PWM output. No interrupt needs to be fired here to start
a conversion, so that is the way to get really, really close to "perfect 50%".
Greets,Kiste
Am Sonntag, 3. April 2022, 19:07:52 MESZ hat vsurducan
Folgendes geschrieben:

Hi all,I'm trying to have a fast bidirectional control between the ISR and
main loop without much success. Everything goes ok if in the main loop I use
the IE registers flags to stop or start things in the ISR. It seems to not work
ok if I try to control things in the main loop by reading registers which are
changed in the ISR.

In the ISR I'm toggling one bit on and off each time the tmr1 is rollowing.
This is generating a 50% duty cycle signal which I need to control two power
solid state switches A and B. The max toggling frequency is around 8KHz. There
is a delay of 2us between switching, both switches have less than 1us latency
between ON-OFF and OFF-ON states on the hardware side, the hardware is running
ok.

In the main loop I'm reading a voltage and a current controlled by the A and B
switches by reading first the ISR toggled bit and then initiating an ADC
measurement. Even the Tcy speed is enough (48MHz clock), sometimes the ADC
current and voltage values correspond to a wrong switch A and B position...and
this is annoying. I did not read the ADC in the ISR because I need a perfect
50% duty cycle and a lot of other things are happening in the ISR adding a
jitterbut perhaps this is the only way?

Any good ideas?

BTW, ( this is another story) during USB serial communication ( interrupt or no
interrupt driven) the other fast processes have to be stopped...and the GIE
flag can not be turned off for a short time in the main loop because connection
is lost...
thx,

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qu-brwAtngxuDb4euqLzH3aAbzCS%2BpunwaxYPN%2BjApkVA%40mail.gmail.com.

Re: [jallib] PWM2.

2022-04-04 Thread 'Oliver Seitz' via jallib

Am Sonntag, 3. April 2022, 16:10:38 MESZ hat hans
Folgendes geschrieben:

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com.

Re: [jallib] Help with PIC16F18313

2022-03-24 Thread 'Oliver Seitz' via jallib

Hello fsfo... and welcome to the mail list.
The microchip site states for this chip: "The Peripheral Pin Select (PPS)
functionality enables pin mapping..."
I would like to add: enables *and*requires* pin mapping. Some pins will not
work without mapping, even if standard locations are described in the
datasheet. General rule: don't rely on reset values, define everyting you need.
serial_software will work without pin mapping, but it has a lot of other
drawbacks. It's more like a last fallback option in most cases.
Greets,Kiste
Am Mittwoch, 23. März 2022, 20:16:48 MEZ hat fsfo...@gmail.com
Folgendes geschrieben:

Hi all,
I need help configuring the TX pin of this MCU; F18313.Can anyone help about
this?This pin is not a "stand-alone" function pin. Only RX is available and
ready to use.Am using an FTDI cable for RS232-5V. Tried to use serial_hardware
lib with no luck.Is it more suitable to use serial_software lib instead?
Thank you very much.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/e05c27d8-a032-4678-9ba8-41f84f5ae08dn%40googlegroups.com.

Re: [jallib] PWM serial audio transmission

2022-03-24 Thread 'Oliver Seitz' via jallib

Altijd met Rust...
It took me two weeks to think, code and test, and it will take more weeks for
proper documentation. So no need for you to hurry ;-)
Greets,Kiste
Am Mittwoch, 23. März 2022, 22:36:19 MEZ hat hans
Folgendes geschrieben:

Hello everyone,

My grandfather Hans has only one usable eye and has got an infection on it. We
have read your contributions and he is veryhappy with them. Sorry but he can't
work with it right now.

Regards Marieke

Op woensdag 23 maart 2022 om 17:22:42 UTC+1 schreef Kiste:

And here's the receiver, and a sample file. Mp3 does work at 1200baud, but you
shouldn't use less than 128kbit for encoding. At 80kbit I only got garbage.
Volume must be reasonably high, slowly turn louder until the error LED is
constantly off.
Don't send too much data back-to-back, have pauses of like 10 ms every second
(but keep the tone on all the time)
Don't assume error-free transmission, send data multiple times and check when
receiving.

Greets,Kiste

Am Sonntag, 20. März 2022, 13:22:14 MEZ hat 'Oliver Seitz' via jallib
Folgendes geschrieben:

Hi all,
here's my encoder. I looked for something similar to the 12F683 which Hans has
in stock, and found some 12F629, which should be quite compatible.

C1: minimum 1µF, no need to be polarizedR1:680R..1kC2: 100nFR2:1k..4k7D1=D2:
1N4148, 1N4001 or similar, silicon, not schottky
This gives a frequency which a line (AUX) audio input should be able to handle.
The receiver will be the same kind of chip, but it must have a comparator and a
reference voltage module. TMR0 will be used.

The transmitter will work on any 6 or 8 pin controller, as it doesn't use any
peripherals.

Greets,Kiste

--
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/189584036.471955.1647778917998%40mail.yahoo.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/2bdcd32b-101d-4d29-8397-ddbb370e4788n%40googlegroups.com.

Re: [jallib] PWM serial audio transmission

2022-02-27 Thread 'Oliver Seitz' via jallib

oice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usually had to try loading a program several times, slightly adjusting the 
volume, until you got lucky.
Greets,Kiste
Am Donnerstag, 24. Februar 2022, 19:56:01 MEZ hat Rob CJ  
Folgendes geschrieben:

Hi Hans,
If I understand you right the only thing you want to do is to record a signal 
or a sequence of signals on a casette player  that can be used to trigger 
something when the recording is played back right?
If my initial suggestion would work - which may work since I have the idea that 
my Apple II did more ore less the same thing - I could give it a try to do a 
proof of concept. 
I may have a the problem that I do not have a casette recorder but I could fake 
it by just connecting two PICs to see if that works. The final test could then 
be done by you.
Which PIC type are you using?
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: donderdag 24 februari 2022 17:07
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission Another piece of text:
So far I've done everything with MIDI. I used one midi channel for the actions 
with a general command type. Then 2 data, one for the device nr (16) and one 
for the command. (0-128)
This has worked well for years, but it does require a complete MIDI sound 
package.

Op donderdag 24 februari 2022 om 16:55:46 UTC+1 schreef hans:

Hey ,
I have tried a circuit with an MT8880 but the ICI has failed. I did hear the 16 
tones, but when I wanted to receive them, the chip gave up the ghost.
In theory I understand your suggestions well, but developing something like 
this is not easy for me. I'm just a LEGO builder.regardsHans

Op woensdag 23 februari 2022 om 19:30:37 UTC+1 schreef rob...@hotmail.com:

Hi Hans, Kiste,
You can still by DTMF decoders and I assume also DTMF encoders. Just look at 
for example Aliexpress and type DTMF.
But another suggestion. Many, many years ago I had built an Apple II and  I 
used cassette tapes to store and load games which was using tones generated by 
the Apple II itself using two tones, one for high, one for low and one as a 
lead-in tone (not sure in the lead-in tone was another tone) to synchronze the 
start of the recorded program. You would not need this lead-in tone in your case
So I think it may not be that complex:-) For recording on casette, generate 
this dual tone by the PIC  via PWM or maybe it is also sufficient to generate 
one tone in case of a 1 and no tone in case of a 0 but I think this will be 
less reliable.-) For playback, measure the length of the recorded PWM tone. If 
is is within a certain range you accept it as a one and in case of two tones 
the lower tone could be zero and the higher tone is one. 
As long as the tone frequency is not too high, I think this could work.
A more advanced solution would be to use a phase locked loop (PLL) but I am not 
sure if it will work. The PLL locks to the input signal so the voltage that 
controls the oscillator goes up and down to follow (lock on to) the input 
signal and this oscillator voltage signal could then be used by a comparator of 
the PIC to detect a high or low tone. You can also use the oscillator of the IC 
to generate the two tones by controlling the oscillator voltage by the PIC. A 
typical IC for that is the HEF4046. I have used this IC many many years ago 
too. This solution may be bit over the top since you only want a kind of 
trigger signal
But maybe the first solution is more doable.  Just give it a try.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: woensdag 23 februari 2022 09:58
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmission Hi Hans,
20 years ago I would have suggested using DTMF, but the decoder chips are rare 
these days...
PIC controllers include various peripherals which can be used to encode and 
decode DC-free signals (which, apart from the frequency below, say, 10kHz, is 
the requirement to be recorded as audio). On/off keying or frequency shift 
keying are the easiest, I think. Which chips are you going to use?
Greets,Kiste
Am Mittwoch, 23. Februar 2022, 09:15:43 MEZ hat hans  
Folgendes geschrieben:

Hello everyone,
I h

Re: [jallib] PWM serial audio transmission

2022-02-26 Thread 'Oliver Seitz' via jallib

e or 
two capacitors and three to five resistors (or two resistors and 
potentiometers). I'm just not sure yet what the best way would be.
To keep things simple, you would probably want to build a transmitter with 
manual controls, and a receiver which controls the actual "show". That way, you 
can connect both modules to the tape recorder, and really see what the output 
does from tape, while recording the show.
Greets,Kiste
Am Samstag, 26. Februar 2022, 09:04:29 MEZ hat hans  
Folgendes geschrieben:

Hey,
I get the impression that my question has not come across properly. I will use 
a regular stereo audio signal. One track contains music, speech and other 
normal sounds. The other track I want to use to record commands with which I 
can move servos, lights, etc. At first I thought to do this with DTMF but the 
MT8880 has died. Then I fiddled with the TCM3105, an old-fashioned modem chip, 
but that didn't work either. I then read something about PW application and 
hence my question.
I've been messing around with PICs for a long time, but because I'm purely 
mechanical by nature, I have to limit myself to what I called LEGO work. You 
make the stones and I make grateful use of them.
regards
Hans

Op zaterdag 26 februari 2022 om 07:41:46 UTC+1 schreef vasile:

Rob, obviously will work. :) But it would be weird to use a bunch of external 
analog electronics.BTW, with a PIC you can do a class D amplifier...  what 
perhaps Hans wanted is not far away: sampling and then digitizing via PWM.Other 
choices are possible as well.  Success on any variant you'll choose!

On Fri, Feb 25, 2022 at 7:58 PM Rob CJ  wrote:

Hi Kiste,
The reason that I think it still might work is because - what I mentioned 
previously - is that my Apple II I had built in the past also just worked with 
tones to store data (at that time only games).
I copied a pice of the casette interface of the Apple II schematic diagram I 
found on the internet. What you see is that with an opamp the audio is input 
signal is converted to a digital signal and the rest of the processing is done 
in software. There is no special chip on the board to process this data stream.
Also the data out is just a direct output of a flip-flop with some resistors to 
reduce the signal outpt but not even a low pass filter.
The variations in cassette speed will result in a variation of the tone so if I 
use a tone range to detect the right tone it might work.
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: vrijdag 25 februari 2022 16:20
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission 
Hi Vasile, 

In my time a birth was still followed by a placenta, nowadays an iphone comes 
after.

A long time ago I was infected by Wouter, Jal is even more persistent than 
corona, seehttp://www.voti.nl/setalk/n_index.html

 

regards Hans

Op vrijdag 25 februari 2022 om 13:34:14 UTC+1 schreef vasile:

Hi Hans. Congratulations for your young mind! There aren't many people 
programming at your age.You are a great example!

On Fri, Feb 25, 2022 at 10:16 AM hans  wrote:

Hi Vasiele and others.
I was born before the last world war and I suspect most of you after it. I hope 
it stays that way!!
Great, I can study today again. Thank you.

Op vrijdag 25 februari 2022 om 06:58:52 UTC+1 schreef vasile:

Kiste, not only the ZX81 but Sinclair Spectrum and most of it's clones did the 
same.The biggest problem was the tape speed variation (among the volume 
variation which was corrected in romanian clones -and we had more than any, I 
recall 5 different types).

Hans, on the actual PIC18 series on which JAL works ( presuming you will do 
with JAL) you might have some sampling speed issues. You need at least 7.5us 
for an ADC sample and according to Nyquist theorem you need not 2x ( which is 
pure theoretical) but at least 4x faster sampling than maximum frequency you 
are recording.After your AD is sampled, the PWM is not an issue, but you might 
experience a small delay between real recorded speech and the PWM filtered 
one.If you plan to add voice for your puppet, then limiting to 4KHz may be a 
good choice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usua

Re: [jallib] PWM serial audio transmission

2022-02-26 Thread 'Oliver Seitz' via jallib

ervos, lights, etc. At first I thought to do this with DTMF but the 
MT8880 has died. Then I fiddled with the TCM3105, an old-fashioned modem chip, 
but that didn't work either. I then read something about PW application and 
hence my question.
I've been messing around with PICs for a long time, but because I'm purely 
mechanical by nature, I have to limit myself to what I called LEGO work. You 
make the stones and I make grateful use of them.
regards
Hans

Op zaterdag 26 februari 2022 om 07:41:46 UTC+1 schreef vasile:

Rob, obviously will work. :) But it would be weird to use a bunch of external 
analog electronics.BTW, with a PIC you can do a class D amplifier...  what 
perhaps Hans wanted is not far away: sampling and then digitizing via PWM.Other 
choices are possible as well.  Success on any variant you'll choose!

On Fri, Feb 25, 2022 at 7:58 PM Rob CJ  wrote:

Hi Kiste,
The reason that I think it still might work is because - what I mentioned 
previously - is that my Apple II I had built in the past also just worked with 
tones to store data (at that time only games).
I copied a pice of the casette interface of the Apple II schematic diagram I 
found on the internet. What you see is that with an opamp the audio is input 
signal is converted to a digital signal and the rest of the processing is done 
in software. There is no special chip on the board to process this data stream.
Also the data out is just a direct output of a flip-flop with some resistors to 
reduce the signal outpt but not even a low pass filter.
The variations in cassette speed will result in a variation of the tone so if I 
use a tone range to detect the right tone it might work.
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: vrijdag 25 februari 2022 16:20
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission 
Hi Vasile, 

In my time a birth was still followed by a placenta, nowadays an iphone comes 
after.

A long time ago I was infected by Wouter, Jal is even more persistent than 
corona, seehttp://www.voti.nl/setalk/n_index.html

 

regards Hans

Op vrijdag 25 februari 2022 om 13:34:14 UTC+1 schreef vasile:

Hi Hans. Congratulations for your young mind! There aren't many people 
programming at your age.You are a great example!

On Fri, Feb 25, 2022 at 10:16 AM hans  wrote:

Hi Vasiele and others.
I was born before the last world war and I suspect most of you after it. I hope 
it stays that way!!
Great, I can study today again. Thank you.

Op vrijdag 25 februari 2022 om 06:58:52 UTC+1 schreef vasile:

Kiste, not only the ZX81 but Sinclair Spectrum and most of it's clones did the 
same.The biggest problem was the tape speed variation (among the volume 
variation which was corrected in romanian clones -and we had more than any, I 
recall 5 different types).

Hans, on the actual PIC18 series on which JAL works ( presuming you will do 
with JAL) you might have some sampling speed issues. You need at least 7.5us 
for an ADC sample and according to Nyquist theorem you need not 2x ( which is 
pure theoretical) but at least 4x faster sampling than maximum frequency you 
are recording.After your AD is sampled, the PWM is not an issue, but you might 
experience a small delay between real recorded speech and the PWM filtered 
one.If you plan to add voice for your puppet, then limiting to 4KHz may be a 
good choice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usually had to try loading a program several times, slightly adjusting the 
volume, until you got lucky.
Greets,Kiste
Am Donnerstag, 24. Februar 2022, 19:56:01 MEZ hat Rob CJ  
Folgendes geschrieben:

Hi Hans,
If I understand you right the only thing you want to do is to record a signal 
or a sequence of signals on a casette player  that can be used to trigger 
something when the recording is played back right?
If my initial suggestion would work - which may work since I have the idea that 
my Apple II did more ore less the same thing - I could give it a try to do a 
proof of concept. 
I may have a the problem that I do not have a casette recorder but I could fake 
it by just connecting two PICs to see if that works. The final test could then 
be done by you.
Whic

Re: [jallib] PWM serial audio transmission

2022-02-26 Thread 'Oliver Seitz' via jallib

m I 
found on the internet. What you see is that with an opamp the audio is input 
signal is converted to a digital signal and the rest of the processing is done 
in software. There is no special chip on the board to process this data stream.
Also the data out is just a direct output of a flip-flop with some resistors to 
reduce the signal outpt but not even a low pass filter.
The variations in cassette speed will result in a variation of the tone so if I 
use a tone range to detect the right tone it might work.
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: vrijdag 25 februari 2022 16:20
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission 
Hi Vasile, 

In my time a birth was still followed by a placenta, nowadays an iphone comes 
after.

A long time ago I was infected by Wouter, Jal is even more persistent than 
corona, seehttp://www.voti.nl/setalk/n_index.html

 

regards Hans

Op vrijdag 25 februari 2022 om 13:34:14 UTC+1 schreef vasile:

Hi Hans. Congratulations for your young mind! There aren't many people 
programming at your age.You are a great example!

On Fri, Feb 25, 2022 at 10:16 AM hans  wrote:

Hi Vasiele and others.
I was born before the last world war and I suspect most of you after it. I hope 
it stays that way!!
Great, I can study today again. Thank you.

Op vrijdag 25 februari 2022 om 06:58:52 UTC+1 schreef vasile:

Kiste, not only the ZX81 but Sinclair Spectrum and most of it's clones did the 
same.The biggest problem was the tape speed variation (among the volume 
variation which was corrected in romanian clones -and we had more than any, I 
recall 5 different types).

Hans, on the actual PIC18 series on which JAL works ( presuming you will do 
with JAL) you might have some sampling speed issues. You need at least 7.5us 
for an ADC sample and according to Nyquist theorem you need not 2x ( which is 
pure theoretical) but at least 4x faster sampling than maximum frequency you 
are recording.After your AD is sampled, the PWM is not an issue, but you might 
experience a small delay between real recorded speech and the PWM filtered 
one.If you plan to add voice for your puppet, then limiting to 4KHz may be a 
good choice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usually had to try loading a program several times, slightly adjusting the 
volume, until you got lucky.
Greets,Kiste
Am Donnerstag, 24. Februar 2022, 19:56:01 MEZ hat Rob CJ  
Folgendes geschrieben:

Hi Hans,
If I understand you right the only thing you want to do is to record a signal 
or a sequence of signals on a casette player  that can be used to trigger 
something when the recording is played back right?
If my initial suggestion would work - which may work since I have the idea that 
my Apple II did more ore less the same thing - I could give it a try to do a 
proof of concept. 
I may have a the problem that I do not have a casette recorder but I could fake 
it by just connecting two PICs to see if that works. The final test could then 
be done by you.
Which PIC type are you using?
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: donderdag 24 februari 2022 17:07
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission Another piece of text:
So far I've done everything with MIDI. I used one midi channel for the actions 
with a general command type. Then 2 data, one for the device nr (16) and one 
for the command. (0-128)
This has worked well for years, but it does require a complete MIDI sound 
package.

Op donderdag 24 februari 2022 om 16:55:46 UTC+1 schreef hans:

Hey ,
I have tried a circuit with an MT8880 but the ICI has failed. I did hear the 16 
tones, but when I wanted to receive them, the chip gave up the ghost.
In theory I understand your suggestions well, but developing something like 
this is not easy for me. I'm just a LEGO builder.regardsHans

Op woensdag 23 februari 2022 om 19:30:37 UTC+1 schreef rob...@hotmail.com:

Hi Hans, Kiste,
You can still by DTMF decoders and I assume also DTMF encoders. Just look at 
for example Aliexpress and type DTMF.
But another suggestion. Many, many years ago I had built an Apple II and  I 
used cassette tapes to stor

Re: [jallib] PWM serial audio transmission

2022-02-26 Thread 'Oliver Seitz' via jallib

e had more than any, I 
recall 5 different types).

Hans, on the actual PIC18 series on which JAL works ( presuming you will do 
with JAL) you might have some sampling speed issues. You need at least 7.5us 
for an ADC sample and according to Nyquist theorem you need not 2x ( which is 
pure theoretical) but at least 4x faster sampling than maximum frequency you 
are recording.After your AD is sampled, the PWM is not an issue, but you might 
experience a small delay between real recorded speech and the PWM filtered 
one.If you plan to add voice for your puppet, then limiting to 4KHz may be a 
good choice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usually had to try loading a program several times, slightly adjusting the 
volume, until you got lucky.
Greets,Kiste
Am Donnerstag, 24. Februar 2022, 19:56:01 MEZ hat Rob CJ  
Folgendes geschrieben:

Hi Hans,
If I understand you right the only thing you want to do is to record a signal 
or a sequence of signals on a casette player  that can be used to trigger 
something when the recording is played back right?
If my initial suggestion would work - which may work since I have the idea that 
my Apple II did more ore less the same thing - I could give it a try to do a 
proof of concept. 
I may have a the problem that I do not have a casette recorder but I could fake 
it by just connecting two PICs to see if that works. The final test could then 
be done by you.
Which PIC type are you using?
Kind regards,
Rob


Van:jal...@googlegroups.com  namens hans 

Verzonden: donderdag 24 februari 2022 17:07
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission Another piece of text:
So far I've done everything with MIDI. I used one midi channel for the actions 
with a general command type. Then 2 data, one for the device nr (16) and one 
for the command. (0-128)
This has worked well for years, but it does require a complete MIDI sound 
package.

Op donderdag 24 februari 2022 om 16:55:46 UTC+1 schreef hans:

Hey ,
I have tried a circuit with an MT8880 but the ICI has failed. I did hear the 16 
tones, but when I wanted to receive them, the chip gave up the ghost.
In theory I understand your suggestions well, but developing something like 
this is not easy for me. I'm just a LEGO builder.regardsHans

Op woensdag 23 februari 2022 om 19:30:37 UTC+1 schreef rob...@hotmail.com:

Hi Hans, Kiste,
You can still by DTMF decoders and I assume also DTMF encoders. Just look at 
for example Aliexpress and type DTMF.
But another suggestion. Many, many years ago I had built an Apple II and  I 
used cassette tapes to store and load games which was using tones generated by 
the Apple II itself using two tones, one for high, one for low and one as a 
lead-in tone (not sure in the lead-in tone was another tone) to synchronze the 
start of the recorded program. You would not need this lead-in tone in your case
So I think it may not be that complex:-) For recording on casette, generate 
this dual tone by the PIC  via PWM or maybe it is also sufficient to generate 
one tone in case of a 1 and no tone in case of a 0 but I think this will be 
less reliable.-) For playback, measure the length of the recorded PWM tone. If 
is is within a certain range you accept it as a one and in case of two tones 
the lower tone could be zero and the higher tone is one. 
As long as the tone frequency is not too high, I think this could work.
A more advanced solution would be to use a phase locked loop (PLL) but I am not 
sure if it will work. The PLL locks to the input signal so the voltage that 
controls the oscillator goes up and down to follow (lock on to) the input 
signal and this oscillator voltage signal could then be used by a comparator of 
the PIC to detect a high or low tone. You can also use the oscillator of the IC 
to generate the two tones by controlling the oscillator voltage by the PIC. A 
typical IC for that is the HEF4046. I have used this IC many many years ago 
too. This solution may be bit over the top since you only want a kind of 
trigger signal
But maybe the first solution is more doable.  Just give it a try.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: woensdag 23 februari 2022 09:5

Re: [jallib] PWM serial audio transmission

2022-02-26 Thread 'Oliver Seitz' via jallib

 Hi Hans,
that's about what I thought. I'm quite sure it can be done with a pic, one or 
two capacitors and three to five resistors (or two resistors and 
potentiometers). I'm just not sure yet what the best way would be.
To keep things simple, you would probably want to build a transmitter with 
manual controls, and a receiver which controls the actual "show". That way, you 
can connect both modules to the tape recorder, and really see what the output 
does from tape, while recording the show.
Greets,Kiste
Am Samstag, 26. Februar 2022, 09:04:29 MEZ hat hans 
 Folgendes geschrieben:  
 
 Hey,
I get the impression that my question has not come across properly. I will use 
a regular stereo audio signal. One track contains music, speech and other 
normal sounds. The other track I want to use to record commands with which I 
can move servos, lights, etc. At first I thought to do this with DTMF but the 
MT8880 has died. Then I fiddled with the TCM3105, an old-fashioned modem chip, 
but that didn't work either. I then read something about PW application and 
hence my question.
I've been messing around with PICs for a long time, but because I'm purely 
mechanical by nature, I have to limit myself to what I called LEGO work. You 
make the stones and I make grateful use of them.
regards
Hans

Op zaterdag 26 februari 2022 om 07:41:46 UTC+1 schreef vasile:

Rob, obviously will work. :) But it would be weird to use a bunch of external 
analog electronics.BTW, with a PIC you can do a class D amplifier...  what 
perhaps Hans wanted is not far away: sampling and then digitizing via PWM.Other 
choices are possible as well.  Success on any variant you'll choose!

On Fri, Feb 25, 2022 at 7:58 PM Rob CJ  wrote:

Hi Kiste,
The reason that I think it still might work is because - what I mentioned 
previously - is that my Apple II I had built in the past also just worked with 
tones to store data (at that time only games).
I copied a pice of the casette interface of the Apple II schematic diagram I 
found on the internet. What you see is that with an opamp the audio is input 
signal is converted to a digital signal and the rest of the processing is done 
in software. There is no special chip on the board to process this data stream.
Also the data out is just a direct output of a flip-flop with some resistors to 
reduce the signal outpt but not even a low pass filter.
The variations in cassette speed will result in a variation of the tone so if I 
use a tone range to detect the right tone it might work.
Kind regards,
Rob


Van: jal...@googlegroups.com  namens hans 

Verzonden: vrijdag 25 februari 2022 16:20
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission 
Hi Vasile, 

In my time a birth was still followed by a placenta, nowadays an iphone comes 
after.

A long time ago I was infected by Wouter, Jal is even more persistent than 
corona, see http://www.voti.nl/setalk/n_index.html

 

regards Hans

Op vrijdag 25 februari 2022 om 13:34:14 UTC+1 schreef vasile:

Hi Hans. Congratulations for your young mind! There aren't many people 
programming at your age.You are a great example!

On Fri, Feb 25, 2022 at 10:16 AM hans  wrote:

Hi Vasiele and others.
I was born before the last world war and I suspect most of you after it. I hope 
it stays that way!!
Great, I can study today again. Thank you.

Op vrijdag 25 februari 2022 om 06:58:52 UTC+1 schreef vasile:

Kiste, not only the ZX81 but Sinclair Spectrum and most of it's clones did the 
same.The biggest problem was the tape speed variation (among the volume 
variation which was corrected in romanian clones -and we had more than any, I 
recall 5 different types).

Hans, on the actual PIC18 series on which JAL works ( presuming you will do 
with JAL) you might have some sampling speed issues. You need at least 7.5us 
for an ADC sample and according to Nyquist theorem you need not 2x ( which is 
pure theoretical) but at least 4x faster sampling than maximum frequency you 
are recording.After your AD is sampled, the PWM is not an issue, but you might 
experience a small delay between real recorded speech and the PWM filtered 
one.If you plan to add voice for your puppet, then limiting to 4KHz may be a 
good choice.
best wishes, 
hopefully not WW III, but in pace for playing nice...

On Thu, Feb 24, 2022 at 10:38 PM 'Oliver Seitz' via jallib 
 wrote:

Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burs

Re: [jallib] PWM serial audio transmission

2022-02-24 Thread 'Oliver Seitz' via jallib

 Hi Rob,
connecting two PICs is not like an audio recording. Better connect the pic to 
your soundcard to record and then playback, that way you'll get something 
similar to a tape recorder.
The difficulties when using audio equipment are (at least):
- only alternating current is transmitted- the volume is never exactly the 
same- the frequency range is limited to like 100Hz-10kHz- the line level 
voltage is less than 1V
 Reading should be possible by most PICs which have comparators. Only a 
resistor is needed, then you can detect zero crossings. 
The Sinclair ZX81 used audio equipment as storage. A burst of three 
oscillations coded a zero, five coded a one. The output was low-pass filtered. 
You usually had to try loading a program several times, slightly adjusting the 
volume, until you got lucky.
Greets,Kiste
Am Donnerstag, 24. Februar 2022, 19:56:01 MEZ hat Rob CJ 
 Folgendes geschrieben:  
 
 Hi Hans,
If I understand you right the only thing you want to do is to record a signal 
or a sequence of signals on a casette player  that can be used to trigger 
something when the recording is played back right?
If my initial suggestion would work - which may work since I have the idea that 
my Apple II did more ore less the same thing - I could give it a try to do a 
proof of concept. 
I may have a the problem that I do not have a casette recorder but I could fake 
it by just connecting two PICs to see if that works. The final test could then 
be done by you.
Which PIC type are you using?
Kind regards,
Rob


Van: jallib@googlegroups.com  namens hans 

Verzonden: donderdag 24 februari 2022 17:07
Aan: jallib 
Onderwerp: Re: [jallib] PWM serial audio transmission Another piece of text:
So far I've done everything with MIDI. I used one midi channel for the actions 
with a general command type. Then 2 data, one for the device nr (16) and one 
for the command. (0-128)
This has worked well for years, but it does require a complete MIDI sound 
package.

Op donderdag 24 februari 2022 om 16:55:46 UTC+1 schreef hans:

Hey ,
I have tried a circuit with an MT8880 but the ICI has failed. I did hear the 16 
tones, but when I wanted to receive them, the chip gave up the ghost.
In theory I understand your suggestions well, but developing something like 
this is not easy for me. I'm just a LEGO builder.regardsHans

Op woensdag 23 februari 2022 om 19:30:37 UTC+1 schreefrob...@hotmail.com:

Hi Hans, Kiste,
You can still by DTMF decoders and I assume also DTMF encoders. Just look at 
for example Aliexpress and type DTMF.
But another suggestion. Many, many years ago I had built an Apple II and  I 
used cassette tapes to store and load games which was using tones generated by 
the Apple II itself using two tones, one for high, one for low and one as a 
lead-in tone (not sure in the lead-in tone was another tone) to synchronze the 
start of the recorded program. You would not need this lead-in tone in your case
So I think it may not be that complex:-) For recording on casette, generate 
this dual tone by the PIC  via PWM or maybe it is also sufficient to generate 
one tone in case of a 1 and no tone in case of a 0 but I think this will be 
less reliable.-) For playback, measure the length of the recorded PWM tone. If 
is is within a certain range you accept it as a one and in case of two tones 
the lower tone could be zero and the higher tone is one. 
As long as the tone frequency is not too high, I think this could work.
A more advanced solution would be to use a phase locked loop (PLL) but I am not 
sure if it will work. The PLL locks to the input signal so the voltage that 
controls the oscillator goes up and down to follow (lock on to) the input 
signal and this oscillator voltage signal could then be used by a comparator of 
the PIC to detect a high or low tone. You can also use the oscillator of the IC 
to generate the two tones by controlling the oscillator voltage by the PIC. A 
typical IC for that is the HEF4046. I have used this IC many many years ago 
too. This solution may be bit over the top since you only want a kind of 
trigger signal
But maybe the first solution is more doable.  Just give it a try.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib 
Verzonden: woensdag 23 februari 2022 09:58
Aan: jal...@googlegroups.com 
Onderwerp: Re: [jallib] PWM serial audio transmission Hi Hans,
20 years ago I would have suggested using DTMF, but the decoder chips are rare 
these days...
PIC controllers include various peripherals which can be used to encode and 
decode DC-free signals (which, apart from the frequency below, say, 10kHz, is 
the requirement to be recorded as audio). On/off keying or frequency shift 
keying are the easiest, I think. Which chips are you going to use?
Greets,Kiste
Am Mittwoch, 23. Februar 2022, 09:15:43 MEZ hat hans  
Folgendes geschrieben:

Hello everyone,
I have been trying for a long time to place a serial signal on one track of an 
audio recording which I can read afterwards. To make all

Re: [jallib] PWM serial audio transmission

2022-02-23 Thread 'Oliver Seitz' via jallib

Hi Hans,
20 years ago I would have suggested using DTMF, but the decoder chips are rare
these days...
PIC controllers include various peripherals which can be used to encode and
decode DC-free signals (which, apart from the frequency below, say, 10kHz, is
the requirement to be recorded as audio). On/off keying or frequency shift
keying are the easiest, I think. Which chips are you going to use?
Greets,Kiste
Am Mittwoch, 23. Februar 2022, 09:15:43 MEZ hat hans
Folgendes geschrieben:

Hello everyone,
I have been trying for a long time to place a serial signal on one track of an
audio recording which I can read afterwards. To make all kinds of things happen
at the same time as the audio is played. I have now tried to do this with the
old modem system ( TCM3105) but it failed hopelessly. I read that there are
also systems to do this using PWM. Does anyone have an idea?
regardsHans

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/773ca37b-9bed-4349-a8eb-32a5d8973df6n%40googlegroups.com.

Re: [jallib] Can you call a procedure from a main program and an interrupt?

2022-02-20 Thread 'Oliver Seitz' via jallib

Hi Rob,
it is possible to call a procedure from both the main program and from an
interrupt alternately, but I would try to avoid that, it's... I'd call it
dangerous.
As jal is not reentrant, you have to make absolutely sure, that no single part
of any procedure is running twice in any case. (The only exception I know of
are the multiplication/division functions which are safe to be called from an
interrupt while running in the main program, but those are not seen as
functions to the user anyway) That means, that if you use e.g. a print
procedure inside the interrupt, you also have to disable interrupts each time
you're using a similar print procedure in the main program. All decimal print
procedures use the same background code, so in this sense, they're "the same
procedure" and need to be surveyed not to run from both the main program and
the interrupt at the same time.
And, you should compile with --no-variable-reuse, as the compiler is probably
not aware of procedures being called from an interrupt.
Can be that you obeyed that rule by disabling interrupts when using I2C in the
main program. But then, there's hardware involved. You need to make sure that
the hardware is idle and in a reset, initialized state each time before
enabling interrupts. I'm not so familiar with the I2C peripheral to decide if
that's a problem. And, also all devices on the I2C bus need to be reset and
initialized each time the interrupt is enabled.
I do prefer handing over the alarm to the main program via volatile flag bit.
Greets,Kiste
Am Samstag, 19. Februar 2022, 09:58:53 MEZ hat rob...@hotmail.com
Folgendes geschrieben:

Hello all,
Some time ago I made a library for the clock IC DS3231. This library is part of
Jallib release 1.7.0.
This IC has an I2C interface and is capable of handling two alarms. When an
alarm is activated an interrupt is generated.
Reading the alarm flag from the IC also uses - of course- the I2C interface but
the I2C interface is also used by the main program.
I thought that if I would disable all interrupts when calling the I2C routines
from the main program and only enable it while not used by the main program
that I could call the same I2C routines from the interrupt routine and so be
able to read the alarm flag from the IC to see if alarm 1 or alarm 2 was
activated.
Unfortunately this did not work.
I thought that when an interrupt is called some info is saved and after the
interrupt restored but I also thought that I could then call any routine from
the interrupt as long that I am certain that no I2C transfer was active (which
should be since the interrupt is disabled when the main program is using the
I2C routines).
Any ideas why this does not work? Am I missing something?
What the current sample program does is just setting a global flag in the
interrupt routine and the main program polls this flag and then reads the alarm
flag of the IC via I2C but this undermines a bit the use of the interrupt.
Thanks.
Kind regards,
Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/ff12f63c-0d1d-4897-8ca4-511869ab68c0n%40googlegroups.com.

AW: Re: [jallib] Re: Not able to use both sw IIC and hw IIC due to procedures having the same name.

2022-02-13 Thread 'Oliver Seitz' via jallib

Different speeds?Different pullup values?Long lines?
Hardware as slave, Software as master?Personal preference?

Gesendet von Yahoo Mail auf Android 
 
  Am Mo., Feb. 14, 2022 at 8:21 schrieb vsurducan:   Hi 
all,Would be interesting to find why it uses both types of i2c. From pure hw 
perspective, once you have an i2c bus, you can expand it as much you want by 
changing it's base address with a buffer/expander. Perhaps the user did not 
knew this.
On Sun 13 Feb 2022, 11:47 PM Matthew Schinkel https://groups.google.com/d/msgid/jallib/1525e85a-c620-474a-8423-24751c38359cn%40googlegroups.com.



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4quBQ6zYMa6X7WjsXvT1LJAbs76wS83fy_gwCE7n2P6AGQ%40mail.gmail.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/836744923.641527.1644823674183%40mail.yahoo.com.

Re: [jallib] Not able to use both sw IIC and hw IIC due to procedures having the same name.

2022-02-13 Thread 'Oliver Seitz' via jallib

Hi Rob,
I think it's a good idea to change the names in both libs.

If it really is a problem for existing programs that are to hard to change
accordingly, we could provide meta-libraries like i2c_legacy_software which do
nothing more than include the new libraries and define aliases for the old
names.
I wouldn't need those legacy libraries, I have an editor that has find/replace,
so no big deal to modify my programs.
Greets,Kiste

Am Sonntag, 13. Februar 2022, 19:12:31 MEZ hat rob...@hotmail.com
Folgendes geschrieben:

Hi all,
I got an e-mail from a Jallib user who wants to use both IIC software and IIC
hardware. This is, however, not possible because both libraries use the same
names in procedures and functions.
For USART the convention 'sw', 'hw' and 'hw2' is used in the procedures.
The problem is easily fixed by adding _sw_ to the software iic procedures. I
did this for this Jallib member and gave him a modified version of
i2c_software. But when changing this and adding this to Jallib then all sample
files that use i2c_software should be changed and members that have made
projects with this library should modify their programs too.
Next to that, for consistency, the i2c_hardware should also get the addition
(in procedure names) _hw_.
What do you think? Should this be changed and if so, how?
Thanks.
Kind regards,

Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/474cfa3b-7eac-4d43-821e-d77fd74916fan%40googlegroups.com.

Re: [jallib] Retouched JAL Logo

2022-02-04 Thread 'Oliver Seitz' via jallib

Hi Rob,
I like it. Does it exist in vector format?
I wouldn't need it, but in case it is drawn in a vector format, the "prototype"
should stay in vector format.

Greets,Kiste

Am Samstag, 5. Februar 2022, 07:57:00 MEZ hat rob...@hotmail.com
Folgendes geschrieben:

Hello all,
If I remember well the daughter of Vasile once made the JAL Logo.
Since my daughter also has some drawing skills, I asked her if she could
retouch the current logo. Keep it as it is but make it a bit more clear. I also
asked her to make one with a transparent background.
In the attached zip file you find some examples.
Are you OK using this Logo? Matt is working on updating the website and I
thought this was a good moment to update the Logo too.
Let me know what you think.
Thanks
Kind regards,
Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/19ce1d30-04e3-4c34-a8b8-e6f219aad8bdn%40googlegroups.com.

Re: [jallib] Re: PWM Library using a PCA9695?

2022-01-17 Thread 'Oliver Seitz' via jallib

 I'm a theatre and show technitian, you're absolutely right that movement can 
be to fast ;-)
What I meant is only, that it is not the servo's job to limit the speed. The 
program should limit the speed like yours does, or a library can have a 
slow-down adjustment.
I did not even look at the servo lib(s) yet, but I have an idea why Matt did 
initialize the servos. When you're starting to transmit data to the servos, you 
need to give them a position. A probably better, but more complicated way would 
be just NOT to transmit anything to a servo which has not been assigned a 
position yet. That way, the servo would usually just do not move, until it 
receives the first position data.
Greets,Kiste
Am Montag, 17. Januar 2022, 19:25:56 MEZ hat hans 
 Folgendes geschrieben:  
 
 Thank you DOOS, once I have a working program that does what I want for me, I 
usually don't have the courage or the will to optimize it further. I will 
definitely apply your recommendation.
That Matt's LIB contains the commands of the basic servo positions is difficult 
as I mentioned.
You can disagree about the speed of the servos. When I use them in my dolls 
without speed reduction, the movements are much too wooden.

Op maandag 17 januari 2022 om 13:49:51 UTC+1 schreef Kiste:

 Hi hans,
heel mooie video's :-)
Your program fragment can be optimized a little, with no loss of function but 
saving code and data space and also execution time (which is not so important, 
as the purpose is to delay...)
tell=0for 4 loop  [...]  servo_move((old_pos[tell] + 1),tell+1)  [...]  
tell=tell+1
end loop
This can be done like
--tell=0for 4 using tell loop  [...]  servo_move((old_pos[tell] + 1),tell+1)  
[...]--  tell=tell+1end loop
This way an invisible loop variable is omitted. In that special case, there's 
another way to improve:
tell=0for 4 loop  tell=tell+1  [...]  servo_move((old_pos[tell] + 1),tell)  
[...]end loop

Now, "tell" is always one count ahead. In each servo_move call, you're saving 
the "+1", which takes code and possibly data space. So, why didn't I just state 
"tell=1" and leave the increment at the bottom of the loop? Very curious PIC 
assembler details... Setting a variable to zero is cheaper than setting to any 
other number. The increment is done four times anyway, so there's no extra cost 
to move it. What about combining both optimizations, like "for 4 using counter 
loop; tell=counter+1 ;[...]"? Terrible. Incrementing a byte "tell=tell+1" is a 
single assembler instruction. "tell=counter+1" is quite a complex calculation 
which takes code and data space.


The purpose of a servo is to move to a certain angle as fast as possible. How 
fast, depends on the power of the servo and to the mass (or rotational inertia) 
connected to it. It is not the responsibility of a library to slow the movement 
down, although I think such functions wouldn't hurt as an extra.
Unfortunately, the communication to the servo is one-way, so, when switching 
on, the controller can not know in which position the servos are. Thus, IMHO, a 
library shoudn't move to any "initialisation position" on it's own. It's the 
responsibility of the application program to move to a starting position. There 
may be a certain procedure that works from all possible starting positions, 
like e.g.
1. bend elbows2. wait for elbows are bent3. move shoulders outward4. ...
That example is clearly wrong for the linked video, as when shoulders are up 
and inward, bending elbows might have the hands collide. But there might be 
another order, which works from any starting position.


Greets,Kiste
(Jij kunt me ook "Doos" noemen :-)


Am Montag, 17. Januar 2022, 12:43:56 MEZ hat hans  
Folgendes geschrieben:  
 
 Here is a program part which i use for reduce 4 servo's speed 
:-- basic 
position all servo's
servo_move(124,1)
servo_move(124,2)
servo_move(129,3)
servo_move(121,4)

 ---
var byte old_pos[4] = {124,124,129,121} -- start up beiden in centrum
var byte new_pos[4]
var byte tell =0
-

---

procedure set_servo_pack (byte in x) is
var byte flag = 0

  var byte tell = 0
  while flag < 4 loop
    flag = 0
    tell = 0

   for 4 loop
       if old_pos[tell] < new_pos[tell] then
          servo_move((old_pos[tell] + 1),tell+1)
          old_pos[tell] = old_pos[tell] + 1
          delay_1mS(x)
       end if

       if old_pos[tell] > new_pos[tell] then
          servo_move((old_pos[tell] - 1),tell+1)
          old_pos[tell] = old_pos[tell] - 1
          delay_1mS(x)
       end if

      if old_pos[tell] == new_pos[tell] then
         flag = flag + 1
      end if
        tell = tell +1

   end loop
end loop
end procedure

Op zondag 16 januari 2022 om 19:40:07 UTC+1 schreef vasile:

Impressive! Congrats Hans!Perhaps using an encoder to "see" the servo

Re: [jallib] Re: PWM Library using a PCA9695?

2022-01-17 Thread 'Oliver Seitz' via jallib

 Hi hans,
heel mooie video's :-)
Your program fragment can be optimized a little, with no loss of function but 
saving code and data space and also execution time (which is not so important, 
as the purpose is to delay...)
tell=0for 4 loop  [...]  servo_move((old_pos[tell] + 1),tell+1)  [...]  
tell=tell+1
end loop
This can be done like
--tell=0for 4 using tell loop  [...]  servo_move((old_pos[tell] + 1),tell+1)  
[...]--  tell=tell+1end loop
This way an invisible loop variable is omitted. In that special case, there's 
another way to improve:
tell=0for 4 loop  tell=tell+1  [...]  servo_move((old_pos[tell] + 1),tell)  
[...]end loop

Now, "tell" is always one count ahead. In each servo_move call, you're saving 
the "+1", which takes code and possibly data space. So, why didn't I just state 
"tell=1" and leave the increment at the bottom of the loop? Very curious PIC 
assembler details... Setting a variable to zero is cheaper than setting to any 
other number. The increment is done four times anyway, so there's no extra cost 
to move it. What about combining both optimizations, like "for 4 using counter 
loop; tell=counter+1 ;[...]"? Terrible. Incrementing a byte "tell=tell+1" is a 
single assembler instruction. "tell=counter+1" is quite a complex calculation 
which takes code and data space.


The purpose of a servo is to move to a certain angle as fast as possible. How 
fast, depends on the power of the servo and to the mass (or rotational inertia) 
connected to it. It is not the responsibility of a library to slow the movement 
down, although I think such functions wouldn't hurt as an extra.
Unfortunately, the communication to the servo is one-way, so, when switching 
on, the controller can not know in which position the servos are. Thus, IMHO, a 
library shoudn't move to any "initialisation position" on it's own. It's the 
responsibility of the application program to move to a starting position. There 
may be a certain procedure that works from all possible starting positions, 
like e.g.
1. bend elbows2. wait for elbows are bent3. move shoulders outward4. ...
That example is clearly wrong for the linked video, as when shoulders are up 
and inward, bending elbows might have the hands collide. But there might be 
another order, which works from any starting position.


Greets,Kiste
(Jij kunt me ook "Doos" noemen :-)


Am Montag, 17. Januar 2022, 12:43:56 MEZ hat hans 
 Folgendes geschrieben:  
 
 Here is a program part which i use for reduce 4 servo's speed 
:-- basic 
position all servo's
servo_move(124,1)
servo_move(124,2)
servo_move(129,3)
servo_move(121,4)

 ---
var byte old_pos[4] = {124,124,129,121} -- start up beiden in centrum
var byte new_pos[4]
var byte tell =0
-

---

procedure set_servo_pack (byte in x) is
var byte flag = 0

  var byte tell = 0
  while flag < 4 loop
    flag = 0
    tell = 0

   for 4 loop
       if old_pos[tell] < new_pos[tell] then
          servo_move((old_pos[tell] + 1),tell+1)
          old_pos[tell] = old_pos[tell] + 1
          delay_1mS(x)
       end if

       if old_pos[tell] > new_pos[tell] then
          servo_move((old_pos[tell] - 1),tell+1)
          old_pos[tell] = old_pos[tell] - 1
          delay_1mS(x)
       end if

      if old_pos[tell] == new_pos[tell] then
         flag = flag + 1
      end if
        tell = tell +1

   end loop
end loop
end procedure

Op zondag 16 januari 2022 om 19:40:07 UTC+1 schreef vasile:

Impressive! Congrats Hans!Perhaps using an encoder to "see" the servo position? 
 The less expensive it's a japanese amazing potmeter which can be rolled over ( 
360 degree movement, 270 degree cursor). I've used such devices, no failure... 

On Sun, Jan 16, 2022 at 4:05 PM hans  wrote:


I've been using Matt's servo lib for years. The maximumnumber of servos in one 
project was 12.( see https://youtu.be/ujfMYD5zXNU)

 

  The only problem Ihad with the lib was that it resets the servos itself int a 
fixed basicposition and that can conflict with the initial position in the 
program. Sowhen you start up, you get a different base position for a while and 
that cancause damage.

A second thing for me is the speed of movement from oneposition to another. I 
now do this in a procedure within the program.

If this sometimes doesn't work out, I'll take another pic,even the small 12F683 
works perfectly.

regards

Hans

Op zondag 16 januari 2022 om 10:35:02 UTC+1 schreef rob...@hotmail.com:

Hello all,
I sometimes see projects using servo's using the JAL servo llibraries. I have 
not yet used any servo's but I regularly have a project with LEDs that uses PWM 
(like the servo library). 
The number of PWM channels is limited on a PIC and it may be that the timers on 
the PIC are needed for something else.
A solution would be to use a

Re: [jallib] CNC idea

2021-12-30 Thread 'Oliver Seitz' via jallib

Hi Hans,
"how you did this?"
Well, I didn't. I just said how I would do it. I usually do projects which are
not readily available or far to expensive.
The raspberry pi is my desktop computer, or a video player, or the more complex
side of a project.
My fridge, which is outside and needs heating in winter, is controlled by a
PIC. It's connected to a Pi zero W, which acts as nothing more than a wifi
interface to get the temperature curves to my screen. Yes, an ESP controller
would do it, but that's a new world I haven't entered yet.
You shoudn't compare the raspberry pi to a PIC controller. It is a (cheap and
small and low-power) computer.
Greets,Kiste
Am Donnerstag, 30. Dezember 2021, 17:39:28 MEZ hat hans
Folgendes geschrieben:

Hi Kiste,Thank you for responding. I bought a raspberry set with screen a
while ago, but because it's very different from JAI, I haven't done anything
with it yet beside running some ready-made programs on it. Can you give me
some info how you did this?

Op woensdag 29 december 2021 om 14:16:31 UTC+1 schreef Kiste:

Hi Hans,
jal is not the language to decode almost any files. It is solely for 8bit
microcontrollers. Such a controller is an excellent choice to control stepper
motors in sync with an engraving laser module, but not for decoding any data
files. You would want something with more computing power, more memory and
other kinds of interfaces.
For decoding files, I myself would use a raspberry pi, connected to a PIC by
UART. Then, I would transmit only simple actions like "go forward 300 steps,
then turn on laser, go forward another 100 steps, turn off laser" to the
microcontroller.
On a complete little computer, there are libraries for decoding most file types
you may want to use. The microcontroller then can do the swiching with
fractions of microseconds accuracy.
Greets,Kiste
Am Mittwoch, 29. Dezember 2021, 10:02:41 MEZ hat hans
Folgendes geschrieben:

Hi all,Having a lot of material like steppers laser etc i am now thinking
about making a cnc graving tool. I have not yet done anything with CNC etc. My
question : Is there a Jal lib for CNC decoding or other advices?Thank in
advance (again)regardsHans

--
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/17de83e8-726d-45fd-8d97-acd61ab06dbdn%40googlegroups.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/2784b35d-bdb0-4a8b-96ac-a3187c468a27n%40googlegroups.com.

Re: [jallib] CNC idea

2021-12-29 Thread 'Oliver Seitz' via jallib

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/17de83e8-726d-45fd-8d97-acd61ab06dbdn%40googlegroups.com.

Re: [jallib] Linux compiler question

2021-12-29 Thread 'Oliver Seitz' via jallib

Hi Rob,
I'm a linux user, no guru either... I wouldn't mind static linking. You can't
do it for big graphical applications like GIMP, VLC or LibreOffice, the
executables would blow up to gigabytes. But for a compiler, it costs a few
bytes and saves a lot of trouble.
The alternative would be to distribute package manager files (like .deb or
.rpm), which include information on dependencies. But that's the hard way to
make a user happy.
Statically linked executables are quick and convenient for everyone :-)
Greets,Kiste
Am Dienstag, 28. Dezember 2021, 19:21:11 MEZ hat rob...@hotmail.com
Folgendes geschrieben:

Hello all,
For creating the Linux (and MacOS) compiler I am using Virtual Box on my
Windows machine. Some time ago a did an upgrade of Virtual Box and that gave
issues. For example I can no longer use the MacOS since it does not work
anymore. Since the number of MacOS users is limited, and setting up this
environment for the MacOS took a lot of time, I will not make a new MacOS
versions of the but will keep the makefile for the MacOS so that others can
create it.
But the question is about something else. For the Linux compiler I am switching
to Ubuntu running on my Windows PC using WSL2. This integrates better with
Windows. The problem is, however, that when I create the Linux compiler now, it
does not run under Linux Mint since it cannot find a library that is
dynamically loaded and that version of that library is not on my Linux Mint
installation.
So I have 2 questions:1) Did you experience any issues with the Linux compiler,
that is, did you had to upgrade or install any library to get it running on
your machine?2) I can solve the issue by linking all libraries with the
application (option -static). This works but this doubles the size of the
compiler to about 1.3 Mbyte (it is normally around 550 kbytes). I do not think
it will slow things down but it will prevent any problems mentioned in 1)
BTW. I am not a Linux guru so maybe some of you have other suggestions.
Please share your thoughts. Thanks.

Kind regards,
Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/36f87e76-1fd5-46c3-b584-814efcf90906n%40googlegroups.com.

Re: [jallib] PIC18FxxJxx voltage reference

2021-11-27 Thread 'Oliver Seitz' via jallib

 Hi!
The minimum reference is 3V, it is in table 31-30 on page 539 of document 
DS30009964C.pdf (PIC18F47J53 datasheet)
Greets,Kiste

Am Samstag, 27. November 2021, 09:36:43 MEZ hat vsurducan 
 Folgendes geschrieben:  
 
 Hi all,I'm using a PIC18F25J53 for it's 12bit ADC feature.I did not find any 
info in the datasheet regarding the minimum value for the ADC external 
reference. Unfortunately it doesn't have a real voltage reference inside, just 
a reference used for ADC offset correction and a brute reference with a 
resistor divider ( used with the comparator). 
Any experience with this ADC microcontroller series?thx



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qupkQB1KxffhZ9UCSqwOZn3eNSRgfD0RjU4Uo3oJFAK0A%40mail.gmail.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/2133632808.1072786.1638008975326%40mail.yahoo.com.

Re: [jallib] Python and JAL

2021-11-16 Thread 'Oliver Seitz' via jallib

Hi Zet!
Python is cross-platform, it runs on Windows, Mac-OS, Linux, Android and on
lesser known operating systems. None of them runs on PIC controllers.
.hex is as much hardware dependent as it gets. A hex file created for PIC16F877
*might* run on PIC16F877A, but there's also a chance that a certain .hex-file
doesn't run on certain revisions of the very same chip.
So, the true answer to your question is: To make a python program run on a
microcontroller, you have to re-write it for the specific controller you want
to use in a suitable language.
Unless there's a microcontroller-targeted python dialect I'm not aware of. But,
usually python is an interpreted language, which is very uncommon on
microcontrollers for various reasons.
Greets,Kiste
Am Dienstag, 16. November 2021, 23:54:28 MEZ hat zet@gmail.com
Folgendes geschrieben:

HiDoes someone knows how to change a Python program into .hex so Pickit3 can
use it ?Thanks.Zet Weeh

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/b990c2b5-0ba5-4434-9782-1b9802021273n%40googlegroups.com.

Re: [jallib] adc average

2021-11-13 Thread 'Oliver Seitz' via jallib

 

Am Samstag, 13. November 2021, 12:27:04 MEZ hat vsurducan 
 Folgendes geschrieben:  
 
 "Old jal (Wouter's) had a feature for testing computation at the compile time. 
I realized it was very useful even if using constants for testing math 
routines."


If that is the case, it's still no part of compilation but some sort of 
simulation. Can be that it was included in that compiler, but it's nothing a 
compiler needs to do in general.
Greets,Kiste
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/408706160.298701.1636806482097%40mail.yahoo.com.

Re: [jallib] adc average

2021-11-13 Thread 'Oliver Seitz' via jallib

 Hi!
_error is meant to produce an error whenever it is compiled. You can only use 
it with constants:
if target_clock<1200 then  _error "Need at least 12MHz for this program"end 
if
If there's a variable in the if statement, the content will have to be 
compiled, and so the error is raised. 
If you want to see characters depending on a value of a variable, you can only 
check at runtime. So, connect some kind of a display and use print_string()

Greets,Kiste
Am Samstag, 13. November 2021, 09:56:29 MEZ hat Rob CJ  
Folgendes geschrieben:  
 
 Hi Vasile,
Thanks for the update. I found something strange. Given the code below.
include 18f4550

var byte i =0
if (i == 100)then  _error "Is 100"end if
When I compile this I get:
jal jalv25r6 (compiled Oct 29 2021)generating p-code16858 tokens, 151522 chars; 
3221 lines; 3 filesgenerating PIC code pass 1generating PIC code pass 20 data 
accesses checked, 0 errors1 skips checked, 0 errors        writing 
resultd:\PIC\Compiler\Test\2021\ADC_in_array\Test.jal:6: "Is 100"1 errors, 0 
warningsThe terminal process "c:\jallib\compiler\jalv2_64.exe 
'd:\PIC\Compiler\Test\2021\ADC_in_array\Test.jal', '-s', 'c:\jallib\lib'" 
terminated with exit code: 1.

Which is not correct. Same happens when you replace it with _warn but then it 
is generated as warning.
But when I have this program:
include 18f4550

var byte i =0
if !defined(i)then  _error "i is not defined"end if
I get:
jal jalv25r6 (compiled Oct 29 2021)generating p-code16858 tokens, 151533 chars; 
3221 lines; 3 filesgenerating PIC code pass 1generating PIC code pass 20 data 
accesses checked, 0 errors0 skips checked, 0 errorswriting resultCode area: 6 
of 32768 used (bytes)Data area: 1 of 2048 usedSoftware stack available: 2046 
bytesHardware stack depth 0 of 310 errors, 0 warnings

Which is correct because when I change i to j the output is:
jal jalv25r6 (compiled Oct 29 2021)generating p-code16858 tokens, 151533 chars; 
3221 lines; 3 filesgenerating PIC code pass 1generating PIC code pass 20 data 
accesses checked, 0 errors0 skips checked, 0 errorswriting 
resultd:\PIC\Compiler\Test\2021\ADC_in_array\Test.jal:6: "i is not defined"1 
errors, 0 warningsThe terminal process "c:\jallib\compiler\jalv2_64.exe 
'd:\PIC\Compiler\Test\2021\ADC_in_array\Test.jal', '-s', 'c:\jallib\lib'" 
terminated with exit code: 1.

So not sure why this happens but is seems to be not OK.
Kind regards,
Rob
Van: jallib@googlegroups.com  namens vsurducan 

Verzonden: zaterdag 13 november 2021 08:08
Aan: jallib@googlegroups.com 
Onderwerp: Re: [jallib] adc average Hi Rob,I think you will not find any issue, 
please don't bother. The code works now (without interrupts), I had a 
multiplication error which is not part of the code.
My original test used  tmr0 interrupt and USB_serial, the average measurements 
should happen in 400us intervals and it seems something went wrong because the 
values are not those expected.

About the test procedure, I've loaded the ADRESH and ADRESL with constant 
values, without using any ADC_read procedure. Then tried to test the average 
procedure using _ERROR.  When the compiler finds the line containing _ERROR it 
reports an error no matter if the condition is true or false. Did I use it in 
the wrong way?A very old version of the JAL compiler used a pragma_test (or 
something like that) previously to start a testing procedure. The result was 
delivered at compile time.thank you,


On Fri, Nov 12, 2021 at 11:37 PM Rob CJ  wrote:

Hi Vasile,
If I want to test this I need to create a program that does not use your 
one_ch_ad_read routine. So if I use the standard adc library the program looks 
like this. Is this program giving the same problem for you (I do not know which 
PIC you are using but it seem to be an 18F)?
About the error and warning. They are only created at compile time and I am not 
sure what voltage is at the time you compile the the program. I am also not 
sure if this works for variables.

include 18f4550--pragma target clock 48_000_000-- magical statements: using a 
20MHz Xtal, you can run @48MHz !pragma target PLLDIV    P5pragma target CPUDIV  
  P1pragma target USBDIV    P2pragma target OSC      HS_PLL
pragma target WDT  control          -- watchdogpragma target LVP  enabled       
   -- allow Low Voltage Programmingpragma target MCLR external         -- reset 
externally
WDTCON_SWDTEN = off                -- no watchdog
-- We'll start to set all pins as digital-- then, using ADC lib, we'll 
configure needed-- ones as analog.enable_digital_io()
const sample_nr  = 8  ; buffer size dimensionvar word voltage1_a[sample_nr]; 
sample arrayvar word one_ch_ad_read, ch0_adc_valuevar word voltage1 =0 ; the 
average value we needconst word c256 =256

-- Configure ADC-- Step 1: ADC input pin setup pin_AN0_direction = input        
              -- Set A0 to analog input ADCON1_PCFG = 0b000-- Step 2: Set VDD 
and VSS as VrefADCON1_VCFG0 = FALSE                            -- Vref+ is 
VDDADCON1_VCFG1

AW: [jallib] script for jal file

2021-11-01 Thread 'Oliver Seitz' via jallib

MPLAB used to come with an additional tool for programming only. It's called
IPE or the like. That tool has an option to e.g. increase a certain address in
the loaded hex file each time you click the "program"-button. That's much more
convenient than modifying-compiling-loading-programming each device.
GreetsKiste

Gesendet von Yahoo Mail auf Android

Am Mo., Nov. 1, 2021 at 6:58 schrieb vsurducan: Hi,I
have a situation where I need to change the value of a constant in a jal file
and compile/program it repeatedly for a number of times. It's about adding an
identifier ( such an address for example) in each programmed microcontroller (
not the one already built in).

Is there any solution to do it in a script which calls repeatedly the jal file,
change the constant value and obtain after the compilation a different hex file
for each constant value? Perhaps somewhere there is a known example?

thank you!

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsY%2B5g3-YTTQdeFCcz13nyGug3p7B7LBjLhxn_B%3DoAMpQ%40mail.gmail.com.

Re: [jallib] library latency

2021-10-17 Thread 'Oliver Seitz' via jallib

Oh, and if you're not using interrupts and it's your intention to wait and
nothing but wait, until all data is sent, then there's serial_software. It can
be very handy for transmissions but it's use as a receiver is limited.
Greets,Kiste
Am Sonntag, 17. Oktober 2021, 18:58:25 MESZ hat 'Oliver Seitz' via jallib
Folgendes geschrieben:

The usart can hold (almost) two bytes in the transmit queue, one in the shift
register which is already in transmit, and another one in the TXREG, which is
waiting to be transmitted. So, when the write function accepts the third byte,
the second byte has just started to transmit. If you want to wait for the
transmission to really end, you have to watch bit TXSTA_TRMT, which indicates
that the last byte is fully shiftet out and the shift register is empty.
Greets,Kiste
Am Sonntag, 17. Oktober 2021, 18:22:48 MESZ hat vsurducan
Folgendes geschrieben:

Hi Kiste, I will come back with a logic capture but not today.
In my example, between the last transmittedbyte (dataL) at 115200bps and the
next instruction (an IO pin change) which took place after the 100us delay, I
should see about 100us delay isn't it?I see 18us, meaning the three bytes
transmission itself takes longer while the delay period has already started.
Interrupts are all off.
If I change that delay from 100us to 50us, the communication crashes. If I
change it to 90us, it will still be ok ( the real delay exists but is only 8us).
thx

On Sun, Oct 17, 2021 at 2:50 PM 'Oliver Seitz' via jallib
wrote:

Hi!
What do you mean by latency?
pin_a0=low_usec_delay(10)pin_a0=highTXREG=255
The time which the serial start bit is delayed more than 1 Tcy I would call
latency. The time that follows then is the time required for transmission,
which is at least 10/baudrate (8 data plus 1 start plus 1 stop bits).
The first byte written to TXREG is going right through to the Transmit Shift
Register (TSR), while the second byte stays in the (user accessible) TXREG,
going automatically to TSR once that is free. If you want to send a third byte,
the library has to wait for TXREG to be free, or data would be overwritten and
lost.
So yes, if you're sending three bytes, the library will have to delay data,
either by blocking the program (serial_hardware) or by caching the data in a
software buffer (serial_hw_int_cts).
I haven't seen a library induced latency before. I presume the 80uS you've seen
are more related to the number of three bytes and the baudrate than to the
32MHz the controller is running on.
Greets,Kiste

Am Sonntag, 17. Oktober 2021, 12:12:49 MESZ hat vsurducan
Folgendes geschrieben:

Hi all, just an info.

Serial_hw_write library seems to add a quite large latency for the real
signals. For example the following instructions:
serial_hw_write (address)
serial_hw_write (dataH)
serial_hw_write (dataL)
;_usec_delay ( 100 )
compiled on a 32MHz clock microcontroller are adding a measurable latency of
about 80uS which seems a bit weird.
If those instructions are chained in a critical time loop, a delay after those
three compiler instructions is mandatory, without it, the communication may
freeze. Actually this delay includes the communication latency. I've used a
logic analyzer to understand that behavior.best wishes,

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtSvoE8zGUJzLzPymC-KKx68vt5QDyzie8_dWotUPQyxA%40mail.gmail.com.

--
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 emai

Re: [jallib] library latency

2021-10-17 Thread 'Oliver Seitz' via jallib

On Sun, Oct 17, 2021 at 2:50 PM 'Oliver Seitz' via jallib
wrote:

Am Sonntag, 17. Oktober 2021, 12:12:49 MESZ hat vsurducan
Folgendes geschrieben:

Hi all, just an info.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtSvoE8zGUJzLzPymC-KKx68vt5QDyzie8_dWotUPQyxA%40mail.gmail.com.

Re: [jallib] library latency

2021-10-17 Thread 'Oliver Seitz' via jallib

Am Sonntag, 17. Oktober 2021, 12:12:49 MESZ hat vsurducan
Folgendes geschrieben:

Hi all, just an info.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com.

Re: [jallib] interrupt on change issue

2021-10-03 Thread 'Oliver Seitz' via jallib

Hi!

Good to hear it's working now.

About what you're describing, it depends on what "precisely" means. You can 
choose a newer chip like from the Q43 series and use the peripherals. There's a 
CWG which has a shutdown feature that switches of the output when a 
configurable interrupt fires - with no software latency at all.

Greets,
Kiste

Am Montag, 4. Oktober 2021, 07:19:07 MESZ hat vsurducan  
Folgendes geschrieben: 

Rob, I like your way of tricking the problem. :)
The final effect looks better, now indeed it detects the positive edge of 
RDY_IN. Assuming the RDY_In is 20ms and RDY_OUT delay in the main loop is say 
1ms that can be correctly seen.
The IOC is almost the same of mine (which started as jal and ended as assembler)
But if you need to precise control the RDY_OUT time, that seems impossible in a 
long main loop which is also large jitter generator ( using the USB_serial for 
instance) . 
Imagine that RDY_IN varies between say 100us to 100ms and RDY_OUT must stay 
high a precise time until user reset it. The RDY_OUT control has to be moved in 
the ISR, but then no delay will be allowed to catch the rising edge...an 
interrupt  timer delay must be implemented.
thanks for your help!

On Sun, Oct 3, 2021 at 3:45 PM Rob Hamerling  wrote:
>  
>  
> Hi Vasili,
> 
> Follow up of my previous message ...
> 
> 
> On 03/10/2021 10.32, vsurducan wrote:
> 
> 
>>  
>> 
>> 
>> On the other hand, if you set only the detection of the rising edge ( 
>> IOCAP_IOCAP0 = high,  IOCAN_IOCAN0 = low),  RDY_OUT stayed indefinitely on 
>> high even on RDY_IN a positive edge occured, which seems wrong.
>> 
>> 
>> 
>> 
> With only rising edge interrupts this is a possibility:
> 
> 
> procedure IOC() is
>     pragma interrupt
>     if INTCON_IOCIF & IOCAF_IOCAF0 then -- edge interrupt on RDY_IN
>     IOCAF = IOCAF & 0xFE    -- clear IOCAF0
>     pin_RDY_OUT = high  -- RDY_OUT high
>     end if
> end procedure
> 
> forever loop
>     if pin_RDY_OUT then
>     delay_1ms(20)
>     pin_RDY_OUT = low
>     end if
> end loop
> 
> 
> 
> 
> -- 
> Rob Hamerling, Vianen, NL
> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/76b8a82d-2e79-89b6-47b1-98169e4c0aae%40gmail.com.
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsXs%2BJXfaaN10tYtfF6R-jO7OeyMTyqfXN8SzV-bSgGoQ%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1148764833.933296.1633326615052%40mail.yahoo.com.

Re: [jallib] interrupt on change issue

2021-10-02 Thread 'Oliver Seitz' via jallib

Hi!

That's something else, I think it's called "fast interrupt" or the like. It's 
not such an easy thing, as it restricts a project to have only *one* ISR 
(=Interrupt Service Routine), which, e.g. with the serial_hw_int_cts library is 
not possible as that library uses interrupts transparently to the user. So, 
activating that switch can be dangerous, depending on what libraries you use.

If there is one or more ISR procedures in a program, INTCON_GIE can be 
activated safely. What we were talking about is a single "fake ISR" which the 
compiler could always generate if there is no real ISR, just in case the 
program accidentally enables INTCON_GIE.

There are two philosophies:

1. Make program errors have an effect to make them visible and easier 
correctable

2. Try to hide program errors and increase reliability, doing your best to just 
keep running

IMHO I dont' really have a preference. But watchdogs and especially PPS lock 
features are clear approaches to Nr. 2.

Greets,
Kiste

Am Samstag, 2. Oktober 2021, 08:38:12 MESZ hat vsurducan  
Folgendes geschrieben: 

Hi Rob, Kiste,
I'm not sure on the actual compiler, but one of old pragma interrupt versions 
allows you to save, restore all registers and retfie manually at your need.
I still believe it was a great option.

On Fri, Oct 1, 2021 at 8:46 PM Rob Hamerling  wrote:
>  
>  
> Hello Kiste,
> 
> 
> On 01/10/2021 17.30, 'Oliver Seitz' via jallib wrote:
> 
> 
>> I didn't check what the compiler does if there's no 
>>interrupt service routine. Would it be smart to always waste five program 
>>words just to be sure not to accidentally restart the program? I.e., always 
>>put a RETFIE at position 0x0004 when there's no pragma interrupt?
>> 
> Yeah, I've thought about that too, but that would mask design errors. Not a 
> good idea in my opinion. 
> 
> Regards, Rob.
> 
> 
> 
> 
> -- 
> Rob Hamerling, Vianen, NL
> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/d5cd970e-5e81-f278-548d-d9476f0e8dc3%40gmail.com.
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt0LpyrKTn_f1r-Ze%3DAk%3Dfam3ika_4b4wqRAmCt924_mQ%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/246922508.716341.1633159041947%40mail.yahoo.com.

Re: [jallib] interrupt on change issue

2021-10-01 Thread 'Oliver Seitz' via jallib

Hi Rob,

that was a thought I had, but I didn't check what the compiler does if there's 
no interrupt service routine. Would it be smart to always waste five program 
words just to be sure not to accidentally restart the program? I.e., always put 
a RETFIE at position 0x0004 when there's no pragma interrupt?

Greets,
Kiste


Am Freitag, 1. Oktober 2021, 10:56:08 MESZ hat Rob Hamerling 
 Folgendes geschrieben: 






I think the cause of your problem is that you set INTCON_GIE = high, but have 
no ISR (Interrupt Service Routine). 
An interrupt (hardware jump to the interrupt vector at address 0x0004) becomes 
practically a restart of the program.
Possible solutions: INTCON_GIE = low, or use an ISR to handle the IOC interrupt 
(but no delay in an ISR!)

Regards, Rob.




On 30/09/2021 17.51, vsurducan wrote:


>  

According to the PIC12F1572 datasheet, rising edge IOC can be detected by 
enabling edge detection on input pins (IOCAPx or IOCANx)

and reading the IOC flag (IOCAFx) or the INTCON_IOCIF, then clearing the flag 
for the next IOC detection.


Seems it does not work.  Any ideas?  Thx.

include 12lf1572                     -- target PICmicro
--
-- This program uses the internal oscillator at 4 MHz.
pragma target clock    32_000_000       -- oscillator frequency
--
pragma target OSC      INTOSC_NOCLKOUT           -- internal oscillator
pragma target PLLEN    DISABLED                  -- PLL off
pragma target CLKOUTEN DISABLED                  -- no clock output
pragma target WDT      DISABLED                  -- watchdog
pragma target BROWNOUT ENABLED                  -- brownout reset
pragma target LVP      DISABLED                  -- no low voltage programming
pragma target MCLR     INTERNAL                  -- internal reset
--
--
OSCCON_SCS = 0                      -- select primary oscillator
OSCCON_IRCF = 0b1110                -- 8 MHz
OSCCON_SPLLEN = ENABLED             -- 4x PLL: 8 -> 32 MHz
--
enable_digital_io()                 -- make all pins digital I/O

include delay                       

alias pin_RDY_IN is pin_A0
alias pin_RDY_IN_direction is pin_A0_direction
pin_RDY_IN_direction = input


alias pin_RDY_OUT is pin_A5
alias pin_RDY_OUT_direction is pin_A5_direction
pin_RDY_OUT_direction = output
pin_RDY_OUT = low

OPTION_REG_WPUEN = 0
WPUA_WPUA0 = 0 ; pull-up disabled on RA0


-- main program
-- 
INTCON_GIE = high   ; not necessary without interrupt routine
INTCON_IOCIE = high ; enable interrupt on change, not necessary without 
interrupt routine
IOCAP_IOCAP0 = high ; enable positive edge interrupt on change on RDY_IN


forever loop

; if INTCON_IOCIF  then
  if IOCAF_IOCAF0  then  ; a positive edge interrupt on change on RDY_IN occured
    pin_RDY_OUT = high
    delay_1mS (20)
    pin_RDY_OUT = low
    IOCAF_IOCAF0 = low    ; clear IOCAF0 flag
;    INTCON_IOCIF = low
 else ; no interrupt occured
    pin_RDY_OUT = low
 end if
 
end loop







-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvv6k0rGBYftBOhsT7HR4wJe8GrM8_vEGUPiTk3MVa%2B8Q%40mail.gmail.com.


-- 
Rob Hamerling, Vianen, NL


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/dd13bf5c-9a69-5157-afa9-fa27d38ece98%40gmail.com
.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/135907067.590815.1633102247578%40mail.yahoo.com.

Re: [jallib] Software Bill of Materials

2021-08-07 Thread 'Oliver Seitz' via jallib

What do you mean by "hitting"? What's the presumed goal? Put an export ban on 
open source software? That wouldn't be a problem I think. The repositories 
would move out of the US altoghether, OSS wouldn't lose anything, but the U.S 
government would lose, not gain, influence.

I still don't see the point, and I also see very little relationship between 
the two articles.

Greets,
Kiste


Am Samstag, 7. August 2021, 09:34:04 MESZ hat vasi vasi  
Folgendes geschrieben: 





This is the latest, strongest and more pressure reason of U.S. continuing in 
hitting open-source
https://merics.org/en/analysis/open-source-trouble-chinas-efforts-decouple-foreign-it-technologies

On Sat, Aug 7, 2021 at 8:21 AM 'Oliver Seitz' via jallib 
 wrote:
> Hi vasi,
> 
> let me, just as an illustration, transfer that article to food.
> 
> U.S. Gov. demands, that in its own canteen there must exist a list of 
> ingredients for each and all types of food. Your conclusion is, that they're 
> preparing to forbid everyone else to possess any similar dishes, right?
> 
> Sounds a lot like a conspiracy tale to me, and a quite recent one. In a quick 
> internet search, I found that most critics of the law say, that it should go 
> even further.
> 
> As I read the order, for OSS is not much to be done, as most of the 
> open-source licenses already require to mention re-use of existing code and 
> contain instructions, what software is needed to bild the product.
> 
> 
> Have you any links which back your concerns?
> 
> 
> Greets,
> Kiste
> 
> Am Samstag, 7. August 2021, 00:51:01 MESZ hat vasi vasi  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Hi guys,
> Be aware that U.S. Gov. is out to identify the list of dependencies for every 
> open software out there, with the undeclared intention to own or cut them. 
> This started under Obama administration, now continues under Obama2/Biden 
> administration. See here some details (second post there) 
> https://sourceforge.net/p/gcbasic/discussion/579126/thread/0d009b1785/
> 
> My advice (because I don't think you can stop this anymore)?
> 
> Secure your tools and platforms. Be sure that you can create and recreate 
> your open-source application at any point in time. Make backups of 
> everything, including of the Linux distro that works now for you, Regarding 
> Linux, I think only Debian comes on DVDs with also all the applications 
> available for it. Secure your dependencies! If not for others, do it for you.
> -- 
> Vasi
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/CABsDq%3D8bjPuwzFuVr0bkL0x4o4pWNxfgjjGvr%2B-xu5Wp10omnw%40mail.gmail.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/628853145.82656.1628313639523%40mail.yahoo.com.
> 


-- 
Vasi


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CABsDq%3D-hx6x1c%3DONb5bkLL9onzMDArPDAn4njGtFEAa7kStiLA%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/536041118.118687.1628354434640%40mail.yahoo.com.

Re: [jallib] Software Bill of Materials

2021-08-06 Thread 'Oliver Seitz' via jallib

Hi vasi,

let me, just as an illustration, transfer that article to food.

U.S. Gov. demands, that in its own canteen there must exist a list of
ingredients for each and all types of food. Your conclusion is, that they're
preparing to forbid everyone else to possess any similar dishes, right?

Sounds a lot like a conspiracy tale to me, and a quite recent one. In a quick
internet search, I found that most critics of the law say, that it should go
even further.

As I read the order, for OSS is not much to be done, as most of the open-source
licenses already require to mention re-use of existing code and contain
instructions, what software is needed to bild the product.

Have you any links which back your concerns?

Greets,
Kiste

Am Samstag, 7. August 2021, 00:51:01 MESZ hat vasi vasi
Folgendes geschrieben:

Hi guys,
Be aware that U.S. Gov. is out to identify the list of dependencies for every
open software out there, with the undeclared intention to own or cut them. This
started under Obama administration, now continues under Obama2/Biden
administration. See here some details (second post there)
https://sourceforge.net/p/gcbasic/discussion/579126/thread/0d009b1785/

My advice (because I don't think you can stop this anymore)?

Secure your tools and platforms. Be sure that you can create and recreate your
open-source application at any point in time. Make backups of everything,
including of the Linux distro that works now for you, Regarding Linux, I think
only Debian comes on DVDs with also all the applications available for it.
Secure your dependencies! If not for others, do it for you.
--
Vasi

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CABsDq%3D8bjPuwzFuVr0bkL0x4o4pWNxfgjjGvr%2B-xu5Wp10omnw%40mail.gmail.com.

Re: [jallib] PWM versus enhanced PWM, oposite polarity output?

2021-08-03 Thread 'Oliver Seitz' via jallib

I've given up on USB a long time ago... If I have to connect to a computer 
which has no serial port, I'm using a raspberry pi as uart to network interface.

Greets,
Kiste

Am Dienstag, 3. August 2021, 06:42:19 MESZ hat vsurducan  
Folgendes geschrieben: 





Thx, I know the jitter issue caused by the compiler delays, in the past I was 
using my own ISR based on Bresenham code. It creates a negligible jitter down 
to 10uS, I think at 48MHz I can go below 1uS without huge issues. Fortunately 
data has to be sent rarely somewhere between 1s and 10s.For that I want to use 
the usb_serial library.The major problem I have is that usb_serial does not 
work reliably for me with PIC18F25k50, with all good help Rob sustained.  In my 
tests the library works reliably on PIC18F2550 or PIC18F26j50 but not with 
PIC18F25k50. I've so far tested SO and SS packages and two manufacturing lots 
thinking it is a microcontroller issue. It seems it is not.

On Mon, Aug 2, 2021 at 8:38 AM 'Oliver Seitz' via jallib 
 wrote:
> You're very welcome :-)
> 
> I want to correct myself about interrupts and jitter: I wrote about +/-2Tcy. 
> That's the hardware part. But then there's JALs interrupt handling: If, say, 
> serial_hw_int_cts is transmitting a string and has just finished one byte 
> shortly before the timer overflows, servicing the timer interrupt will be 
> delayed until serial_hw_int_cts has finished preparing the next byte, which 
> can take quite some time. Then, depending on the order of the service 
> routines which you don't have control over, the timer interrupt can be served 
> immediately afterwards, or, some more service routiunes are called, control 
> may even be given back to the main program to execute one machine instruction 
> just to then go back to the list of interrupt service routines until finally 
> servicing the timer interrupt. 
> 
> That means, if there's more than one interrupt in use, servicing can have a 
> jitter of indefinite amount, even to the point when interrupt events are 
> skipped.
> 
> Greets,
> Kiste
> 
> 
> 
> Am Montag, 2. August 2021, 07:18:09 MESZ hat vsurducan  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Kiste, thanks for opening my eyes, PIC18F25k50 will do my job, it has indeed 
> the ECCP, I didn't read correctly the notes 4 and 5 at pin descriptions. 
> Thank you again.
> 
> On Mon, Aug 2, 2021 at 8:36 AM vsurducan  wrote:
>> Hi Kiste, as far as I read my version of k50 (PIC18F25k50) does not have 
>> ECCP it in 28 pin, I have to stick on my available stock of microcontrollers 
>> during the inexistence at this point (Farnell, TME) of too many options to 
>> buy immediately PIC microcontrollers.
>> Thanks for your solution, I think I will do it in interrupts using TMR0 for 
>> a short timebase, count it for the needed frequency and toggle the output 
>> pins.
>> Yes, indeed a CLC would be helpful with the standard CCP...
>> best wishes,
>> 
>> On Sun, Aug 1, 2021 at 5:48 PM 'Oliver Seitz' via jallib 
>>  wrote:
>>> Hi!
>>> 
>>> Well... almost all 28pin? Chips with suffixes like k20, k22, k50, k80, j11, 
>>> j13, j50 and j80 do have ECCP, chips with suffixes like q40, q41, q43, q83, 
>>> q84, k42, k83 and numerous more have CWG and/or CLC modules, which both 
>>> allow the generation of those signals using a simple PWM. 
>>> 
>>> 
>>> With the PIC18F2550, I only have one idea... Externally feed the pmw signal 
>>> back to pins A0 and A1, set the CVRef module to somewhere in the middle, 
>>> set comparator mode 0b110, and set one of the CxINV bits. Then you have the 
>>> symmetric signals on C1out and C2out. It's not the most elegant solution, I 
>>> admit...
>>> 
>>> Greets,
>>> Kiste
>>> 
>>> 
>>> 
>>> Am Sonntag, 1. August 2021, 14:58:43 MESZ hat vsurducan 
>>>  Folgendes geschrieben: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thx Rob, the bridge mode (enhanced CCP) works only for a 40 pin device, I 
>>> have a 28 pin device on my board. Enhanced CCP is available only on large 
>>> size microcontroller. :(   Almost all 28 pin microcontrollers suffer from 
>>> this issue (PIC18F25k50, etc.)
>>> Since I need two signals with opposite phases, 50% duty cycle, whose 
>>> frequency should be programmable between 1KHz and 2KHz I think they can be 
>>> generated in compare mode...or perhaps in software.  I also need to trigger 
>>> an ADC read during the high level of those pulses from time to time.
>>> 
>>> On Sun, Aug 1, 2021 at 2:17 PM Rob CJ  wrote:
>>>>  
>>>>  
>

Re: [jallib] PWM versus enhanced PWM, oposite polarity output?

2021-08-01 Thread 'Oliver Seitz' via jallib

You're very welcome :-)

I want to correct myself about interrupts and jitter: I wrote about +/-2Tcy. 
That's the hardware part. But then there's JALs interrupt handling: If, say, 
serial_hw_int_cts is transmitting a string and has just finished one byte 
shortly before the timer overflows, servicing the timer interrupt will be 
delayed until serial_hw_int_cts has finished preparing the next byte, which can 
take quite some time. Then, depending on the order of the service routines 
which you don't have control over, the timer interrupt can be served 
immediately afterwards, or, some more service routiunes are called, control may 
even be given back to the main program to execute one machine instruction just 
to then go back to the list of interrupt service routines until finally 
servicing the timer interrupt. 

That means, if there's more than one interrupt in use, servicing can have a 
jitter of indefinite amount, even to the point when interrupt events are 
skipped.

Greets,
Kiste



Am Montag, 2. August 2021, 07:18:09 MESZ hat vsurducan  
Folgendes geschrieben: 





Kiste, thanks for opening my eyes, PIC18F25k50 will do my job, it has indeed 
the ECCP, I didn't read correctly the notes 4 and 5 at pin descriptions. Thank 
you again.

On Mon, Aug 2, 2021 at 8:36 AM vsurducan  wrote:
> Hi Kiste, as far as I read my version of k50 (PIC18F25k50) does not have ECCP 
> it in 28 pin, I have to stick on my available stock of microcontrollers 
> during the inexistence at this point (Farnell, TME) of too many options to 
> buy immediately PIC microcontrollers.
> Thanks for your solution, I think I will do it in interrupts using TMR0 for a 
> short timebase, count it for the needed frequency and toggle the output pins.
> Yes, indeed a CLC would be helpful with the standard CCP...
> best wishes,
> 
> On Sun, Aug 1, 2021 at 5:48 PM 'Oliver Seitz' via jallib 
>  wrote:
>> Hi!
>> 
>> Well... almost all 28pin? Chips with suffixes like k20, k22, k50, k80, j11, 
>> j13, j50 and j80 do have ECCP, chips with suffixes like q40, q41, q43, q83, 
>> q84, k42, k83 and numerous more have CWG and/or CLC modules, which both 
>> allow the generation of those signals using a simple PWM. 
>> 
>> 
>> With the PIC18F2550, I only have one idea... Externally feed the pmw signal 
>> back to pins A0 and A1, set the CVRef module to somewhere in the middle, set 
>> comparator mode 0b110, and set one of the CxINV bits. Then you have the 
>> symmetric signals on C1out and C2out. It's not the most elegant solution, I 
>> admit...
>> 
>> Greets,
>> Kiste
>> 
>> 
>> 
>> Am Sonntag, 1. August 2021, 14:58:43 MESZ hat vsurducan 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> Thx Rob, the bridge mode (enhanced CCP) works only for a 40 pin device, I 
>> have a 28 pin device on my board. Enhanced CCP is available only on large 
>> size microcontroller. :(   Almost all 28 pin microcontrollers suffer from 
>> this issue (PIC18F25k50, etc.)
>> Since I need two signals with opposite phases, 50% duty cycle, whose 
>> frequency should be programmable between 1KHz and 2KHz I think they can be 
>> generated in compare mode...or perhaps in software.  I also need to trigger 
>> an ADC read during the high level of those pulses from time to time.
>> 
>> On Sun, Aug 1, 2021 at 2:17 PM Rob CJ  wrote:
>>>  
>>>  
>>>  Hi Vasile,
>>> 
>>>  
>>> 
>>> 
>>>  Not sure if I understood you correctly. If you want the PWM signals to be 
>>>exactly the same but only inverted you can use the bridge mode for one of 
>>>the PWM's that is when one output goes high the other goes low. 
>>> 
>>>  
>>> 
>>> 
>>>  
>>> 
>>> 
>>>  
>>> 
>>> 
>>>  
>>> 
>>> 
>>>  Kind regards,
>>> 
>>>  
>>> 
>>> 
>>>  Rob
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> Van: jallib@googlegroups.com  namens vsurducan 
>>> 
>>> Verzonden: zondag 1 augustus 2021 10:14
>>> Aan: jallib@googlegroups.com 
>>> Onderwerp: [jallib] PWM versus enhanced PWM, oposite polarity output? 
>>>  
>>> 
>>> 
>>>  
>>>  
>>> Hi all,
>>> 
>>> PIC18F2550, 28pin PIC device has only the PWM implemented, the enhanced PWM 
>>> is available on 40/44pin devices only. However, If I want on a 28pin PIC  
>>> two PWMs running at the same frequency, with the same duty-cycle, how can I 
>>> generate one active hi

Re: [jallib] PWM versus enhanced PWM, oposite polarity output?

2021-08-01 Thread 'Oliver Seitz' via jallib

Hi,

if I download the datasheet (PIC18F2X_45K50-3684B.pdf), it says the chip 
has one ECCP and one CCP module. The output of CCP2, the simple one, is on pin 
12 (pin 9 on QFN package) and can be relocated to pin 24 (pin 21 on QFN). The 
outputs A,B,C and D of CCP1 are on pins 13, 23, 22 and 25 (10, 20, 19 and 22 on 
QFN). The Errata doesn't mention any problems with ECCP. 

2kHz is not that fast, so you can use an interrupt of course. I try to avoid 
that, as interrupts can introduce some jitter (about +/-2Tcy) and if that 
causes a problem, it may be hard to trace.

Greets,
Kiste


Am Montag, 2. August 2021, 06:38:36 MESZ hat vsurducan  
Folgendes geschrieben: 





Hi Kiste, as far as I read my version of k50 (PIC18F25k50) does not have ECCP 
it in 28 pin, I have to stick on my available stock of microcontrollers during 
the inexistence at this point (Farnell, TME) of too many options to buy 
immediately PIC microcontrollers.
Thanks for your solution, I think I will do it in interrupts using TMR0 for a 
short timebase, count it for the needed frequency and toggle the output pins.
Yes, indeed a CLC would be helpful with the standard CCP...
best wishes,

On Sun, Aug 1, 2021 at 5:48 PM 'Oliver Seitz' via jallib 
 wrote:
> Hi!
> 
> Well... almost all 28pin? Chips with suffixes like k20, k22, k50, k80, j11, 
> j13, j50 and j80 do have ECCP, chips with suffixes like q40, q41, q43, q83, 
> q84, k42, k83 and numerous more have CWG and/or CLC modules, which both allow 
> the generation of those signals using a simple PWM. 
> 
> 
> With the PIC18F2550, I only have one idea... Externally feed the pmw signal 
> back to pins A0 and A1, set the CVRef module to somewhere in the middle, set 
> comparator mode 0b110, and set one of the CxINV bits. Then you have the 
> symmetric signals on C1out and C2out. It's not the most elegant solution, I 
> admit...
> 
> Greets,
> Kiste
> 
> 
> 
> Am Sonntag, 1. August 2021, 14:58:43 MESZ hat vsurducan  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Thx Rob, the bridge mode (enhanced CCP) works only for a 40 pin device, I 
> have a 28 pin device on my board. Enhanced CCP is available only on large 
> size microcontroller. :(   Almost all 28 pin microcontrollers suffer from 
> this issue (PIC18F25k50, etc.)
> Since I need two signals with opposite phases, 50% duty cycle, whose 
> frequency should be programmable between 1KHz and 2KHz I think they can be 
> generated in compare mode...or perhaps in software.  I also need to trigger 
> an ADC read during the high level of those pulses from time to time.
> 
> On Sun, Aug 1, 2021 at 2:17 PM Rob CJ  wrote:
>>  
>>  
>>  Hi Vasile,
>> 
>>  
>> 
>> 
>>  Not sure if I understood you correctly. If you want the PWM signals to be 
>>exactly the same but only inverted you can use the bridge mode for one of the 
>>PWM's that is when one output goes high the other goes low. 
>> 
>>  
>> 
>> 
>>  
>> 
>> 
>>  
>> 
>> 
>>  
>> 
>> 
>>  Kind regards,
>> 
>>  
>> 
>> 
>>  Rob
>> 
>>  
>> 
>> 
>> 
>>  
>> Van: jallib@googlegroups.com  namens vsurducan 
>> 
>> Verzonden: zondag 1 augustus 2021 10:14
>> Aan: jallib@googlegroups.com 
>> Onderwerp: [jallib] PWM versus enhanced PWM, oposite polarity output? 
>>  
>> 
>> 
>>  
>>  
>> Hi all,
>> 
>> PIC18F2550, 28pin PIC device has only the PWM implemented, the enhanced PWM 
>> is available on 40/44pin devices only. However, If I want on a 28pin PIC  
>> two PWMs running at the same frequency, with the same duty-cycle, how can I 
>> generate one active high and one active low PWM signals without using any 
>> external inverter? No deadband between the output signals is required.
>> 
>> Any experience is appreciated.
>> 
>> thank you!
>> 
>> 
>> 
>> -- 
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit  
>> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvHSZrsUtoF_1GcDrNS2_mup_hc5ZbYOuQu4uGw5TYuAQ%40mail.gmail.com.
>> 
>> 
>> 
>> 
>> -- 
>> 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+unsubscr...@googlegroups.com.
>> To view this discussi

Re: [jallib] PWM versus enhanced PWM, oposite polarity output?

2021-08-01 Thread 'Oliver Seitz' via jallib

Hi!

Well... almost all 28pin? Chips with suffixes like k20, k22, k50, k80, j11, 
j13, j50 and j80 do have ECCP, chips with suffixes like q40, q41, q43, q83, 
q84, k42, k83 and numerous more have CWG and/or CLC modules, which both allow 
the generation of those signals using a simple PWM. 


With the PIC18F2550, I only have one idea... Externally feed the pmw signal 
back to pins A0 and A1, set the CVRef module to somewhere in the middle, set 
comparator mode 0b110, and set one of the CxINV bits. Then you have the 
symmetric signals on C1out and C2out. It's not the most elegant solution, I 
admit...

Greets,
Kiste



Am Sonntag, 1. August 2021, 14:58:43 MESZ hat vsurducan  
Folgendes geschrieben: 





Thx Rob, the bridge mode (enhanced CCP) works only for a 40 pin device, I have 
a 28 pin device on my board. Enhanced CCP is available only on large size 
microcontroller. :(   Almost all 28 pin microcontrollers suffer from this issue 
(PIC18F25k50, etc.)
Since I need two signals with opposite phases, 50% duty cycle, whose frequency 
should be programmable between 1KHz and 2KHz I think they can be generated in 
compare mode...or perhaps in software.  I also need to trigger an ADC read 
during the high level of those pulses from time to time.

On Sun, Aug 1, 2021 at 2:17 PM Rob CJ  wrote:
>  
>  
>  Hi Vasile,
> 
>  
> 
> 
>  Not sure if I understood you correctly. If you want the PWM signals to be 
>exactly the same but only inverted you can use the bridge mode for one of the 
>PWM's that is when one output goes high the other goes low. 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  Kind regards,
> 
>  
> 
> 
>  Rob
> 
>  
> 
> 
> 
>  
> Van: jallib@googlegroups.com  namens vsurducan 
> 
> Verzonden: zondag 1 augustus 2021 10:14
> Aan: jallib@googlegroups.com 
> Onderwerp: [jallib] PWM versus enhanced PWM, oposite polarity output? 
>  
> 
> 
>  
>  
> Hi all,
> 
> PIC18F2550, 28pin PIC device has only the PWM implemented, the enhanced PWM 
> is available on 40/44pin devices only. However, If I want on a 28pin PIC  two 
> PWMs running at the same frequency, with the same duty-cycle, how can I 
> generate one active high and one active low PWM signals without using any 
> external inverter? No deadband between the output signals is required.
> 
> Any experience is appreciated.
> 
> thank you!
> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit  
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvHSZrsUtoF_1GcDrNS2_mup_hc5ZbYOuQu4uGw5TYuAQ%40mail.gmail.com.
> 
> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/AM0PR07MB624142E76C9FF412EBE22FC5E6EE9%40AM0PR07MB6241.eurprd07.prod.outlook.com.
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qstLOMHMLtJcLLEfywQ_%2BTYOWzEUCkLtghwrskyk%3DO%3DAg%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/592117056.1109097.1627829331026%40mail.yahoo.com.

Re: [jallib] Pin_c4 undefined in PIC18F2550 ?!?

2021-07-29 Thread 'Oliver Seitz' via jallib

Thanks! :-)

Greets,
Kiste




Am Donnerstag, 29. Juli 2021, 21:16:08 MESZ hat Rob CJ  
Folgendes geschrieben: 







Hello Oliver, Majid,




I fixed the device files with the missing RC4 and RC5 input pins. Will be 
available in the next bee release.




Kind regards,




Rob





 
Van: jallib@googlegroups.com  namens Rob CJ 

Verzonden: maandag 26 juli 2021 12:29
Aan: 'Oliver Seitz' via jallib 
Onderwerp: Re: [jallib] Pin_c4 undefined in PIC18F2550 ?!? 
 



Hi Oliver, Majid,




Thanks for the info. I will have a look at the Python script that generates the 
device files to see what is going on. I just  received a list of devices from 
Rob Hamerling for which the pins are missing (list below).




Once I fixed it  I will upload the device files so that they will be part of 
one of the bee packages.






























>  Device files with PORT_RC4 but missing pin_C4
> 

>  18f4450.jal
> 18f46j53.jal
> 18f2550.jal
> 18f4550.jal
> 18lf2450.jal
> 18lf2553.jal
> 18f2455.jal
> 18f4553.jal
> 18lf2455.jal
> 18lf4450.jal
> 18lf2550.jal
> 18lf4455.jal
> 18f4455.jal
> 18lf4550.jal
> 18lf4553.jal
> 18lf46j53.jal
> 18lf4458.jal
> 18lf27j53.jal
> 18f2553.jal
> 18f27j53.jal
> 18f26j53.jal
> 18f4458.jal
> 18lf47j53.jal
> 18f47j53.jal
> 18lf2458.jal
> 18lf26j53.jal
> 18f2450.jal
> 18f2458.jal
> Device files missing pin_C4: 28




























Kind regards,



Rob





________ 
Van: 'Oliver Seitz' via jallib 
Verzonden: maandag 26 juli 2021 09:06
Aan: 'Oliver Seitz' via jallib 
Onderwerp: Re: [jallib] Pin_c4 undefined in PIC18F2550 ?!? 
 



Sorry, my answer was not totally correct. Those pins are input only, the lat 
and the 'put parts are not available on that device. Also there's no direction 
for c4 and c5. Anyway, to be used as inputs, the pin_c4 and pin_c5 alias should 
be defined.

--
var volatile bit    pin_C4                    at PORTC : 4
--
var volatile bit    pin_C5                    at PORTC : 5
--

Greets,
Kiste





Am Montag, 26. Juli 2021, 09:01:31 MESZ hat 'Oliver Seitz' via jallib 
 Folgendes geschrieben: 





Hi Majid,

this time, you really spotted a device file error.

The chip has no pin_c3, but the device file does also not define the pins c4 
and c5, which is indeed an error of the device file.

Until the device file is fixed, add these lines to your program:

--
var volatile bit    LATC_LATC4                at LATC : 4
var volatile bit    pin_C4                    at PORTC : 4
--
procedure pin_C4'put(bit in x at LATC : 4) is
   pragma inline
end procedure
--
var volatile bit    LATC_LATC5                at LATC : 5
var volatile bit    pin_C5                    at PORTC : 5
--
procedure pin_C5'put(bit in x at LATC : 5) is
   pragma inline
end procedure
--


Greets,
Kiste

Am Montag, 26. Juli 2021, 08:48:48 MESZ hat majid ebru  
Folgendes geschrieben: 





Hi to all

I use PIC18F2550.

When I complie I have error

[Error] (X-GLCD-10.jal) [Line 69] "pin_c4" not defined
[Error] (X-GLCD-10.jal) [Line 69] '=' expected (got 'pin_c4_direction')
[Error] (X-GLCD-10.jal) [Line 70] "pin_c4_direction" not defined
[Error] (X-GLCD-10.jal) [Line 70] unexpected token: pin_c4_direction

Pin_c4 undefined ?!!Why 藍


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit  
https://groups.google.com/d/msgid/jallib/c16e1fb4-0547-48ef-9954-224bb58f8bf8n%40googlegroups.com.


-- 
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+unsubscr...@googlegroups.com.

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit  
https://groups.google.com/d/msgid/jallib/687613790.752262.1627283190792%40mail.yahoo.com.




-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit  
https://groups.google.com/d/msgid/jallib/AM0PR07MB6241B3541AF2D5239C145ACAE6E89%40AM0PR07MB6241.eurprd07.prod.outlook.com.



-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this gr

Re: [jallib] I can't use font8*12?!?

2021-07-28 Thread 'Oliver Seitz' via jallib

Hi Majid,

you see, it would probably need two or three workdays, maybe much more to make 
the characters able to rotate, be it only the 8*12 font, or all fonts, only by 
90 degrees or also by 270 or 180. 

Instead of just doing it, explaining all the steps to you would need about 
three times as long. 

Noone found the time to do that until now. I presume noone will find three 
times as long a time to not only do it, but teach you to do it.

If you can't find out to do it by yourself, I don't think you can urge someone 
else to do it for you just when you need it to be done, let alone teach you how 
to do it.

If you want to decide what other people do, in this world, you usually have to 
pay them.


Greets,
Kiste

Am Mittwoch, 28. Juli 2021, 12:40:58 MESZ hat majid ebru  
Folgendes geschrieben: 





please guide me

On Tuesday, July 27, 2021 at 10:13:36 PM UTC+4:30 majid ebru wrote:
> Hi Rob
> 
> I don't findout ?!樂
> 
> My program is above and I complie it and I don't see correctly?!
> 
> Can you guide me more?!!
> 
> Thank you
> 
> On Monday, July 26, 2021 at 11:16:29 PM UTC+4:30 rob...@hotmail.com wrote:
>>  
>>  
>>  
>>  
>>  Hi Majid,
>> 
>>  
>> 
>> 
>>  Make a copy, make the changes, test it and if it works we could add it to 
>>Jallib as an improved version.
>> 
>>  
>> 
>> 
>>  It may take you some time to fix it.
>> 
>> 
>>  
>> 
>> 
>> 
>> Met vriendelijke groet,
>> 
>> Rob Jansen 
>> 
>> 
>>  
>> From: jal...@googlegroups.com  on behalf of majid 
>> ebru 
>> Sent: Monday, July 26, 2021 8:22:20 PM
>> To: jallib 
>> Subject: Re: [jallib] I can't use font8*12?!? 
>>  
>> 
>> 
>> 
>> Hi Rob 
>> How can I do that?!
>> 
>> 
>> 
>> 
>> Kind regards
>> 
>> 
>> 
>>  
>> On Monday, July 26, 2021 at 9:13:47 PM UTC+4:30 rob...@hotmail.com wrote:
>> 
>> 
>>>  
>>>  
>>>  Hi Majid,
>>> 
>>>  
>>> 
>>> 
>>>  Normally a character fits on one row in height when it is at most 8 pixels 
>>>high so that's why it is straight forward to print a font like 5 * 7 or 6 
>>>*8. A 8 * 12 font does not fit on one row (12 pixels instead of 8) and if 
>>>you want to use that font anyway it is rotated but you then also have to 
>>>rotate your LCD.
>>> 
>>>  
>>> 
>>> 
>>>  A solution would be to implement the font without rotation but for that - 
>>>if I am correct - the driver needs to be updated.
>>> 
>>>  
>>> 
>>> 
>>>  Kind regards,
>>> 
>>>  
>>> Rob
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> Van: jal...@googlegroups.com  namens majid ebru 
>>> 
>>> Verzonden: maandag 26 juli 2021 12:34
>>> Aan: jallib 
>>> Onderwerp: [jallib] I can't use font8*12?!? 
>>>  
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  
>>> Hi to all 
>>> 
>>> 
>>> 
>>> I comeback
>>> 
>>> Don't worry , everything is ok
>>> 
>>> 藍藍藍
>>> 
>>> 
>>> 
>>> 
>>> I can't use font 8*12,
>>> 
>>> Can someone help and guide me ?!
>>> 
>>> 
>>> 
>>> 
>>> --;@main 
>>> 
>>> include 18f4520 
>>> 
>>> pragma target clock 8_000_000 -- xtal frequency 
>>> 
>>> pragma target OSC hs 
>>> 
>>> pragma target WDT disabled 
>>> 
>>> pragma target LVP disabled 
>>> 
>>> enable_digital_io() 
>>> 
>>> -- GRAPHIC_LCD IO definition -- 
>>> 
>>> var byte GLCD_DATAPRT is portD 
>>> 
>>> var byte GLCD_DATAPRT_DIR is portD_direction 
>>> 
>>> alias GLCD_E is pin_b0 
>>> 
>>> alias GLCD_RW is pin_b1 
>>> 
>>> alias GLCD_DI is pin_b2 
>>> 
>>> alias GLCD_CS1 is pin_b3 
>>> 
>>> alias GLCD_CS2 is pin_b4 
>>> 
>>> alias GLCD_RST is pin_b5 
>>> 
>>> -- 
>>> 
>>> alias GLCD_CS1_DIRECTION is pin_b3_direction 
>>> 
>>> alias GLCD_CS2_DIRECTION is pin_b4_direction 
>>> 
>>> alias GLCD_RST_DIRECTION is pin_b5_direction 
>>> 
>>> alias GLCD_E_DIRECTION is pin_b0_direction 
>>> 
>>> alias GLCD_RW_DIRECTION is pin_b1_direction 
>>> 
>>> alias GLCD_DI_DIRECTION is pin_b2_direction 
>>> 
>>> -- 
>>> 
>>> --const GLCD_CLIPPING = TRUE -- enable clipping (of ellipse) 
>>> 
>>> -- 
>>> 
>>> include delay 
>>> 
>>> include glcd_5x7_font 
>>> 
>>> include glcd_6x8_font 
>>> 
>>> include glcd_8x12_font 
>>> 
>>> include glcd_font 
>>> 
>>> glcd_font_use(FONT_5X7) 
>>> 
>>> -- 
>>> 
>>> include glcd_ks0108 
>>> 
>>> include glcd_common 
>>> 
>>> -- 
>>> 
>>> glcd_init() 
>>> 
>>> glcd_clear_screen() 
>>> 
>>>  
>>> 
>>> glcd_font_use(FONT_8X12) 
>>> 
>>> glcd_char_goto(1, 1) 
>>> 
>>> print_string(glcd,"Seting") 
>>> 
>>> delay_1s(2) 
>>> 
>>> - 
>>> 
>>> glcd_font_use(FONT_6X8) 
>>> 
>>> glcd_char_goto(1, 20) 
>>> 
>>> print_string(glcd,"Seting") 
>>> 
>>> delay_1s(2) 
>>> 
>>> - 
>>> 
>>> glcd_font_use(FONT_5X7) 
>>> 
>>> glcd_char_goto(1, 40) 
>>> 
>>> print_string(glcd,"Seting") 
>>> 
>>> delay_1s(2) 
>>> 
>>> - 
>>> 
>>> forever loop 
>>> 
>>> end loop 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google Groups

Re: [jallib] Re: Pin_c4 undefined in PIC18F2550 ?!?

2021-07-26 Thread 'Oliver Seitz' via jallib

Well... The answer on how to do it is easy. You simply can not. It is 
impossible. The pins do not have output transistors. There is no way to use c4 
or c5 as outputs.

If you can't use other pin locations or another type of controller, you have to 
solder wires to your board to be able to use other pins which do have output 
transistors.

There is no pin_c4_direction or pin_c5_direction because the hardware of those 
pins can not be outputs. 

See the attached bit of the datasheet. Pins c2 and c6 are called "Digital I/O". 
I/O stands for Input/Output. Pins c4 and c5 are called "Digital Input". That 
stands for Input and not Output.

Greets,
Kiste

Am Montag, 26. Juli 2021, 12:03:55 MESZ hat majid ebru  
Folgendes geschrieben: 

Ok Kiste 
Now How can I set direction and use alias ?!

On Monday, July 26, 2021 at 11:33:29 AM UTC+4:30 majid ebru wrote:
> Also
> Pin_c5 not defined in PIC18F2550 ?!
> 
> 
> On Monday, July 26, 2021 at 10:57:57 AM UTC+4:30 majid ebru wrote:
>> Hi to all
>> 
>> I use PIC18F2550.
>> 
>> When I complie I have error
>> 
>> [Error] (X-GLCD-10.jal) [Line 69] "pin_c4" not defined
>> [Error] (X-GLCD-10.jal) [Line 69] '=' expected (got 'pin_c4_direction')
>> [Error] (X-GLCD-10.jal) [Line 70] "pin_c4_direction" not defined
>> [Error] (X-GLCD-10.jal) [Line 70] unexpected token: pin_c4_direction
>> 
>> Pin_c4 undefined ?!!Why 藍

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/e449d318-0f82-4d48-959c-e608e1033b27n%40googlegroups.com
.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1965690428.773553.1627295505269%40mail.yahoo.com.

Re: [jallib] Re: Pin_c4 undefined in PIC18F2550 ?!?

2021-07-26 Thread 'Oliver Seitz' via jallib

Yes, if you need those locations as outputs, use a chip without USB module.

Greets,
Kiste




Am Montag, 26. Juli 2021, 09:25:24 MESZ hat majid ebru  
Folgendes geschrieben: 





藍

I use these pins for output ?!?

What can I do ?

I should change microcontroller type?!

On Monday, July 26, 2021 at 11:45:09 AM UTC+4:30 majid ebru wrote:
> Ok Kiste 
> Now How can I set direction and use alias ?!
> 
> 
> On Monday, July 26, 2021 at 11:33:29 AM UTC+4:30 majid ebru wrote:
>> Also
>> Pin_c5 not defined in PIC18F2550 ?!
>> 
>> 
>> On Monday, July 26, 2021 at 10:57:57 AM UTC+4:30 majid ebru wrote:
>>> Hi to all
>>> 
>>> I use PIC18F2550.
>>> 
>>> When I complie I have error
>>> 
>>> [Error] (X-GLCD-10.jal) [Line 69] "pin_c4" not defined
>>> [Error] (X-GLCD-10.jal) [Line 69] '=' expected (got 'pin_c4_direction')
>>> [Error] (X-GLCD-10.jal) [Line 70] "pin_c4_direction" not defined
>>> [Error] (X-GLCD-10.jal) [Line 70] unexpected token: pin_c4_direction
>>> 
>>> Pin_c4 undefined ?!!Why 藍


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/996df6cd-c0e6-4b30-9a3a-668b72659117n%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/14870481.747208.1627285503138%40mail.yahoo.com.

Re: [jallib] Pin_c4 undefined in PIC18F2550 ?!?

2021-07-26 Thread 'Oliver Seitz' via jallib

Sorry, my answer was not totally correct. Those pins are input only, the lat 
and the 'put parts are not available on that device. Also there's no direction 
for c4 and c5. Anyway, to be used as inputs, the pin_c4 and pin_c5 alias should 
be defined.

--
var volatile bit    pin_C4                    at PORTC : 4
--
var volatile bit    pin_C5                    at PORTC : 5
--

Greets,
Kiste





Am Montag, 26. Juli 2021, 09:01:31 MESZ hat 'Oliver Seitz' via jallib 
 Folgendes geschrieben: 





Hi Majid,

this time, you really spotted a device file error.

The chip has no pin_c3, but the device file does also not define the pins c4 
and c5, which is indeed an error of the device file.

Until the device file is fixed, add these lines to your program:

--
var volatile bit    LATC_LATC4                at LATC : 4
var volatile bit    pin_C4                    at PORTC : 4
--
procedure pin_C4'put(bit in x at LATC : 4) is
   pragma inline
end procedure
--
var volatile bit    LATC_LATC5                at LATC : 5
var volatile bit    pin_C5                    at PORTC : 5
--
procedure pin_C5'put(bit in x at LATC : 5) is
   pragma inline
end procedure
--


Greets,
Kiste

Am Montag, 26. Juli 2021, 08:48:48 MESZ hat majid ebru  
Folgendes geschrieben: 





Hi to all

I use PIC18F2550.

When I complie I have error

[Error] (X-GLCD-10.jal) [Line 69] "pin_c4" not defined
[Error] (X-GLCD-10.jal) [Line 69] '=' expected (got 'pin_c4_direction')
[Error] (X-GLCD-10.jal) [Line 70] "pin_c4_direction" not defined
[Error] (X-GLCD-10.jal) [Line 70] unexpected token: pin_c4_direction

Pin_c4 undefined ?!!Why 藍


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/c16e1fb4-0547-48ef-9954-224bb58f8bf8n%40googlegroups.com.


-- 
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+unsubscr...@googlegroups.com.

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/687613790.752262.1627283190792%40mail.yahoo.com.

Re: [jallib] Pin_c4 undefined in PIC18F2550 ?!?

2021-07-26 Thread 'Oliver Seitz' via jallib

Hi Majid,

this time, you really spotted a device file error.

The chip has no pin_c3, but the device file does also not define the pins c4 
and c5, which is indeed an error of the device file.

Until the device file is fixed, add these lines to your program:

--
var volatile bit    LATC_LATC4                at LATC : 4
var volatile bit    pin_C4                    at PORTC : 4
--
procedure pin_C4'put(bit in x at LATC : 4) is
   pragma inline
end procedure
--
var volatile bit    LATC_LATC5                at LATC : 5
var volatile bit    pin_C5                    at PORTC : 5
--
procedure pin_C5'put(bit in x at LATC : 5) is
   pragma inline
end procedure
--


Greets,
Kiste

Am Montag, 26. Juli 2021, 08:48:48 MESZ hat majid ebru  
Folgendes geschrieben: 





Hi to all

I use PIC18F2550.

When I complie I have error

[Error] (X-GLCD-10.jal) [Line 69] "pin_c4" not defined
[Error] (X-GLCD-10.jal) [Line 69] '=' expected (got 'pin_c4_direction')
[Error] (X-GLCD-10.jal) [Line 70] "pin_c4_direction" not defined
[Error] (X-GLCD-10.jal) [Line 70] unexpected token: pin_c4_direction

Pin_c4 undefined ?!!Why 藍


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/c16e1fb4-0547-48ef-9954-224bb58f8bf8n%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1669519631.747340.1627282888545%40mail.yahoo.com.

Re: [jallib] how can i disable WDT in PIC18F2550?!?

2021-07-26 Thread 'Oliver Seitz' via jallib

Hi Majid,

don't change the device file, it is useless. The chip only has the options of
"enabled" and "control", no matter what names you give to the options.

It's explained in the comments you copied: If you set the pragma to "control",
the bit SWDTEN controls the watchdog. Presumably that bit by default disables
the watchdog, but to be sure, have a look in the device's datasheet.

Greets,
Kiste

Am Montag, 26. Juli 2021, 08:27:55 MESZ hat majid ebru
Folgendes geschrieben:

Hi to all

i use PIC18F2550.
when i compile my program.i see error:
unknown pragma target: wdt pragma

how can i disable WDT??

i opened 18f2550.jal and go to line :

pragma fuse_def WDT:3 0x1 { -- Watchdog Timer Enable bit
ENABLED = 0x1 -- WDT enabled
CONTROL = 0x0 -- WDT disabled (control is placed on the SWDTEN bit)
}

and change CONTROL to DISABLE .

is it true??

please help and guide me

kind regards

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/2b08c525-38f4-4882-aab1-c9d57ccb046cn%40googlegroups.com.

Re: [jallib] New - Dutch - book on programming PIC microcontrollers with JAL

2021-06-22 Thread 'Oliver Seitz' via jallib

Oh! That is *very* good to know, thanks! Maybe I'll have to dump my ICD3, as it 
doesn't support Qx0/Qx1/Qx3/Qx4 :-(

Greets,
Kiste




Am Dienstag, 22. Juni 2021, 09:13:31 MESZ hat 'Evan Venn' via jallib 
 Folgendes geschrieben: 






The product is not available from Microchip – correct.
 
But, Microchip Open Sourced PK2 in 2009 and PK3 in 2012.  Which means there are 
hardware developers selling PK2 and PK3.
 
As of 2021 we were appointed as a Microchip Partner to provide PICKITPlus 
software for the PK2 and PK3.
 
PK2 and PK3 are not dead. Far from it.  We are adding the Q83 and Q84 this 
month.  We have software for Windows, Linus, Pi. And, we have many software 
options across these operating systems.
 

 
Evan
 
 
Sent from Mail for Windows 10
 
From: 'Oliver Seitz' via jallib
Sent: 22 June 2021 07:31
To: 'evan@googlemail.com' via jallib
Subject: Re: [jallib] New - Dutch - book on programming PIC microcontrollers 
with JAL
 
Hi Evan,
 
"Status: No Longer Available" says Microchip website about PICKit2 *and* 
PICKit3. The book addresses people who never have used microcontrollers, they 
presumably don't have any equipment already. I think it's ok not to talk about 
the device peceeding the now-obsolete device.
 
 
Greets,
Kiste
 
 
Am Dienstag, 22. Juni 2021, 07:54:18 MESZ hat 'evan@googlemail.com' via 
jallib  Folgendes geschrieben: 
 
 
 
 
 
Interesting book. I do hope it sells.
 
Has anyone read the book?  What was said about PICKit3?  and why is PICKit2 
missing?   With PICKitPlus supporting most operating systems and the Microchip 
PIC range I would like to see this in the book.
 
Anyone got any insights?
 
Evan
 
On Tuesday, 22 June 2021 at 06:04:44 UTC+1 rob...@hotmail.com wrote:
>  
>  
>  
>  
>  The book is about getting started with programming microcontrollers without 
>having any prior knowledge about programming nor electronics and it uses JAL 
>as programming language. You can read part of the book on the Elektor website. 
>So it is different from most other books for which you need to have some basic 
>knowledge.
> 
>  
> 
> 
>  I heard from Peter that an English version is depending on the sales of the 
>Dutch version.
> 
> 
>  
> 
> 
> 
> Met vriendelijke groet,
> 
> Rob Jansen 
> 
> 
>  
> From: jal...@googlegroups.com  on behalf of hans 
> 
> Sent: Monday, June 21, 2021 9:57:43 PM
> To: jallib 
> Subject: Re: [jallib] New - Dutch - book on programming PIC microcontrollers 
> with JAL 
>  
> 
> 
> 
> Have a look at this 
> 
> 
>  
> Op maandag 21 juni 2021 om 09:17:38 UTC+2 schreef Kiste:
> 
> 
>>  Hi Rob, 
>> 
>> very interesting, I'm not sure if I'll buy it, it's quite pricy.. Usually, 
>> I'm learning from datasheets, so I don't know if I would learn a lot about 
>> PICs. But I would definitely improve my dutch reading abilities ;-) 
>> 
>> Greets, 
>> Kiste 
>> 
>> 
>> 
>> 
>> Am Montag, 21. Juni 2021, 08:46:06 MESZ hat rob...@hotmail.com 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> Hi all, 
>> 
>> This information is meant for people that are capable of reading Dutch. 
>> 
>> Peter Zwart recently wrote a Dutch book called (translated) 'Programming 
>> Microcontrollers - Learn to program PIC-Microcontrollers with JAL in 60 
>> lessons'. 
>> 
>> If I understood Peter right, the book does not use custom made JAL libraries 
>> like the other books on JAL written by Bert van Dam but uses JAL as it is. 
>> 
>> So if you are interested or know somebody who wants to start with 
>> programming PIC microcontrollers, you could buy this book (I will, since I 
>> want to know what I do not yet know about PIC microcontrollers ) 
>> See: Microcontrollers Programmeren, Peter Zwart | 9789053813072 | Boek -  
>> bookspot.nl 
>> 
>> This book will help to improve the popularity of JAL and increase the JAL 
>> community. 
>> 
>> Kind regards, 
>> 
>> Rob 
>> 
>> 
>> 
>> -- 
>> 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+u...@googlegroups.com. 
>> To view this discussion on the web visit  
>> https://groups.google.com/d/msgid/jallib/3f37bf5c-94f7-459c-b31e-b2e6a995a23dn%40googlegroups.com.
>>  
>> 
>> 
>> 
>  
>  
> 
> -- 
> 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

Re: [jallib] New - Dutch - book on programming PIC microcontrollers with JAL

2021-06-22 Thread 'Oliver Seitz' via jallib

Hi Evan,

"Status: No Longer Available" says Microchip website about PICKit2 *and* 
PICKit3. The book addresses people who never have used microcontrollers, they 
presumably don't have any equipment already. I think it's ok not to talk about 
the device peceeding the now-obsolete device.


Greets,
Kiste


Am Dienstag, 22. Juni 2021, 07:54:18 MESZ hat 'evan@googlemail.com' via 
jallib  Folgendes geschrieben: 





Interesting book. I do hope it sells.

Has anyone read the book?  What was said about PICKit3?  and why is PICKit2 
missing?   With PICKitPlus supporting most operating systems and the Microchip 
PIC range I would like to see this in the book.

Anyone got any insights?

Evan

On Tuesday, 22 June 2021 at 06:04:44 UTC+1 rob...@hotmail.com wrote:
>  
>  
>  
>  
>  The book is about getting started with programming microcontrollers without 
>having any prior knowledge about programming nor electronics and it uses JAL 
>as programming language. You can read part of the book on the Elektor website. 
>So it is different from most other books for which you need to have some basic 
>knowledge.
> 
>  
> 
> 
>  I heard from Peter that an English version is depending on the sales of the 
>Dutch version.
> 
> 
>  
> 
> 
> 
> Met vriendelijke groet,
> 
> Rob Jansen 
> 
> 
>  
> From: jal...@googlegroups.com  on behalf of hans 
> 
> Sent: Monday, June 21, 2021 9:57:43 PM
> To: jallib 
> Subject: Re: [jallib] New - Dutch - book on programming PIC microcontrollers 
> with JAL 
>  
> 
> 
> 
> Have a look at this 
> 
> 
>  
> Op maandag 21 juni 2021 om 09:17:38 UTC+2 schreef Kiste:
> 
> 
>>  Hi Rob, 
>> 
>> very interesting, I'm not sure if I'll buy it, it's quite pricy... Usually, 
>> I'm learning from datasheets, so I don't know if I would learn a lot about 
>> PICs. But I would definitely improve my dutch reading abilities ;-) 
>> 
>> Greets, 
>> Kiste 
>> 
>> 
>> 
>> 
>> Am Montag, 21. Juni 2021, 08:46:06 MESZ hat rob...@hotmail.com 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> Hi all, 
>> 
>> This information is meant for people that are capable of reading Dutch. 
>> 
>> Peter Zwart recently wrote a Dutch book called (translated) 'Programming 
>> Microcontrollers - Learn to program PIC-Microcontrollers with JAL in 60 
>> lessons'. 
>> 
>> If I understood Peter right, the book does not use custom made JAL libraries 
>> like the other books on JAL written by Bert van Dam but uses JAL as it is. 
>> 
>> So if you are interested or know somebody who wants to start with 
>> programming PIC microcontrollers, you could buy this book (I will, since I 
>> want to know what I do not yet know about PIC microcontrollers ) 
>> See: Microcontrollers Programmeren, Peter Zwart | 9789053813072 | Boek -  
>> bookspot.nl 
>> 
>> This book will help to improve the popularity of JAL and increase the JAL 
>> community. 
>> 
>> Kind regards, 
>> 
>> Rob 
>> 
>> 
>> 
>> -- 
>> 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/3f37bf5c-94f7-459c-b31e-b2e6a995a23dn%40googlegroups.com.
>>  
>> 
>> 
>> 
>  
>  
> 
> -- 
> 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/5d5e78e7-15bc-49cc-8053-c43fae2e91d0n%40googlegroups.com.
> 
> 
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/09255233-6527-46b2-ad79-e15fbf992558n%40googlegroups.com
.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/786452631.1417760.1624343482740%40mail.yahoo.com.

Re: [jallib] New - Dutch - book on programming PIC microcontrollers with JAL

2021-06-22 Thread 'Oliver Seitz' via jallib

Dank je wel! It's a good oversight on the scope of the book, which seems really 
good to learn the basics.

One chapter drew my special focus: "Job 18: ADC high and low resolution and 
updating the library... Page 206"

Might be we're discussing how to make that chapter outdated in another thread 
right now... If the book really uses jallib. Another chapter title mentions 
"RS232_hw", which does not look like "live" jallib. Maybe it's a mirror or fork.

Greets,
Kiste (of doos in nederlands ;-) )  






Am Montag, 21. Juni 2021, 21:57:50 MESZ hat hans 
 Folgendes geschrieben: 





Have a look at this 

Op maandag 21 juni 2021 om 09:17:38 UTC+2 schreef Kiste:
> Hi Rob, 
> 
> very interesting, I'm not sure if I'll buy it, it's quite pricy... Usually, 
> I'm learning from datasheets, so I don't know if I would learn a lot about 
> PICs. But I would definitely improve my dutch reading abilities ;-) 
> 
> Greets, 
> Kiste 
> 
> 
> 
> 
> Am Montag, 21. Juni 2021, 08:46:06 MESZ hat rob...@hotmail.com 
>  Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Hi all, 
> 
> This information is meant for people that are capable of reading Dutch. 
> 
> Peter Zwart recently wrote a Dutch book called (translated) 'Programming 
> Microcontrollers - Learn to program PIC-Microcontrollers with JAL in 60 
> lessons'. 
> 
> If I understood Peter right, the book does not use custom made JAL libraries 
> like the other books on JAL written by Bert van Dam but uses JAL as it is. 
> 
> So if you are interested or know somebody who wants to start with programming 
> PIC microcontrollers, you could buy this book (I will, since I want to know 
> what I do not yet know about PIC microcontrollers ) 
> See: Microcontrollers Programmeren, Peter Zwart | 9789053813072 | Boek - 
> bookspot.nl 
> 
> This book will help to improve the popularity of JAL and increase the JAL 
> community. 
> 
> Kind regards, 
> 
> Rob 
> 
> 
> 
> -- 
> 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/3f37bf5c-94f7-459c-b31e-b2e6a995a23dn%40googlegroups.com.
>  
> 
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/5d5e78e7-15bc-49cc-8053-c43fae2e91d0n%40googlegroups.com
.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1071269461.1242613.1624342662898%40mail.yahoo.com.

Re: [jallib] New - Dutch - book on programming PIC microcontrollers with JAL

2021-06-21 Thread 'Oliver Seitz' via jallib

Hi Rob,

very interesting, I'm not sure if I'll buy it, it's quite pricy... Usually, I'm
learning from datasheets, so I don't know if I would learn a lot about PICs.
But I would definitely improve my dutch reading abilities ;-)

Greets,
Kiste

Am Montag, 21. Juni 2021, 08:46:06 MESZ hat rob...@hotmail.com
Folgendes geschrieben:

Hi all,

This information is meant for people that are capable of reading Dutch.

Peter Zwart recently wrote a Dutch book called (translated) 'Programming
Microcontrollers - Learn to program PIC-Microcontrollers with JAL in 60
lessons'.

If I understood Peter right, the book does not use custom made JAL libraries
like the other books on JAL written by Bert van Dam but uses JAL as it is.

So if you are interested or know somebody who wants to start with programming
PIC microcontrollers, you could buy this book (I will, since I want to know
what I do not yet know about PIC microcontrollers )
See: Microcontrollers Programmeren, Peter Zwart | 9789053813072 | Boek -
bookspot.nl

This book will help to improve the popularity of JAL and increase the JAL
community.

Kind regards,

Rob

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/3f37bf5c-94f7-459c-b31e-b2e6a995a23dn%40googlegroups.com.

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

Hi Majid,

no need to call me "god", "excellency" would highly suffice.

You have been told to use serial_hw_int_cts, as serial_software is always a 
blocking read?

Yes, your program HAS TO STOP DOING ANYTHING ELSE, while serial_software 
listens for data on its input pin.

I'm starting to ask myself, what for do I explain all that lot, if you choose 
to ignore most of my words?

Greets,
Kiste




Am Samstag, 24. April 2021, 19:57:01 MESZ hat majid ebru  
Folgendes geschrieben: 





oh my god

if i change this bit , i don't have any communication between PICs.
just in this mode(Master = "const serial_sw_invert = false" and Slave "const 
serial_sw_invert = true"  , you write mistake ) 
, i can send/receive and in other modes , i can't send/receive and PICs stopped 
(because i have a led  for blanking ,in other modes led doesn't work)

how do i do for solve?


On Saturday, April 24, 2021 at 9:58:18 PM UTC+4:30 Kiste wrote:
> Master has 
> 
> "const serial_sw_invert = true" 
> 
> Slave has 
> 
> "const serial_sw_invert = false" 
> 
> That is what I meant by mismatched polarity 
> 
> 
> 
> 
> 
> 
> Am Samstag, 24. April 2021, 19:19:14 MESZ hat majid ebru  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Thank you 
> this is minimum. 
> 
> On Saturday, April 24, 2021 at 8:43:59 PM UTC+4:30 rob...@hotmail.com wrote: 
>>   
>>   
>>  Hi Majid, 
>> 
>>   
>> 
>> 
>>  Discussing this without any sample program doet not help to analyze the 
>>problem. 
>> 
>>   
>> 
>> 
>>  Back to my previous question. Did you minimize the program so that you are 
>>only testing the communication? 
>> 
>>   
>> 
>> 
>>  Can you send a sample program and maybe also a schematic diagram of the 
>>hardware you are using? 
>> 
>>   
>> 
>> 
>>  Kind regards, 
>> 
>>   
>> 
>> 
>>  Rob 
>> 
>>   
>> 
>> 
>> 
>>  
>> 
>> Van: jal...@googlegroups.com  namens majid ebru 
>>  
>> Verzonden: zaterdag 24 april 2021 17:35 
>> Aan: jallib Onderwerp: Re: NT: [jallib] How to send 
>> & receive data over medium distance 
>> Reverse polarity?! 
>> Sorry but how do I do that?! 
>> 
>>   
>> On Saturday, April 24, 2021 at 7:24:34 PM UTC+4:30 Kiste wrote: 
>> 
>> 
>>>  So you're sending 57 (=0b00111001 or "9") and receiving 99 (=0b01100011 or 
>>>"c").  Could be reverse polarity. 
>>> 
>>> 
>>> 
>>> Am Samstag, 24. April 2021, 16:41:57 MESZ hat majid ebru 
>>>  Folgendes geschrieben: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Hi 
>>> 
>>> PIc1(sender) : 
>>> forever loop 
>>>     if btn1 then block 
>>>     serial_sw_data = "9" 
>>>     delay_1ms(5) 
>>>     end if 
>>> end loop 
>>> - 
>>> 
>>> 
>>> 
>>> PIc2(receiver) : 
>>> forever loop 
>>>     if (serial_sw_read(char)) then block 
>>>  lcd_cursor_position(1,1) 
>>>          print_byte_dec(lcd, char+ "0")  -- ==> i see in LCD :  147 
>>> -- 
>>>          lcd_cursor_position(1,8) -- ==> i see in LCD : (  c  )  --  
>>> character c 
>>>          lcd = char 
>>>  end block 
>>>     end if 
>>> end loop 
>>> - 
>>> 
>>> On Saturday, April 24, 2021 at 5:56:21 PM UTC+4:30 majid ebru wrote: 
>>>> 
>>>> Hi again 
>>>> 
>>>> I'm very confused. 
>>>> 
>>>> Why can't I send and receive?!? 
>>>> 
>>>> I tested both codes,integer and ASCII code , but I read incorrect data. 
>>>> 
>>>> What is your suggestions ?! 
>>>> On Saturday, April 24, 2021 at 2:23:56 PM UTC+4:30 Kiste wrote: 
>>>>> It is important whether you use one or the other. If the sender speaks 
>>>>> tagalog, and the receiver expects to hear mandarin, they won't be able to 
>>>>> communicate. 
>>>>> 
>>>>> Greets, 
>>>>> Kiste 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Am Samstag, 24. April 2021, 11:49:49 MESZ hat majid ebru 
>>>>>  Folgen

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

Master has

"const serial_sw_invert = true"

Slave has

"const serial_sw_invert = false"

That is what I meant by mismatched polarity






Am Samstag, 24. April 2021, 19:19:14 MESZ hat majid ebru  
Folgendes geschrieben: 





Thank you
this is minimum. 

On Saturday, April 24, 2021 at 8:43:59 PM UTC+4:30 rob...@hotmail.com wrote:
>  
>  
>  Hi Majid,
> 
>  
> 
> 
>  Discussing this without any sample program doet not help to analyze the 
>problem.
> 
>  
> 
> 
>  Back to my previous question. Did you minimize the program so that you are 
>only testing the communication?
> 
>  
> 
> 
>  Can you send a sample program and maybe also a schematic diagram of the 
>hardware you are using?
> 
>  
> 
> 
>  Kind regards,
> 
>  
> 
> 
>  Rob
> 
>  
> 
> 
> 
>  
> 
> Van: jal...@googlegroups.com  namens majid ebru 
> 
> Verzonden: zaterdag 24 april 2021 17:35
> Aan: jallib Onderwerp: Re: NT: [jallib] How to send 
> & receive data over medium distance
> Reverse polarity?! 
> Sorry but how do I do that?!
> 
>  
> On Saturday, April 24, 2021 at 7:24:34 PM UTC+4:30 Kiste wrote:
> 
> 
>>  So you're sending 57 (=0b00111001 or "9") and receiving 99 (=0b01100011 or 
>>"c").  Could be reverse polarity. 
>> 
>> 
>> 
>> Am Samstag, 24. April 2021, 16:41:57 MESZ hat majid ebru 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> Hi 
>> 
>> PIc1(sender) : 
>> forever loop 
>>     if btn1 then block 
>>     serial_sw_data = "9" 
>>     delay_1ms(5) 
>>     end if 
>> end loop 
>> - 
>> 
>> 
>> 
>> PIc2(receiver) : 
>> forever loop 
>>     if (serial_sw_read(char)) then block 
>>  lcd_cursor_position(1,1) 
>>          print_byte_dec(lcd, char+ "0")  -- ==> i see in LCD :  147 
>> -- 
>>          lcd_cursor_position(1,8) -- ==> i see in LCD : (  c  )  --  
>> character c 
>>          lcd = char 
>>  end block 
>>     end if 
>> end loop 
>> - 
>> 
>> On Saturday, April 24, 2021 at 5:56:21 PM UTC+4:30 majid ebru wrote: 
>>> 
>>> Hi again 
>>> 
>>> I'm very confused. 
>>> 
>>> Why can't I send and receive?!? 
>>> 
>>> I tested both codes,integer and ASCII code , but I read incorrect data. 
>>> 
>>> What is your suggestions ?! 
>>> On Saturday, April 24, 2021 at 2:23:56 PM UTC+4:30 Kiste wrote: 
>>>> It is important whether you use one or the other. If the sender speaks 
>>>> tagalog, and the receiver expects to hear mandarin, they won't be able to 
>>>> communicate. 
>>>> 
>>>> Greets, 
>>>> Kiste 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Am Samstag, 24. April 2021, 11:49:49 MESZ hat majid ebru 
>>>>  Folgendes geschrieben: 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Hi 
>>>> 
>>>> It isn't important that I read ASCII or  . 
>>>> It is important that I read true. 
>>>> 
>>>> Thanks , I will test and I say result. 
>>>> 
>>>> On Saturday, April 24, 2021 at 11:59:22 AM UTC+4:30  rob...@hotmail.com 
>>>> wrote: 
>>>>>   
>>>>>   
>>>>>  Hi Majid, 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>>  If you want to print it  - as ASCII -on the receiving side, change 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>>  temp[i] = char  
>>>>> 
>>>>>  by 
>>>>> 
>>>>>  temp[i] = char + "0" 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>>  Then you can print it. 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>>  Kind regards, 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>>  Rob 
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> Van: 'Oliver Seitz' via jallib Verzo

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

So you're sending 57 (=0b00111001 or "9") and receiving 99 (=0b01100011 or 
"c").  Could be reverse polarity. 



Am Samstag, 24. April 2021, 16:41:57 MESZ hat majid ebru  
Folgendes geschrieben: 





Hi

PIc1(sender) :
forever loop
    if btn1 then block
    serial_sw_data = "9"
    delay_1ms(5)
    end if
end loop
-



PIc2(receiver) :
forever loop
    if (serial_sw_read(char)) then block
 lcd_cursor_position(1,1)
         print_byte_dec(lcd, char+ "0")  -- ==> i see in LCD :  147
--
         lcd_cursor_position(1,8) -- ==> i see in LCD : (  c  )  --  character 
c 
         lcd = char
 end block
    end if
end loop
-

On Saturday, April 24, 2021 at 5:56:21 PM UTC+4:30 majid ebru wrote:
> 
> Hi again
> 
> I'm very confused.
> 
> Why can't I send and receive?!?
> 
> I tested both codes,integer and ASCII code , but I read incorrect data.
> 
> What is your suggestions ?!
> On Saturday, April 24, 2021 at 2:23:56 PM UTC+4:30 Kiste wrote:
>> It is important whether you use one or the other. If the sender speaks 
>> tagalog, and the receiver expects to hear mandarin, they won't be able to 
>> communicate. 
>> 
>> Greets, 
>> Kiste 
>> 
>> 
>> 
>> 
>> 
>> 
>> Am Samstag, 24. April 2021, 11:49:49 MESZ hat majid ebru 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> Hi 
>> 
>> It isn't important that I read ASCII or  . 
>> It is important that I read true. 
>> 
>> Thanks , I will test and I say result. 
>> 
>> On Saturday, April 24, 2021 at 11:59:22 AM UTC+4:30 rob...@hotmail.com 
>> wrote: 
>>>   
>>>   
>>>  Hi Majid, 
>>> 
>>>   
>>> 
>>> 
>>>  If you want to print it  - as ASCII -on the receiving side, change 
>>> 
>>>   
>>> 
>>> 
>>>  temp[i] = char  
>>> 
>>>  by 
>>> 
>>>  temp[i] = char + "0" 
>>> 
>>>   
>>> 
>>> 
>>>  Then you can print it. 
>>> 
>>>   
>>> 
>>> 
>>>  Kind regards, 
>>> 
>>>   
>>> 
>>> 
>>>  Rob 
>>> 
>>>   
>>> 
>>> 
>>> 
>>>  
>>> Van: 'Oliver Seitz' via jallib Verzonden: zaterdag 
>>> 24 april 2021 09:07Aan: jal...@googlegroups.com  
>>> Onderwerp: Re: NT: [jallib] How to send & receive data over medium distance 
>>> You're sending binary and trying to receive ad ASCII 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am Samstag, 24. April 2021, 09:00:37 MESZ hat majid ebru 
>>>  Folgendes geschrieben: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> For example,I want to send 642  
>>> 
>>> I use this code in sender 
>>> ... 
>>> Serial_sw_data = 6 
>>> Delay_1ms(2) 
>>> Serial_sw_data = 4 
>>> Delay_1ms(2) 
>>> Serial_sw_data = 2 
>>> Delay_1ms(2) 
>>> ... 
>>> 
>>> But in receiver , I can't read correctly. 
>>> 
>>> Var byte Temp[3] 
>>> Var byte i = 0 
>>> For loop 
>>>   If serial_sw_read(char) then 
>>>     Temp[i] = char 
>>>      Print_string(lcd,Temp[i]) 
>>>      i = i + 1 
>>>      If 2 < i then i = 0 end if 
>>> End loop 
>>> On Saturday, April 24, 2021 at 11:19:31 AM UTC+4:30 majid ebru wrote: 
>>>> Thank all 
>>>> 
>>>> But I need sample code for read. 
>>>> 
>>>> Almost ,all documents use write code and I didn't saw read code. 
>>>> 
>>>> 
>>>> On Saturday, April 24, 2021 at 10:58:36 AM UTC+4:30 vasile wrote: 
>>>>> Majid, one good practice when you're testing communication between two 
>>>>> embedded systems (A and B) is to check each one with a terminal first. 
>>>>> 
>>>>> Assuming A is sending to B and B receives and does something on IO port, 
>>>>> test first the TX of A to the computer terminal, then RX of B from the 
>>>>> computer terminal. After that, only if each one works ok, connect TX/RX 
>>>>> of A with B.  Some good free terminals for this job (search for:) 
>>>>> Realterm, Teraterm, Termite. You may also need a hardware converter which 
>>>&g

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

did you ever try the suggestion about connecting a computer terminal? I'd 
recommend minicom on linux.
Did you ever send "hello world" to the LCD? Did you send 123? And 1 2 3? And 
the result of 3*12?

If you haven't released a baloon and thrown a paper plane, don't try to become 
a rocket scientist.

Greets,
Kiste







Am Samstag, 24. April 2021, 15:31:43 MESZ hat majid ebru  
Folgendes geschrieben: 






Hi again

I'm very confused.

Why can't I send and receive?!?

I tested both codes,integer and ASCII code , but I read incorrect data.

What is your suggestions ?!
On Saturday, April 24, 2021 at 2:23:56 PM UTC+4:30 Kiste wrote:
> It is important whether you use one or the other. If the sender speaks 
> tagalog, and the receiver expects to hear mandarin, they won't be able to 
> communicate. 
> 
> Greets, 
> Kiste 
> 
> 
> 
> 
> 
> 
> Am Samstag, 24. April 2021, 11:49:49 MESZ hat majid ebru  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Hi 
> 
> It isn't important that I read ASCII or  . 
> It is important that I read true. 
> 
> Thanks , I will test and I say result. 
> 
> On Saturday, April 24, 2021 at 11:59:22 AM UTC+4:30 rob...@hotmail.com wrote: 
>>   
>>   
>>  Hi Majid, 
>> 
>>   
>> 
>> 
>>  If you want to print it  - as ASCII -on the receiving side, change 
>> 
>>   
>> 
>> 
>>  temp[i] = char  
>> 
>>  by 
>> 
>>  temp[i] = char + "0" 
>> 
>>   
>> 
>> 
>>  Then you can print it. 
>> 
>>   
>> 
>> 
>>  Kind regards, 
>> 
>>   
>> 
>> 
>>  Rob 
>> 
>>   
>> 
>> 
>> 
>>  
>> Van: 'Oliver Seitz' via jallib Verzonden: zaterdag 
>> 24 april 2021 09:07Aan: jal...@googlegroups.com  
>> Onderwerp: Re: NT: [jallib] How to send & receive data over medium distance 
>> You're sending binary and trying to receive ad ASCII 
>> 
>> 
>> 
>> 
>> 
>> 
>> Am Samstag, 24. April 2021, 09:00:37 MESZ hat majid ebru 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> For example,I want to send 642  
>> 
>> I use this code in sender 
>> ... 
>> Serial_sw_data = 6 
>> Delay_1ms(2) 
>> Serial_sw_data = 4 
>> Delay_1ms(2) 
>> Serial_sw_data = 2 
>> Delay_1ms(2) 
>> ... 
>> 
>> But in receiver , I can't read correctly. 
>> 
>> Var byte Temp[3] 
>> Var byte i = 0 
>> For loop 
>>   If serial_sw_read(char) then 
>>     Temp[i] = char 
>>      Print_string(lcd,Temp[i]) 
>>      i = i + 1 
>>      If 2 < i then i = 0 end if 
>> End loop 
>> On Saturday, April 24, 2021 at 11:19:31 AM UTC+4:30 majid ebru wrote: 
>>> Thank all 
>>> 
>>> But I need sample code for read. 
>>> 
>>> Almost ,all documents use write code and I didn't saw read code. 
>>> 
>>> 
>>> On Saturday, April 24, 2021 at 10:58:36 AM UTC+4:30 vasile wrote: 
>>>> Majid, one good practice when you're testing communication between two 
>>>> embedded systems (A and B) is to check each one with a terminal first. 
>>>> 
>>>> Assuming A is sending to B and B receives and does something on IO port, 
>>>> test first the TX of A to the computer terminal, then RX of B from the 
>>>> computer terminal. After that, only if each one works ok, connect TX/RX of 
>>>> A with B.  Some good free terminals for this job (search for:) Realterm, 
>>>> Teraterm, Termite. You may also need a hardware converter which depends on 
>>>> your computer (if you have a real COM port with RS232 levels or just an 
>>>> USB/RS232 with 3.3V or 5V levels). 
>>>>  
>>>> This approach will protect you from a lot of trouble and make you 
>>>> understand if a byte, a word, an ASCII or something else is truly 
>>>> sent/received and was sent/received in the right order. 
>>>> 
>>>> Simplify your work by sending and receiving ASCII symbols first and then 
>>>> understand all the used procedures from the libraries (this is mandatory 
>>>> to understand which is your fault/misunderstanding or which is the 
>>>> software bug... there are bugs in any software...:) ). 
>>>> 
>>>> 
>>>> 
>>>> On Sat, Apr 24, 2021 at 8:36 AM Rob CJ  wrote: 
>>>>>   
>>>>>   
>>>>>  Hi Majid, 
>>&

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

It is important whether you use one or the other. If the sender speaks tagalog, 
and the receiver expects to hear mandarin, they won't be able to communicate.

Greets,
Kiste






Am Samstag, 24. April 2021, 11:49:49 MESZ hat majid ebru  
Folgendes geschrieben: 





Hi

It isn't important that I read ASCII or  .
It is important that I read true.

Thanks , I will test and I say result.

On Saturday, April 24, 2021 at 11:59:22 AM UTC+4:30 rob...@hotmail.com wrote:
>  
>  
>  Hi Majid,
> 
>  
> 
> 
>  If you want to print it  - as ASCII -on the receiving side, change
> 
>  
> 
> 
>  temp[i] = char 
> 
>  by
> 
>  temp[i] = char + "0"
> 
>  
> 
> 
>  Then you can print it.
> 
>  
> 
> 
>  Kind regards,
> 
>  
> 
> 
>  Rob
> 
>  
> 
> 
> 
>  
> Van: 'Oliver Seitz' via jallib Verzonden: zaterdag 
> 24 april 2021 09:07Aan: jal...@googlegroups.com 
> Onderwerp: Re: NT: [jallib] How to send & receive data over medium distance
> You're sending binary and trying to receive ad ASCII
> 
> 
> 
> 
> 
> 
> Am Samstag, 24. April 2021, 09:00:37 MESZ hat majid ebru  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> For example,I want to send 642 
> 
> I use this code in sender
> ...
> Serial_sw_data = 6
> Delay_1ms(2)
> Serial_sw_data = 4
> Delay_1ms(2)
> Serial_sw_data = 2
> Delay_1ms(2)
> ...
> 
> But in receiver , I can't read correctly.
> 
> Var byte Temp[3]
> Var byte i = 0
> For loop
>   If serial_sw_read(char) then
>     Temp[i] = char
>      Print_string(lcd,Temp[i])
>      i = i + 1
>      If 2 < i then i = 0 end if
> End loop
> On Saturday, April 24, 2021 at 11:19:31 AM UTC+4:30 majid ebru wrote:
>> Thank all
>> 
>> But I need sample code for read.
>> 
>> Almost ,all documents use write code and I didn't saw read code.
>> 
>> 
>> On Saturday, April 24, 2021 at 10:58:36 AM UTC+4:30 vasile wrote:
>>> Majid, one good practice when you're testing communication between two 
>>> embedded systems (A and B) is to check each one with a terminal first. 
>>> 
>>> Assuming A is sending to B and B receives and does something on IO port, 
>>> test first the TX of A to the computer terminal, then RX of B from the 
>>> computer terminal. After that, only if each one works ok, connect TX/RX of 
>>> A with B.  Some good free terminals for this job (search for:) Realterm, 
>>> Teraterm, Termite. You may also need a hardware converter which depends on 
>>> your computer (if you have a real COM port with RS232 levels or just an 
>>> USB/RS232 with 3.3V or 5V levels). 
>>>  
>>> This approach will protect you from a lot of trouble and make you 
>>> understand if a byte, a word, an ASCII or something else is truly 
>>> sent/received and was sent/received in the right order. 
>>> 
>>> Simplify your work by sending and receiving ASCII symbols first and then 
>>> understand all the used procedures from the libraries (this is mandatory to 
>>> understand which is your fault/misunderstanding or which is the software 
>>> bug... there are bugs in any software...:) ).
>>> 
>>> 
>>> 
>>> On Sat, Apr 24, 2021 at 8:36 AM Rob CJ  wrote:
>>>>  
>>>>  
>>>>  Hi Majid,
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  If you want to send an integer value you indeed have to send it in bytes. 
>>>>But that thouls be faily easy with JAL.
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  If have for example a variable of type word you can do the following
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  var word my_word_variable
>>>> 
>>>>  var byte  my_byte_variable_low at my_word_variable
>>>> 
>>>>  var byte my_byte_high at my_word_variable + 1
>>>> 
>>>>  
>>>> 
>>>>  You can then send both 'my_byte' variables separately and in the other 
>>>>PIC you do the same, read the two bytes which are mapped to a word.
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  Als see the documentation of the JAL compiler.
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  Kind regards,
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  Rob
>>>> 
>>>>  
>>>> 
>>&

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

narrow down the code down to the minimal size to show that it 
>>>>fails? If so you can share that code.
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  And to answer your other - not posted - comment. Due to the fact that you 
>>>>use this group to answer trivial questions that you can find on the 
>>>>Internet (which you should not do) and which are specific JAL or PIC 
>>>>related, your posts are now moderated. Only posts which are relevant to 
>>>>this group are passed on to the other group members.
>>>> 
>>>>  
>>>> 
>>>> 
>>>>  Kind regards,
>>>> 
>>>>  
>>>> Rob
>>>> 
>>>>  
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> 
>>>> 
>>>>  
>>>> Van: jal...@googlegroups.com  namens majid ebru 
>>>> 
>>>> 
>>>> 
>>>>  
>>>> Verzonden: donderdag 22 april 2021 20:19
>>>> 
>>>> 
>>>>  
>>>> Aan: jallib Onderwerp: Re: NT: [jallib] How to 
>>>> send & receive data over medium distance
>>>> 
>>>> 
>>>>  
>>>> Hi  
>>>> 
>>>> 
>>>> 
>>>> Please help me again梁梁樂樂
>>>> 
>>>> 
>>>> 
>>>> 
>>>> When I connected two PICs together , everything is ok.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> But when disconnect port serial , both PICs hanged ?!?!
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Both micro stoped , and when connected again ,both micro work correctly?!
>>>> 
>>>> 
>>>> 
>>>> 
>>>> In fact both micro stopped in line : if  serial_sw_read(char)) then block 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> And doesn't run other codes樂梁
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Why?!
>>>> 
>>>> 
>>>> 
>>>> 
>>>> How should I do ?!
>>>> 
>>>>  
>>>> On Wednesday, April 21, 2021 at 10:12:03 PM UTC+4:30 funlw65(Vasi) wrote:
>>>> 
>>>> 
>>>>>  
>>>>> The microcontroller boards that are used in Polish Universities are all 
>>>>> equipped with (external - note for Majid) RS485 chips.  
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> On Wed, Apr 21, 2021 at 4:54 PM Rob CJ  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>>>  
>>>>>>  
>>>>>>  Hi Majid,
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>>  Please use Google to find out what RS485 and IIC is. Use the Jallib 
>>>>>>group for issues with libraries and the compiler not for general 
>>>>>>questions that you can easily find on the internet.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>>  Thanks.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>>  Kind regards,
>>>>>> 
>>>>>>  
>>>>>> Rob
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>> Van: jal...@googlegroups.com  namens majid ebru 
>>>>>> 
>>>>>> Verzonden: woensdag 21 april 2021 15:47
>>>>>> Aan: jallib 
>>>>>> Onderwerp: Re: NT: [jallib] How to send & receive data over medium 
>>>>>> distance 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>> RS485 is very powerful. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> But I don't how to implement in PIC?!?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Is i2c the same rs485?!
>>>>>> 
>>>>>> 
>>>>>> 
>>>

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

>>>passed on to the other group members.
>>> 
>>>  
>>> 
>>> 
>>>  Kind regards,
>>> 
>>>  
>>> Rob
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> Van: jal...@googlegroups.com  namens majid ebru 
>>> 
>>> 
>>> 
>>>  
>>> Verzonden: donderdag 22 april 2021 20:19
>>> 
>>> 
>>>  
>>> Aan: jallib Onderwerp: Re: NT: [jallib] How to 
>>> send & receive data over medium distance
>>> 
>>> 
>>>  
>>> Hi  
>>> 
>>> 
>>> 
>>> Please help me again梁梁樂樂
>>> 
>>> 
>>> 
>>> 
>>> When I connected two PICs together , everything is ok.
>>> 
>>> 
>>> 
>>> 
>>> But when disconnect port serial , both PICs hanged ?!?!
>>> 
>>> 
>>> 
>>> 
>>> Both micro stoped , and when connected again ,both micro work correctly?!
>>> 
>>> 
>>> 
>>> 
>>> In fact both micro stopped in line : if  serial_sw_read(char)) then block 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> And doesn't run other codes樂梁
>>> 
>>> 
>>> 
>>> 
>>> Why?!
>>> 
>>> 
>>> 
>>> 
>>> How should I do ?!
>>> 
>>>  
>>> On Wednesday, April 21, 2021 at 10:12:03 PM UTC+4:30 funlw65(Vasi) wrote:
>>> 
>>> 
>>>>  
>>>> The microcontroller boards that are used in Polish Universities are all 
>>>> equipped with (external - note for Majid) RS485 chips.  
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  
>>>> On Wed, Apr 21, 2021 at 4:54 PM Rob CJ  wrote:
>>>> 
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>>  
>>>>>  Hi Majid,
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>>  Please use Google to find out what RS485 and IIC is. Use the Jallib 
>>>>>group for issues with libraries and the compiler not for general questions 
>>>>>that you can easily find on the internet.
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>>  Thanks.
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>>  Kind regards,
>>>>> 
>>>>>  
>>>>> Rob
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> Van: jal...@googlegroups.com  namens majid ebru 
>>>>> 
>>>>> Verzonden: woensdag 21 april 2021 15:47
>>>>> Aan: jallib 
>>>>> Onderwerp: Re: NT: [jallib] How to send & receive data over medium 
>>>>> distance 
>>>>>  
>>>>> 
>>>>> 
>>>>> RS485 is very powerful. 
>>>>> 
>>>>> 
>>>>> 
>>>>> But I don't how to implement in PIC?!?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Is i2c the same rs485?!
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> On Wednesday, April 21, 2021 at 4:41:19 PM UTC+4:30 vasile wrote:
>>>>> 
>>>>> 
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>> At 15m and 5V there is no problem with data sent in current. Using 
>>>>>> twisted wire cable is a good habit. 
>>>>>> 
>>>>>> From the EMI perspective twisted cable it is about half as good as a 
>>>>>> shielded cable and has the parasitic capacity quite low compared with 
>>>>>> the shielded cable.
>>>>>> 
>>>>>> RS485 (standard 32 loads) is feasible at 1Km and quite high speed. Still 
>>>>>> there is an issue with the ground line and requires good terminators.
>>>>>> 
>>>>>> Data goes either on A plus ground cable (three wires between Tx and 
>>>>>> RX) or just A (two wire cable) and ground connected to earth on the 
>>>>>> transmitter and receiver end. 
>>>>

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-24 Thread 'Oliver Seitz' via jallib

gt;> 
>>> 
>>>  
>>> Van: jal...@googlegroups.com  namens majid ebru 
>>> 
>>> Verzonden: woensdag 21 april 2021 15:47
>>> Aan: jallib 
>>> Onderwerp: Re: NT: [jallib] How to send & receive data over medium distance 
>>>  
>>> 
>>> 
>>> RS485 is very powerful. 
>>> 
>>> 
>>> 
>>> But I don't how to implement in PIC?!?
>>> 
>>> 
>>> 
>>> 
>>> Is i2c the same rs485?!
>>> 
>>> 
>>> 
>>>  
>>> On Wednesday, April 21, 2021 at 4:41:19 PM UTC+4:30 vasile wrote:
>>> 
>>> 
>>>>  
>>>>  
>>>>  
>>>> At 15m and 5V there is no problem with data sent in current. Using twisted 
>>>> wire cable is a good habit. 
>>>> 
>>>> From the EMI perspective twisted cable it is about half as good as a 
>>>> shielded cable and has the parasitic capacity quite low compared with the 
>>>> shielded cable.
>>>> 
>>>> RS485 (standard 32 loads) is feasible at 1Km and quite high speed. Still 
>>>> there is an issue with the ground line and requires good terminators.
>>>> 
>>>> Data goes either on A plus ground cable (three wires between Tx and RX) 
>>>> or just A (two wire cable) and ground connected to earth on the 
>>>> transmitter and receiver end. 
>>>> 
>>>> In the last configuration an issue is quite frequent caused by an offset 
>>>> (variable ground potential between TX and RX).
>>>> 
>>>> Also lightning is a problem for outdoor cables...and nothing help... :)... 
>>>> no matter how others will convince you to put three tranzorbs on each TX 
>>>> and RX  end.
>>>> 
>>>> happy communications! 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  
>>>>  
>>>> On Wed, Apr 21, 2021 at 8:32 AM 'Oliver Seitz' via jallib 
>>>>  wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  
>>>>  
>>>>>  Thanks for the additional information, 800m is something very different 
>>>>>from 20m ;-)
>>>>> 
>>>>> I can imagine that 20m at 5V ground-referenced is doable, but when you're 
>>>>> starting, better stick to the specifications and try your luck when you 
>>>>> have a bit of experience.
>>>>> 
>>>>> I myself am at a similar project, like 15 meter, and I want to use as 
>>>>> little standby current as possible, and no twisted pairs. It's 
>>>>> uni-directional, with constant-current pullup at the receiver and 
>>>>> optically isolated pulldown at the sender with 1200 baud... First test of 
>>>>> the concept in a few days ;-)
>>>>> 
>>>>> If standby current was of no concern, I'd use RS422 or RS485 
>>>>> drivers/receivers, true RS232 is old-fashioned and needs to many 
>>>>> components.
>>>>> 
>>>>> 
>>>>> Greets,
>>>>> Kiste
>>>>> 
>>>>> Am Mittwoch, 21. April 2021, 07:02:46 MESZ hat vsurducan 
>>>>>  Folgendes geschrieben: 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Oliver, I remember the problems I had with an EIA232 with +/-8V output 
>>>>> running at 800m at 9600bps. Everything works until due the transceiver 
>>>>> heating the voltage dropped at +/-7.6V...:)
>>>>> The length is given by the voltage at the level converter of the 
>>>>> transmitter output. All level converters with charge pumps are not able 
>>>>> to give more than +/-8V...+/-10V in the happiest circumstances.
>>>>> Oldest/goldest EIA232 worked at +/-25V up to 2km.
>>>>> For 20m you do noy need any level converter at the output of your PIC, 
>>>>> just a twisted pair RX-GND TX-GND (CAT5 ethernet cable is perfect) and an 
>>>>> open collector transmitter ( a gate) with pull-up resistor in the 
>>>>> receiver end (at 20m distance from the transmitter).
>>>>> However Majid,  I think you need first to learn jal and for that there is 
>>>>> a learning curve which has to be passed
>>>>> Please

Re: [jallib] clock

2021-04-23 Thread 'Oliver Seitz' via jallib



An analog clock with hands usually *never* shows the right time, unless it 
doesn't run, only then it shows the correct time twice a day.

And no, the internet time is not synced to an atomic clock, but to a network of 
atomic clocks around the world.

Greets,
Kiste



Am Freitag, 23. April 2021, 11:40:30 MESZ hat vsurducan  
Folgendes geschrieben: 





Eur, an analog clock which does tic-tac, shows accurate time twice per day. It 
does not need synch. :)
The real question is how we do know that the network time is accurate indeed? 
It is synchronized with an atomic clock? :)
best wishes,

On Fri, Apr 23, 2021 at 12:31 PM zet@gmail.com  wrote:
> Hi
> Thanks for all the information.
> I have to read a lot.
> Till then I buy a cheap timer in the shop on the corner.
> Peter
> 
> Op dinsdag 20 april 2021 om 09:45:10 UTC+2 schreef Eur van Andel:
>> Hi Zet
>> 
>> Olivier Seitz has said a lot of useful things about keeping time already. I 
>> can add that some  PIC18Fs have hardware real time clocks, some even with 
>> support for a 32kHz watch crystal on special pins. This will be accurate to 
>> minutes per year. 
>> 
>> Keeping time is of no use without syncing. That also holds for calendars. 
>> Syncing is so important for agriculture that several ancient civilisations 
>> spent insane amounts of work erecting huge stones to sync their calendars 
>> with the orbit of the planet. 
>> 
>> If you want to sync your time, you need to connect to a network. I do this 
>> in several ways:
>> 
>> - with an RN171 wifi module, which is end-of-life, so not recommended
>> - with an ESP32 which is cheap but overkill
>> - with a SIM800L GSM module, which needs a SIM card
>> 
>> SIM cards with data prices of €0.01/MB can be bought for €10 at keepgo.com
>> The SIM800L can be bought on AliExpress for €2
>> I wrote a library for the SIM800, which I can add to jallib if you are 
>> interested. The SIM800 is 2G only, so your country should still support 
>> that. Europe does. 
>> 
>> The mobile network knows both the time, the time zone and the local DST. 
>> (Daylight Savings Time)
>> 
>> A low cost solution could be a local “Stonehenge” with a narrow slit and a 
>> small solar cell that gives a good signal in direct sunlight. This would 
>> require a fixed location for the hardware and an unobstructed view to (a 
>> part of) the southern sky. You will also have to do some astronomical 
>> calculations. The Druids in England did those 5000 years ago, without the 
>> internet, so that won’t be too hard. 
>> 
>> You will be on solar time and syncing with a calendar will be hard, next to 
>> impossible. So when the DST kicks in will be unknown. 
>> 
>> 
>> 
>>> On 19 Apr 2021, at 23:23:03, zet@gmail.com  wrote:
>>> 
>>> Does a library excist with timezone Amsterdam so the microprocessor can use 
>>> it to send an order to start or stop a device every day at the same time? 
>>> 
>> 
>>  
>> ---
>> ir EE van Andel e...@fiwihex.nl  http://www.fiwihex.nl
>> Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands
>> tel+31-653-286573
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/21a991c4-df5e-4db9-a69d-f58bfae43c94n%40googlegroups.com.
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsTho1s-%3D_nve92Y2qnaRZx5-5orXG7gY1MVYCgg_6WEg%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1191615495.236101.1619171287043%40mail.yahoo.com.

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-21 Thread 'Oliver Seitz' via jallib

ue the transceiver 
>> heating the voltage dropped at +/-7.6V...:) 
>> The length is given by the voltage at the level converter of the transmitter 
>> output. All level converters with charge pumps are not able to give more 
>> than +/-8V...+/-10V in the happiest circumstances. 
>> Oldest/goldest EIA232 worked at +/-25V up to 2km. 
>> For 20m you do noy need any level converter at the output of your PIC, just 
>> a twisted pair RX-GND TX-GND (CAT5 ethernet cable is perfect) and an open 
>> collector transmitter ( a gate) with pull-up resistor in the receiver end 
>> (at 20m distance from the transmitter). 
>> However Majid,  I think you need first to learn jal and for that there is a 
>> learning curve which has to be passed 
>> Please start with the examples, compile them, make them run, modify them as 
>> you wish and post only when nothing works for you after three days of 
>> trying...this will help you more than you may believe right now... 
>> best wishes 
>> 
>> On Wed, Apr 21, 2021 at 7:28 AM 'Oliver Seitz' via jallib 
>>  wrote: 
>>> Hi Majid, 
>>> 
>>> SPI is designed for centimeters, I don't think it can work reliably over 20 
>>> meters. 
>>> 
>>> RS232 at 9600 baud is ok for 150 meters, if you're using real RS232 drivers 
>>> and receivers like from the MAX232 series. The PIC controller does not have 
>>> RS232, it has a usart which handles the NRZ protocol. This protocol is best 
>>> known as being used by the RS232 interface. Therefore the protocol itself 
>>> is commonly (but wrongly) referred to as "RS232" 
>>> 
>>> RS232 uses negative voltages as a symbolic "1" and positive voltages for 
>>> "0". At the receiving side, the voltage must at least go higher than +3V 
>>> for "0" and lower than -3V for "1". At the sending side, voltages from up 
>>> to +15V and down to -15V are used. 
>>> 
>>> So, to answer your question in two simple sentences: RS232 is ok for the 
>>> job. But RS232 is not what comes out of the controller. 
>>> 
>>> Greets, 
>>> Kiste 
>>> 
>>> 
>>> 
>>> 
>>> Am Dienstag, 20. April 2021, 21:56:34 MESZ hat majid ebru 
>>>  Folgendes geschrieben: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> can i ask another  question?? 
>>> 
>>> if it is 20 meter distance between PICs , i should use RS232 or SPI? 
>>> 
>>> so sorry and thanks a lot 
>>> 
>>> ‪majid ebru‬‏ در تاریخ سه‌شنبه ۲۰ آوریل ۲۰۲۱ ساعت 
>>> 
>>> -- 
>>> 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/1697687282.4677348.1618979276333%40mail.yahoo.com.
>>>  
>>> 
>> 
>> 
>> -- 
>> 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/CAM%2Bj4qtaBjojssk_HHFK1M2dhhL9CNNf3mygd1F3nH0B5bck9A%40mail.gmail.com.
>>  
>> 
> 
> 
> -- 
> 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/5e7554f0-a1c8-45cb-a79f-1419870ed5fbn%40googlegroups.com
>  
> 
> . 
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/69c84bcb-2462-40be-bbff-179415d53bbfn%40googlegroups.com
.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/768653501.4727365.1618993165963%40mail.yahoo.com.

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-21 Thread 'Oliver Seitz' via jallib

To start, use a short connection, like 50cm maximum. 

Transmit data which only has one bit (plus start bit) set, like

0x01
0x02
0x04

That way you can find out, if polarity and baud rate are correct.

I have a cheap scope, but it is good to see if the transmitter or the receiver 
doesn't work properly.

Greets,
Kiste


Am Mittwoch, 21. April 2021, 08:45:23 MESZ hat majid ebru 
 Folgendes geschrieben: 





Thank you

Ok I use RS232.

But I can't read correctly data ,yet

Please guide me

When I send  "0x052" from pic1 , I received data in pic2 , but it is not correct


If serial_sw_read(char)) then block 

     lcd_cursor_position(1,5) 
     print_byte_hex(lcd, char)     --  > print 2B
     lcd_cursor_position(1,10) 
     lcd = char.    --.    > Print +
..


On Wednesday, April 21, 2021 at 10:02:54 AM UTC+4:30 Kiste wrote:
> Thanks for the additional information, 800m is something very different from 
> 20m ;-) 
> 
> I can imagine that 20m at 5V ground-referenced is doable, but when you're 
> starting, better stick to the specifications and try your luck when you have 
> a bit of experience. 
> 
> I myself am at a similar project, like 15 meter, and I want to use as little 
> standby current as possible, and no twisted pairs. It's uni-directional, with 
> constant-current pullup at the receiver and optically isolated pulldown at 
> the sender with 1200 baud... First test of the concept in a few days ;-) 
> 
> If standby current was of no concern, I'd use RS422 or RS485 
> drivers/receivers, true RS232 is old-fashioned and needs to many components. 
> 
> 
> Greets, 
> Kiste 
> 
> Am Mittwoch, 21. April 2021, 07:02:46 MESZ hat vsurducan  
> Folgendes geschrieben: 
> 
> 
> 
> 
> 
> Oliver, I remember the problems I had with an EIA232 with +/-8V output 
> running at 800m at 9600bps. Everything works until due the transceiver 
> heating the voltage dropped at +/-7.6V...:) 
> The length is given by the voltage at the level converter of the transmitter 
> output. All level converters with charge pumps are not able to give more than 
> +/-8V...+/-10V in the happiest circumstances. 
> Oldest/goldest EIA232 worked at +/-25V up to 2km. 
> For 20m you do noy need any level converter at the output of your PIC, just a 
> twisted pair RX-GND TX-GND (CAT5 ethernet cable is perfect) and an open 
> collector transmitter ( a gate) with pull-up resistor in the receiver end (at 
> 20m distance from the transmitter). 
> However Majid,  I think you need first to learn jal and for that there is a 
> learning curve which has to be passed 
> Please start with the examples, compile them, make them run, modify them as 
> you wish and post only when nothing works for you after three days of 
> trying...this will help you more than you may believe right now... 
> best wishes 
> 
> On Wed, Apr 21, 2021 at 7:28 AM 'Oliver Seitz' via jallib 
>  wrote: 
>> Hi Majid, 
>> 
>> SPI is designed for centimeters, I don't think it can work reliably over 20 
>> meters. 
>> 
>> RS232 at 9600 baud is ok for 150 meters, if you're using real RS232 drivers 
>> and receivers like from the MAX232 series. The PIC controller does not have 
>> RS232, it has a usart which handles the NRZ protocol. This protocol is best 
>> known as being used by the RS232 interface. Therefore the protocol itself is 
>> commonly (but wrongly) referred to as "RS232" 
>> 
>> RS232 uses negative voltages as a symbolic "1" and positive voltages for 
>> "0". At the receiving side, the voltage must at least go higher than +3V for 
>> "0" and lower than -3V for "1". At the sending side, voltages from up to 
>> +15V and down to -15V are used. 
>> 
>> So, to answer your question in two simple sentences: RS232 is ok for the 
>> job. But RS232 is not what comes out of the controller. 
>> 
>> Greets, 
>> Kiste 
>> 
>> 
>> 
>> 
>> Am Dienstag, 20. April 2021, 21:56:34 MESZ hat majid ebru 
>>  Folgendes geschrieben: 
>> 
>> 
>> 
>> 
>> 
>> can i ask another  question?? 
>> 
>> if it is 20 meter distance between PICs , i should use RS232 or SPI? 
>> 
>> so sorry and thanks a lot 
>> 
>> ‪majid ebru‬‏ در تاریخ سه‌شنبه ۲۰ آوریل ۲۰۲۱ ساعت 
>> 
>> -- 
>> 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/1697687282.4677348.

Re: NT: [jallib] How to send & receive data over medium distance

2021-04-20 Thread 'Oliver Seitz' via jallib

Thanks for the additional information, 800m is something very different from 
20m ;-)

I can imagine that 20m at 5V ground-referenced is doable, but when you're 
starting, better stick to the specifications and try your luck when you have a 
bit of experience.

I myself am at a similar project, like 15 meter, and I want to use as little 
standby current as possible, and no twisted pairs. It's uni-directional, with 
constant-current pullup at the receiver and optically isolated pulldown at the 
sender with 1200 baud... First test of the concept in a few days ;-)

If standby current was of no concern, I'd use RS422 or RS485 drivers/receivers, 
true RS232 is old-fashioned and needs to many components.


Greets,
Kiste

Am Mittwoch, 21. April 2021, 07:02:46 MESZ hat vsurducan  
Folgendes geschrieben: 





Oliver, I remember the problems I had with an EIA232 with +/-8V output running 
at 800m at 9600bps. Everything works until due the transceiver heating the 
voltage dropped at +/-7.6V...:)
The length is given by the voltage at the level converter of the transmitter 
output. All level converters with charge pumps are not able to give more than 
+/-8V...+/-10V in the happiest circumstances.
Oldest/goldest EIA232 worked at +/-25V up to 2km.
For 20m you do noy need any level converter at the output of your PIC, just a 
twisted pair RX-GND TX-GND (CAT5 ethernet cable is perfect) and an open 
collector transmitter ( a gate) with pull-up resistor in the receiver end (at 
20m distance from the transmitter).
However Majid,  I think you need first to learn jal and for that there is a 
learning curve which has to be passed
Please start with the examples, compile them, make them run, modify them as you 
wish and post only when nothing works for you after three days of trying...this 
will help you more than you may believe right now...
best wishes

On Wed, Apr 21, 2021 at 7:28 AM 'Oliver Seitz' via jallib 
 wrote:
> Hi Majid,
> 
> SPI is designed for centimeters, I don't think it can work reliably over 20 
> meters.
> 
> RS232 at 9600 baud is ok for 150 meters, if you're using real RS232 drivers 
> and receivers like from the MAX232 series. The PIC controller does not have 
> RS232, it has a usart which handles the NRZ protocol. This protocol is best 
> known as being used by the RS232 interface. Therefore the protocol itself is 
> commonly (but wrongly) referred to as "RS232"
> 
> RS232 uses negative voltages as a symbolic "1" and positive voltages for "0". 
> At the receiving side, the voltage must at least go higher than +3V for "0" 
> and lower than -3V for "1". At the sending side, voltages from up to +15V and 
> down to -15V are used.
> 
> So, to answer your question in two simple sentences: RS232 is ok for the job. 
> But RS232 is not what comes out of the controller.
> 
> Greets,
> Kiste
> 
> 
> 
> 
> Am Dienstag, 20. April 2021, 21:56:34 MESZ hat majid ebru 
>  Folgendes geschrieben: 
> 
> 
> 
> 
> 
> can i ask another  question??
> 
> if it is 20 meter distance between PICs , i should use RS232 or SPI?
> 
> so sorry and thanks a lot
> 
> ‪majid ebru‬‏ در تاریخ سه‌شنبه ۲۰ آوریل ۲۰۲۱ ساعت 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jallib/1697687282.4677348.1618979276333%40mail.yahoo.com.
> 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtaBjojssk_HHFK1M2dhhL9CNNf3mygd1F3nH0B5bck9A%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/1020737915.4719521.1618983169979%40mail.yahoo.com.

1 2 3 >

1 - 100 of 219 matches

Mail list logo