Re: [jallib] Re: Problem with jallist group

[vsurducan]

It may be a problem with unusual traffic from sender email address or
sender computer.

Some things which might work: clean your computer using a cleaner software,
change email password and make it unique, add google authenticator code to
log in, do not use wifi to connect to your email...

On Wed, Apr 24, 2024, 09:05 Rob CJ  wrote:

> Hi David,
>
> For some unknown reason  your messages are seen as spam and are blocked
> until I or Matt release them. I have been looking for a fix but could not
> find it. We could try the following. I could delete you as member and if
> you then send a message you are added again. Shall we try that?
>
> Met vriendelijke groet,
> Rob Jansen
> --
> *From:* jallib@googlegroups.com  on behalf of
> David VB 
> *Sent:* Tuesday, April 23, 2024 7:46:41 PM
> *To:* jallib 
> *Subject:* [jallib] Re: Problem with jallist group
>
> (I do have the solution for Hans problem "PicKit3 problems").
> It is off-topic here, but is it OK I post it here anyway, since I cannot
> post anything more on jallist ?
>
> Kr
>
> David
>
> Le mardi 23 avril 2024 à 19:36:49 UTC+2, David VB a écrit :
>
> Hi,
>
> I tried to post some answers on the jallist group, but all my messages
> were deleted without an apparent reason.
>
> We wil see if my message here will be published.
>
> In the meantime, I quit the jallist group, hoping this could solve the
> problem, but now I cannot ask to reintegrate it
>
> To whom can I ask ?
>
> Thanks,
>
> Kind regards,
>
> David
>
>
> --
> 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/83ffa1c1-e90b-4643-a335-7a873efdc89dn%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/GVXP195MB16373B2A6FE4DD66095706A7E6102%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/CAM%2Bj4quLuXG2sNQoQNwRreCT7XpRo5a1Rem86sasKyyQ1Q-Xuw%40mail.gmail.com.

Re: [jallib] Assembling

[vsurducan]

Vasi, from assembler to hex it is a painful operation. Asm file created by
jal will probably gave a bunch of errors if you"ll try to compile it with
an older version of mplabx. Even a source written for an older version of
mplab but compiled with an upgraded version of mplab will gave a huge
number of errors. If finally have zero error after asm file  compilation,
the resulted hex file still can be useless. :(

On Tue, Apr 16, 2024, 14:12 vasi vasi  wrote:

> Thank you Rob, but which mplabx assembler? The standalone version (which
> is available also for Linux) is from 2015. You know that the support is
> hardcoded... I mean, you can't use that old version by simply adding inc
> and lkr files... It doesn't work like jal :(
>
> On Tue, Apr 16, 2024 at 1:27 PM Rob CJ  wrote:
>
>> Hi Vasi,
>>
>> I think not but you should be able to  create a hexfile using the mplabx
>> assembler since the syntax should be correct.
>>
>> Met vriendelijke groet,
>> Rob Jansen
>> --
>> *From:* jallib@googlegroups.com  on behalf of
>> vasi vasi 
>> *Sent:* Tuesday, April 16, 2024 11:02:33 AM
>> *To:* jallib@googlegroups.com 
>> *Subject:* [jallib] Assembling
>>
>> Can jalv2 generate a hex file from its own (generated) asm file if
>> provided with only that?
>>
>> --
>> 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-u1tFwiCh5oBtK-6Hdh%3DsZQ0gP4j8KD2GQAyotsdh%2BQQ%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/GVXP195MB1637C4A3CBB292F2BBD41472E6082%40GVXP195MB1637.EURP195.PROD.OUTLOOK.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%3D9kB5P1_%2B%3Djkj7bmBxC8%3D70uvFEJ-zahsi5ozBM4B0Wkw%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%2Bj4qtBVK9hjgh93NFmEEe-J-4fnLigwdG-0dHcRS51zyk-CA%40mail.gmail.com.

Re: [jallib] Greenhouse

[vsurducan]

That is a programming issue not a library issue. Check hardware, supply,
cable length, wires with cold solder or even not connected, programmer
speed, programmer software malfunction. I guess you need pickit3 plus or
pickit3 minus to program that pic. With a correct definition file.

On Tue, Apr 9, 2024 at 10:45 PM jos smans  wrote:

> hi Rob,
> I have compiled  the 18f4431 and a hex file was made, but after
> programming  the pic with pickit 3, the error occurred "programming failed
> at program memory address 0x00".Maybe the adc library must, as you said
> before, changed.
> kind regards
> Jos
>
> Op di 9 apr 2024 om 21:09 schreef jos smans :
>
>> Hi Rob,
>> Thank you very much for your support. It works excellent.
>> Kind regards
>> Jos
>>
>> Op di 9 apr 2024 om 19:48 schreef Rob CJ :
>>
>>> Hi Jos,
>>>
>>> The problem is in the ADC library. Apparently the 18F4431 has a
>>> different way of selecting the ADC channel that I have never seen before.
>>>
>>> I made a quick fix and added the channel selection for your PIC but to
>>> the attached ADC library did not test this so you should give it a try. The
>>> code I added could be simplified but that is something that could be done
>>> later.
>>>
>>> So place the attached ADC library in the directory of your program
>>> recompile it and let me know if it works.
>>>
>>> Thanks.
>>>
>>> Kind regards,
>>>
>>> Rob
>>>
>>> --
>>> *Van:* jallib@googlegroups.com  namens jos
>>> smans 
>>> *Verzonden:* dinsdag 9 april 2024 16:56
>>> *Aan:* jallib 
>>> *Onderwerp:* [jallib] Greenhouse
>>>
>>> Good day, i have a problem with a program to make   automatic my
>>> greenhouse. With pic 18f4455,  it  works fine, but not with pic 18f4431.I
>>> think its a adc fault but i am not sure.
>>> Can someone help me? thanks
>>> --
>>> 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/eaae0d75-efe1-4bdc-b6ce-ca87db6dd560n%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/GVXP195MB1637171120AC6BA343AB4AFFE6072%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/CAMK-nAftmPUHcT-g_kMvgQW0HykAT40z2yZi7z_cKAsxjbO%2BUQ%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%2Bj4qs-jwoRSyH81N8gqEEgXhp1fRuJ_OkfYku55YFm5dK_hg%40mail.gmail.com.

Re: [jallib] Jallib 1.9.0 Beta is available

[vsurducan]

Some components can be found at TME and Farnell. Analog Devices embargo
components from Digikey or Mouser only. DIP is history even for hobby. Only
vintage electronics use  DIP and vacuum tubes, which are nice. :)



On Wed, Apr 3, 2024, 20:38 David VB  wrote:

> Hi Rob,
>
> Thanks for the tip
>
> When you buy form Digikey.NL or Mouse.NL (or any european domain), custom
> duties and taxes are already included in the displayed price.
> The only thing to add is the VAT (21% in Belgium) if you buy as an
> individual.
> And be sure to buy for at least 50 €, to get free shipping.
> Digikey is usually a bit cheaper than Mouser, but with Mouser, the parcel
> usually arrives one day earlier (Fedex)
> What's interesting with those resellers is that the price is depending of
> the quantity and rapidly goes down...
> Example: When buying a PIC reference I still don't have in stock, I buy 2
> in DIP-package (for the breaboard) and then 25 in SOIC or SSOP for my
> projects.   The price is then ridicously low.
> Sometimes I do not even buy DIP's anymore, and use SOIC on a little
> DIP-adapter board as you can find on AliExpress which can then be use on
> breadboards
>
> So, feel comfortable to buy from them: their prices are unbeatable, and
> there are no hidden costs
>
> I also know about Reichelt and regurlarly buy from them too, especially
> when they have components in their "Sale" list: they are then sometimes
> cheaper than on the "big" distributors.   And they have a great customer
> service: I once bought a defective device, and they replaced it
> immediately, for free, without making any trouble.
>
> Conrad is also available in Belgium, but their price tags have
> sky-rocketted, and I do not even spend my time to take them into
> comparison.   I only search on their site for things I do not find on the
> other shops.
>
> Be sure to also test ELV.DE   They sell some items (especially kits and
> modules) you will not find elsewhere.   Website in German or Austrian
> only
>
> Back to the CLB subject: these peripherals are totally new.  The 16F131xx
> family is their first implementation.   They look incredibly powerful and
> easy to use, with the help of the synthesiser that allows you to create the
> logic model either graphically or by importing a Verilog file.   What
> remains unclear for me is how to program the PIC with this logical model,
> since only the input and output, and some general configuration registers
> are available to the user.  The logical design itself (output of the
> synthesizer) is a set of files from which some is/are include during the
> programming ("burning") phase, along with the hex file, but I still do not
> know how to do that
>
> I still have some documentation to read and try.
>
> (BTW, I think that for this CLB subject, it should be more advisabe to
> publish in the jallist group, because it is not directly linked to
> jallib.   When I will habve find something useful, I will open a new topic
> in the jallist for it)
>
> Kind regards,
>
> David
>
> Le mardi 2 avril 2024 à 18:54:06 UTC+2, Rob CJ a écrit :
>
>> Hi David,
>>
>> I never worked with those configurable blocks but it can be interesting.
>>
>> BTW. I think if you order at Digikey I thougt you also had to pay costs
>> for customs (I think I had to pay that a long time ago since the components
>> came from the USA).
>>
>> If I am right you live in Belgium. An option would be to order the chip
>> at Reichelt in Germany. They are not every expensive and the shipment costs
>> are OK (some other suppliers use DTP or others who are very expensive in
>> shipment costs).
>>
>> Just an idea to save money (I hope), Dutch habbit .
>>
>> E.g.
>> https://www.reichelt.nl/nl/nl/mcu-picmicro-14-kb-32-mhz-pdip-20-pic16f13145-ep-p370198.html?=pos_6=1
>>
>> 
>> PIC16F13145-EP - MCU, PICmicro, 14 KB, 32 MHz, PDIP-20
>> 
>> De PIC16F13145-microcontrollerfamilie biedt een effectieve methode voor
>> de implementatie van op hardware gebaseerde oplossingen. Door de
>> introductie van de CLB-randapparatuur (Configurable Logic [...]
>> www.reichelt.nl
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens David VB
>> 
>> *Verzonden:* dinsdag 2 april 2024 16:26
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Jallib 1.9.0 Beta is available
>> Hi Rob,
>>
>> Thanks for your answer.
>> I have just bought the Curiosity Nano 16F13145 board, but have not yet
>> tested it.
>> I have several other references of that family (16F131xx) in my basket
>> since they now become available on Digikey, but for those, I waited to buy
>> them because I would like to test the CLB first.
>>
>> Unfortunately, it seems that the CLB is only usable with the synthesis
>> tool available online or from MPLABX, and 

Re: [jallib] 18f4431 problems

[vsurducan]

It might be a hardware problem. Have you checked twice the connectoin
between programmer and pic? Short cable length (20-30cm). GND cables
between clock and data signals.Do you have correct programming and supply
voltage? Use HV programming mode not LVP.

On Sun 5 Nov 2023, 4:36 PM jos smans,  wrote:

> Hello, I have a problem by programming a pic 18f4431. When i make a verry
> simple  program blink a led ,jaledit accept the HEX program, but ,when i
> put it in pic, error occurs on my pickit3"Programming failed at Program
> Memory 0x00"
> I also I attempt a sample from jalib directory"18f4431_blink_HS.jal"with
> the same error.
> Can i have a litlle help?
> Thanks
>
> --
> 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/77b05aac-91b9-4246-abd1-04bf83fffc56n%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%2Bj4qvzCZiR%3D08XrTHyK%2BBjktkXO4aOg%3DC3NtqeVKeRvHAuWQ%40mail.gmail.com.

Re: [jallib] DAIKIN REMOTE

[vsurducan]

There is something cheaper for debugging data. It worth more than a
Tektronix MSO4104 with logic analyzer but without having decoding card
https://www.aliexpress.com/item/1005002399378513.html

On Mon 4 Sep 2023, 12:46 PM David VB,  wrote:

> Hi,
>
> In case you didn't know, this cute little device enables you to retrieve
> the codes in hex format of IR emitter
>
> DSO TC-3
>
> It's inexpensive (around 65 €) and receives much appraisal in the reviews
> I've seen so far.
> It is also a portable basic oscilloscope, signal generator and component
> tester
>
> There are several videos on YouTube that you can search for, and it is
> available from Elektor, Amazon, AliExpress etc
>
> Hope this helps
>
> Le dimanche 3 septembre 2023 à 19:23:27 UTC+2, Rob CJ a écrit :
>
>> Hi Hans,
>>
>> Your plan is to send Daikin commands to your airconditioning and you need
>> some software to get the commands that you need?
>>
>> I think the commands you need can be found on the internet (you will nog
>> be the first person who wants to do that).
>>
>> If you have the commands from the internet, then the only thing remaining
>> is sending out the data according to the protocol, correct?
>>
>> I found this by Googlw: https://github.com/blafois/Daikin-IR-Reverse or
>> https://www.instructables.com/Reverse-engineering-of-an-Air-Conditioning-control/
>>
>> 
>> Reverse Engineering Air Conditioner IR Remote Control Protocol
>> 
>> Reverse Engineering Air Conditioner IR Remote Control Protocol: Hi, this
>> is my first instructable, hope you like it. To get into electronics I chose
>> a home automation project: a system allowing me to control and program both
>> air conditioner units in my flat. In this instructable I show how I got to
>> understa…
>> www.instructables.com
>>
>> So when you have the commands you can use the software you already
>> created to send the data out.
>>
>> Is my assumption correct or is it something else you want to achieve?
>>
>> Thanks.
>>
>> Kind regards,
>>
>> Rob
>>
>>
>> --
>> *Van:* jal...@googlegroups.com  namens hans <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* zondag 3 september 2023 16:05
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] DAIKIN REMOTE
>> Okay Rob.
>>  After 4 days of struggling and a mess of results, I followed my wife's
>> advice. I'm going to start with the old graphics approach.
>>  Make an audio recording, greatly enlarge and print it and then write
>> down the series of zeros and ones
>> . For example, I made my circuit earlier and last winter it switched the
>> air conditioners on and off according to the program as heating.
>>  Remains with me the respect for the programs you all can make.
>> regards
>> Hans
>>
>> Op donderdag 31 augustus 2023 om 18:48:01 UTC+2 schreef Rob CJ:
>>
>> Hi Hans,
>>
>> What you could do is modify the NEC decoder library and change the bit
>> times and the number of bits. Since you know which bit time is 1 and which
>> is 0 this should be douable.
>>
>> The NEC prototol also starts with a pulse more or less the same as the
>> Daikin, followed by bytes of data and a stop bit.
>>
>> You find the info in the library. The protocol is as follows.
>>
>> -- Specification of NEC IR protocol:
>> -- Logical '0': A 562.5 us pulse burst followed by a 562.5 us space,
>> --  with a total transmit time of 1.125 ms
>> -- Logical '1': A 562.5 us pulse burst followed by a 1.6875ms space,
>> --  with a total transmit time of 2.25 ms
>> -- *) Start with 9 ms leading pulse burst (16 times the pulse burst
>> length used
>> --for a logical data bit) followed by a a 4.5 ms space.
>> -- *) 8-bit address for the receiving device or 16 bit for the extended
>> protocol
>> -- *) 8-bit logical inverse of the address or high byte for the extended
>> protocol.
>> -- *) 8-bit command.
>> -- *) 8-bit logical inverse of the command.
>> -- *) Final 562.5 us pulse burst to signify the end of message
>> transmission.
>> -- *) The four bytes of data bits are each sent least significant bit
>> first.
>> -- *) After a command is tranmitted and the key on the remote control is
>> still
>> --pressed only a repeat message is sent consisting of a start pulse of
>> --9 ms, followed by a 2.25 ms space.
>>
>> Kind regards,
>>
>> Rob
>>
>>
>> --
>> *Van:* jal...@googlegroups.com  namens hans <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* donderdag 31 augustus 2023 12:00
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] DAIKIN REMOTE
>> The remote control read on a KY-022 is HIGH at rest.
>> 1. 350 us low
>> 2. 120 us high
>> 3. Then always the 19 bytes burst = 450 us, 0 =350 and 1 =1190
>> 4. Followed by 19 bytes of which the first 4 are always equal 17,218,39,0
>>
>> I am now reading this out in an audio program and then puzzle the 

Re: [jallib] IF statement fails

[vsurducan]

Rob, the compiler knows you. :)


On Sun, Aug 20, 2023 at 11:49 AM Rob CJ  wrote:

> Hi Andreas,
>
> I made this test program to print messages via the serial port:
>
> var byte dummy = 0
> var byte i,j,k
>
> function test1() return byte is
> return 0
> end function
> i=test1()
> if i>0 & i<13 then
>   -- goes here but is wrong
>   print_string(serial, "1: It should NOT come here! ")
>   dummy = dummy + 1
> else
>print_string(serial, "1: This is OK. ")
>  dummy = dummy + 2
> end if
> print_crlf(serial)
>
> function test2() return byte is
> return 0
> end function
> -- but this code works:
> j=test2()
> if j<13 & j>0 then
>dummy = dummy + 3
>   print_string(serial, "2: It should NOT come here! ")
>
> else
>-- goes here and OK
>  dummy = dummy + 4
>print_string(serial, "2: This is OK. ")
>
> end if
> print_crlf(serial)
>
> -- if you remove the function, it works, too:
> k=0
> if k>0 & k<13 then
>dummy = dummy + 5
>   print_string(serial, "3: It should NOT come here! ")
> else
>-- goes here and OK
>  dummy = dummy + 6
>print_string(serial, "3: This is OK. ")
> end if
> print_crlf(serial)
>
> The output on the terminal is as follows:
> 1: This is OK.
> 2: This is OK.
> 3: This is OK.
>
> So it does not happen in my case. Can you explain this?
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens Rob CJ <
> rob...@hotmail.com>
> *Verzonden:* vrijdag 18 augustus 2023 22:02
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] IF statement fails
>
> Hi Andreas, Vasile,
>
> The reason I think it is an optimization issue is because I had a look at
> the assembly code when the code reduce option is switched off.
>
> The original code that went wrong was this (where the Z flag is not
> affected):
> ;   14 i=test1()
>movlw0
>movwfv_i
> ;   15 if i>0 & i<13 then
>movf v_i,w
>bsf  v__bitbucket, 0 ; _btemp1
>btfscv__status, v__z
>
> With the code reduce disabled the code is as follows (where the Z flag is
> affected, because of the subwf instruction):
> ;   14 i=test1()
>movlw0
>movwfv_i
> ;   15 if i>0 & i<13 then
>movlw0
>subwfv_i,w
>    bcf  v__bitbucket, 0 ; _btemp1
>btfscv__status, v__z
>
> As said I will test both options on a PIC so see if this indeed solves the
> problem. If so, I need to have a look at the optimization routine that does
> this.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* vrijdag 18 augustus 2023 19:12
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] IF statement fails
>
> :) good idea, no effect...
> Forcing the operation order does not change anything?
>
> If (i<13) & (i>0) then
>
> If not, then only some workaround on the if, separe it in two sentences,
> that usually works.
>
>
> On Fri 18 Aug 2023, 6:12 PM 'off...@schloegl-software.at' via jallib, <
> jallib@googlegroups.com> wrote:
>
> I remove d "-no-variable-reuse" from the compiler call to see if there is
> a different:
> No it is not, but good idea!
>
> Best Regards,
> Andreas
>
> On Friday, August 18, 2023 at 1:45:42 PM UTC+2 vsurducan wrote:
>
> Hi Rob, I think it's about disabling reusing variable space and not about
> expression reduction.
>
> On Fri 18 Aug 2023, 9:48 AM Rob CJ,  wrote:
>
> Hi Andreas
>
> Strange, I will do some testing this weekend.
>
> Thanks for the update.
>
> Met vriendelijke groet,
> Rob Jansen
> --
> *From:* 'off...@schloegl-software.at' via jallib 
> *Sent:* Friday, August 18, 2023 8:33:06 AM
> *To:* jallib 
> *Subject:* Re: [jallib] IF statement fails
>
> Hi Rob,
>
> I tried that. As a result the code size increased (+200 byte), but the
> program doesn't work any more, the output on my display stopped working, so
> it's hard to further debug this.
> So it's not clear if this helps or not because then other problems come
> into.
>
> Andreas
>
> On Thursday, Aug

Re: [jallib] IF statement fails

[vsurducan]

:) good idea, no effect...
Forcing the operation order does not change anything?

If (i<13) & (i>0) then

If not, then only some workaround on the if, separe it in two sentences,
that usually works.


On Fri 18 Aug 2023, 6:12 PM 'off...@schloegl-software.at' via jallib, <
jallib@googlegroups.com> wrote:

> I remove d "-no-variable-reuse" from the compiler call to see if there is
> a different:
> No it is not, but good idea!
>
> Best Regards,
> Andreas
>
> On Friday, August 18, 2023 at 1:45:42 PM UTC+2 vsurducan wrote:
>
>> Hi Rob, I think it's about disabling reusing variable space and not about
>> expression reduction.
>>
>> On Fri 18 Aug 2023, 9:48 AM Rob CJ,  wrote:
>>
>>> Hi Andreas
>>>
>>> Strange, I will do some testing this weekend.
>>>
>>> Thanks for the update.
>>>
>>> Met vriendelijke groet,
>>> Rob Jansen
>>> --
>>> *From:* 'off...@schloegl-software.at' via jallib <
>>> jal...@googlegroups.com>
>>> *Sent:* Friday, August 18, 2023 8:33:06 AM
>>> *To:* jallib 
>>> *Subject:* Re: [jallib] IF statement fails
>>>
>>> Hi Rob,
>>>
>>> I tried that. As a result the code size increased (+200 byte), but the
>>> program doesn't work any more, the output on my display stopped working, so
>>> it's hard to further debug this.
>>> So it's not clear if this helps or not because then other problems come
>>> into.
>>>
>>> Andreas
>>>
>>> On Thursday, August 17, 2023 at 10:29:51 PM UTC+2 Rob CJ wrote:
>>>
>>> Hi Andreas,
>>>
>>> It might be a optimization issues.
>>>
>>> Can you add the following to your program and test if the problem is
>>> gone?
>>>
>>>   pragma opt expr_reduce no
>>>
>>> It will disable code optimization.
>>>
>>> Thanks.
>>>
>>> Kind regards,
>>>
>>> Rob
>>>
>>> --
>>> *Van:* 'off...@schloegl-software.at' via jallib >> >
>>> *Verzonden:* donderdag 17 augustus 2023 21:42
>>>
>>> *Aan:* jallib 
>>> *Onderwerp:* Re: [jallib] IF statement fails
>>> Hi Rob,
>>> thanks that you are digging into this problem and maybe found the issue
>>> already.
>>> I'm a heavy Jal User I would call myself, but this is the first issue I
>>> found over the last years :-)
>>>
>>> On Thursday, August 17, 2023 at 9:31:13 PM UTC+2 Rob CJ wrote:
>>>
>>> Hi Andreas,
>>>
>>> I had a quick look at the generated assemble code for a PIC16.
>>>
>>> In your first code example the code is (I changed 3 times i into i, j
>>> and k so I could compile it):
>>>
>>>  ;   10 i=test1()
>>>movlw0
>>>movwfv_i
>>> ;   11 if i>0 & i<13 then
>>>movf v_i,w
>>>bsf  v__bitbucket, 0 ; _btemp1
>>>btfscv__status, v__z
>>>
>>> In your last code example where you removed the function the code is:
>>>
>>>   clrf v_k
>>> ;   35 if k>0 & k<13 then
>>>movf v_k,w
>>>bsf  v__bitbucket, 6 ; _btemp7
>>>btfscv__status, v__z
>>>
>>> If I am right - and I hope I am not - the first piece of code does not
>>> work because the Z flag (v__z) of the status register (v__status) is never
>>> affected by any of these instructions. In the last code example the clrf
>>> instruction sets the Z flag.
>>>
>>> In other words, moving the return value of 0 to v_i is not the same as
>>> clearing the value of v_k. So it might be a compiler bug. I wonder why it
>>> has not been discovered before.
>>>
>>> Still need to see if my draft conclusion is correct.
>>>
>>> Kind regards,
>>>
>>> Rob
>>>
>>>
>>>
>>> --
>>> *Van:* 'off...@schloegl-software.at' via jallib >> >
>>> *Verzonden:* donderdag 17 augustus 2023 21:07
>>> *Aan:* jallib 
>>> *Onderwerp:* Re: [jallib] IF statement fails
>>>
>>> Hello Rob,
>>> PIC is a 18f26K83
&

Re: [jallib] IF statement fails

[vsurducan]

Hi Rob, I think it's about disabling reusing variable space and not about
expression reduction.

On Fri 18 Aug 2023, 9:48 AM Rob CJ,  wrote:

> Hi Andreas
>
> Strange, I will do some testing this weekend.
>
> Thanks for the update.
>
> Met vriendelijke groet,
> Rob Jansen
> --
> *From:* 'off...@schloegl-software.at' via jallib 
> *Sent:* Friday, August 18, 2023 8:33:06 AM
> *To:* jallib 
> *Subject:* Re: [jallib] IF statement fails
>
> Hi Rob,
>
> I tried that. As a result the code size increased (+200 byte), but the
> program doesn't work any more, the output on my display stopped working, so
> it's hard to further debug this.
> So it's not clear if this helps or not because then other problems come
> into.
>
> Andreas
>
> On Thursday, August 17, 2023 at 10:29:51 PM UTC+2 Rob CJ wrote:
>
> Hi Andreas,
>
> It might be a optimization issues.
>
> Can you add the following to your program and test if the problem is gone?
>
>   pragma opt expr_reduce no
>
> It will disable code optimization.
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* 'off...@schloegl-software.at' via jallib 
> *Verzonden:* donderdag 17 augustus 2023 21:42
>
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] IF statement fails
> Hi Rob,
> thanks that you are digging into this problem and maybe found the issue
> already.
> I'm a heavy Jal User I would call myself, but this is the first issue I
> found over the last years :-)
>
> On Thursday, August 17, 2023 at 9:31:13 PM UTC+2 Rob CJ wrote:
>
> Hi Andreas,
>
> I had a quick look at the generated assemble code for a PIC16.
>
> In your first code example the code is (I changed 3 times i into i, j and
> k so I could compile it):
>
>  ;   10 i=test1()
>movlw0
>movwfv_i
> ;   11 if i>0 & i<13 then
>movf v_i,w
>bsf  v__bitbucket, 0 ; _btemp1
>btfscv__status, v__z
>
> In your last code example where you removed the function the code is:
>
>   clrf v_k
> ;   35 if k>0 & k<13 then
>movf v_k,w
>bsf  v__bitbucket, 6 ; _btemp7
>btfscv__status, v__z
>
> If I am right - and I hope I am not - the first piece of code does not
> work because the Z flag (v__z) of the status register (v__status) is never
> affected by any of these instructions. In the last code example the clrf
> instruction sets the Z flag.
>
> In other words, moving the return value of 0 to v_i is not the same as
> clearing the value of v_k. So it might be a compiler bug. I wonder why it
> has not been discovered before.
>
> Still need to see if my draft conclusion is correct.
>
> Kind regards,
>
> Rob
>
>
>
> --
> *Van:* 'off...@schloegl-software.at' via jallib 
> *Verzonden:* donderdag 17 augustus 2023 21:07
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] IF statement fails
>
> Hello Rob,
> PIC is a 18f26K83
> compiler called with: ../jalv25r7/compiler/jalv2-x86-64 -no-variable-reuse
> no other specific setting
> Thanks,
> Andreas
>
> On Thursday, August 17, 2023 at 9:00:33 PM UTC+2 Rob CJ wrote:
>
> Hi,
>
> For which PIC did you compile this? 12, 16, 18?
>
> Did you use any compiler optimizations?
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* 'off...@schloegl-software.at' via jallib 
> *Verzonden:* woensdag 16 augustus 2023 22:18
> *Aan:* jallib 
> *Onderwerp:* [jallib] IF statement fails
>
> Hello everyone,
>
> I found this code is not working (using jal jalv25r7, but also older
> versions). Can anyone pls verify:
>
>
> *var byte i *
>
>
> *function test() return byte is return 0 end function*
>
> *i=test() *
> *if i>0 & i<13 then*
>
> *  -- goes here but is wrong *
> *else*
> * ..*
> *end if*
>
> but this code works:
>
> *var byte i *
>
>
> *function test() return byte is return 0 end function*
> *i=test()*
> *if i<13 & i>0 then*
>
> *  .. *
> *else*
>
> *   -- goes here and OK *
> *end if*
>
> if you remove the function, it works, too:
>
> *var byte i *
> *i=0*
> *if i>0 & i<13 then*
>
> *  .. *
> *else*
>  *  -- goes here and OK*
> *end if*
>
> --
> 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/2b197dbf-4628-4acd-b13c-11e3b6ba2228n%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] Releasing untested device files

[vsurducan]

Sorry for this android mess.
The speaker you may consider is thatype from this picture:
https://www.aliexpress.com/item/1005005665700141.html


On Sat, Jul 1, 2023 at 2:21 PM vsurducan  wrote:

> Very nice! One of the chinese kit I have is not able to memorize the last
> frequency. After powering up it starts always at 107MHz.
> However, having a clock to wake you up with a different broadcasted
> program on each morning can be considered too. :)
> And a better speaker.
>
>
> On Thu 29 Jun 2023, 7:34 PM Rob CJ,  wrote:
>
>> Hi Vasile,
>>
>> I am using a single chip FM radio chip for my alarm clock that uses IIC
>> as interface.
>>
>> I even made a JAL library for it (rda5807m.jal) and a video:
>> https://youtu.be/ou3_I3khLIU
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jallib@googlegroups.com  namens
>> vsurducan 
>> *Verzonden:* woensdag 28 juni 2023 20:16
>> *Aan:* jallib@googlegroups.com 
>> *Onderwerp:* Re: [jallib] Releasing untested device files
>>
>> Rob, why don't you use the FM i2c radio module as clock alarm? :)  It's a
>> cool chip. Perhaps you can program it to wake up on different FM
>> frequencies each morning
>>
>> On Tue 27 Jun 2023, 9:13 PM Rob CJ,  wrote:
>>
>> Hi David,
>>
>> Why not use the syntax highlighting in Visual Studio Code using the JAL
>> extension made by Sunish? VS Code is free.
>>
>> Looks very nice (and I find VS Code a very nice editor since you can
>> easily spilt a JAL file and edit in 2 windows at the same time) and it
>> works on Windows, Linux and MAC. A screenshot is given below.
>>
>> The installation of installing the VS Code plug-in is described in the
>> Jallib Tutorial.
>>
>> Nowadays I only use VS Code for all my development.
>>
>> And you are correct. RobBest on Instructables is me since my name is Rob
>> and I live in Best in The Netherlands . I indeed post these project to
>> promote JAL.
>>
>> Currently I am working on my Digital Alarm Clock project. The clock broke
>> down but instead of throwing it away I decided to make the a version using
>> a PIC and JAL. I can then finally make use of some of the libraries that I
>> created earlier .  The project will be posted on Instructable once I
>> have completed the project.
>>
>> Kind regards,
>>
>> Rob
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Van:* jallib@googlegroups.com  namens Rob
>> Hamerling 
>> *Verzonden:* dinsdag 27 juni 2023 19:59
>> *Aan:* jallib@googlegroups.com 
>> *Onderwerp:* Re: [jallib] Releasing untested device files
>>
>>
>> Hi David,
>>
>> On 27-06-2023 18:04, pinhe...@gmail.com wrote:
>>
>>
>> One thing I always wanted but was also too lazy to set up, as a
>> configuraiton file for setting up the syntax coloring and complier command
>> lines for jal in NotePad++.
>> And maybe also other popular editors you may know of.
>>
>> Although I'm not doing much with JAL these days I made a Jal syntax
>> highlighting file for XED and GEDIT not so long ago. Maybe it can help you
>> to make something alike for NotePad++ (whatever that may be). In that case
>> see:
>>
>> https://gitlab.com/robhamerling/jal_language_highlighting_with_gtksourceview
>>
>> Regards, Rob.
>>
>> --
>> *Rob H*amerling, 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/e13fe273-174d-b1d9-3059-0dbb3f047df3%40gmail.com
>> <https://groups.google.com/d/msgid/jallib/e13fe273-174d-b1d9-3059-0dbb3f047df3%40gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jallib+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jallib/GVXP195MB16374DFE707BC64A43168C2EE627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
>> <https://groups.google.com/d/msgid/jallib/GVXP195MB16374DFE707BC64A43168C2EE627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
&g

Re: [jallib] Releasing untested device files

[vsurducan]

Actually, the better choice is a random FM selection each time you need an
alarm.
I wrote a while ago one 32bit pseudorandom generator, I think... :)
Even better: a random wake-up hour for your clock!   :) :P

On Wed, Jun 28, 2023 at 8:16 PM vsurducan  wrote:

> Rob, why don't you use the FM i2c radio module as clock alarm? :)  It's a
> cool chip. Perhaps you can program it to wake up on different FM
> frequencies each morning
>
> On Tue 27 Jun 2023, 9:13 PM Rob CJ,  wrote:
>
>> Hi David,
>>
>> Why not use the syntax highlighting in Visual Studio Code using the JAL
>> extension made by Sunish? VS Code is free.
>>
>> Looks very nice (and I find VS Code a very nice editor since you can
>> easily spilt a JAL file and edit in 2 windows at the same time) and it
>> works on Windows, Linux and MAC. A screenshot is given below.
>>
>> The installation of installing the VS Code plug-in is described in the
>> Jallib Tutorial.
>>
>> Nowadays I only use VS Code for all my development.
>>
>> And you are correct. RobBest on Instructables is me since my name is Rob
>> and I live in Best in The Netherlands . I indeed post these project to
>> promote JAL.
>>
>> Currently I am working on my Digital Alarm Clock project. The clock broke
>> down but instead of throwing it away I decided to make the a version using
>> a PIC and JAL. I can then finally make use of some of the libraries that I
>> created earlier .  The project will be posted on Instructable once I
>> have completed the project.
>>
>> Kind regards,
>>
>> Rob
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Van:* jallib@googlegroups.com  namens Rob
>> Hamerling 
>> *Verzonden:* dinsdag 27 juni 2023 19:59
>> *Aan:* jallib@googlegroups.com 
>> *Onderwerp:* Re: [jallib] Releasing untested device files
>>
>>
>> Hi David,
>>
>> On 27-06-2023 18:04, pinhe...@gmail.com wrote:
>>
>>
>> One thing I always wanted but was also too lazy to set up, as a
>> configuraiton file for setting up the syntax coloring and complier command
>> lines for jal in NotePad++.
>> And maybe also other popular editors you may know of.
>>
>> Although I'm not doing much with JAL these days I made a Jal syntax
>> highlighting file for XED and GEDIT not so long ago. Maybe it can help you
>> to make something alike for NotePad++ (whatever that may be). In that case
>> see:
>>
>> https://gitlab.com/robhamerling/jal_language_highlighting_with_gtksourceview
>>
>> Regards, Rob.
>>
>> --
>> *Rob H*amerling, 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/e13fe273-174d-b1d9-3059-0dbb3f047df3%40gmail.com
>> <https://groups.google.com/d/msgid/jallib/e13fe273-174d-b1d9-3059-0dbb3f047df3%40gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jallib+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jallib/GVXP195MB16374DFE707BC64A43168C2EE627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
>> <https://groups.google.com/d/msgid/jallib/GVXP195MB16374DFE707BC64A43168C2EE627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt%2B4%3Dhj7kwGAw%2Bave7EK3Tw9KZN6F7HZtcmgCqvsKk73g%40mail.gmail.com.

Re: [jallib] Peripheral hardware and interrupts

[vsurducan]

> ;  120end if
> ;  121 end function
> l__l523
>decfsz   v__ri2c_transmit_byte,f
>goto l__l715
>return
> l__l715
>movf v__pic_stkptr+1,w
>movwfv__fsr0h
>movf v__pic_stkptr,w
>movwfv__fsr0l
>movf v__ind,w
>movwfv__fi2c_transmit_byte
>incf v__fsr0l,w
>movwfv__pic_stkptr
> l__l714
>return
>
> I think it cannot be mixed. The only solution I can think of is making
> separate routines that access the IIC hardware registers directly without a
> call to any other - common - routine.
>
> Kind regards,
>
> Rob
>
>
> --
> *Van:* jallib@googlegroups.com  namens Rob CJ <
> rob...@hotmail.com>
> *Verzonden:* donderdag 1 juni 2023 21:01
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Peripheral hardware and interrupts
>
> Hi Vasile,
>
> Good suggestion. I will give it a try.
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* donderdag 1 juni 2023 20:58
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Peripheral hardware and interrupts
>
> Hi Rob,
> Perhaps you should disable/enable interrupts within the I2c procedures and
> not for the entire main program.
> The way you did it, by writing a flag in the ISR and reading it in the
> main is correct. If you need less delay between the main execution and
> interrupt flag refresh, you should have just one interrupt routine and keep
> it as short as possible. Nowadays the JAL libraries are using multiple
> ISR's which are controlled entirely by the compiler. This feature does not
> give too many options to the user except writing his own procedures for
> sensitive interrupt applications instead of using libraries with their own
> ISR's.
>
> best wishes
>
> On Thu, Jun 1, 2023 at 9:34 PM rob...@hotmail.com 
> wrote:
>
> Hi all,
>
> I have the following issue and I am interested in either your suggestions
> or if you encountered the same problem. The example is based on the sample
> program I made for the real time clock library DS3231.
>
> The DS3231 has two alarms and uses the IIC interface. The device has an
> interrupt line that can be activated when an alarm is triggered. I
> connected this line to the external interrupt of the PIC.
>
> The main program read the time and sends it to the serial port. Since the
> main program calls DA3231 functions, the IIC interface is used to access
> the DS3231. When an interrupt occurs, a register has to be read from the
> DS3231 to see which alarm was activated also using the IIC interface of
> course.
>
> In order to prevent that halfway an IIC transmission initiated by a
> library call from the main program, I disable the external interrupt of the
> PIC at the start of the main program an enable it again at the end of the
> main program. In that way I am sure that the interrupt does not interrupt
> an IIC transmission initiated by the main program. There is a delay at the
> end of the main program, sufficient for any pending interrupt to be handled.
>
> The problem is that it does not work. The PIC just hangs and does not
> start. The only solution I found is setting a flag in the interrupt routine
> and let the main program poll this flag and read the register from the
> DS3231 to check which alarm was activated. But in this way the whole idea
> of the interrupt is gone.
>
> Looking forward to your reactions and 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 to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/679a0f81-03fe-4310-b401-ac69f2d2aeadn%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/679a0f81-03fe-4310-b401-ac69f2d2aeadn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "jallib" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jallib/13BABaIMXzs/unsubscribe.
> To unsubscribe from t

Re: [jallib] Peripheral hardware and interrupts

[vsurducan]

Hi Rob,
Perhaps you should disable/enable interrupts within the I2c procedures and
not for the entire main program.
The way you did it, by writing a flag in the ISR and reading it in the main
is correct. If you need less delay between the main execution and interrupt
flag refresh, you should have just one interrupt routine and keep it as
short as possible. Nowadays the JAL libraries are using multiple ISR's
which are controlled entirely by the compiler. This feature does not give
too many options to the user except writing his own procedures for
sensitive interrupt applications instead of using libraries with their own
ISR's.

best wishes

On Thu, Jun 1, 2023 at 9:34 PM rob...@hotmail.com 
wrote:

> Hi all,
>
> I have the following issue and I am interested in either your suggestions
> or if you encountered the same problem. The example is based on the sample
> program I made for the real time clock library DS3231.
>
> The DS3231 has two alarms and uses the IIC interface. The device has an
> interrupt line that can be activated when an alarm is triggered. I
> connected this line to the external interrupt of the PIC.
>
> The main program read the time and sends it to the serial port. Since the
> main program calls DA3231 functions, the IIC interface is used to access
> the DS3231. When an interrupt occurs, a register has to be read from the
> DS3231 to see which alarm was activated also using the IIC interface of
> course.
>
> In order to prevent that halfway an IIC transmission initiated by a
> library call from the main program, I disable the external interrupt of the
> PIC at the start of the main program an enable it again at the end of the
> main program. In that way I am sure that the interrupt does not interrupt
> an IIC transmission initiated by the main program. There is a delay at the
> end of the main program, sufficient for any pending interrupt to be handled.
>
> The problem is that it does not work. The PIC just hangs and does not
> start. The only solution I found is setting a flag in the interrupt routine
> and let the main program poll this flag and read the register from the
> DS3231 to check which alarm was activated. But in this way the whole idea
> of the interrupt is gone.
>
> Looking forward to your reactions and 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 to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/679a0f81-03fe-4310-b401-ac69f2d2aeadn%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%2Bj4qt%3DKi2pGVDwyLkzHmZJAsaX0qkoQPxM-p580W4BC%3DKNMw%40mail.gmail.com.

Re: [jallib] ChatGPT does not know JAL :-(

[vsurducan]

Beware Rob.
I suggest you see a movie prior to teaching AI anything. It's called
"Somebody", Korea 2022.
Unless you want uncontrollable modifications to your jal pack...

On Sun, Jan 29, 2023 at 7:22 PM rob...@hotmail.com 
wrote:

> Hi all,
>
> I see people using ChatGPT to make programs for Arduino. I thought to give
> it a try and asked ChatGPT if it could write a JAL program for a PIC
> microcontroller.
>
> The response was as folows:
>
> "I apologize, but as JAL is not a programming language that I am aware of,
> I am unable to provide a sample program for it. If you provide more
> information about JAL such as specifications, syntax, and libraries, I
> would be happy to help you create a program. Also, PIC microcontroller are
> programmable with a variety of languages such as C, Basic, and Assembler.
> It would be helpful to know which type of PIC Microcontroller you have, and
> what would you like to achieve with the program."
>
> We need to learn this AI some JAL :-)
>
> 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/6bd003aa-9606-4ab5-9d5a-2a58e2cdf1c2n%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%2Bj4qs85pXY0%3DD7sHc%3DZ2DH%2BWOYC_c2azX77uOH-yLmJTGjPQ%40mail.gmail.com.

Re: [jallib] PIC Simulator (free software)

[vsurducan]

Oshon was free at the beginning of jal...Very nice colours...:)

 It's impossible to simulate a hex without comment delays first, or set
breakpoints. Unless you want to be sure that delays  works ok. :)  Of
course if still choose line by line simulation on the entire source
retirement will definitely happen untill finish.
On the other hand, spending time on simulation is valuable. Finally you can
realise that simulator does not work as it should...:)

On Thu 26 Jan 2023, 7:42 PM Rob CJ  Hi Vasile,
>
> Hi have played with this one but it is not free:
> https://oshonsoft.com/pic.php
> <https://oshonsoft.com/pic.php>
> OshonSoft PIC Simulator IDE with PIC Basic Compiler
> <https://oshonsoft.com/pic.php>
> PIC SIMULATOR IDE (with pic basic compiler) HOMEPAGE. PIC Simulator IDE is
> powerful application that supplies Microchip microcontroller users with
> user-friendly graphical development environment for Windows with integrated
> simulator (emulator), pic basic compiler, assembler, disassembler and
> debugger. PIC Simulator IDE supports the extensive number of
> microcontrollers (MCUs) from the Microchip ...
> oshonsoft.com
>
> I also did some debugging using MPLABX. You can load your hexfile and step
> through the code. When using a PICkit3 you can also set a breakpoint and
> stop but it is not easy since you need the asm file to find out where you
> are.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* donderdag 26 januari 2023 04:45
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] PIC Simulator (free software)
>
> Beware, you will not be able to simulate your code as is, just non delayed
> routines, some math computations, etc. Old jal had a built in simulator for
> this, it was good stuff at that time...
>
> On Wed 25 Jan 2023, 9:50 PM flyway38 
> Hello all,
>
> Does anyone know any PIC simulator, free software for PC to check some
> basic stuff code and able to read the HEX file?
> 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/aed6af05-ad9e-4f33-953d-17a35a8058bfn%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/aed6af05-ad9e-4f33-953d-17a35a8058bfn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsdmLEe29vunsCGKBHmRgPdawKpUcFv%3D%3Da2hvjihrOPKQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsdmLEe29vunsCGKBHmRgPdawKpUcFv%3D%3Da2hvjihrOPKQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/GVXP195MB1637B9D44D2D629E65275ADBE6CF9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637B9D44D2D629E65275ADBE6CF9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt0Ra%2BtEoHEqNB9UKznLeNsy78nxgx_MxKvckJW9%3DW8Xw%40mail.gmail.com.

Re: [jallib] PIC Simulator (free software)

[vsurducan]

Beware, you will not be able to simulate your code as is, just non delayed
routines, some math computations, etc. Old jal had a built in simulator for
this, it was good stuff at that time...

On Wed 25 Jan 2023, 9:50 PM flyway38  Hello all,
>
> Does anyone know any PIC simulator, free software for PC to check some
> basic stuff code and able to read the HEX file?
> 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/aed6af05-ad9e-4f33-953d-17a35a8058bfn%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%2Bj4qsdmLEe29vunsCGKBHmRgPdawKpUcFv%3D%3Da2hvjihrOPKQ%40mail.gmail.com.

Re: [jallib] Convert Ascii Digits String to word var help

[vsurducan]

Hi Fellipe,
If the ascii string content is numbers 0 to 9, then perhaps you can use
function string_to_ dword from strings.jal library.

However I'm not sure is better than yours. It depends of what you try to
hit: best structured source code, fastest hex code or lowest hw stack.
best wishes,

On Sat 21 Jan 2023, 8:57 PM flyway38  Hello to all,
>
> Am facing this task of converting to a word var, for use in some
> calculations, a value that is received as a ascii string, ex: "00800" that
> need it as a value of 800 in a word var.
> Came up with this code below, but need some advice on a more efficient
> method to get same result.
> Any ideas would be great.
>
> function AsciiStringToWord(byte IN str[]) return word is
>-- Max LEN in str is 5 chars (Converting to word: max= 65535)
>var word wRtn
>var word len = count(str)
>var byte i
>var byte ii
>--
>for len using i loop -- Can be use STEP -1 ??
>   --wRtn = wRtn + str[i]*(10^i) -- Can be used "^" for power
> operations ???
>   -- This code would be enough
>
>   -- Here my alternate code for same result
>   case i of
>   0: wRtn=wRtn+(str[5 - len + i]-48)
>   1: wRtn=wRtn+(str[5 - len + i]-48)*10
>   2: wRtn=wRtn+(str[5 - len + i]-48)*100
>   3: wRtn=wRtn+(str[5 - len + i]-48)*1_000
>   4: wRtn=wRtn+(str[5 - len + i]-48)*10_000
>   end case
>end loop
> end function
>
> Thank you.
>
> 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/f3e04583-4ea7-4302-9273-220361de6874n%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%2Bj4qt2U1ZuL2Pii97SaD6G%3D3Om-uwbaXqw-YT%3DSNSW99eRZw%40mail.gmail.com.

Re: [jallib] Jallib - 1.7 Beta

[vsurducan]

But the github can be downloaded prior to any release...
Seems no congrats then... :)  except if you understood my thought.

On Fri, Jan 20, 2023 at 10:55 AM Rob CJ  wrote:

> Hi Vasile,
>
> Note that these are items that are on GitHub and are not yet part of the
> release. Some because e.g. the device could not yet be tested or samples
> are not yet available.
>
> The contents of the items which will be part of the new release are in the
> Changelog (see attachment) .
>
> These items are already part of the bee-packages.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* vrijdag 20 januari 2023 04:44
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Jallib - 1.7 Beta
>
> The jal growth is fantastic! Congrats guys!
>
>
> On Fri 20 Jan 2023, 4:44 AM Matthew Schinkel  wrote:
>
> Here's the output of torelease.py. Thanks Rob.
>
> If anyone wants any of these in the release, please add them to TORELEASE.
>
> Unreleased libraries and device files
> 
> include/device/12lf1840t39a.jal
> include/device/12lf1840t48a.jal
> include/device/16f17114.jal
> include/device/16f17115.jal
> include/device/16f17124.jal
> include/device/16f17125.jal
> include/device/16f17144.jal
> include/device/16f17145.jal
> include/device/16f18026.jal
> include/device/16f18046.jal
> include/device/16f18054.jal
> include/device/16f18055.jal
> include/device/16f18074.jal
> include/device/16f18075.jal
> include/device/16f18114.jal
> include/device/16f18115.jal
> include/device/16f18124.jal
> include/device/16f18125.jal
> include/device/16f18126.jal
> include/device/16f18144.jal
> include/device/16f18145.jal
> include/device/16f18146.jal
> include/device/16f1829lin.jal
> include/device/16f83.jal
> include/device/16f84.jal
> include/device/16lf1824t39a.jal
> include/device/18f26q71.jal
> include/device/18f46q71.jal
> include/device/18f56q71.jal
> include/device/18f86j72.jal
> include/device/18f87j72.jal
> include/external/battery/ltc2942.jal
> include/external/lcd/glcd_digits.jal
> include/external/oxygen/goel370.jal
> include/external/pressure/bmp085.jal
> include/external/rtc/rtc_mcp7940.jal
> include/external/sound/beep.jal
> include/external/storage/flash_sst25vf.jal
> include/jal/debug_queue.jal
>
> 39 unreleased libraries and device files
>
>
> Unreleased samples (including basic blink samples)
> ---
> sample/12f1572_steppermotor.jal
> sample/12lf1840t39a_blink_hs.jal
> sample/12lf1840t39a_blink_intosc.jal
> sample/12lf1840t48a_blink_hs.jal
> sample/12lf1840t48a_blink_intosc.jal
> sample/16f1519_bmp085.jal
> sample/16f1615_steppermotor.jal
> sample/16f17114_blink_hs.jal
> sample/16f17114_blink_intosc.jal
> sample/16f17115_blink_hs.jal
> sample/16f17115_blink_intosc.jal
> sample/16f17124_blink_hs.jal
> sample/16f17124_blink_intosc.jal
> sample/16f17125_blink_hs.jal
> sample/16f17125_blink_intosc.jal
> sample/16f17144_blink_hs.jal
> sample/16f17144_blink_intosc.jal
> sample/16f17145_blink_hs.jal
> sample/16f17145_blink_intosc.jal
> sample/16f1765_steppermotor.jal
> sample/16f18026_blink_intosc.jal
> sample/16f18046_blink_intosc.jal
> sample/16f18054_blink_intosc.jal
> sample/16f18055_blink_intosc.jal
> sample/16f18074_blink_intosc.jal
> sample/16f18075_blink_intosc.jal
> sample/16f18114_blink_hs.jal
> sample/16f18114_blink_intosc.jal
> sample/16f18115_blink_hs.jal
> sample/16f18115_blink_intosc.jal
> sample/16f18124_blink_hs.jal
> sample/16f18124_blink_intosc.jal
> sample/16f18125_blink_hs.jal
> sample/16f18125_blink_intosc.jal
> sample/16f18126_blink_hs.jal
> sample/16f18126_blink_intosc.jal
> sample/16f18144_blink_hs.jal
> sample/16f18144_blink_intosc.jal
> sample/16f18145_blink_hs.jal
> sample/16f18145_blink_intosc.jal
> sample/16f18146_blink_hs.jal
> sample/16f18146_blink_intosc.jal
> sample/16f1829lin_blink_hs.jal
> sample/16f1829lin_blink_intosc.jal
> sample/16f18325_steppermotor.jal
> sample/16f83_blink_hs.jal
> sample/16f84_blink_hs.jal
> sample/16lf1824t39a_blink_hs.jal
> sample/16lf1824t39a_blink_intosc.jal
> sample/18f06q41_blink_hs.jal
> sample/18f2585_oxygen_goel370.jal
> sample/18f26k22_sst25vf.jal
> sample/18f26q71_blink_hs.jal
> sample/18f26q71_blink_intosc.jal
> sample/18f27j53_sst25vf.jal
> sample/18f27q84_blink_hs.jal
> sample/18f4620_rotary_encoder_e6b2.jal
> sample/18f4620_rtc_mcp7940.jal
> sample/18f4620_timer.jal
> sample/18f46q71_blink_hs.jal
> sample/18f46q71_blink_intosc.jal
> sample/18f4

Re: [jallib] Jallib - 1.7 Beta

[vsurducan]

The jal growth is fantastic! Congrats guys!


On Fri 20 Jan 2023, 4:44 AM Matthew Schinkel  Here's the output of torelease.py. Thanks Rob.
>
> If anyone wants any of these in the release, please add them to TORELEASE.
>
> Unreleased libraries and device files
> 
> include/device/12lf1840t39a.jal
> include/device/12lf1840t48a.jal
> include/device/16f17114.jal
> include/device/16f17115.jal
> include/device/16f17124.jal
> include/device/16f17125.jal
> include/device/16f17144.jal
> include/device/16f17145.jal
> include/device/16f18026.jal
> include/device/16f18046.jal
> include/device/16f18054.jal
> include/device/16f18055.jal
> include/device/16f18074.jal
> include/device/16f18075.jal
> include/device/16f18114.jal
> include/device/16f18115.jal
> include/device/16f18124.jal
> include/device/16f18125.jal
> include/device/16f18126.jal
> include/device/16f18144.jal
> include/device/16f18145.jal
> include/device/16f18146.jal
> include/device/16f1829lin.jal
> include/device/16f83.jal
> include/device/16f84.jal
> include/device/16lf1824t39a.jal
> include/device/18f26q71.jal
> include/device/18f46q71.jal
> include/device/18f56q71.jal
> include/device/18f86j72.jal
> include/device/18f87j72.jal
> include/external/battery/ltc2942.jal
> include/external/lcd/glcd_digits.jal
> include/external/oxygen/goel370.jal
> include/external/pressure/bmp085.jal
> include/external/rtc/rtc_mcp7940.jal
> include/external/sound/beep.jal
> include/external/storage/flash_sst25vf.jal
> include/jal/debug_queue.jal
>
> 39 unreleased libraries and device files
>
>
> Unreleased samples (including basic blink samples)
> ---
> sample/12f1572_steppermotor.jal
> sample/12lf1840t39a_blink_hs.jal
> sample/12lf1840t39a_blink_intosc.jal
> sample/12lf1840t48a_blink_hs.jal
> sample/12lf1840t48a_blink_intosc.jal
> sample/16f1519_bmp085.jal
> sample/16f1615_steppermotor.jal
> sample/16f17114_blink_hs.jal
> sample/16f17114_blink_intosc.jal
> sample/16f17115_blink_hs.jal
> sample/16f17115_blink_intosc.jal
> sample/16f17124_blink_hs.jal
> sample/16f17124_blink_intosc.jal
> sample/16f17125_blink_hs.jal
> sample/16f17125_blink_intosc.jal
> sample/16f17144_blink_hs.jal
> sample/16f17144_blink_intosc.jal
> sample/16f17145_blink_hs.jal
> sample/16f17145_blink_intosc.jal
> sample/16f1765_steppermotor.jal
> sample/16f18026_blink_intosc.jal
> sample/16f18046_blink_intosc.jal
> sample/16f18054_blink_intosc.jal
> sample/16f18055_blink_intosc.jal
> sample/16f18074_blink_intosc.jal
> sample/16f18075_blink_intosc.jal
> sample/16f18114_blink_hs.jal
> sample/16f18114_blink_intosc.jal
> sample/16f18115_blink_hs.jal
> sample/16f18115_blink_intosc.jal
> sample/16f18124_blink_hs.jal
> sample/16f18124_blink_intosc.jal
> sample/16f18125_blink_hs.jal
> sample/16f18125_blink_intosc.jal
> sample/16f18126_blink_hs.jal
> sample/16f18126_blink_intosc.jal
> sample/16f18144_blink_hs.jal
> sample/16f18144_blink_intosc.jal
> sample/16f18145_blink_hs.jal
> sample/16f18145_blink_intosc.jal
> sample/16f18146_blink_hs.jal
> sample/16f18146_blink_intosc.jal
> sample/16f1829lin_blink_hs.jal
> sample/16f1829lin_blink_intosc.jal
> sample/16f18325_steppermotor.jal
> sample/16f83_blink_hs.jal
> sample/16f84_blink_hs.jal
> sample/16lf1824t39a_blink_hs.jal
> sample/16lf1824t39a_blink_intosc.jal
> sample/18f06q41_blink_hs.jal
> sample/18f2585_oxygen_goel370.jal
> sample/18f26k22_sst25vf.jal
> sample/18f26q71_blink_hs.jal
> sample/18f26q71_blink_intosc.jal
> sample/18f27j53_sst25vf.jal
> sample/18f27q84_blink_hs.jal
> sample/18f4620_rotary_encoder_e6b2.jal
> sample/18f4620_rtc_mcp7940.jal
> sample/18f4620_timer.jal
> sample/18f46q71_blink_hs.jal
> sample/18f46q71_blink_intosc.jal
> sample/18f47q84_blink_hs.jal
> sample/18f56q71_blink_hs.jal
> sample/18f56q71_blink_intosc.jal
> sample/18f57q84_blink_hs.jal
> sample/18f67j50_debug_queue.jal
> sample/18f86j72_blink_hs.jal
> sample/18f86j72_blink_intosc.jal
> sample/18f86j72_blink_intosc_usb.jal
> sample/18f87j72_blink_hs.jal
> sample/18f87j72_blink_intosc.jal
> sample/18f87j72_blink_intosc_usb.jal
>
> 72 unreleased sample files
>
>
> Unreleased Project files
> 
> project/catpad_mw/Handset_16f877.jal
> project/catpad_mw/adc_channels.jal
> project/catpad_mw/adc_clock.jal
> project/catpad_mw/analogue.jal
> project/catpad_mw/array_storage.jal
> project/catpad_mw/bcd_utils.jal
> project/catpad_mw/calendar.jal
> project/catpad_mw/cat_ft817.jal
> project/catpad_mw/catpad_main.jal
> project/catpad_mw/catpatv2.jal
> project/catpad_mw/delay.jal
> project/catpad_mw/dev_glcd_ks0108.jal
> project/catpad_mw/dev_keypad5x5.jal
> project/catpad_mw/dev_keypad6x8.jal
> project/catpad_mw/dev_lcd_hd44780_4.jal
> project/catpad_mw/dev_lcd_hd44780_common.jal
> project/catpad_mw/dev_rds_rx.jal
> project/catpad_mw/dev_sram_23k256_spi.jal
> project/catpad_mw/graphics.jal
> project/catpad_mw/io_i2c_sw.jal
> project/catpad_mw/io_usart_common.jal
> 

Re: [jallib] PIC16F19176 rtc help

[vsurducan]

Yep. If a secondary oscillator available, definitely yes for the RTC,
except maybe for running at -20C where a good TCXO is expensive, using only
one could be an option.
Apples with pears are still fruits, not very bad comparison. :)

On Wed, Jan 11, 2023 at 7:46 PM Rob CJ  wrote:

> Hi Filipe,
>
> It helps if you send your program otherwise we are comparing apples with
> pears.
>
> There is another possibility. Your PIC has a secondary oscillator, meant
> for connecting a 32 kHz crystal. If you use that, you can make your own RTC
> and the only thing you need is a 32 kHz crystal and a small piece of
> software.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens flyway38 <
> fsfon...@gmail.com>
> *Verzonden:* woensdag 11 januari 2023 14:53
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] PIC16F19176 rtc help
>
> Hello Vasile,
>
> I think that have already tried that sample, but as said before, think i
> fall into some LIB errors...
> Will check again, but maybe get stuck while adapting it to my PIC...
> Will back here with results.
> Thank you very much.
>
> Cheers,
> FS
>
> On Wednesday, January 11, 2023 at 3:50:33 AM UTC vasile wrote:
>
> Hi Fellipe,
> You will not like my ideea but any rtc can be implemented in any pic, much
> better than using an external RTC, by using Bresenham zero error algorithm.
>
> It's in the sample and works perfect with all timers.
>
> It's set to seconds but works down to 1ms for fast pics.
> You have just to set a flag in the isr when time passed and reset it in
> the main after you have read it.
>
> The only thing to care is the total lenght of your isr, including your own
> application which must be shorter than time genetated (aka 1 second or
> shorter).
>
>
> On Tue 10 Jan 2023, 9:25 PM flyway38 
> Hi Rob,
>
> It seems something not working...
> Not sure why, but using your sample (part of it, check below what have
> integrated in my code from your sample), it doesn't even reach the FOREVER
> LOOP...
> Maybe because am using serial_hw_int_cts instead of serial_hardware, or
> even because am using timer0_isr_interval... don't know...
> Here's what am using from your sample:
>
> -- Settings for the RTC and intialization.
> alias rtc_sck is pin_C0 -- Pin 10 for 14 pin DIP
> alias rtc_sck_direction is pin_C0_direction
> alias rtc_sdo is pin_C1 -- Pin 9 for 14 pin DIP.
> alias rtc_sdo_direction is pin_C1_direction
> -- If you want to use software IIC, define the following constant.
> -- const RTC_SOFTWARE_IIC = TRUE
> include rtc_ds3231
>
> -- Setting to check the alarm on a poll basis or interrupt bases. When
> -- defined the alarms are checked using the external interrupt of the PIC.
> -- Using the interrupt has its limitations for this rtc as explained in the
> -- sample interrupt routine below.
> -- const ALARM_ON_INTERRUPT = TRUE
>
> -- Print the current time of the rtc.
> procedure print_time() is
>
>var byte hours, minutes, seconds
>
>rtc_get_time_bin(hours, minutes, seconds)
>print_string(serial_hw_data, "H:")
>print_byte_dec(serial_hw_data, hours)
>print_string(serial_hw_data, " M:")
>print_byte_dec(serial_hw_data, minutes)
>print_string(serial_hw_data, " S:")
>print_byte_dec(serial_hw_data, seconds)
>print_crlf(serial_hw_data)
>
> end procedure
>
> -- Example of handling the alarm on an interrupt basis. Note that we cannot
> -- call any of the RTC procedures because it will interfere with the IIC
> -- transmission. We can only set a flag that can be checked later. Note
> that
> -- the interrupt is edge triggered. The rtc interrupt stays low as long as
> -- the alarm flag of the RTC is set.
> if defined(ALARM_ON_INTERRUPT) then
>procedure alarm_interrupt is pragma interrupt
>   if INTCON_INTF then
>  INTCON_INTF = FALSE
>  alarm_was_given = TRUE
>   end if
>end procedure
> end if
>
> rtc_init()
>
> -- Enable interrupts if setting is defined.
> if defined(ALARM_ON_INTERRUPT) then
>INTCON_INTE = TRUE
>-- Interrupt on falling edge.
>OPTION_REG_INTEDG = FALSE
>INTCON_GIE = TRUE
>rtc_enable_alarm_1_interrupt()
>rtc_enable_alarm_2_interrupt()
> end if
>
> Don't need to use any Alarms...
> But need to use Timer Interval to do some checks regularly.
>
> Anyways, have put just before FOREVER LOOP:
> -- Set some intial time hh:mm:ss in binary format and print it.
> rtc_set_time_bin(18, 51, 30)
> print_time()
> This code doesn't run...
>
> Any ideas?
> Thank you very much.
>
> FS
> On Tuesday, January 10, 2023 at 6:45:27 PM UTC flyway38 wrote:
>
> Hi Rob,
>
> Wow.
> Thank you very much for the fast reply.
> Will check and back here with results.
>
> Cheers,
> FS
>
> On Tuesday, January 10, 2023 at 6:35:45 PM UTC rob...@hotmail.com wrote:
>
> Hi Filipe,
>
> I took the sample program 16f1825_rtc_ds3231.jal and changed it for the
> 16f19176.
>
> No compiler issues.
>
> See attachment.
>
> Kind regards,
>
> Rob
>
> 

Re: [jallib] PIC16F19176 rtc help

[vsurducan]

Hi Fellipe,
You will not like my ideea but any rtc can be implemented in any pic, much
better than using an external RTC, by using Bresenham zero error algorithm.

It's in the sample and works perfect with all timers.

It's set to seconds but works down to 1ms for fast pics.
You have just to set a flag in the isr when time passed and reset it in the
main after you have read it.

The only thing to care is the total lenght of your isr, including your own
application which must be shorter than time genetated (aka 1 second or
shorter).


On Tue 10 Jan 2023, 9:25 PM flyway38  Hi Rob,
>
> It seems something not working...
> Not sure why, but using your sample (part of it, check below what have
> integrated in my code from your sample), it doesn't even reach the FOREVER
> LOOP...
> Maybe because am using serial_hw_int_cts instead of serial_hardware, or
> even because am using timer0_isr_interval... don't know...
> Here's what am using from your sample:
>
> -- Settings for the RTC and intialization.
> alias rtc_sck is pin_C0 -- Pin 10 for 14 pin DIP
> alias rtc_sck_direction is pin_C0_direction
> alias rtc_sdo is pin_C1 -- Pin 9 for 14 pin DIP.
> alias rtc_sdo_direction is pin_C1_direction
> -- If you want to use software IIC, define the following constant.
> -- const RTC_SOFTWARE_IIC = TRUE
> include rtc_ds3231
>
> -- Setting to check the alarm on a poll basis or interrupt bases. When
> -- defined the alarms are checked using the external interrupt of the PIC.
> -- Using the interrupt has its limitations for this rtc as explained in the
> -- sample interrupt routine below.
> -- const ALARM_ON_INTERRUPT = TRUE
>
> -- Print the current time of the rtc.
> procedure print_time() is
>
>var byte hours, minutes, seconds
>
>rtc_get_time_bin(hours, minutes, seconds)
>print_string(serial_hw_data, "H:")
>print_byte_dec(serial_hw_data, hours)
>print_string(serial_hw_data, " M:")
>print_byte_dec(serial_hw_data, minutes)
>print_string(serial_hw_data, " S:")
>print_byte_dec(serial_hw_data, seconds)
>print_crlf(serial_hw_data)
>
> end procedure
>
> -- Example of handling the alarm on an interrupt basis. Note that we cannot
> -- call any of the RTC procedures because it will interfere with the IIC
> -- transmission. We can only set a flag that can be checked later. Note
> that
> -- the interrupt is edge triggered. The rtc interrupt stays low as long as
> -- the alarm flag of the RTC is set.
> if defined(ALARM_ON_INTERRUPT) then
>procedure alarm_interrupt is pragma interrupt
>   if INTCON_INTF then
>  INTCON_INTF = FALSE
>  alarm_was_given = TRUE
>   end if
>end procedure
> end if
>
> rtc_init()
>
> -- Enable interrupts if setting is defined.
> if defined(ALARM_ON_INTERRUPT) then
>INTCON_INTE = TRUE
>-- Interrupt on falling edge.
>OPTION_REG_INTEDG = FALSE
>INTCON_GIE = TRUE
>rtc_enable_alarm_1_interrupt()
>rtc_enable_alarm_2_interrupt()
> end if
>
> Don't need to use any Alarms...
> But need to use Timer Interval to do some checks regularly.
>
> Anyways, have put just before FOREVER LOOP:
> -- Set some intial time hh:mm:ss in binary format and print it.
> rtc_set_time_bin(18, 51, 30)
> print_time()
> This code doesn't run...
>
> Any ideas?
> Thank you very much.
>
> FS
> On Tuesday, January 10, 2023 at 6:45:27 PM UTC flyway38 wrote:
>
>> Hi Rob,
>>
>> Wow.
>> Thank you very much for the fast reply.
>> Will check and back here with results.
>>
>> Cheers,
>> FS
>>
>> On Tuesday, January 10, 2023 at 6:35:45 PM UTC rob...@hotmail.com wrote:
>>
>>> Hi Filipe,
>>>
>>> I took the sample program 16f1825_rtc_ds3231.jal and changed it for the
>>> 16f19176.
>>>
>>> No compiler issues.
>>>
>>> See attachment.
>>>
>>> Kind regards,
>>>
>>> Rob
>>>
>>> --
>>> *Van:* jal...@googlegroups.com  namens
>>> flyway38 
>>> *Verzonden:* dinsdag 10 januari 2023 19:04
>>> *Aan:* jallib 
>>> *Onderwerp:* [jallib] PIC16F19176 rtc help
>>>
>>> Hello all,
>>>
>>> Need help on coding for an rtc for the 16F19176.
>>> Have tried many samples with no luck. They get alot of failures, like
>>> not defined terms...
>>> Need to implement a simple RTC code to keep track of time even if PIC is
>>> handling "closed loop" routines, like reading Comm Port or resetting the
>>> gsm modem, etc...
>>> Need these routines to get interrupted, and finished after RTC updates
>>> time.
>>> It would be a very fast code, only to increment a variable.
>>> Need some sample code adapted for this PIC, please.
>>> Thank you
>>>
>>> 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+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jallib/4b03768d-331b-4a4c-aa10-afbf73fc952cn%40googlegroups.com
>>> 

Re: [jallib] USB_help

[vsurducan]

Perhaps a note in the sample header should attention the user  to read
datasheet about the use of PGM pin and LVP bit when LVP programming is used?

That will avoid other possible situations for not tested microcontrollers
using various types of programmers HW.

For example the user is not disconnecting the programmer, has a pull down
on his HW but the programmer has a pull-up on PGM. The combination may
create an erratic voltage on PGM (not low but also not high) if the user
does not disconnect the programmer cable before use...

It seems to me that LVP  is not about library but about programming.


On Wed 4 Jan 2023, 7:50 PM Rob CJ  Hi Vasile,
>
> OK, so PGM should either be low (no LVP) or high (LVP) and not floating.
>
> This means that for these PIC's - with PGM pin-  there should be a note
> added to the programming mode.
>
> For example:
> pragma target LVP  ENABLED   -- low voltage
> programming. Note: PGM pin must be HIGH
> pragma target LVP  DISABLED  -- no low voltage
> programming. Note: PGM pin must be LOW
>
> Agree?
>
> Kind regards,
>
> Rob
>
> ------
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* woensdag 4 januari 2023 07:49
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] USB_help
>
> To avoid entering in lvp mode by mistake at powering up, a pull down was
> used on PGM.
>
> It was a long discussion on Microchip or piclist forum about using pickit2
> in lvp mode (using aux output).
>
> On Wed 4 Jan 2023, 8:15 AM vsurducan 
> On old PiC16F877, entering in lvp mode hapened with a low to high
> transition on LVP pin. I remember pull-up was used, but pull-down seems
> also ok.
>
> On Tue 3 Jan 2023, 6:36 PM Rob CJ 
> Hi RobH,
>
> If the default of the samples (and user programs) would be to enable LVP
> then the warning comment should then be to have a pull-up resistor on the
> PGM pin or am I interpreting the datasheet wrong?
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens Rob
> Hamerling 
> *Verzonden:* dinsdag 3 januari 2023 16:59
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] USB_help
>
>
> Hi RobJ,
>
> On 03/01/2023 15.33, rob...@hotmail.com wrote:
>
>
> I had an e-mail discussion with the other Rob since he also had
> programming issues using LVP. It seems that for some (older?) PICs that
> have LVP only work if you pull a special PGM pin high (so not floating)
> with a resistor.
>
>
> I'm afraid I have to correct this: When LVP is enabled and the PIC has a
> Pin_PGM, this pin requires a *pull_down* resistor to prevent the PIC
> entering LVP mode accidentally.
>
> In order to prevent issues I could check which PICs have this PGM pin and
> for those PICs create only blink samples with LVP disabled. Another option
> is to enable LVP and mention in the blink sample comment to pull the PGM
> pin high for those PICs.
>
>
> The *pull-down* requirement applies to every program, not only samples
> also user programs.
>
> The reason (at least one of 'm) to specify LVP ENABLE in Jallib (blink)
> samples was that it allows the use the Microchip SNAP programmer (or any
> other LVP programmer) besides any HVP programmer like PicKit3. So my vote
> would be for adding a warning comment.
>
> Regards, Rob.
>
>
> --
> *Rob H*amerling, 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/bcc403f2-6580-1d18-0d8a-25109e7a933d%40gmail.com
> <https://groups.google.com/d/msgid/jallib/bcc403f2-6580-1d18-0d8a-25109e7a933d%40gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/GVXP195MB1637E54549EBC46A30C7266AE6F49%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637E54549EBC46A30C7266AE6F49%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+u

Re: [jallib] USB_help

[vsurducan]

To avoid entering in lvp mode by mistake at powering up, a pull down was
used on PGM.

It was a long discussion on Microchip or piclist forum about using pickit2
in lvp mode (using aux output).

On Wed 4 Jan 2023, 8:15 AM vsurducan  On old PiC16F877, entering in lvp mode hapened with a low to high
> transition on LVP pin. I remember pull-up was used, but pull-down seems
> also ok.
>
> On Tue 3 Jan 2023, 6:36 PM Rob CJ 
>> Hi RobH,
>>
>> If the default of the samples (and user programs) would be to enable LVP
>> then the warning comment should then be to have a pull-up resistor on the
>> PGM pin or am I interpreting the datasheet wrong?
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jallib@googlegroups.com  namens Rob
>> Hamerling 
>> *Verzonden:* dinsdag 3 januari 2023 16:59
>> *Aan:* jallib@googlegroups.com 
>> *Onderwerp:* Re: [jallib] USB_help
>>
>>
>> Hi RobJ,
>>
>> On 03/01/2023 15.33, rob...@hotmail.com wrote:
>>
>>
>> I had an e-mail discussion with the other Rob since he also had
>> programming issues using LVP. It seems that for some (older?) PICs that
>> have LVP only work if you pull a special PGM pin high (so not floating)
>> with a resistor.
>>
>>
>> I'm afraid I have to correct this: When LVP is enabled and the PIC has a
>> Pin_PGM, this pin requires a *pull_down* resistor to prevent the PIC
>> entering LVP mode accidentally.
>>
>> In order to prevent issues I could check which PICs have this PGM pin and
>> for those PICs create only blink samples with LVP disabled. Another option
>> is to enable LVP and mention in the blink sample comment to pull the PGM
>> pin high for those PICs.
>>
>>
>> The *pull-down* requirement applies to every program, not only samples
>> also user programs.
>>
>> The reason (at least one of 'm) to specify LVP ENABLE in Jallib (blink)
>> samples was that it allows the use the Microchip SNAP programmer (or any
>> other LVP programmer) besides any HVP programmer like PicKit3. So my vote
>> would be for adding a warning comment.
>>
>> Regards, Rob.
>>
>>
>> --
>> *Rob H*amerling, 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/bcc403f2-6580-1d18-0d8a-25109e7a933d%40gmail.com
>> <https://groups.google.com/d/msgid/jallib/bcc403f2-6580-1d18-0d8a-25109e7a933d%40gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jallib+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jallib/GVXP195MB1637E54549EBC46A30C7266AE6F49%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
>> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637E54549EBC46A30C7266AE6F49%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvc5FJ%2BA9eVpwjG6K13FxzF%3Dsukai%3D%3DvUuPSEHTfH18_Q%40mail.gmail.com.

Re: [jallib] USB_help

[vsurducan]

On old PiC16F877, entering in lvp mode hapened with a low to high
transition on LVP pin. I remember pull-up was used, but pull-down seems
also ok.

On Tue 3 Jan 2023, 6:36 PM Rob CJ  Hi RobH,
>
> If the default of the samples (and user programs) would be to enable LVP
> then the warning comment should then be to have a pull-up resistor on the
> PGM pin or am I interpreting the datasheet wrong?
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens Rob
> Hamerling 
> *Verzonden:* dinsdag 3 januari 2023 16:59
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] USB_help
>
>
> Hi RobJ,
>
> On 03/01/2023 15.33, rob...@hotmail.com wrote:
>
>
> I had an e-mail discussion with the other Rob since he also had
> programming issues using LVP. It seems that for some (older?) PICs that
> have LVP only work if you pull a special PGM pin high (so not floating)
> with a resistor.
>
>
> I'm afraid I have to correct this: When LVP is enabled and the PIC has a
> Pin_PGM, this pin requires a *pull_down* resistor to prevent the PIC
> entering LVP mode accidentally.
>
> In order to prevent issues I could check which PICs have this PGM pin and
> for those PICs create only blink samples with LVP disabled. Another option
> is to enable LVP and mention in the blink sample comment to pull the PGM
> pin high for those PICs.
>
>
> The *pull-down* requirement applies to every program, not only samples
> also user programs.
>
> The reason (at least one of 'm) to specify LVP ENABLE in Jallib (blink)
> samples was that it allows the use the Microchip SNAP programmer (or any
> other LVP programmer) besides any HVP programmer like PicKit3. So my vote
> would be for adding a warning comment.
>
> Regards, Rob.
>
>
> --
> *Rob H*amerling, 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/bcc403f2-6580-1d18-0d8a-25109e7a933d%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/GVXP195MB1637E54549EBC46A30C7266AE6F49%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/CAM%2Bj4qtRBu9MiWwMhJQzN26vj0LGZNqZm2uhKxnwKsetYMmuhw%40mail.gmail.com.

Re: [jallib] EXIT FUNCTION option

[vsurducan]

Sorry Felipe, I was thinking of exiting from a loop, there are some options
there (repeat and while) which look redundant.
Perhaps you can use a procedure instead of a function and just return from
the procedure?

>From Jal manual:
RETURN [ expr ]
When executed, the sub program immediately returns. If the sub program is a
FUNCTION, expr is
required. If it is a PROCEDURE, expr is forbidden.


About other languages, each time I'm looking at Arduino examples I regret
the missing of compatible math representation in Jal. Each time I'm
struggling with Arduino IDE, I heavily appreciate Jal.
I really don't want an IDE where I can't even look at the library's
content. You need another editor to see Arduino library files. :)  However,
all programmable components in this world have Arduino libraries. Weird.


On Mon, Jan 2, 2023 at 1:56 PM flyway38  wrote:

> Hi Vasile,
>
> Am thinking of something that many other programming languages have.
> "Exit Function" to exit immediately a function without running the rest of
> it's code.
> Thank you anyways.
>
> Cheers,
> FS
>
> On Monday, January 2, 2023 at 5:26:55 AM UTC vasile wrote:
>
>> The immediat exit from everything is if-end if. Avoiding loops in fast
>> needed processes is healthy thinking. Each line means processing time.
>> The second is writting jal code for good hex result, not for short
>> structure...
>>
>> On Sun 1 Jan 2023, 8:22 PM flyway38 >
>>> Hello to all,
>>>
>>> *Happy new year to all !!!*
>>>
>>> Is there anyways of use something like this: "Exit Function" to exit
>>> immediately a function ?
>>> Thank you.
>>>
>>> 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+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jallib/67a3c8ae-31fc-4151-a289-d104b8160b31n%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/33b23896-a953-46cc-b3a1-7e322b44adf8n%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%2Bj4qtUZCqAMuQ6L0Jq_MLnTBdoimPxRDRWmt0gUHdyosdyzA%40mail.gmail.com.

Re: [jallib] EXIT FUNCTION option

[vsurducan]

The immediat exit from everything is if-end if. Avoiding loops in fast
needed processes is healthy thinking. Each line means processing time.
The second is writting jal code for good hex result, not for short
structure...

On Sun 1 Jan 2023, 8:22 PM flyway38  Hello to all,
>
> *Happy new year to all !!!*
>
> Is there anyways of use something like this: "Exit Function" to exit
> immediately a function ?
> Thank you.
>
> 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/67a3c8ae-31fc-4151-a289-d104b8160b31n%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%2Bj4qtP9cpUciG1nYiX6cSwDxFutGDfRYR_5EuupdiFV7QRaw%40mail.gmail.com.

Re: [jallib] AS5600

[vsurducan]

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-calculated
That'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...)
>>
>>
>>  Forwarded Message 
>> Subject: Re: [jallib] AS5600
>> Date: Mon, 26 Dec 2022 13:34:09 -0500
>> From: Tom Crawford 
>> Reply-To: tomc...@gmail.com
>> To: jal...@googlegroups.com
>>
>> 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 couple of my
>> pictures, when I modified it for smaller size...
>> I have attached one of these correctly, and added another pic:
>> 1 - the LFL just prior to renovations, showing general appearance,
>> weather station sensors, solar panels...  It is located near the road, with
>> no 

Re: [jallib] AS5600

[vsurducan]

Hi guys, would be interesting to see the presentation. This chip is really
able to sense reliably below 0.3 degrees or so?
Thx,

On Mon 26 Dec 2022, 11:56 AM hans  Hello Tom,
> Delicious, a JAL project !! That is the great strength of Arduino,
> practical examples.
> It looks like my problem. Now my wind direction works with a Greats disc
> and light cells, but they are affected by the weather.
> .
>   That's why my question. Do you use the analog output or the spi? Do you
> work wirelessly? And do you also have information for me about the program?
> Well, the risk if you give me an answer that I have many more questions
>   I ordered a set with the magnet
>   It's still fun.
> regards
> Hans
>
> Op maandag 26 december 2022 om 09:15:30 UTC+1 schreef Tom:
>
>> (Resend to provide smaller attachment)
>>
>>
>>  Forwarded Message 
>> Subject: Re: [jallib] AS5600
>> Date: Sun, 25 Dec 2022 14:15:33 -0500
>> From: Tom Crawford 
>> Reply-To: tomc...@gmail.com
>> To: jal...@googlegroups.com
>>
>> 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+un...@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
>> 
>> <#m_-6885758527998679651_m_-5172031385688370383_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
> --
> 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/0a123447-d3f5-44b8-8b34-5cce6d39d77dn%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%2Bj4qvHhU1tshu-jMM2YhE1MUJKkzE6jGRS_kvhnnQWh96bBw%40mail.gmail.com.

Re: [jallib] AS5600

[vsurducan]

Seems complicated: https://ams.com/en/as5600
I don't know why everything already has a library in Arduino...
https://www.youtube.com/watch?app=desktop=LsLBLrk2P_E
One problem for all Hall sensors is the remanence magnetisation, hopefully
this one will not have one without an iron core around...

On Sun, Dec 25, 2022 at 11: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
> 
> .
>

-- 
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%2Bj4qsDdYQ9Fqd%3D88p7%3Ddu91ogkf7oDJpTrQMcPOvvi-8RR6A%40mail.gmail.com.

Re: [jallib] USB_help

[vsurducan]

;> protected
>>>>>>> pragma target EBTR1 DISABLED-- table read block 1 not
>>>>>>> protected
>>>>>>> pragma target EBTR2 DISABLED-- table read block 2 not
>>>>>>> protected
>>>>>>> pragma target EBTR3 DISABLED-- table read block 3 not
>>>>>>> protected
>>>>>>> pragma target EBTRB DISABLED-- boot block not protected
>>>>>>>
>>>>>>> WDTCON_SWDTEN = OFF -- disable watchdog
>>>>>>>
>>>>>>> const USB_INTERRUPT_DRIVEN = TRUE
>>>>>>> include usb_serial
>>>>>>> include print
>>>>>>> include delay
>>>>>>>
>>>>>>> -- constants
>>>>>>> ; const  byte str_welcome[] = "JALLIB USB Serial Demo app\n"
>>>>>>>
>>>>>>> -- setup the USB serial library
>>>>>>> usb_serial_init()
>>>>>>>
>>>>>>> -- variables
>>>>>>> var bit has_shown_welcome_msg = true
>>>>>>> var byte ch
>>>>>>> var dword counter_dw  = 0x_
>>>>>>> var byte counter_b = 0
>>>>>>> var word timer = 0
>>>>>>>
>>>>>>> delay_1s (5)
>>>>>>>
>>>>>>> -- main loop
>>>>>>> forever loop
>>>>>>>
>>>>>>>if !defined(USB_INTERRUPT_DRIVEN) then
>>>>>>>   -- When the interrupt mode is not used we need to poll the usb
>>>>>>> ISR function
>>>>>>>   -- on a regular base, in order to serve the USB requests
>>>>>>> otherwise
>>>>>>>   -- this call can be removed.
>>>>>>>   usb_serial_flush()
>>>>>>>end if
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ;   timer = timer + 1
>>>>>>> ;if timer == 500 then
>>>>>>> ;   timer = 0
>>>>>>>
>>>>>>> ;   print_byte_dec (usb_serial_data, counter_b)
>>>>>>> ;   _usec_delay( 1 )
>>>>>>> ;   usb_serial_data = " "
>>>>>>>print_dword_dec( usb_serial_data, counter_dw )
>>>>>>> ;   _usec_delay( 1 )
>>>>>>>print_crlf(usb_serial_data)
>>>>>>> ;   counter_dw = counter_dw + 1
>>>>>>> ;   counter_b = counter_b + 1
>>>>>>> ;end if
>>>>>>> ;   _usec_delay( 1 )
>>>>>>>
>>>>>>> end loop
>>>>>>>
>>>>>>> On Fri, Dec 16, 2022 at 3:20 PM hans  wrote:
>>>>>>>
>>>>>>>> Hey ,
>>>>>>>> I have now received the 18F4550 and the 16F1455 and have tried both
>>>>>>>> with the usb_serial samples. programming with PicKit_3, but in all 
>>>>>>>> cases I
>>>>>>>> get a warning on my PC (both on win10 and win7) that the USB is not
>>>>>>>> recognized. The Vusb with capacitor reads 3.3 volts and I have 
>>>>>>>> programmed
>>>>>>>> both with and without LVP. identical to my previous attempts.
>>>>>>>> Apparently USB is not allowed to me
>>>>>>>> Hans
>>>>>>>>
>>>>>>>> Op woensdag 14 december 2022 om 14:19:16 UTC+1 schreef
>>>>>>>> zet@gmail.com:
>>>>>>>>
>>>>>>>>> Hi Matt
>>>>>>>>>
>>>>>>>>> I see your question 10-12 now: Wednesday 14-12
>>>>>>>>>
>>>>>>>>> I am not at home for 2 days.
>>>>>>>>>
>>>>>>>>> I can test. You hear as soon as possible.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>

Re: [jallib] USB_help

[vsurducan]

t;
>>>>>>
>>>>>>
>>>>>> Is anyone else able to test the 18f4455 blink usb sample?
>>>>>>
>>>>>> On Saturday, December 10, 2022 at 1:18:39 PM UTC-5 hans wrote:
>>>>>>
>>>>>> Hello, I tested the sample 18f4455 Blink_hs_usb.jal. This one didn't
>>>>>> work. Then I restarted Bert van Dam's old business and tried the same
>>>>>> program on it. that works as it should.
>>>>>> I have also tested ports D+ and D- (24 and 23) as inputs and those
>>>>>> ports work as well. I now doubt whether the PIC is broken or something 
>>>>>> else
>>>>>> is going on.
>>>>>> regards
>>>>>> Hans
>>>>>>
>>>>>> Op zaterdag 10 december 2022 om 10:30:14 UTC+1 schreef hans:
>>>>>>
>>>>>> Hello champs,
>>>>>> I have reassembled everything and I can only conclude that the PIC
>>>>>> itself (has done some things before) is defective. Unfortunately, I no
>>>>>> longer have a PIC with USB, so I put it back in the fridge. I will have 
>>>>>> to
>>>>>> look for another one but the market is scarce.
>>>>>> Thanks again for your great responses.
>>>>>> regards
>>>>>> Hans
>>>>>>
>>>>>> Op zaterdag 10 december 2022 om 06:18:17 UTC+1 schreef vasile:
>>>>>>
>>>>>> Yep. Matt has right.
>>>>>>
>>>>>> 1.The clock speed is esential.
>>>>>>
>>>>>> 2. You will notice quite a long delay (5s or so) between plugging the
>>>>>> pic usb and the moment when OS recognize it on pc. This depends by your
>>>>>> computer speed and pic firmware contents. If pic clk is wrong, you will 
>>>>>> not
>>>>>> see any usb device. After it appears, check on printer/pheripheral for 
>>>>>> your
>>>>>> device but watch for any warnings there
>>>>>>
>>>>>> On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel >>>>> wrote:
>>>>>>
>>>>>> Also use the code in 18f455_blink_hs_usb.jal
>>>>>>
>>>>>>
>>>>>>
>>>>>> You are missing this one:
>>>>>>
>>>>>> OSCCON_SCS = 0  -- select primary oscillator
>>>>>>
>>>>>> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel
>>>>>> wrote:
>>>>>>
>>>>>> Hi Hans,
>>>>>>
>>>>>>
>>>>>>
>>>>>> There must be an issue with your circuit. Do you have the correct
>>>>>> clock speed? Make sure a blink sample and normal serial port is working.
>>>>>> Try another PC. Windows should pick it up.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Matt.
>>>>>>
>>>>>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>>>>>
>>>>>> Hello,
>>>>>> Thank you. I did what you recommended. Last Bee and tip from Vasile.
>>>>>> Same message from windows, not recognized and causing a malfunction.
>>>>>> Pff/
>>>>>> regards
>>>>>> Hans
>>>>>>
>>>>>> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef
>>>>>> rob...@hotmail.com:
>>>>>>
>>>>>> Hi Hans,
>>>>>>
>>>>>>
>>>>>>
>>>>>> As Vasile already mentioned Windows 10 will detect your device as a
>>>>>> serial (COM) port without the need of installing a separate driver.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Make sure you have the USB connections right. The signals are not
>>>>>> crossed like for USART, so D+ to D+ and D- to D-.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I attached a schematic diagram based on the PIC16F1455 for your
>>>>>> information and the USB connectors and what the signals look like.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Good luck!
>>>>>>

Re: [jallib] USB_help

[vsurducan]

ears, check on printer/pheripheral for your
> device but watch for any warnings there
>
> On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel 
> Also use the code in 18f455_blink_hs_usb.jal
>
>
>
> You are missing this one:
>
> OSCCON_SCS = 0      -- select primary oscillator
>
> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel wrote:
>
> Hi Hans,
>
>
>
> There must be an issue with your circuit. Do you have the correct clock
> speed? Make sure a blink sample and normal serial port is working. Try
> another PC. Windows should pick it up.
>
>
>
> Matt.
>
> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>
> Hello,
> Thank you. I did what you recommended. Last Bee and tip from Vasile. Same
> message from windows, not recognized and causing a malfunction. Pff/
> regards
> Hans
>
> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef rob...@hotmail.com:
>
> Hi Hans,
>
>
>
> As Vasile already mentioned Windows 10 will detect your device as a serial
> (COM) port without the need of installing a separate driver.
>
>
>
> Make sure you have the USB connections right. The signals are not crossed
> like for USART, so D+ to D+ and D- to D-.
>
>
>
> I attached a schematic diagram based on the PIC16F1455 for your
> information and the USB connectors and what the signals look like.
>
>
>
> Good luck!
>
>
>
> Kind regards,
>
>
> Rob
>
>
> --
>
> *Van:* jal...@googlegroups.com  namens vsurducan
> 
> *Verzonden:* vrijdag 9 december 2022 18:12
> *Aan:* jal...@googlegroups.com 
> *Onderwerp:* Re: [jallib] USB_help
>
>
>
> Hi Hans,
>
> for win10 you do not need any special driver, just a good terminal like
> Teraterm.
>
> Download the last jal package, Rob did some modifications on USB driver,
>
> my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
>
> The maximum speed is about 100kbps.
>
>
>
>
>
>
>
> On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:
>
> Hello,
> I am trying to learn more about USB and have tried a sample program( ex
> 18F2450)  (see attachment) I keep getting the remark that windows 10 does
> not recognize the connection and cannot install the driver. What am I doing
> wrong??
> 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+un...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+un...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+un...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/1c3098ea-5a51-4e41-a148-9782036d4b34n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/1c3098ea-5a51-4e41-a148-9782036d4b34n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+un...@googlegroups.com.
>
> To

Re: [jallib] USB_help

[vsurducan]

estion 10-12 now: Wednesday 14-12
>>
>> I am not at home for 2 days.
>>
>> I can test. You hear as soon as possible.
>>
>>
>>
>> Regards
>>
>> Peter
>>
>>
>>
>> *Van:* jal...@googlegroups.com [mailto:jal...@googlegroups.com] *Namens 
>> *Matthew
>> Schinkel
>> *Verzonden:* zondag 11 december 2022 04:18
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] USB_help
>>
>>
>>
>> Hi Hans, what chip is it working on?
>>
>>
>>
>> Is anyone else able to test the 18f4455 blink usb sample?
>>
>> On Saturday, December 10, 2022 at 1:18:39 PM UTC-5 hans wrote:
>>
>> Hello, I tested the sample 18f4455 Blink_hs_usb.jal. This one didn't
>> work. Then I restarted Bert van Dam's old business and tried the same
>> program on it. that works as it should.
>> I have also tested ports D+ and D- (24 and 23) as inputs and those ports
>> work as well. I now doubt whether the PIC is broken or something else is
>> going on.
>> regards
>> Hans
>>
>> Op zaterdag 10 december 2022 om 10:30:14 UTC+1 schreef hans:
>>
>> Hello champs,
>> I have reassembled everything and I can only conclude that the PIC itself
>> (has done some things before) is defective. Unfortunately, I no longer have
>> a PIC with USB, so I put it back in the fridge. I will have to look for
>> another one but the market is scarce.
>> Thanks again for your great responses.
>> regards
>> Hans
>>
>> Op zaterdag 10 december 2022 om 06:18:17 UTC+1 schreef vasile:
>>
>> Yep. Matt has right.
>>
>> 1.The clock speed is esential.
>>
>> 2. You will notice quite a long delay (5s or so) between plugging the pic
>> usb and the moment when OS recognize it on pc. This depends by your
>> computer speed and pic firmware contents. If pic clk is wrong, you will not
>> see any usb device. After it appears, check on printer/pheripheral for your
>> device but watch for any warnings there
>>
>> On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel > wrote:
>>
>> Also use the code in 18f455_blink_hs_usb.jal
>>
>>
>>
>> You are missing this one:
>>
>> OSCCON_SCS = 0  -- select primary oscillator
>>
>> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel wrote:
>>
>> Hi Hans,
>>
>>
>>
>> There must be an issue with your circuit. Do you have the correct clock
>> speed? Make sure a blink sample and normal serial port is working. Try
>> another PC. Windows should pick it up.
>>
>>
>>
>> Matt.
>>
>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>
>> Hello,
>> Thank you. I did what you recommended. Last Bee and tip from Vasile. Same
>> message from windows, not recognized and causing a malfunction. Pff/
>> regards
>> Hans
>>
>> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef rob...@hotmail.com:
>>
>> Hi Hans,
>>
>>
>>
>> As Vasile already mentioned Windows 10 will detect your device as a
>> serial (COM) port without the need of installing a separate driver.
>>
>>
>>
>> Make sure you have the USB connections right. The signals are not crossed
>> like for USART, so D+ to D+ and D- to D-.
>>
>>
>>
>> I attached a schematic diagram based on the PIC16F1455 for your
>> information and the USB connectors and what the signals look like.
>>
>>
>>
>> Good luck!
>>
>>
>>
>> Kind regards,
>>
>>
>> Rob
>>
>>
>> --
>>
>> *Van:* jal...@googlegroups.com  namens
>> vsurducan 
>> *Verzonden:* vrijdag 9 december 2022 18:12
>> *Aan:* jal...@googlegroups.com 
>> *Onderwerp:* Re: [jallib] USB_help
>>
>>
>>
>> Hi Hans,
>>
>> for win10 you do not need any special driver, just a good terminal like
>> Teraterm.
>>
>> Download the last jal package, Rob did some modifications on USB driver,
>>
>> my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
>>
>> The maximum speed is about 100kbps.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:
>>
>> Hello,
>> I am trying to learn more about USB and have tried a sample program( ex
>> 18F2450)  (see attachment) I keep getting the remark that windows 10 does
>> not recognize the connection and cannot install the driver. What am I doing
>> wrong??
&

Re: [jallib] USB_help

[vsurducan]

serial_data = " "
>>print_dword_dec( usb_serial_data, counter_dw )
>> ;   _usec_delay( 1 )
>>print_crlf(usb_serial_data)
>> ;   counter_dw = counter_dw + 1
>> ;   counter_b = counter_b + 1
>> ;end if
>> ;   _usec_delay( 1 )
>>
>> end loop
>>
>> On Fri, Dec 16, 2022 at 3:20 PM hans  wrote:
>>
>>> Hey ,
>>> I have now received the 18F4550 and the 16F1455 and have tried both with
>>> the usb_serial samples. programming with PicKit_3, but in all cases I get a
>>> warning on my PC (both on win10 and win7) that the USB is not recognized.
>>> The Vusb with capacitor reads 3.3 volts and I have programmed both with and
>>> without LVP. identical to my previous attempts.
>>> Apparently USB is not allowed to me
>>> Hans
>>>
>>> Op woensdag 14 december 2022 om 14:19:16 UTC+1 schreef zet@gmail.com
>>> :
>>>
>>>> Hi Matt
>>>>
>>>> I see your question 10-12 now: Wednesday 14-12
>>>>
>>>> I am not at home for 2 days.
>>>>
>>>> I can test. You hear as soon as possible.
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> *Van:* jal...@googlegroups.com [mailto:jal...@googlegroups.com] *Namens
>>>> *Matthew Schinkel
>>>> *Verzonden:* zondag 11 december 2022 04:18
>>>> *Aan:* jallib 
>>>> *Onderwerp:* Re: [jallib] USB_help
>>>>
>>>>
>>>>
>>>> Hi Hans, what chip is it working on?
>>>>
>>>>
>>>>
>>>> Is anyone else able to test the 18f4455 blink usb sample?
>>>>
>>>> On Saturday, December 10, 2022 at 1:18:39 PM UTC-5 hans wrote:
>>>>
>>>> Hello, I tested the sample 18f4455 Blink_hs_usb.jal. This one didn't
>>>> work. Then I restarted Bert van Dam's old business and tried the same
>>>> program on it. that works as it should.
>>>> I have also tested ports D+ and D- (24 and 23) as inputs and those
>>>> ports work as well. I now doubt whether the PIC is broken or something else
>>>> is going on.
>>>> regards
>>>> Hans
>>>>
>>>> Op zaterdag 10 december 2022 om 10:30:14 UTC+1 schreef hans:
>>>>
>>>> Hello champs,
>>>> I have reassembled everything and I can only conclude that the PIC
>>>> itself (has done some things before) is defective. Unfortunately, I no
>>>> longer have a PIC with USB, so I put it back in the fridge. I will have to
>>>> look for another one but the market is scarce.
>>>> Thanks again for your great responses.
>>>> regards
>>>> Hans
>>>>
>>>> Op zaterdag 10 december 2022 om 06:18:17 UTC+1 schreef vasile:
>>>>
>>>> Yep. Matt has right.
>>>>
>>>> 1.The clock speed is esential.
>>>>
>>>> 2. You will notice quite a long delay (5s or so) between plugging the
>>>> pic usb and the moment when OS recognize it on pc. This depends by your
>>>> computer speed and pic firmware contents. If pic clk is wrong, you will not
>>>> see any usb device. After it appears, check on printer/pheripheral for your
>>>> device but watch for any warnings there
>>>>
>>>> On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel >>> wrote:
>>>>
>>>> Also use the code in 18f455_blink_hs_usb.jal
>>>>
>>>>
>>>>
>>>> You are missing this one:
>>>>
>>>> OSCCON_SCS = 0  -- select primary oscillator
>>>>
>>>> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel wrote:
>>>>
>>>> Hi Hans,
>>>>
>>>>
>>>>
>>>> There must be an issue with your circuit. Do you have the correct clock
>>>> speed? Make sure a blink sample and normal serial port is working. Try
>>>> another PC. Windows should pick it up.
>>>>
>>>>
>>>>
>>>> Matt.
>>>>
>>>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>>>
>>>> Hello,
>>>> Thank you. I did what you recommended. Last Bee and tip from Vasile.
>>>> Same message from windows, not recognized and causing a malfun

Re: [jallib] USB_help

[vsurducan]

ards
>>
>> Peter
>>
>>
>>
>> *Van:* jal...@googlegroups.com [mailto:jal...@googlegroups.com] *Namens 
>> *Matthew
>> Schinkel
>> *Verzonden:* zondag 11 december 2022 04:18
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] USB_help
>>
>>
>>
>> Hi Hans, what chip is it working on?
>>
>>
>>
>> Is anyone else able to test the 18f4455 blink usb sample?
>>
>> On Saturday, December 10, 2022 at 1:18:39 PM UTC-5 hans wrote:
>>
>> Hello, I tested the sample 18f4455 Blink_hs_usb.jal. This one didn't
>> work. Then I restarted Bert van Dam's old business and tried the same
>> program on it. that works as it should.
>> I have also tested ports D+ and D- (24 and 23) as inputs and those ports
>> work as well. I now doubt whether the PIC is broken or something else is
>> going on.
>> regards
>> Hans
>>
>> Op zaterdag 10 december 2022 om 10:30:14 UTC+1 schreef hans:
>>
>> Hello champs,
>> I have reassembled everything and I can only conclude that the PIC itself
>> (has done some things before) is defective. Unfortunately, I no longer have
>> a PIC with USB, so I put it back in the fridge. I will have to look for
>> another one but the market is scarce.
>> Thanks again for your great responses.
>> regards
>> Hans
>>
>> Op zaterdag 10 december 2022 om 06:18:17 UTC+1 schreef vasile:
>>
>> Yep. Matt has right.
>>
>> 1.The clock speed is esential.
>>
>> 2. You will notice quite a long delay (5s or so) between plugging the pic
>> usb and the moment when OS recognize it on pc. This depends by your
>> computer speed and pic firmware contents. If pic clk is wrong, you will not
>> see any usb device. After it appears, check on printer/pheripheral for your
>> device but watch for any warnings there
>>
>> On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel > wrote:
>>
>> Also use the code in 18f455_blink_hs_usb.jal
>>
>>
>>
>> You are missing this one:
>>
>> OSCCON_SCS = 0  -- select primary oscillator
>>
>> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel wrote:
>>
>> Hi Hans,
>>
>>
>>
>> There must be an issue with your circuit. Do you have the correct clock
>> speed? Make sure a blink sample and normal serial port is working. Try
>> another PC. Windows should pick it up.
>>
>>
>>
>> Matt.
>>
>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>
>> Hello,
>> Thank you. I did what you recommended. Last Bee and tip from Vasile. Same
>> message from windows, not recognized and causing a malfunction. Pff/
>> regards
>> Hans
>>
>> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef rob...@hotmail.com:
>>
>> Hi Hans,
>>
>>
>>
>> As Vasile already mentioned Windows 10 will detect your device as a
>> serial (COM) port without the need of installing a separate driver.
>>
>>
>>
>> Make sure you have the USB connections right. The signals are not crossed
>> like for USART, so D+ to D+ and D- to D-.
>>
>>
>>
>> I attached a schematic diagram based on the PIC16F1455 for your
>> information and the USB connectors and what the signals look like.
>>
>>
>>
>> Good luck!
>>
>>
>>
>> Kind regards,
>>
>>
>> Rob
>>
>>
>> --
>>
>> *Van:* jal...@googlegroups.com  namens
>> vsurducan 
>> *Verzonden:* vrijdag 9 december 2022 18:12
>> *Aan:* jal...@googlegroups.com 
>> *Onderwerp:* Re: [jallib] USB_help
>>
>>
>>
>> Hi Hans,
>>
>> for win10 you do not need any special driver, just a good terminal like
>> Teraterm.
>>
>> Download the last jal package, Rob did some modifications on USB driver,
>>
>> my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
>>
>> The maximum speed is about 100kbps.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:
>>
>> Hello,
>> I am trying to learn more about USB and have tried a sample program( ex
>> 18F2450)  (see attachment) I keep getting the remark that windows 10 does
>> not recognize the connection and cannot install the driver. What am I doing
>> wrong??
>> regards
>> Hans
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jallib" group.
>> To unsubsc

Re: [jallib] Re: Variable Table Append

[vsurducan]

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.jal
2. in the serial_hv_int_cts_modified.jal modify the
_serial_receive_interrupt_handler() with the one below

3. in the main program include the modified library and:

var bit datapresent = false
var 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 if
end 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
   _serial_offsetrcvhead = 1
chars_ok = 1
else
   if (chars_ok > 0) then
  _serial_offsetrcvhead = _serial_offsetrcvhead + 1
  chars_ok = chars_ok + 1
  if (chars_ok == chars_sent) then
  datapresent = true
  chars_ok = 0
  _serial_offsetrcvhead = 0
  end if
end if
 end if
  end if -- datapresent
  end if
   end if

end procedure

On Mon, Dec 12, 2022 at 9:29 PM flyway38  wrote:

> Hello Vasile and Rob,
>
> Thank you for your feedback.
>
> @Vasile;
> 1 - No. It will depend on the number of SMS received by the modem. But
> only need the 2nd line of each SMS. This answers your #2.
> 2 - Yes. But this is still a test information received as an SMS. Later
> on, it will be different and much probably bigger in nr of chars...
>
> @Rob
> Am not sure on how to use that and copy the data from the buffer to a
> large array library.
> Maybe some sample code would help.
> Heres my receiving code, anyways:
>
>for 50 using Index loop
>   fRtn = serial_hw_read(char)
>   if fRtn then
>  Received[Index] = char
>   end if
>end loop
>--
>fRtn=FALSE
>--
>for 74 using Index loop
>   if (Received[Index]=="+"
>  & Received[Index+1]=="C"
>  & Received[Index+2]=="M"
>  & Received[Index+3]=="G"
>  & Received[Index+4]=="L"
>  & Received[Index+5]==":") then
>  fRtn=TRUE
>   end if
>end loop
>
> Thank you guys for your help.
> Cheers,
>
> FS
> On Monday, December 12, 2022 at 6:48:31 PM UTC rob...@hotmail.com wrote:
>
>> Hi Filipe,
>>
>> You should use the large array library and copy the data from the buffer
>> (which can then be smaller) to the large array.
>>
>> Met vriendelijke groet,
>> Rob Jansen
>> --
>> *From:* jal...@googlegroups.com  on behalf of
>> vsurducan 
>> *Sent:* Monday, December 12, 2022 7:37:34 PM
>> *To:* jal...@googlegroups.com 
>>
>> *Subject:* Re: [jallib] Re: Variable Table Append
>> 1.The length of your message is always the same?
>> 2. From the whole message, receiving the part GA6...2.757V would be
>> sufficient?
>>
>>
>>
>> On Mon 12 Dec 2022, 7:59 PM flyway38 >
>> Hey all,
>>
>> Am back on this subje

Re: [jallib] Re: Variable Table Append

[vsurducan]

t be 80 bytes.
>> You can use the large array library if you need a larger buffer.
>>
>> Met vriendelijke groet,
>> Rob Jansen
>> --
>> *From:* jal...@googlegroups.com  on behalf of
>> flyway38 
>> *Sent:* Saturday, December 3, 2022 7:58:35 PM
>> *To:* jallib 
>> *Subject:* Re: [jallib] Re: Variable Table Append
>>
>> Hi Vasile,
>>
>> I want to read the answers from modem just like Hyperterminal or Termite
>> does.
>> As example:
>> This the AT command to question modem for new SMS received:
>> AT+CMGL="ALL"
>> In my case I know theres a SMS in memory, so modem answers to that
>> command:
>> +CMGL: 1,"REC READ","+351000MyNrHere000",,"2022/12/03,18:10:22+00"
>> Test
>>
>> OK
>> Can see all this in Hyperterminal happening, but PIC doesn't get that
>> answer from modem...
>> I need to read this answer from modem, and then extract the message
>> "Test" part of modem answer
>> It would be enough to read the "+GMGL: 1" from the modem's answer but
>> no luck so far.
>> Thanks anyway for the input.
>>
>> Regards,
>> Filipe Santos
>>
>> On Saturday, December 3, 2022 at 6:41:30 PM UTC vasile wrote:
>>
>> I'm not sure if this is your case, but if you need to identify the AT
>> during a string reception, but prior to store the string in any buffer, I
>> think the library will not work as is...
>>
>> On Sat 3 Dec 2022, 7:23 PM flyway38 >
>> The oddest thing here, is it seems only my PIC doesn't pick up the
>> answers from the modem, except the "OK" but even these fail sometimes to
>> get picked up by the PIC.
>> I have a derived connection from that serial port using an FTDI cable
>> connected to my computer, and can check what is going on using the
>> Hyperterminal App or even the Termite App and these apps can see the
>> answers from the modem crazy stuff going on here...
>>
>> On Saturday, December 3, 2022 at 4:48:16 PM UTC flyway38 wrote:
>>
>> Hi Rob,
>>
>> Thanks for that help.
>> But, right now am concerned about the other acknowledge messages... "OK"
>> is now working good enough here.
>> And it seems serial_hw_int_cts LIB is not making any difference.
>> Maybe am not taking full advantages from it.
>> Cheers,
>>
>> FS
>> On Saturday, December 3, 2022 at 2:22:04 PM UTC rob...@hotmail.com wrote:
>>
>> Hi Filipe,
>>
>> In the bluetooth_hc_05.jal library I made a function that reads a string
>> including OK but returns only the string (without the OK). The code is as
>> follows:
>>
>> -- Wait for data from the module and copy all data to the bluetooth
>> receive
>> -- buffer until 'OK' is found. If 'OK' is found the function returns TRUE.
>> -- The number of bytes in the receive buffer is stored in the global
>> variable
>> -- bluetooth_hc05_bytes_received and the read pointer is reset.
>> -- Note that 'OK' is not stored in bluetooth_hc05_bytes_received but the
>> -- carriage return and line feed are.
>> function _bluetooth_hc05_wait_and_get_data_ok() return bit is
>>
>>var dword timeout = 0
>>var byte index = 0
>>var byte character
>>var bit found_o  = FALSE
>>var bit found_ok = FALSE
>>
>>bluetooth_hc05_bytes_received = 0
>>_bluetooth_hc05_read_pointer = 0
>>while (index < BLUETOOTH_HC05_RECEIVE_BUFFER_SIZE) & !found_ok &
>>  (timeout < _bluetooth_hc05_wait_time) loop
>>
>>   if _bluetooth_hc05_serial_read(character) then
>>  bluetooth_hc05_receive_buffer[index] = character
>>  index = index + 1
>>  timeout = 0
>>  if (character == "O") then
>> found_o = TRUE
>>  elsif (character == "K") & found_o then
>> found_ok = TRUE
>> -- Bytes received is everything except for 'OK'.
>> bluetooth_hc05_bytes_received = index - 2
>> else
>> -- It was not 'OK', reset.
>> found_o  = FALSE
>> found_ok = FALSE
>>  end if
>>   end if
>>
>>   timeout = timeout + 1
>>   _usec_delay(100)
>>end loop
>>
>>return found_ok
>>
>> end function
>>
>> Kind regards,
>>
>> Rob
>> --
>> *Van:* jal...@googlegroups.com  namens flyway38
>> 
>>

Re: [jallib] USB_help

[vsurducan]

gt;>>>
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> There must be an issue with your circuit. Do you have the correct
>>>>>>> clock speed? Make sure a blink sample and normal serial port is working.
>>>>>>> Try another PC. Windows should pick it up.
>>>>>>>
>>>>>>> Matt.
>>>>>>>
>>>>>>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> Thank you. I did what you recommended. Last Bee and tip from
>>>>>>>> Vasile. Same message from windows, not recognized and causing a
>>>>>>>> malfunction. Pff/
>>>>>>>> regards
>>>>>>>> Hans
>>>>>>>>
>>>>>>>> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef
>>>>>>>> rob...@hotmail.com:
>>>>>>>>
>>>>>>>>> Hi Hans,
>>>>>>>>>
>>>>>>>>> As Vasile already mentioned Windows 10 will detect your device as
>>>>>>>>> a serial (COM) port without the need of installing a separate driver.
>>>>>>>>>
>>>>>>>>> Make sure you have the USB connections right. The signals are not
>>>>>>>>> crossed like for USART, so D+ to D+ and D- to D-.
>>>>>>>>>
>>>>>>>>> I attached a schematic diagram based on the PIC16F1455 for your
>>>>>>>>> information and the USB connectors and what the signals look like.
>>>>>>>>>
>>>>>>>>> Good luck!
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>>
>>>>>>>>> Rob
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Van:* jal...@googlegroups.com  namens
>>>>>>>>> vsurducan 
>>>>>>>>> *Verzonden:* vrijdag 9 december 2022 18:12
>>>>>>>>> *Aan:* jal...@googlegroups.com 
>>>>>>>>> *Onderwerp:* Re: [jallib] USB_help
>>>>>>>>>
>>>>>>>>> Hi Hans,
>>>>>>>>> for win10 you do not need any special driver, just a good terminal
>>>>>>>>> like Teraterm.
>>>>>>>>> Download the last jal package, Rob did some modifications on USB
>>>>>>>>> driver,
>>>>>>>>> my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
>>>>>>>>> The maximum speed is about 100kbps.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> I am trying to learn more about USB and have tried a sample
>>>>>>>>> program( ex 18F2450)  (see attachment) I keep getting the remark that
>>>>>>>>> windows 10 does not recognize the connection and cannot install the 
>>>>>>>>> driver.
>>>>>>>>> What am I doing wrong??
>>>>>>>>> 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+un...@googlegroups.com.
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com
>>>>>>>>> <https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "jallib" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to jallib+un...@googlegroups.com.
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com
>>>>>>>>> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com?utm_medium=email_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "jallib" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to jallib+un...@googlegroups.com.
>>>>>>
>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/d6f2eb77-c5dc-4518-8560-fd45bf6a854fn%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/d6f2eb77-c5dc-4518-8560-fd45bf6a854fn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qv0Yj_XgzjmqdS1XH63O4AV8%3D3JegxmaGqx626KTEaa8A%40mail.gmail.com.

Re: [jallib] USB_help

[vsurducan]

Yep. Matt has right.
1.The clock speed is esential.
2. You will notice quite a long delay (5s or so) between plugging the pic
usb and the moment when OS recognize it on pc. This depends by your
computer speed and pic firmware contents. If pic clk is wrong, you will not
see any usb device. After it appears, check on printer/pheripheral for your
device but watch for any warnings there

On Sat 10 Dec 2022, 4:59 AM Matthew Schinkel  Also use the code in 18f455_blink_hs_usb.jal
>
> You are missing this one:
> OSCCON_SCS = 0  -- select primary oscillator
>
> On Friday, December 9, 2022 at 9:54:43 PM UTC-5 Matthew Schinkel wrote:
>
>> Hi Hans,
>>
>> There must be an issue with your circuit. Do you have the correct clock
>> speed? Make sure a blink sample and normal serial port is working. Try
>> another PC. Windows should pick it up.
>>
>> Matt.
>>
>> On Friday, December 9, 2022 at 3:12:12 PM UTC-5 hans wrote:
>>
>>> Hello,
>>> Thank you. I did what you recommended. Last Bee and tip from Vasile.
>>> Same message from windows, not recognized and causing a malfunction.
>>> Pff/
>>> regards
>>> Hans
>>>
>>> Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef rob...@hotmail.com:
>>>
>>>> Hi Hans,
>>>>
>>>> As Vasile already mentioned Windows 10 will detect your device as a
>>>> serial (COM) port without the need of installing a separate driver.
>>>>
>>>> Make sure you have the USB connections right. The signals are not
>>>> crossed like for USART, so D+ to D+ and D- to D-.
>>>>
>>>> I attached a schematic diagram based on the PIC16F1455 for your
>>>> information and the USB connectors and what the signals look like.
>>>>
>>>> Good luck!
>>>>
>>>> Kind regards,
>>>>
>>>> Rob
>>>>
>>>> --
>>>> *Van:* jal...@googlegroups.com  namens
>>>> vsurducan 
>>>> *Verzonden:* vrijdag 9 december 2022 18:12
>>>> *Aan:* jal...@googlegroups.com 
>>>> *Onderwerp:* Re: [jallib] USB_help
>>>>
>>>> Hi Hans,
>>>> for win10 you do not need any special driver, just a good terminal like
>>>> Teraterm.
>>>> Download the last jal package, Rob did some modifications on USB
>>>> driver,
>>>> my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
>>>> The maximum speed is about 100kbps.
>>>>
>>>>
>>>>
>>>> On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:
>>>>
>>>> Hello,
>>>> I am trying to learn more about USB and have tried a sample program( ex
>>>> 18F2450)  (see attachment) I keep getting the remark that windows 10 does
>>>> not recognize the connection and cannot install the driver. What am I doing
>>>> wrong??
>>>> 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+un...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jallib/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "jallib" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jallib+un...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qv594CbfE6fkJWWskZDebruDXUkhoRtsZFQy_%3D0LzEXGg%40mail.gmail.com.

Re: [jallib] USB_help

[vsurducan]

Hi Hans,
for win10 you do not need any special driver, just a good terminal like
Teraterm.
Download the last jal package, Rob did some modifications on USB driver,
my suggestion is to use const USB_INTERRUPT_DRIVEN = TRUE
The maximum speed is about 100kbps.



On Fri, Dec 9, 2022 at 5:42 PM hans  wrote:

> Hello,
> I am trying to learn more about USB and have tried a sample program( ex
> 18F2450)  (see attachment) I keep getting the remark that windows 10 does
> not recognize the connection and cannot install the driver. What am I doing
> wrong??
> 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/c92e6cb2-a584-4b1b-a77f-d8bf943560b2n%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%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com.

Re: [jallib] Re: Variable Table Append

[vsurducan]

gt;   timeout = timeout + 1
>   _usec_delay(100)
>end loop
>
>return found_ok
>
> end function
>
> Kind regards,
>
> Rob
> --
> *Van:* jal...@googlegroups.com  namens flyway38 <
> fsfo...@gmail.com>
> *Verzonden:* zaterdag 3 december 2022 15:11
>
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] Re: Variable Table Append
> Hi Rob,
>
> Thank you for that info.
> The OK answer from the modem, am already getting, but using "like brute
> force" serial readings...
>
> function CheckComms_OK() return bit is
>timer = 0
>Received[0] = "X"
>Received[1] = "X"
>--
>while (Received[0]!="O" | Received[1]!="K") & timer < 60_000 loop
>   fReturn = serial_hw_read(char)
>   Received[0] = char
>   fReturn = serial_hw_read(char)
>   Received[1] = char
>   --
>   timer = timer + 1
>end loop
>--
>fReturn = FALSE
>--
>if (Received[0]=="O" & Received[1]=="K") then
>   return TRUE
>else
>   return FALSE
>end if
> end function
>
> But other answers from the modem are still a no go.
> Example: "+CMGS" from an AT+CMGS="phone nr"
> Will need this because will need to also receive SMS with this PIC.
>
> Will check that LIB you mentioned.
> Thank you.
>
> Cheers,
> FS
>
> On Saturday, December 3, 2022 at 1:43:23 PM UTC rob...@hotmail.com wrote:
>
> Hi Filipe, Vasile,
>
> I would recommend using the serial libraries that work on an interrupt
> basis like serial_hw_int_cts.jal. Using this library with a big enough
> buffer will prevent that you miss any characters.
>
> I used this - using AT commands - in the libraries bluetooth_hc05.jal and
> bluetooth_hc06.jal as to be able to check if an OK was received after an AT
> command.
>
> Kind regards,
>
> Rob
>
>
>
> --
> *Van:* jal...@googlegroups.com  namens vsurducan
> 
> *Verzonden:* zaterdag 3 december 2022 11:09
>
> *Aan:* jal...@googlegroups.com 
> *Onderwerp:* Re: [jallib] Re: Variable Table Append
> Oh, understood. Reading needs to have priority. Use interrupts then...or
> avoid using any delays in your actual code.
> A sms has not an instant execution ( most of the time). So using low speed
> transmission/reception it might be a working solution.
>
> On Sat, Dec 3, 2022 at 11:53 AM flyway38  wrote:
>
> Hello Vasile,
>
> Am not using serial lib with interrupts.
> Maybe I need to use that lib.
> Current problem is GSM modem seems to acknowledge (ex: "OK") faster than
> my code can read it...
> A simple "AT" seems to get the "OK" faster than I can read.
> And I want to get all acknowledges... to not step to next AT command
> before having sure of "OK" response from the modem.
> All my AT commands to send an SMS are working ok, if no checking for the
> acknowledges...
> Big battle here under going. :D
> Thank you for your input.
>
> Cheers,
> FS
>
> On Saturday, December 3, 2022 at 6:18:47 AM UTC vasile wrote:
>
> Fellipe, I'm curious if this will work fo you. I was never able to use the
> serial library (interrupts) as is without a slip of one char in received
> characters order.  I've counted chars to solvethe problem
> Depending on your GSM transciever, some delays may be needed between chars
> and some longer delays between AT commands and chars.
>
> On Fri 2 Dec 2022, 9:25 PM flyway38 
> Hello Rob,
>
> Thank you very much.
> This will help alot.
> Cheers.
>
> FS
>
> On Friday, December 2, 2022 at 7:21:46 PM UTC rob...@hotmail.com wrote:
>
> Hi Filipe,
>
> One correction. if you get a timeout then there is no string (or only a
> partial string) so you have to check if the timer has reached the timeout
> after the repeat.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jal...@googlegroups.com  namens Rob CJ <
> rob...@hotmail.com>
> *Verzonden:* vrijdag 2 december 2022 20:20
> *Aan:* jal...@googlegroups.com 
>
> *Onderwerp:* Re: [jallib] Re: Variable Table Append
> Hi Filipe,
>
> Some sample code. I did not test it (or compiled it) but I assume you get
> the idea.
>
> const word MAX_TIMEOUT = 20_000
> const byte MAX_BUFFER = 20
> const byte CR = 0x0D
> const byte LF = 0x0A
>
> var word timer = 0
> var byte my_buffer[MAX_BUFFER]
> var byte index = 0
> var byte character = 0
>
> -- Read a string.
> repeat
> if serial_hw_data_available() then
>character = serial_hw_data
>m

Re: [jallib] Re: Variable Table Append

[vsurducan]

I'm not sure if this is your case, but if you need to identify the AT
during a string reception, but prior to store the string in any buffer, I
think the library will not work as is...

On Sat 3 Dec 2022, 7:23 PM flyway38  The oddest thing here, is it seems only my PIC doesn't pick up the answers
> from the modem, except the "OK" but even these fail sometimes to get picked
> up by the PIC.
> I have a derived connection from that serial port using an FTDI cable
> connected to my computer, and can check what is going on using the
> Hyperterminal App or even the Termite App and these apps can see the
> answers from the modem crazy stuff going on here...
>
> On Saturday, December 3, 2022 at 4:48:16 PM UTC flyway38 wrote:
>
>> Hi Rob,
>>
>> Thanks for that help.
>> But, right now am concerned about the other acknowledge messages... "OK"
>> is now working good enough here.
>> And it seems serial_hw_int_cts LIB is not making any difference.
>> Maybe am not taking full advantages from it.
>> Cheers,
>>
>> FS
>> On Saturday, December 3, 2022 at 2:22:04 PM UTC rob...@hotmail.com wrote:
>>
>>> Hi Filipe,
>>>
>>> In the bluetooth_hc_05.jal library I made a function that reads a string
>>> including OK but returns only the string (without the OK). The code is as
>>> follows:
>>>
>>> -- Wait for data from the module and copy all data to the bluetooth
>>> receive
>>> -- buffer until 'OK' is found. If 'OK' is found the function returns
>>> TRUE.
>>> -- The number of bytes in the receive buffer is stored in the global
>>> variable
>>> -- bluetooth_hc05_bytes_received and the read pointer is reset.
>>> -- Note that 'OK' is not stored in bluetooth_hc05_bytes_received but the
>>> -- carriage return and line feed are.
>>> function _bluetooth_hc05_wait_and_get_data_ok() return bit is
>>>
>>>var dword timeout = 0
>>>var byte index = 0
>>>var byte character
>>>var bit found_o  = FALSE
>>>var bit found_ok = FALSE
>>>
>>>bluetooth_hc05_bytes_received = 0
>>>_bluetooth_hc05_read_pointer = 0
>>>while (index < BLUETOOTH_HC05_RECEIVE_BUFFER_SIZE) & !found_ok &
>>>  (timeout < _bluetooth_hc05_wait_time) loop
>>>
>>>   if _bluetooth_hc05_serial_read(character) then
>>>  bluetooth_hc05_receive_buffer[index] = character
>>>  index = index + 1
>>>  timeout = 0
>>>  if (character == "O") then
>>> found_o = TRUE
>>>  elsif (character == "K") & found_o then
>>> found_ok = TRUE
>>> -- Bytes received is everything except for 'OK'.
>>> bluetooth_hc05_bytes_received = index - 2
>>> else
>>> -- It was not 'OK', reset.
>>> found_o  = FALSE
>>> found_ok = FALSE
>>>  end if
>>>   end if
>>>
>>>   timeout = timeout + 1
>>>   _usec_delay(100)
>>>end loop
>>>
>>>return found_ok
>>>
>>> end function
>>>
>>> Kind regards,
>>>
>>> Rob
>>> --
>>> *Van:* jal...@googlegroups.com  namens
>>> flyway38 
>>> *Verzonden:* zaterdag 3 december 2022 15:11
>>>
>>> *Aan:* jallib 
>>> *Onderwerp:* Re: [jallib] Re: Variable Table Append
>>> Hi Rob,
>>>
>>> Thank you for that info.
>>> The OK answer from the modem, am already getting, but using "like brute
>>> force" serial readings...
>>>
>>> function CheckComms_OK() return bit is
>>>timer = 0
>>>Received[0] = "X"
>>>Received[1] = "X"
>>>--
>>>while (Received[0]!="O" | Received[1]!="K") & timer < 60_000 loop
>>>   fReturn = serial_hw_read(char)
>>>   Received[0] = char
>>>   fReturn = serial_hw_read(char)
>>>   Received[1] = char
>>>   --
>>>   timer = timer + 1
>>>end loop
>>>--
>>>fReturn = FALSE
>>>--
>>>if (Received[0]=="O" & Received[1]=="K") then
>>>   return TRUE
>>>else
>>>   return FALSE
>>>end if
>>> end function
>>>
>>> But other answer

Re: [jallib] Re: Variable Table Append

[vsurducan]

Oh, understood. Reading needs to have priority. Use interrupts then...or
avoid using any delays in your actual code.
A sms has not an instant execution ( most of the time). So using low speed
transmission/reception it might be a working solution.

On Sat, Dec 3, 2022 at 11:53 AM flyway38  wrote:

> Hello Vasile,
>
> Am not using serial lib with interrupts.
> Maybe I need to use that lib.
> Current problem is GSM modem seems to acknowledge (ex: "OK") faster than
> my code can read it...
> A simple "AT" seems to get the "OK" faster than I can read.
> And I want to get all acknowledges... to not step to next AT command
> before having sure of "OK" response from the modem.
> All my AT commands to send an SMS are working ok, if no checking for the
> acknowledges...
> Big battle here under going. :D
> Thank you for your input.
>
> Cheers,
> FS
>
> On Saturday, December 3, 2022 at 6:18:47 AM UTC vasile wrote:
>
>> Fellipe, I'm curious if this will work fo you. I was never able to use
>> the serial library (interrupts) as is without a slip of one char in
>> received characters order.  I've counted chars to solvethe problem
>> Depending on your GSM transciever, some delays may be needed between
>> chars and some longer delays between AT commands and chars.
>>
>> On Fri 2 Dec 2022, 9:25 PM flyway38 >
>>> Hello Rob,
>>>
>>> Thank you very much.
>>> This will help alot.
>>> Cheers.
>>>
>>> FS
>>>
>>> On Friday, December 2, 2022 at 7:21:46 PM UTC rob...@hotmail.com wrote:
>>>
 Hi Filipe,

 One correction. if you get a timeout then there is no string (or only a
 partial string) so you have to check if the timer has reached the timeout
 after the repeat.

 Kind regards,

 Rob

 --
 *Van:* jal...@googlegroups.com  namens Rob CJ
 
 *Verzonden:* vrijdag 2 december 2022 20:20
 *Aan:* jal...@googlegroups.com 

 *Onderwerp:* Re: [jallib] Re: Variable Table Append
 Hi Filipe,

 Some sample code. I did not test it (or compiled it) but I assume you
 get the idea.

 const word MAX_TIMEOUT = 20_000
 const byte MAX_BUFFER = 20
 const byte CR = 0x0D
 const byte LF = 0x0A

 var word timer = 0
 var byte my_buffer[MAX_BUFFER]
 var byte index = 0
 var byte character = 0

 -- Read a string.
 repeat
 if serial_hw_data_available() then
character = serial_hw_data
my_buffer[index] = character
index = index + 1
end if
 timer = timer + 1
 _usec_delay(100)
 until (index == MAX_BUFFER) | (character == CR) | (character == LF) |
 (timer == MAX_TIMEOUT)

 The string is then in my_buffer (including a CR or LF).

 Kind regards,

 Rob


 --
 *Van:* jal...@googlegroups.com  namens
 flyway38 
 *Verzonden:* vrijdag 2 december 2022 19:23
 *Aan:* jallib 
 *Onderwerp:* Re: [jallib] Re: Variable Table Append

 Hi Rob,

 Thanks for your input.
 Could you post some sample code please?
 I think am missing some important details...
 How can I define a variable buffer?
 Because this seems not work: var byte received[]=""...

 Am also struggling to read my modems relies to AT commands...
 It seems my code is working correctly and after sending the AT command,
 the readings from serial port seems to point to characters from the sent
 command...
 Getting crazy here while in battle with the code... :D
 Thank you very much.

 Best regards,
 Filipe Santos

 On Friday, December 2, 2022 at 6:06:56 PM UTC rob...@hotmail.com wrote:

 Hi Filipe,

 You just read the data from a serial port, add that to your local
 variable buffer, increment an index pointer with each received character
 and read until you receive either a Carriage Return or a Line Feed (one of
 the will do). I normally also add a timeout to the read function so that it
 does not hang when nothing is received.

 Kind regards,

 rob



 --
 *Van:* jal...@googlegroups.com  namens
 flyway38 
 *Verzonden:* vrijdag 2 december 2022 12:38
 *Aan:* jallib 
 *Onderwerp:* [jallib] Re: Variable Table Append

 Am trying to mimic a "Read_String" from serial port.
 Any ideas?

 Thank you.

 Regards,
 FS

 On Friday, December 2, 2022 at 9:42:34 AM UTC flyway38 wrote:

 Hello all,

 Have searched for it but haven't found anything useful.
 Need to know a good way of appending a variable table.
 Starting from a MyVar[] = "", then just append data to it...
 Also what happen to website: https://justanotherlanguage.org/ ?
 Cannot connect to that website.
 Thank you very much.

 Kind regards,
 Filipe Santos.

 --
 You 

Re: [jallib] Re: Variable Table Append

[vsurducan]

Fellipe, I'm curious if this will work fo you. I was never able to use the
serial library (interrupts) as is without a slip of one char in received
characters order.  I've counted chars to solvethe problem
Depending on your GSM transciever, some delays may be needed between chars
and some longer delays between AT commands and chars.

On Fri 2 Dec 2022, 9:25 PM flyway38  Hello Rob,
>
> Thank you very much.
> This will help alot.
> Cheers.
>
> FS
>
> On Friday, December 2, 2022 at 7:21:46 PM UTC rob...@hotmail.com wrote:
>
>> Hi Filipe,
>>
>> One correction. if you get a timeout then there is no string (or only a
>> partial string) so you have to check if the timer has reached the timeout
>> after the repeat.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens Rob CJ <
>> rob...@hotmail.com>
>> *Verzonden:* vrijdag 2 december 2022 20:20
>> *Aan:* jal...@googlegroups.com 
>>
>> *Onderwerp:* Re: [jallib] Re: Variable Table Append
>> Hi Filipe,
>>
>> Some sample code. I did not test it (or compiled it) but I assume you get
>> the idea.
>>
>> const word MAX_TIMEOUT = 20_000
>> const byte MAX_BUFFER = 20
>> const byte CR = 0x0D
>> const byte LF = 0x0A
>>
>> var word timer = 0
>> var byte my_buffer[MAX_BUFFER]
>> var byte index = 0
>> var byte character = 0
>>
>> -- Read a string.
>> repeat
>> if serial_hw_data_available() then
>>character = serial_hw_data
>>my_buffer[index] = character
>>index = index + 1
>>end if
>> timer = timer + 1
>> _usec_delay(100)
>> until (index == MAX_BUFFER) | (character == CR) | (character == LF) |
>> (timer == MAX_TIMEOUT)
>>
>> The string is then in my_buffer (including a CR or LF).
>>
>> Kind regards,
>>
>> Rob
>>
>>
>> --
>> *Van:* jal...@googlegroups.com  namens flyway38
>> 
>> *Verzonden:* vrijdag 2 december 2022 19:23
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Re: Variable Table Append
>>
>> Hi Rob,
>>
>> Thanks for your input.
>> Could you post some sample code please?
>> I think am missing some important details...
>> How can I define a variable buffer?
>> Because this seems not work: var byte received[]=""...
>>
>> Am also struggling to read my modems relies to AT commands...
>> It seems my code is working correctly and after sending the AT command,
>> the readings from serial port seems to point to characters from the sent
>> command...
>> Getting crazy here while in battle with the code... :D
>> Thank you very much.
>>
>> Best regards,
>> Filipe Santos
>>
>> On Friday, December 2, 2022 at 6:06:56 PM UTC rob...@hotmail.com wrote:
>>
>> Hi Filipe,
>>
>> You just read the data from a serial port, add that to your local
>> variable buffer, increment an index pointer with each received character
>> and read until you receive either a Carriage Return or a Line Feed (one of
>> the will do). I normally also add a timeout to the read function so that it
>> does not hang when nothing is received.
>>
>> Kind regards,
>>
>> rob
>>
>>
>>
>> --
>> *Van:* jal...@googlegroups.com  namens flyway38
>> 
>> *Verzonden:* vrijdag 2 december 2022 12:38
>> *Aan:* jallib 
>> *Onderwerp:* [jallib] Re: Variable Table Append
>>
>> Am trying to mimic a "Read_String" from serial port.
>> Any ideas?
>>
>> Thank you.
>>
>> Regards,
>> FS
>>
>> On Friday, December 2, 2022 at 9:42:34 AM UTC flyway38 wrote:
>>
>> Hello all,
>>
>> Have searched for it but haven't found anything useful.
>> Need to know a good way of appending a variable table.
>> Starting from a MyVar[] = "", then just append data to it...
>> Also what happen to website: https://justanotherlanguage.org/ ?
>> Cannot connect to that website.
>> 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+un...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jallib/2251b524-7658-42f7-970b-a6817d6709e1n%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/37733abd-20ed-4130-8aa2-03381fb3ac1an%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] Coding for a GA6-B

[vsurducan]

Yes, but in BLE the AT command set is restricted to several configuration
schemes (set device as central unit/peripheral unit, set MAC address, set
tx power, sleep, wake, etc). If you are sending auto sms with different
text to al your girlfriends...should be much difficult.

On Fri 2 Dec 2022, 2:48 PM flyway38  Hi Vasile,
>
> Did you used AT commands in that BLE project?
> Does your code interpret received messages?
> Am struggling with that code...
> Thanks
>
> Cheers,
> Filipe Santos
>
> On Friday, December 2, 2022 at 11:04:06 AM UTC vasile wrote:
>
>> Great. :)
>>
>> On Fri 2 Dec 2022, 11:32 AM flyway38 >
>>> Hi Vasile, yes, have used hyperterminal to understand what was not
>>> working and found out some issues about connections and some other bugs in
>>> AT commands to be sent.
>>> Also had success in solving this issue.
>>>
>>> Cheers,
>>> FS
>>>
>>> On Thursday, December 1, 2022 at 6:21:51 AM UTC vasile wrote:
>>>
 I would try first with a standard terminal connected to your GSM
 module, and a link between two computers.
 Perhaps there are some delays you need to comply with. That will solve
 any connection issues (if any).
 I remember the BLE communication on some moisture sensors I
 manufactured, they had the same problem but finally worked.

 On Wed, Nov 30, 2022 at 8:21 PM flyway38  wrote:

> Hello all,
>
> Am trying to implement code to send SMS and make a Call (for testing
> only) using this PIC16F19176 with a GSM module: GA6-B.
> Heres the arduino code:
>
> //
> ---
> // Example Support of GOOUUU TECH IOT-GA6-B Gprs Gsm Module
> //
> ---
> #include 
> #define GSM_RX 2 // Arduino pin 2 to URX
> #define GSM_TX 3 // Arduino pin 3 to URX
> SoftwareSerial sim(GSM_RX, GSM_TX); //
> // The GSM
> String number = "07905582XXX"; //-> change with your number
> void setup() {
> Serial.begin(9600); // GPS on 0,1 pin
> Serial.println("System Started...");
> sim.begin(115200);
> delay(1000);
> Serial.println("Communicating GSM/GPS.");
> sms(); //send sms
> call(); //call to us
> }
> void loop() {
> //do your code
> } //loop
> //---GSM Function
> -
> void sms()
> {
> Serial.println ("Sending Message");
> sim.println("AT+CMGF=1"); //Sets the GSM Module in Text Mode
> delay(1000);
> Serial.println ("Set SMS Number");
> sim.println("AT+CMGS=\"" + number + "\"\r"); //Mobile phone number to
> send message
> delay(1000);
> String SMS = "Sample SMS is sending."; //sms content
> sim.println(SMS);
> delay(100);
> sim.println((char)26);// ASCII code of CTRL+Z
> delay(1000);
> }
> void call() {
> sim.print (F("ATD"));
> sim.print (number);
> sim.print (F(";\r\n"));
> }
>
> And here relevant part of my code (not working):
> --
> include pps
> pps_control_lock(FALSE)
> RC6PPS = PPS_TX1  -- TX1 re-assigned to C6  (default)
> RX1PPS = PPS_RC7  -- C7 re-assigned to RX1  (default)
> pps_control_lock(TRUE)
> --
> --
> --
> -- ok, now setup serial
> --const serial_hw_baudrate = 999_000
> -- (115_200 / 256_000 / 512_000 já testados com sucesso)
> --
> -- Include and initialize serial hardware library.
> const serial_hw_baudrate = 115200
> --const serial_hw_baudrate = 9600
> alias pin_TX_direction is pin_C6_direction  -- Transmit pin.
> alias pin_RX_direction is pin_C7_direction  -- Receive pin.
> include serial_hardware
> serial_hw_init()
> --
> -- output library
> include print
> --
> include delay
> --
> const byte AT1[] = "ATD"
> const byte AT2[] = "XXXMyNumberXXX"
> const byte AT3[] = ";"
> --
> forever loop
>--
>led = OFF
>delay_1ms(10_000)
>--
>led = ON
>print_string(serial_hw_data,AT1)
>print_string(serial_hw_data,AT2)
>print_string(serial_hw_data,AT3)
>--print_crlf(serial_hw_data)
>delay_1ms(5_000)
>--
> end loop
>
> Testing only with a CALL making. No success so far.
> AT commands are sent (received and read in computer)
> Any help will be great.
> Thank you very much.
>
> Best 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/142573ae-b364-4ba8-b01c-96a7355af724n%40googlegroups.com
> 

Re: [jallib] Coding for a GA6-B

[vsurducan]

Great. :)

On Fri 2 Dec 2022, 11:32 AM flyway38  Hi Vasile, yes, have used hyperterminal to understand what was not working
> and found out some issues about connections and some other bugs in AT
> commands to be sent.
> Also had success in solving this issue.
>
> Cheers,
> FS
>
> On Thursday, December 1, 2022 at 6:21:51 AM UTC vasile wrote:
>
>> I would try first with a standard terminal connected to your GSM module,
>> and a link between two computers.
>> Perhaps there are some delays you need to comply with. That will solve
>> any connection issues (if any).
>> I remember the BLE communication on some moisture sensors I manufactured,
>> they had the same problem but finally worked.
>>
>> On Wed, Nov 30, 2022 at 8:21 PM flyway38  wrote:
>>
>>> Hello all,
>>>
>>> Am trying to implement code to send SMS and make a Call (for testing
>>> only) using this PIC16F19176 with a GSM module: GA6-B.
>>> Heres the arduino code:
>>>
>>> //
>>> ---
>>> // Example Support of GOOUUU TECH IOT-GA6-B Gprs Gsm Module
>>> //
>>> ---
>>> #include 
>>> #define GSM_RX 2 // Arduino pin 2 to URX
>>> #define GSM_TX 3 // Arduino pin 3 to URX
>>> SoftwareSerial sim(GSM_RX, GSM_TX); //
>>> // The GSM
>>> String number = "07905582XXX"; //-> change with your number
>>> void setup() {
>>> Serial.begin(9600); // GPS on 0,1 pin
>>> Serial.println("System Started...");
>>> sim.begin(115200);
>>> delay(1000);
>>> Serial.println("Communicating GSM/GPS.");
>>> sms(); //send sms
>>> call(); //call to us
>>> }
>>> void loop() {
>>> //do your code
>>> } //loop
>>> //---GSM Function
>>> -
>>> void sms()
>>> {
>>> Serial.println ("Sending Message");
>>> sim.println("AT+CMGF=1"); //Sets the GSM Module in Text Mode
>>> delay(1000);
>>> Serial.println ("Set SMS Number");
>>> sim.println("AT+CMGS=\"" + number + "\"\r"); //Mobile phone number to
>>> send message
>>> delay(1000);
>>> String SMS = "Sample SMS is sending."; //sms content
>>> sim.println(SMS);
>>> delay(100);
>>> sim.println((char)26);// ASCII code of CTRL+Z
>>> delay(1000);
>>> }
>>> void call() {
>>> sim.print (F("ATD"));
>>> sim.print (number);
>>> sim.print (F(";\r\n"));
>>> }
>>>
>>> And here relevant part of my code (not working):
>>> --
>>> include pps
>>> pps_control_lock(FALSE)
>>> RC6PPS = PPS_TX1  -- TX1 re-assigned to C6  (default)
>>> RX1PPS = PPS_RC7  -- C7 re-assigned to RX1  (default)
>>> pps_control_lock(TRUE)
>>> --
>>> --
>>> --
>>> -- ok, now setup serial
>>> --const serial_hw_baudrate = 999_000
>>> -- (115_200 / 256_000 / 512_000 já testados com sucesso)
>>> --
>>> -- Include and initialize serial hardware library.
>>> const serial_hw_baudrate = 115200
>>> --const serial_hw_baudrate = 9600
>>> alias pin_TX_direction is pin_C6_direction  -- Transmit pin.
>>> alias pin_RX_direction is pin_C7_direction  -- Receive pin.
>>> include serial_hardware
>>> serial_hw_init()
>>> --
>>> -- output library
>>> include print
>>> --
>>> include delay
>>> --
>>> const byte AT1[] = "ATD"
>>> const byte AT2[] = "XXXMyNumberXXX"
>>> const byte AT3[] = ";"
>>> --
>>> forever loop
>>>--
>>>led = OFF
>>>delay_1ms(10_000)
>>>--
>>>led = ON
>>>print_string(serial_hw_data,AT1)
>>>print_string(serial_hw_data,AT2)
>>>print_string(serial_hw_data,AT3)
>>>--print_crlf(serial_hw_data)
>>>delay_1ms(5_000)
>>>--
>>> end loop
>>>
>>> Testing only with a CALL making. No success so far.
>>> AT commands are sent (received and read in computer)
>>> Any help will be great.
>>> Thank you very much.
>>>
>>> Best 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+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jallib/142573ae-b364-4ba8-b01c-96a7355af724n%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/b8f54e75-bb5e-4342-8626-2995b5dae198n%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 

Re: [jallib] Coding for a GA6-B

[vsurducan]

I would try first with a standard terminal connected to your GSM module,
and a link between two computers.
Perhaps there are some delays you need to comply with. That will solve any
connection issues (if any).
I remember the BLE communication on some moisture sensors I manufactured,
they had the same problem but finally worked.

On Wed, Nov 30, 2022 at 8:21 PM flyway38  wrote:

> Hello all,
>
> Am trying to implement code to send SMS and make a Call (for testing only)
> using this PIC16F19176 with a GSM module: GA6-B.
> Heres the arduino code:
>
> //
> ---
> // Example Support of GOOUUU TECH IOT-GA6-B Gprs Gsm Module
> //
> ---
> #include 
> #define GSM_RX 2 // Arduino pin 2 to URX
> #define GSM_TX 3 // Arduino pin 3 to URX
> SoftwareSerial sim(GSM_RX, GSM_TX); //
> // The GSM
> String number = "07905582XXX"; //-> change with your number
> void setup() {
> Serial.begin(9600); // GPS on 0,1 pin
> Serial.println("System Started...");
> sim.begin(115200);
> delay(1000);
> Serial.println("Communicating GSM/GPS.");
> sms(); //send sms
> call(); //call to us
> }
> void loop() {
> //do your code
> } //loop
> //---GSM Function
> -
> void sms()
> {
> Serial.println ("Sending Message");
> sim.println("AT+CMGF=1"); //Sets the GSM Module in Text Mode
> delay(1000);
> Serial.println ("Set SMS Number");
> sim.println("AT+CMGS=\"" + number + "\"\r"); //Mobile phone number to
> send message
> delay(1000);
> String SMS = "Sample SMS is sending."; //sms content
> sim.println(SMS);
> delay(100);
> sim.println((char)26);// ASCII code of CTRL+Z
> delay(1000);
> }
> void call() {
> sim.print (F("ATD"));
> sim.print (number);
> sim.print (F(";\r\n"));
> }
>
> And here relevant part of my code (not working):
> --
> include pps
> pps_control_lock(FALSE)
> RC6PPS = PPS_TX1  -- TX1 re-assigned to C6  (default)
> RX1PPS = PPS_RC7  -- C7 re-assigned to RX1  (default)
> pps_control_lock(TRUE)
> --
> --
> --
> -- ok, now setup serial
> --const serial_hw_baudrate = 999_000
> -- (115_200 / 256_000 / 512_000 já testados com sucesso)
> --
> -- Include and initialize serial hardware library.
> const serial_hw_baudrate = 115200
> --const serial_hw_baudrate = 9600
> alias pin_TX_direction is pin_C6_direction  -- Transmit pin.
> alias pin_RX_direction is pin_C7_direction  -- Receive pin.
> include serial_hardware
> serial_hw_init()
> --
> -- output library
> include print
> --
> include delay
> --
> const byte AT1[] = "ATD"
> const byte AT2[] = "XXXMyNumberXXX"
> const byte AT3[] = ";"
> --
> forever loop
>--
>led = OFF
>delay_1ms(10_000)
>--
>led = ON
>print_string(serial_hw_data,AT1)
>print_string(serial_hw_data,AT2)
>print_string(serial_hw_data,AT3)
>--print_crlf(serial_hw_data)
>delay_1ms(5_000)
>--
> end loop
>
> Testing only with a CALL making. No success so far.
> AT commands are sent (received and read in computer)
> Any help will be great.
> Thank you very much.
>
> Best 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/142573ae-b364-4ba8-b01c-96a7355af724n%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%2Bj4qtjLtv%3DYJrnMgJNjKXC%2Bsu%2BjATit6sUNcrXdPE5uxisKQ%40mail.gmail.com.

Re: [jallib] Re: Help on integrating PIC16F19176 in Pickit 2 options

[vsurducan]

Evan, I am a bit confused. Pickit+ is using different firmware than the
original  Microchip. Pickit- is using Microchip firmware and Pickit+
database That looks strange in my logic, but also shows that Pickit-
may be somehow different than Pickit+?

On Sun 27 Nov 2022, 6:10 PM 'evan@googlemail.com' via jallib <
jallib@googlegroups.com wrote:

> @Filipe
>
> PICKIT- developer took our database, took our ideas and now are hurting
> us.  I have spoken on the real issues regarding the changes made to the
> database that can cause real damage to microcontrollers.
> I am personally in debt regarding the development of PICKitPlus.
> Please consider donating to our project even if the donation is a token
> donation of a few $$.
>
> Evan
>
> On Saturday, 26 November 2022 at 20:17:34 UTC fsfo...@gmail.com wrote:
>
>> Hi again.
>>
>> PickitMinus is great!!!
>> It has that PIC (16F19176) that am using (and many other ones) and it
>> worked like a charm.
>> Thank you so much Rob.
>>
>> Cheers,
>> Filipe Santos.
>>
>> On Saturday, November 26, 2022 at 8:08:05 PM UTC flyway38 wrote:
>>
>>> Hey Vasile/ Rob.
>>>
>>> Thank you very much for your input.
>>> Will check that options.
>>>
>>> Best regards,
>>> Filipe Santos.
>>>
>>> On Saturday, November 26, 2022 at 1:32:51 PM UTC evan@googlemail.com
>>> wrote:
>>>
 Yes. Not happy that someone took our work. Very unhappy.

 Get Outlook for Android 
 --
 *From:* jal...@googlegroups.com  on behalf of
 flyway38 
 *Sent:* Saturday, November 26, 2022 12:43:54 PM
 *To:* jallib 
 *Subject:* Re: [jallib] Re: Help on integrating PIC16F19176 in Pickit
 2 options

 Hello Evan

 Yes, am using standard Pickit 2 software.
 Where do I find newer data base for it?
 Will google for it.
 Thanks.

 Regards,
 Filipe Santos.

 On Saturday, November 26, 2022 at 12:15:47 PM UTC
 evan@googlemail.com wrote:

 re:  The chip you are trying to add.

 It uses a different protocol for the SPI communications.  You will
 require to make changes to the application to change from LSB SPI to MSB
 SPI, and, a host of other application changes in  terms of memory 
 locations.

 The newer chips starting with the 16F18855 chip family and then the
 18FxxK40 use the different protocol.

 Options:
 IPE for MPLAB 5.xx and onwards
 PICKitPlus
 change programmer to a North Programmer ( very fast).





 On Saturday, 26 November 2022 at 11:49:30 UTC rob...@hotmail.com wrote:

 Hi Filip,

 Which software are you using with your PicKit2, is that the standard
 Microchip software?

 I guess you need a more recent database. Did you try that?

 Kind regards,

 Rob

 --
 *Van:* jal...@googlegroups.com  namens
 flyway38 
 *Verzonden:* zaterdag 26 november 2022 11:17
 *Aan:* jallib 
 *Onderwerp:* [jallib] Re: Help on integrating PIC16F19176 in Pickit 2
 options

 Hello all,

 No help here?
 Tried to use PIC16F1939 as base to my PIC16F19176.
 Changed only Device ID (tried 30A0 as per datasheet and 309C as per JAL
 PIC lib) and no luck.
 Kept all other parameters as they show similar to my PIC ones (at least
 the ones I could identify).
 Pickit 2 shows warning message: "Hex File Loaded is large than device"
 Thank you very much.

 Regards,
 Filipe Santos.


 On Friday, November 25, 2022 at 7:37:44 PM UTC evan@googlemail.com
 wrote:

 See
 https://github.com/Anobium/PICKitPlus/tree/master/PickIt%20ScriptEditor
 for our editor.

 There are applications changes required to make the new chips.

 But, happy to share the editor.

 Evan

 On Friday, 25 November 2022 at 19:33:08 UTC fsfo...@gmail.com wrote:

 Hey again Evan,

 Thank for the input and corrections.
 Just found a "cheaper" way :D
 https://jared.geek.nz/2013/jan/adding-extra-chips-to-the-pickit-2
 Now only need to find what's similar to my pic, in Pickit 2 original
 library.
 Thanks anyways.

 Greetings
 Filipe Santos.

 On Friday, November 25, 2022 at 7:21:42 PM UTC evan@googlemail.com
 wrote:

 Apologies.

 www.pickitplus.co.uk

 What works out of the box?  We provide PK2 software that is fully
 supported.  We are a Microchip Software Partner.
 Are you developer of what?  PICKITPlus software
 That website doesn't work (server not found)...My error, see URL abouve
 Not sure how to solve my issue that way. - install our software and it
 will work. We have Windows, LX and Pi versions.  We have UI version and
 command line versions.

 Evan


 On Friday, 25 November 2022 at 19:18:10 UTC 

Re: [jallib] Re: Help on integrating PIC16F19176 in Pickit 2 options

[vsurducan]

Rob, I believed that pickitminus is your joke naming the pickitplus:)
now I see that really exists.

On Sat 26 Nov 2022, 3:09 PM Rob CJ  Hi Filipe,
>
> Evan will not be happy but you can download PICkitminus from here:
> http://kair.us/projects/pickitminus/
> PICkitminus - updated software and device file for PICkit 2 and PICkit 3 -
> KAIR.US 
> kair.us/ projects/ pickitminus/ PICkit- software suite. You can use your
> trusty old PICkit2 and PICkit3 with the new Microchip PIC microcontrollers
> with PICkitminus program.
> kair.us
>
> I did had some issues with it, that it sometimes recognized the wrong PIC
> but when detected correctly (which it mostly did) I was able to program
> newer PICs with this software.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens flyway38 <
> fsfon...@gmail.com>
> *Verzonden:* zaterdag 26 november 2022 13:43
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] Re: Help on integrating PIC16F19176 in Pickit 2
> options
>
> Hello Evan
>
> Yes, am using standard Pickit 2 software.
> Where do I find newer data base for it?
> Will google for it.
> Thanks.
>
> Regards,
> Filipe Santos.
>
> On Saturday, November 26, 2022 at 12:15:47 PM UTC evan@googlemail.com
> wrote:
>
> re:  The chip you are trying to add.
>
> It uses a different protocol for the SPI communications.  You will require
> to make changes to the application to change from LSB SPI to MSB SPI, and,
> a host of other application changes in  terms of memory locations.
>
> The newer chips starting with the 16F18855 chip family and then the
> 18FxxK40 use the different protocol.
>
> Options:
> IPE for MPLAB 5.xx and onwards
> PICKitPlus
> change programmer to a North Programmer ( very fast).
>
>
>
>
>
> On Saturday, 26 November 2022 at 11:49:30 UTC rob...@hotmail.com wrote:
>
> Hi Filip,
>
> Which software are you using with your PicKit2, is that the standard
> Microchip software?
>
> I guess you need a more recent database. Did you try that?
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jal...@googlegroups.com  namens flyway38 <
> fsfo...@gmail.com>
> *Verzonden:* zaterdag 26 november 2022 11:17
> *Aan:* jallib 
> *Onderwerp:* [jallib] Re: Help on integrating PIC16F19176 in Pickit 2
> options
>
> Hello all,
>
> No help here?
> Tried to use PIC16F1939 as base to my PIC16F19176.
> Changed only Device ID (tried 30A0 as per datasheet and 309C as per JAL
> PIC lib) and no luck.
> Kept all other parameters as they show similar to my PIC ones (at least
> the ones I could identify).
> Pickit 2 shows warning message: "Hex File Loaded is large than device"
> Thank you very much.
>
> Regards,
> Filipe Santos.
>
>
> On Friday, November 25, 2022 at 7:37:44 PM UTC evan@googlemail.com
> wrote:
>
> See
> https://github.com/Anobium/PICKitPlus/tree/master/PickIt%20ScriptEditor
> for our editor.
>
> There are applications changes required to make the new chips.
>
> But, happy to share the editor.
>
> Evan
>
> On Friday, 25 November 2022 at 19:33:08 UTC fsfo...@gmail.com wrote:
>
> Hey again Evan,
>
> Thank for the input and corrections.
> Just found a "cheaper" way :D
> https://jared.geek.nz/2013/jan/adding-extra-chips-to-the-pickit-2
> Now only need to find what's similar to my pic, in Pickit 2 original
> library.
> Thanks anyways.
>
> Greetings
> Filipe Santos.
>
> On Friday, November 25, 2022 at 7:21:42 PM UTC evan@googlemail.com
> wrote:
>
> Apologies.
>
> www.pickitplus.co.uk
>
> What works out of the box?  We provide PK2 software that is fully
> supported.  We are a Microchip Software Partner.
> Are you developer of what?  PICKITPlus software
> That website doesn't work (server not found)...My error, see URL abouve
> Not sure how to solve my issue that way. - install our software and it
> will work. We have Windows, LX and Pi versions.  We have UI version and
> command line versions.
>
> Evan
>
>
> On Friday, 25 November 2022 at 19:18:10 UTC fsfo...@gmail.com wrote:
>
> Hi Evan
>
> Not sure if understand correctly your text.
> What works out of the box?
> Are you developer of what?
> That website doesn't work (server not found)...
> Not sure how to solve my issue that way.
> I know I can add this PIC to Pickit 2 library. Just need some hint to
> start with.
> Thanks
>
> Filipe Santos.
>
> On Friday, November 25, 2022 at 7:01:28 PM UTC evan@googlemail.com
> wrote:
>
> Notes: As we are developing more and more.
>
> Added recently.  16F181xx,  16F171xx and the  16F188xx families of chips.
> All tested on real silicon.
> Also, recenlty.
> Resolved 18fXXQ84/Q83 issues.
> Resolve 18fXXQ43 Config value.
> Resolved K40 read error .
> Added wider support for the dsPIC30 family  - tested on real silicon
> Revised all LF chips to correct voltage
> Revised :LF  config with changes and corrections
> EE Erase improvements for all chips
> Added PIC18FxxJ94/3
> Resolved Qxx Progmem issue
> Added PIC18FxxQ83/4
>
>
> On Friday, 

Re: [jallib] Re: Help on integrating PIC16F19176 in Pickit 2 options

[vsurducan]

I wish to be so easy:)
Finally you will end buying either a pickit4 or upgrading your pickit2 or 3
with Evan's software/firmware...or both of them. The problem is that newer
pics have different programming algorithm, faster and different. The old
pickit2 firmware does not work with them.


On Fri 25 Nov 2022, 9:33 PM flyway38  Hey again Evan,
>
> Thank for the input and corrections.
> Just found a "cheaper" way :D
> https://jared.geek.nz/2013/jan/adding-extra-chips-to-the-pickit-2
> Now only need to find what's similar to my pic, in Pickit 2 original
> library.
> Thanks anyways.
>
> Greetings
> Filipe Santos.
>
> On Friday, November 25, 2022 at 7:21:42 PM UTC evan@googlemail.com
> wrote:
>
>> Apologies.
>>
>> www.pickitplus.co.uk
>>
>> What works out of the box?  We provide PK2 software that is fully
>> supported.  We are a Microchip Software Partner.
>> Are you developer of what?  PICKITPlus software
>> That website doesn't work (server not found)...My error, see URL abouve
>> Not sure how to solve my issue that way. - install our software and it
>> will work. We have Windows, LX and Pi versions.  We have UI version and
>> command line versions.
>>
>> Evan
>>
>>
>> On Friday, 25 November 2022 at 19:18:10 UTC fsfo...@gmail.com wrote:
>>
>>> Hi Evan
>>>
>>> Not sure if understand correctly your text.
>>> What works out of the box?
>>> Are you developer of what?
>>> That website doesn't work (server not found)...
>>> Not sure how to solve my issue that way.
>>> I know I can add this PIC to Pickit 2 library. Just need some hint to
>>> start with.
>>> Thanks
>>>
>>> Filipe Santos.
>>>
>>> On Friday, November 25, 2022 at 7:01:28 PM UTC evan@googlemail.com
>>> wrote:
>>>
 Notes: As we are developing more and more.

 Added recently.  16F181xx,  16F171xx and the  16F188xx families of
 chips.  All tested on real silicon.
 Also, recenlty.
 Resolved 18fXXQ84/Q83 issues.
 Resolve 18fXXQ43 Config value.
 Resolved K40 read error .
 Added wider support for the dsPIC30 family  - tested on real silicon
 Revised all LF chips to correct voltage
 Revised :LF  config with changes and corrections
 EE Erase improvements for all chips
 Added PIC18FxxJ94/3
 Resolved Qxx Progmem issue
 Added PIC18FxxQ83/4


 On Friday, 25 November 2022 at 18:49:36 UTC evan@googlemail.com
 wrote:

> Filipe it works out of the box.  Along with most of the new chips.
>
> I am the developer and you can get at  www.pickiplus.co.uk
>
> You will be operational and supported in a few minutes.
>
> Send me a PM and I will get you a URL that you can use to get the PK2
> only software = less.
>
> Evan
>
>
> On Friday, 25 November 2022 at 18:46:07 UTC fsfo...@gmail.com wrote:
>
>> Hello,
>>
>> Need help on this integration; PIC16F19176 into Pickit 2' s library.
>> Am aware of Pickit2 Script Editor. Have already used it to integrate
>> an easier one before.
>> But for this on (16F19176) don't know any similar one to start with.
>> Any would would be appreciated.
>> 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/0ed25b7c-30d2-4776-8ee4-343738c7b21cn%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%2Bj4qtt0mX0PSkb3%2BZfs-aj0QLhw-oGeauS2mGYO86h2u4ZbA%40mail.gmail.com.

Re: [jallib] PWM serial audio transmission

[vsurducan]

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  Hello highly honored public,
>
> I did some research in low/high pass filter science and found a lot of
> calculation programs.
>
> In the contribution of Kiste 20 Mar. 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 the transmitter and receiver do work,
> only with glitches.
>
> My question is outside the JALLIB world 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. I have taken up
>> the matter again and on my pin board both the transmitter and the receiver
>> work with a 12F683 at 1200 baud. I did put a 100nF in series at the output
>> according to your diagram. I also put a similar filter in the input of the
>> receiver. Identical to your proposal but because I know absolutely nothing
>> about filter matters I don't know if I did this right.
>>
>> I feed a separate uart signal as input and read out another uart 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 bit of junk.
>>
>> My question : what should the inlet filter to the receiver look like.
>>
>> I know your box of thanks is already full, but I'll add another 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 transmission
 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 <
 hansvanve...@gmail.com> 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 again
 hans

 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 <
 hansvanve...@gmail.com>
 *Verzonden:* zondag 3 april 2022 15:11
 *Aan:* jallib 

 *Onderwerp:* Re: [jallib] PWM serial audio transmission
 Still 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 

Re: [jallib] Re: PICKIT 3 problems

[vsurducan]

Rob, prior to throwing it away, plug it in a stanium foil for a while to
short all pins together.
Old PIC12F675 had this problem with address 0 and this was in a surprising
way the cure.

Of course, only if you did not supply it at 220V, see the top right
corner...
http://www.voti.nl/wloader/index_1.html
another one of my daughter's old drawings...:)


On Fri, Nov 11, 2022 at 9:53 PM Rob CJ  wrote:

> Hi Evan,
>
> Downloaded, installed it and it work for my PIC16F18857 (also programmed a
> PIC 12F675 and works OK).
>
> I still get the error on the PIC16F18857 that it is not able to program
> address 0x (verification error) but I think the PIC died so not related
> to the PICKit3 software. I will try with a fresh version.
>
> Thanks for the quick service.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* 'evan@googlemail.com' via jallib 
> *Verzonden:* vrijdag 11 november 2022 19:10
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] Re: PICKIT 3 problems
>
> Just sent the order go through the process.
>
> If you have issues, then, we can set about resolving for you and the
> greater community.  The new release has the new 16F180xx and 16F171xx
> chipfamily - we are waiting on the  16F181xx to arrive before we can add
> (as we have to test them!).  Also, adding more PIC32Mxs at the moment.
> Always busy.
>
> On Friday, 11 November 2022 at 17:59:56 UTC rob...@hotmail.com wrote:
>
> Hi Evan,
>
> I noticed indeed issues with PICkitminus that it sometimes recognizes
> another PIC than the one that is installed.
>
> So in order to get rid of this - and other issues I encountered - I just
> ordered your PICKitPlus software for my PICKit3 .
>
> Kind regards,
>
> Rob
>
> --
> *Van:* 'evan@googlemail.com' via jallib 
> *Verzonden:* vrijdag 11 november 2022 07:51
> *Aan:* jallib 
> *Onderwerp:* [jallib] Re: PICKIT 3 problems
>
> As the real developer of PICKitPlus and the database that was plagiarized
> by PK- I am the right person to help.
>
> When our database was copied the developer decided to change the order
> that the chip families are searched.  I wrote a detailed analysis for him
> and he ignored. So, using PK- can apply the incorrect voltage your PCB
> during startup.
>
> Which chip or chips have this issue?  This will help me isolate the issue.
>
> Evan
>
> On Friday, 11 November 2022 at 06:43:29 UTC hans wrote:
>
> Hello all,
>
> I regularly have problems with the pickit-3.(MPlab X IPE v 5.45) .
>
>   Because it happens less often when I first start up my PC, connect the
> pickit to the PIC and put voltage on it and only then connect the USB
> cable, this is my base.
>
>   Despite this, I get often  messages that the voltage is insufficient,
> the PIC is not the right type or a wrong feedback occurs during
> programming. This can almost always be solved by restarting MPlab, or by
> first performing a read or an erase.
>
> Lately I've been working with 3.3V. Now I had a program under 3.3V and
> that didn't work at all after programming without errors. After I erased
> the PIC separately below 5 V, the program works again.
>
> I have two clones. One suddenly doesn't work at all under 3.3 V, but with
> the Pickit_minus (with modified firmware) on 5V.
>
> Can anyone tell me where to look for the cause of all 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/e74098b6-6d7d-45a6-ba6c-087cc51faadcn%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/64b27e61-12c7-451c-85e4-5c743cb3b417n%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/GVXP195MB16375063A36BD0B02383E0C0E6009%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
> 
> .
>

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

Re: [jallib] PicKit minus - Free is not always bug free

[vsurducan]

Rob, I know you know, :) be sure.

The error from your picture appears to me each time there is a connector
problem ( for example Vpp has a contact issue which appears and disappears
intermittently) or the PIC life has ended ( it's not able to retain address
0 content) or the supply voltage is below the specifications for
programming.

That is what I can think about.

I suggest checking Evans software/firmware pair for newer pics ( if you
didn't yet), it is worth it for sure.


On Sun, Oct 23, 2022 at 8:14 PM Rob CJ  wrote:

> Hi Vasile,
>
> I know software is not bug free. I had no other connections to the
> programmer pins. It could be a bad connection (although IPE from MPLABX had
> no problem.
>
> I will try again later to see if the problem persists. Sometimes it helps
> to just restart the programmer software.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* 'Evan Venn' via jallib 
> *Verzonden:* zondag 23 oktober 2022 15:31
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] PicKit minus - Free is not always bug free
>
> I have just created a test program that fills that chip. No issues.
>
> However, until I get the hex I cannot assure you.
>
> There may be issues in the format of the hex thru to physical issues.  We
> have very robust test beds that rule out physical issues, so, can focus on
> the software.
>
> Your call to send to me for assurance.
>
> Evan
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> --
> *From:* jallib@googlegroups.com  on behalf of
> vsurducan 
> *Sent:* Sunday, October 23, 2022 11:50:44 AM
> *To:* jallib@googlegroups.com 
> *Subject:* Re: [jallib] PicKit minus - Free is not always bug free
>
> Rob, what is "bug free" ?  I have never heard about such a thing...
> :)
> Assuming your pickit3 software and companion definition file is compatible
> with PIC16F8857, your problem might be from an incorrect connection to ICSP
> or heavily loaded iclk and dat lines. One option is to "filter" those lines
> with 200ohm-680ohm resistors in series between the pic and your load, while
> your programmer stays connected directly to the PIC ICSP lines using as
> short as possible cable ( aka 20-30cm).  The other issue I saw is the USB
> cable length and quality.
>
> On Sun, Oct 23, 2022 at 12:47 PM rob...@hotmail.com 
> wrote:
>
> Hello all,
>
> This is for your information. I am looking at a problem I have with my
> PIC16F18857. It goes haywire when the code size becomes large (> 16 Kbyte).
>
> I did not yet find the root cause but I ran into another issue with the
> PicKit minus software.
>
> Although I am normally able to program the PIC16F18857 with this software
> it gives the following error when programming this large program (see
> attachment). It seems that the program is programmed correctly but still
> you do not want this type of error.
>
> The problem does not occur when using MPLABX IPE.
>
> So maybe better go for Evans PICKit Plus Software, not free but I assume
> bug free  ...
>
> 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/eb4d4a4d-5a10-45ab-8872-630303f75d32n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/eb4d4a4d-5a10-45ab-8872-630303f75d32n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qu8fndi2YQWVNuDPtb84Lb0vU8DcOVPVME0ni_qy%2BMyJg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qu8fndi2YQWVNuDPtb84Lb0vU8DcOVPVME0ni_qy%2BMyJg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CWXP265MB25182CE15D1E50E66689ED99F92F9%40CWXP265MB2518.GBRP265.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/jallib/CWXP265MB25182CE15D1E50E66689ED99F

Re: [jallib] PicKit minus - Free is not always bug free

[vsurducan]

Rob, what is "bug free" ?  I have never heard about such a thing...
:)
Assuming your pickit3 software and companion definition file is compatible
with PIC16F8857, your problem might be from an incorrect connection to ICSP
or heavily loaded iclk and dat lines. One option is to "filter" those lines
with 200ohm-680ohm resistors in series between the pic and your load, while
your programmer stays connected directly to the PIC ICSP lines using as
short as possible cable ( aka 20-30cm).  The other issue I saw is the USB
cable length and quality.

On Sun, Oct 23, 2022 at 12:47 PM rob...@hotmail.com 
wrote:

> Hello all,
>
> This is for your information. I am looking at a problem I have with my
> PIC16F18857. It goes haywire when the code size becomes large (> 16 Kbyte).
>
> I did not yet find the root cause but I ran into another issue with the
> PicKit minus software.
>
> Although I am normally able to program the PIC16F18857 with this software
> it gives the following error when programming this large program (see
> attachment). It seems that the program is programmed correctly but still
> you do not want this type of error.
>
> The problem does not occur when using MPLABX IPE.
>
> So maybe better go for Evans PICKit Plus Software, not free but I assume
> bug free  ...
>
> 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/eb4d4a4d-5a10-45ab-8872-630303f75d32n%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%2Bj4qu8fndi2YQWVNuDPtb84Lb0vU8DcOVPVME0ni_qy%2BMyJg%40mail.gmail.com.

Re: [jallib] Baudrate control

[vsurducan]

Bill, one good workaround for zero error baudrate is to use zero error
usart crystals You will always have zero error baud rate. 7.3728MHz,
14.7456MHz etc.

On Sat 22 Oct 2022, 5:14 PM Bill Beek  Hi Rob,
> I applied the function unchanged to 3 types: 16F876A, 18F2520 and
> 18F25K22.
> On the first 2 the function worked fine. So very useful for me.
> The function is used as a library "usart_dynamic" with the following 2
> lines added:
>  if (defined(usart_hw_serial) == FALSE) then
> const bit usart_hw_serial = TRUE   ; default is async mode (not sync)
> end if
> In the library "serial_hardware" I have changed the call to the correct
> library and the new function.
> I have change the name of this lib of coarse. It worked right away.
> The 18F25K22 does not want to generate the correct Baud rate, the relevant
> registers do have the correct values.
> I will look with the oscilloscope to see what kind of Baud rate is really
> generated.
>
> Thanks again for your help,
> Kind regards Bill.
>
> On Friday, October 21, 2022 at 7:23:33 PM UTC+2 rob...@hotmail.com wrote:
>
>> Hi Bill,
>>
>> Thanks and good to hear that you might becomd a fan of JAL.
>>
>> I saw that your PIC had an 8-bit baudrate generator so you would only
>> need this part of the code:
>>
>>  -- use classic (8 bit) baudrate register
>>  --  = ( Fosc / ( 4 * Baudrate ) ) -1
>>  -- first try high baudrate, will generate highest accuarcy
>>  -- to get the right rounding (5 + 10*f(x)) /10
>>  usart_calculation =((5 + ((10 * clock) / (16 * baudrate))) / 10)
>> - 1
>>  usart_div = word(usart_calculation)
>>  -- special case if divider is 0, test if deviation is not too
>> much
>>  if usart_div == 0 then
>> if (100 * (baudrate - (clock / 16))) / baudrate >=
>> max_deviation then
>>-- Asynchronous baudrate is too high
>>succes = FALSE
>> end if
>>  end if
>>  -- if divider small enough calculate divider and set high-speed
>>  real_baud = clock / 16 / (usart_div + 1)
>>  if usart_div <= 255 then
>> if (real_baud > baudrate) then
>>if (100 * (real_baud - baudrate) / baudrate >=
>> max_deviation) then
>>   -- Asynchronous baudrate deviation is too large
>>   succes = FALSE
>>end if
>> else
>>if (100 * (baudrate - real_baud) / baudrate >=
>> max_deviation) then
>>   -- Asynchronous baudrate deviation is too large
>>   succes = FALSE
>>end if
>> end if
>> SPBRGL = byte(usart_div)
>> TXSTA_BRGH = TRUE
>> -- try the low-speed mode
>>  else
>> usart_div_low = 10 * clock) / (64 * baudrate)) + 5) / 10)
>> - 1
>> -- here divider will never be 0
>> -- but special case to consider,
>> -- if baudrate is just a little too low
>> if (usart_div_low > 255) & (100 * ((clock / (64 * 256 )) -
>> baudrate)) /
>>   baudrate < max_deviation then
>>SPBRGL = 255
>>TXSTA_BRGH = FALSE
>>-- now calculate divider and set high-speed / low-speed
>> bit
>> elsif usart_div_low <= 255 then
>>SPBRGL = byte(usart_div_low)
>>TXSTA_BRGH = FALSE
>> else
>>-- Asynchronous baudrate is too low
>>succes = FALSE
>> end if
>>  end if
>>   end if
>>
>> Good luck testing.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens Bill
>> Beek 
>> *Verzonden:* donderdag 20 oktober 2022 19:15
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Baudrate control
>> Hi Rob,
>> I am going to try out the function you have sent, I see that it is
>> suitable for various PIC's and also test whetherthe chosen X-tal frequency
>> is good enough for the desired baudates. I myself use an 18.432 MHz x-tal
>> that I still found in my junkbox. in that casemy code can
>> be more simple because of the very small spread, but obviously not for
>> general use.
>>  I'll let you know if it worked out. B.T.W. this is very instructive for
>> me. and I'm going to appreciate JAL more and more.
>> Thank you for your effort,
>> Kind regards Bill.
>>
>> On Tuesday, October 18, 2022 at 7:23:04 PM UTC+2 rob...@hotmail.com
>> wrote:
>>
>> Hi Bill,
>>
>> I understand what you try to do but it does not work because the hardware
>> baudrate setting is calculated at compile time not at runtime.
>>
>> In the library usart_common.jal you find the procedure that calculates
>> the baudrate settings.
>>
>> I once changed this code to be dynamic and created the following code but
>> I do not remember if I ever tested it (it compiled as far as I know ).
>>
>> I did not use it because it is a lot of code for 

Re: [jallib] Re: PICKit3 programmer question.

[vsurducan]

Ok, I'm reformulating: Pk4 is faster than any old Pk programmer.  But I had
problems with Pk4 too which suddenly died. It was in warranty period so the
Irish guys replaced it quite fast... The only issue was the shipping costs
for returning the programmer which was almost equal with a new programmer...

About writing software for the pk4, each person has the free will in
choosing his/her own suffering. :)


On Thu, Oct 20, 2022 at 10:09 AM 'evan.r2...@googlemail.com' via jallib <
jallib@googlegroups.com> wrote:

> Sorry. Change 'boot' to 'start the application with the programmer
> attached to the chip/circuit'.
>
>
>
>1. Yes. You cam, easily, end up with corrupted firmware as the PK2 or
>pk3 searches through the chip families. I can tell you the exact
>circumstances – it essentially changing from the chip families with MSB to
>non MSB chip family and you use Automatic Search OR Tools/Communication AND
>NOT manual chip selectionThis rule is ONLY applicable to the released
>versions of the PK+ database. PK- changed the database and made the
>situation a lot worse where you can whack a chip with ease.
>2. Old programmer and old firmware does not resolve.
>3. PK+CommandLine and PK4 resolve this.  It makes you select the
>chip.  You take the responsibility for chip selection and PK4 even warns
>you of the danger.
>4. Pk2 is better that PK3.  PK4 is different from PK2 and PK3 and the
>PK4 is not the best.  We are working to gain access to the PK4 protocols to
>write our software for the PK4.
>
>
>
> Hope this helps.
>
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>
> *From:* jallib@googlegroups.com  on behalf of
> vsurducan 
> *Sent:* Thursday, October 20, 2022 7:27:27 AM
> *To:* jallib@googlegroups.com 
> *Subject:* Re: [jallib] Re: PICKit3 programmer question.
>
>
>
> Evan, I would say: do not boot your PC with Pickit2 connected to the USB.
> Why? because there are chances to end with corrupted firmware. It happened
> once. Fortunately having an old programmer and the firmware may solve this
> possible issue.
>
> Pickit2 seems better than pickit3. Pickit4 is better than any previous (
> maybe because it's Atmel based ? :P ) but its software stinks^3.
>
>
>
> On Wed, Oct 19, 2022 at 11:45 PM 'Evan Venn' via jallib <
> jallib@googlegroups.com> wrote:
>
> I know how the software works.
>
>
>
> The formal position is. Do not connect a pk3 or pk2 to the circuit and
> then star the Windows application with AutoDectect checked.
>
>
>
> Why?  The software will control the PK3 or Pk2 with respect to 3v3 for a
> specific chip.  But, if AutoDectect is checked and the previous chip is use
> is a non 3v3 chip then the Pk3 ot Pk2 will apply 5v0 during the detection
> process.
>
>
>
> So, best practice.  Use manual selection of the chip and do not use Auto
> Detect when using a 3v3 circuit.
>
>
>
> Evan
>
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>
> *From:* 'Mike' via jallib 
> *Sent:* Wednesday, October 19, 2022 9:40:21 PM
> *To:* jallib 
> *Subject:* Re: [jallib] Re: PICKit3 programmer question.
>
>
>
> It should be noted that the PICKits also program "LF" devices.  So,
> programming at 3.3V should not be a problem.  Do brownout settings have to
> be changed?
>
>
>
> Regards,
>
> Mike
>
>
>
>
>
> On Wednesday, October 19, 2022 at 1:45:42 PM UTC-4 rob...@hotmail.com
> wrote:
>
> Hello all,
>
>
>
> Thanks for your answers so it is save to run the PIC (and the rest) on 3.3
> Volt and program the PIC in-circuit with my PICkit3.
>
>
>
> I will give it a try since it saves me a lot of level shift connections
> and wires on the breadboard.
>
>
>
> Thanks again.
>
>
>
> Kind regards,
>
>
> Rob
>
>
>
> *Van:* jal...@googlegroups.com  namens vsurducan
> 
> *Verzonden:* woensdag 19 oktober 2022 06:07
> *Aan:* jal...@googlegroups.com 
> *Onderwerp:* Re: [jallib] Re: PICKit3 programmer question.
>
>
>
> Pickit2/Pickit2+ (Evan's firmware/software) works ok as you described. I
> guess will be no issue on Pickit3 either.
>
> best wishes,
>
> On Wed 19 Oct 2022, 6:16 AM Matthew Schinkel 
> I use PICKit3 ICSP with a 3.3v circuit. I haven't had any problems.
>
>
>
> Matt.
>
> On Tuesday, October 18, 2022 at 1:25:36 PM UTC-4 rob...@hotmail.com wrote:
>
> Hi all,
>
>
>
> I have a question about a PICKit3 programmer. Instead of trying it out and
> blowing up my programmer I thought I ask you.
>
>
>
> I often have a device that operates at 3.3. Volt and 

Re: [jallib] Re: PICKit3 programmer question.

[vsurducan]

Evan, I would say: do not boot your PC with Pickit2 connected to the USB.
Why? because there are chances to end with corrupted firmware. It happened
once. Fortunately having an old programmer and the firmware may solve this
possible issue.
Pickit2 seems better than pickit3. Pickit4 is better than any previous (
maybe because it's Atmel based ? :P ) but its software stinks^3.

On Wed, Oct 19, 2022 at 11:45 PM 'Evan Venn' via jallib <
jallib@googlegroups.com> wrote:

> I know how the software works.
>
> The formal position is. Do not connect a pk3 or pk2 to the circuit and
> then star the Windows application with AutoDectect checked.
>
> Why?  The software will control the PK3 or Pk2 with respect to 3v3 for a
> specific chip.  But, if AutoDectect is checked and the previous chip is use
> is a non 3v3 chip then the Pk3 ot Pk2 will apply 5v0 during the detection
> process.
>
> So, best practice.  Use manual selection of the chip and do not use Auto
> Detect when using a 3v3 circuit.
>
> Evan
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> --
> *From:* 'Mike' via jallib 
> *Sent:* Wednesday, October 19, 2022 9:40:21 PM
> *To:* jallib 
> *Subject:* Re: [jallib] Re: PICKit3 programmer question.
>
> It should be noted that the PICKits also program "LF" devices.  So,
> programming at 3.3V should not be a problem.  Do brownout settings have to
> be changed?
>
> Regards,
> Mike
>
>
> On Wednesday, October 19, 2022 at 1:45:42 PM UTC-4 rob...@hotmail.com
> wrote:
>
> Hello all,
>
> Thanks for your answers so it is save to run the PIC (and the rest) on 3.3
> Volt and program the PIC in-circuit with my PICkit3.
>
> I will give it a try since it saves me a lot of level shift connections
> and wires on the breadboard.
>
> Thanks again.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jal...@googlegroups.com  namens vsurducan
> 
> *Verzonden:* woensdag 19 oktober 2022 06:07
> *Aan:* jal...@googlegroups.com 
> *Onderwerp:* Re: [jallib] Re: PICKit3 programmer question.
>
> Pickit2/Pickit2+ (Evan's firmware/software) works ok as you described. I
> guess will be no issue on Pickit3 either.
> best wishes,
>
> On Wed 19 Oct 2022, 6:16 AM Matthew Schinkel 
> I use PICKit3 ICSP with a 3.3v circuit. I haven't had any problems.
>
> Matt.
>
> On Tuesday, October 18, 2022 at 1:25:36 PM UTC-4 rob...@hotmail.com wrote:
>
> Hi all,
>
> I have a question about a PICKit3 programmer. Instead of trying it out and
> blowing up my programmer I thought I ask you.
>
> I often have a device that operates at 3.3. Volt and the PIC running at 5
> Volt. I use level shifters to get then connected. I program my PIC
> in-circuit so I do not remove it from the breadboard.
>
> I can run the PIC at 3.3. Volt so that I do no longer need any level
> shifters.
>
> My question is the following. Can I reprogram my PIC in-circuit when it is
> running at 3.3 Volt or will I kill the PIC?
>
> Are there any issues I should take into account, e.g. only use Low Voltage
> Programming or 'do not try this at all!'?
>
> 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/e81b2f33-7232-490e-becf-ae84d3585c0en%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/e81b2f33-7232-490e-becf-ae84d3585c0en%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsBjavKTpAmw2PohBBEQv_0MDKRftPeRFZnfio1ua0%2BKA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsBjavKTpAmw2PohBBEQv_0MDKRftPeRFZnfio1ua0%2BKA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/84124dfe-ebc8-4696-8f7c-c3fe29a663e7n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/84124dfe-ebc8-4696-8f7c-c3fe29a663e7n%40

Re: [jallib] Re: PICKit3 programmer question.

[vsurducan]

Pickit2/Pickit2+ (Evan's firmware/software) works ok as you described. I
guess will be no issue on Pickit3 either.
best wishes,

On Wed 19 Oct 2022, 6:16 AM Matthew Schinkel  I use PICKit3 ICSP with a 3.3v circuit. I haven't had any problems.
>
> Matt.
>
> On Tuesday, October 18, 2022 at 1:25:36 PM UTC-4 rob...@hotmail.com wrote:
>
>> Hi all,
>>
>> I have a question about a PICKit3 programmer. Instead of trying it out
>> and blowing up my programmer I thought I ask you.
>>
>> I often have a device that operates at 3.3. Volt and the PIC running at 5
>> Volt. I use level shifters to get then connected. I program my PIC
>> in-circuit so I do not remove it from the breadboard.
>>
>> I can run the PIC at 3.3. Volt so that I do no longer need any level
>> shifters.
>>
>> My question is the following. Can I reprogram my PIC in-circuit when it
>> is running at 3.3 Volt or will I kill the PIC?
>>
>> Are there any issues I should take into account, e.g. only use Low
>> Voltage Programming or 'do not try this at all!'?
>>
>> 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/e81b2f33-7232-490e-becf-ae84d3585c0en%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%2Bj4qsBjavKTpAmw2PohBBEQv_0MDKRftPeRFZnfio1ua0%2BKA%40mail.gmail.com.

Re: [jallib] exit of master/slave?

[vsurducan]

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* to *spi_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 H*amerling, 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+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 to jallib+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
>>
>> --
>> 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/CABsDq%3D-k7Zxa%3D0YqALyetLkrPnjKY0P_PZMypzS%3DTDA1ik0Mdg%40mail.gmail.com
>> 
>> .
>>
> --
> 

Re: [jallib] Re: Which programmer ?

[vsurducan]

There isn't anything for free in this world, including jal.

On Tue, Oct 4, 2022 at 8:40 PM 'Mike' via jallib 
wrote:

> And you took the good work that Microchip did, which they made available
> to the public for free.  :)
>
> On Tuesday, October 4, 2022 at 8:52:46 AM UTC-4 evan@googlemail.com
> wrote:
>
>> Please pay for PICKITPLUS. We develop the solution and others copy our
>> good works.
>>
>> We provide support and maintenance.
>>
>> Evan
>>
>> Get Outlook for Android 
>> --
>> *From:* 'Mike' via jallib 
>> *Sent:* Tuesday, October 4, 2022 1:25:16 PM
>> *To:* jallib 
>> *Subject:* [jallib] Re: Which programmer ?
>>
>> The PICKitPlus (pay) and PICKitMinus (free) projects allow using a PK2
>> (and I think PK3?) to program newer PIC's.  If that's what you're asking?
>>
>> Regards,
>> Mike
>>
>>
>> On Tuesday, October 4, 2022 at 6:40:57 AM UTC-4 pinhe...@gmail.com wrote:
>>
>>
>> Hi all,
>> My ICD2 stopped working, thanks to Windows 11 
>> Fortunately, I have other programmers at hand, including a PicKit3,
>> PicKit4 , and a TL866 Minipro.
>>
>> I wonder if someone knows a way to use the Minipro TL866 from a command
>> line.   This would allow to program a chip directly from JalEdit.
>> I found such a tool online, but it is limited to Linux
>>
>> I prefer to use MiniPro TL866 whenever possible, but if someone knows of
>> a way to do the same with a PicKit 3 or PicKit 4, that would be great also !
>>
>> Thanks a lot
>>
>> --
>> 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/a0169fec-a3c1-46ac-9175-88cc63426df8n%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/269ae49b-66d3-4005-abf0-1a1766514362n%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%2Bj4qtCgK48k0a1Vd%3DAXBmZmcdisgaTCwqAVJNPjVFxaeo0Ew%40mail.gmail.com.

Re: [jallib] Re: 18F4520 interrupt

[vsurducan]

Well, from 102-103 it seems it should work on RB4... try the following
pseudocode.
Pin B4 must be set as input and toggled by your hardware.

RCON_IPEN = low ; low priority interrupt,
INTCON_GIE = high   ; enable global interrupts
INTCON_PEIE_GIEL = high  ; enable pheripheral interrupts
INTCON_RBIE = high  ; enable interrupts on change on port B4-B7
var byte MY_data = 0

procedure IOC() is
 pragma interrupt
 if INTCON_RBIF then
MY_data = port_B
-- from datasheet page 87: a mismatch condition will continue to set this
bit. Reading PORTB will end the mismatch condition and allow the bit to be
cleared
MY_bit = pin_B4
INTCON_RBIF = low
 end if
end procedure

forever loop
LED = MY_bit
end loop





On Sun, Sep 25, 2022 at 7:59 PM hans  wrote:

> Hi Vasile,
> I've tried to understand page 103, but I shouldn't have. Anyway, an
> adjustment to my PCB and we happily continue. (to bed on time tonight)
> Thanks for all your responses
> Hans
>
> Op zondag 25 september 2022 om 10:43:11 UTC+2 schreef vasile:
>
>> I guess nothing can be done. This pic (if I don't miss anything) has
>> three interrupts on B0, B1 and B2. I don't see any PPS module. BTW I
>> thought seniors are starting at 3am and sleep at midnight...
>>
>> On Sun 25 Sep 2022, 10:27 AM hans >
>>> Hi Vasile,
>>> I had pull down on the input, set the pin 5,6 and 7 to output etc
>>> At Mid night I have changed the input from B4 to B0 and now it works
>>> perfect. So what to do if i want to use B4 ??
>>> regards
>>> Hans
>>>
>>> Op zondag 25 september 2022 om 08:08:08 UTC+2 schreef vasile:
>>>
 Hi Hans,
 This the way INT1 worked for me on PIC18F26J50, I think your PIC is
 more or less the same, however each PIC has its own stupidity, so it might
 not work as expected...

 You might want to set the pull-up resistor on your INT pin ( or not, as
 your schematic requires).
 If you are not using dedicated INT pin and your PIC micro has the
 stupid PPS relocation, it will be additional headache, so check all of
 these...
 good luck!

 -- ---interrupt of change
 IOC---
 var bit MY_flag = low
 procedure IOC() is
  pragma interrupt
  if INTCON3_INT1IF then
 MY_flag = high
 INTCON3_INT1IF = low
  end if
 end procedure

 RCON_IPEN = low ; low priority interrupt, PIC16 compatibility
 INTCON_GIE = high   ; enable global interrupts
 INTCON_PEIE_GIEL = high  ; enable pheripheral interrupts
 INTCON3_INT1IE = high; enable INT1 on pin_RB5
 INTCON2_INTEDG1 = high   ; enable interrupt on rising edge


 forever loop
 -- use MY_flag for whatever
 -- reset MY_flag
 end loop


 On Sat, Sep 24, 2022 at 9:33 PM hans  wrote:

> Hi Rob,
> I did with the attached file in another pcd-set with no other things.
> The led wichh gives the pulses show a regular (1 sec) blink but the output
> from the interrupt goes on and something off.
> Hans
>
> Op zaterdag 24 september 2022 om 20:04:23 UTC+2 schreef
> rob...@hotmail.com:
>
>> Hi Hans,
>>
>> I see that this PIC has interrupts with prioirities.
>>
>> Since you only use interrupt 0 as a regular interrupt can you change
>> this (make FALSE instead of TRUE):
>>
>> INTCON_PEIE = FALSE
>>
>> If I look in the schematic diagram of the datahseet, setting this to
>> TRUE enables the other priority interrupt vector but it does not have any
>> effect on INT0.
>>
>> Not sure if it helps but you can give it a try.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens hans
>> 
>> *Verzonden:* zaterdag 24 september 2022 19:19
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Re: 18F4520 interrupt
>>
>> My last try. Loaded in another set. On the output from A 1 shows a
>> led a steady on/off. So also at the entrance of B4. The led on A0 flashes
>> very fast but there is no connection with the input
>>
>> Op zaterdag 24 september 2022 om 10:39:51 UTC+2 schreef hans:
>>
>> Hi Rob,
>> I did already but no result. A led in the interrupt and one on the
>> pinB4. The last one shows the action but the led inside teh pragme not.
>>  I have now made an procedure which i am calling on several places in
>> my program and it worked.
>> procedure DTMF_receive is
>>if portD_low != DTMF_old then
>>  DTMF = portD_low
>>end if
>>  end procedure
>>
>> Op zaterdag 24 september 2022 om 09:45:51 UTC+2 schreef
>> rob...@hotmail.com:
>>
>> Hi Hans,
>>
>> The code looks OK. Maybe as a test you can activate a LED in the
>> interrupt routine to check if it gets there.
>>
>> 

Re: [jallib] Re: 18F4520 interrupt

[vsurducan]

I guess nothing can be done. This pic (if I don't miss anything) has three
interrupts on B0, B1 and B2. I don't see any PPS module. BTW I thought
seniors are starting at 3am and sleep at midnight...

On Sun 25 Sep 2022, 10:27 AM hans  Hi Vasile,
> I had pull down on the input, set the pin 5,6 and 7 to output etc
> At Mid night I have changed the input from B4 to B0 and now it works
> perfect. So what to do if i want to use B4 ??
> regards
> Hans
>
> Op zondag 25 september 2022 om 08:08:08 UTC+2 schreef vasile:
>
>> Hi Hans,
>> This the way INT1 worked for me on PIC18F26J50, I think your PIC is more
>> or less the same, however each PIC has its own stupidity, so it might not
>> work as expected...
>>
>> You might want to set the pull-up resistor on your INT pin ( or not, as
>> your schematic requires).
>> If you are not using dedicated INT pin and your PIC micro has the stupid
>> PPS relocation, it will be additional headache, so check all of these...
>> good luck!
>>
>> -- ---interrupt of change
>> IOC---
>> var bit MY_flag = low
>> procedure IOC() is
>>  pragma interrupt
>>  if INTCON3_INT1IF then
>> MY_flag = high
>> INTCON3_INT1IF = low
>>  end if
>> end procedure
>>
>> RCON_IPEN = low ; low priority interrupt, PIC16 compatibility
>> INTCON_GIE = high   ; enable global interrupts
>> INTCON_PEIE_GIEL = high  ; enable pheripheral interrupts
>> INTCON3_INT1IE = high; enable INT1 on pin_RB5
>> INTCON2_INTEDG1 = high   ; enable interrupt on rising edge
>>
>>
>> forever loop
>> -- use MY_flag for whatever
>> -- reset MY_flag
>> end loop
>>
>>
>> On Sat, Sep 24, 2022 at 9:33 PM hans  wrote:
>>
>>> Hi Rob,
>>> I did with the attached file in another pcd-set with no other things.
>>> The led wichh gives the pulses show a regular (1 sec) blink but the output
>>> from the interrupt goes on and something off.
>>> Hans
>>>
>>> Op zaterdag 24 september 2022 om 20:04:23 UTC+2 schreef
>>> rob...@hotmail.com:
>>>
 Hi Hans,

 I see that this PIC has interrupts with prioirities.

 Since you only use interrupt 0 as a regular interrupt can you change
 this (make FALSE instead of TRUE):

 INTCON_PEIE = FALSE

 If I look in the schematic diagram of the datahseet, setting this to
 TRUE enables the other priority interrupt vector but it does not have any
 effect on INT0.

 Not sure if it helps but you can give it a try.

 Kind regards,

 Rob

 --
 *Van:* jal...@googlegroups.com  namens hans <
 hanz...@zeelandnet.nl>
 *Verzonden:* zaterdag 24 september 2022 19:19

 *Aan:* jallib 
 *Onderwerp:* Re: [jallib] Re: 18F4520 interrupt

 My last try. Loaded in another set. On the output from A 1 shows a led
 a steady on/off. So also at the entrance of B4. The led on A0 flashes very
 fast but there is no connection with the input

 Op zaterdag 24 september 2022 om 10:39:51 UTC+2 schreef hans:

 Hi Rob,
 I did already but no result. A led in the interrupt and one on the
 pinB4. The last one shows the action but the led inside teh pragme not.
  I have now made an procedure which i am calling on several places in
 my program and it worked.
 procedure DTMF_receive is
if portD_low != DTMF_old then
  DTMF = portD_low
end if
  end procedure

 Op zaterdag 24 september 2022 om 09:45:51 UTC+2 schreef
 rob...@hotmail.com:

 Hi Hans,

 The code looks OK. Maybe as a test you can activate a LED in the
 interrupt routine to check if it gets there.

 What exactly the behaviour?

 Kind regards,

 Rob

 --
 *Van:* jal...@googlegroups.com  namens hans <
 hanz...@zeelandnet.nl>
 *Verzonden:* zaterdag 24 september 2022 08:33
 *Aan:* jallib 
 *Onderwerp:* Re: [jallib] Re: 18F4520 interrupt

 I have changed the program part as follows from the example port B0 ,
 compiling is ok but no result

 -- alias the interrupt flags so they are readable.
 alias INT_0_ENABLE_BIT is INTCON_INT0IE
 alias INT_0_FLAG_BIT is INTCON_INT0IF
 alias INT_0_EDGE_BIT is INTCON2_INTEDG0

 -- enable global interrupts
 INTCON_GIE  = TRUE-- Enables all unmasked interrupts
 INTCON_PEIE = TRUE-- Enables all unmasked peripheral interrupts

 -- define your interrupt pin
 alias interrupt_pin is pin_B4
 alias interrupt_pin_direction is pin_B4_direction
 interrupt_pin_direction = INPUT -- interrupt pin is input
 INT_0_ENABLE_BIT = TRUE   -- interrupt pin enable bit for B0
 procedure int_on_change_b0() -- procedure is written later

 -- main interrupt handler
 procedure interrupt() is
pragma interrupt
-- Check if interrupt pin 0 (B0) has an 

Re: [jallib] Re: 18F4520 interrupt

[vsurducan]

Hi Hans,
This the way INT1 worked for me on PIC18F26J50, I think your PIC is more or
less the same, however each PIC has its own stupidity, so it might not work
as expected...

You might want to set the pull-up resistor on your INT pin ( or not, as
your schematic requires).
If you are not using dedicated INT pin and your PIC micro has the stupid
PPS relocation, it will be additional headache, so check all of these...
good luck!

-- ---interrupt of change
IOC---
var bit MY_flag = low
procedure IOC() is
 pragma interrupt
 if INTCON3_INT1IF then
MY_flag = high
INTCON3_INT1IF = low
 end if
end procedure

RCON_IPEN = low ; low priority interrupt, PIC16 compatibility
INTCON_GIE = high   ; enable global interrupts
INTCON_PEIE_GIEL = high  ; enable pheripheral interrupts
INTCON3_INT1IE = high; enable INT1 on pin_RB5
INTCON2_INTEDG1 = high   ; enable interrupt on rising edge


forever loop
-- use MY_flag for whatever
-- reset MY_flag
end loop


On Sat, Sep 24, 2022 at 9:33 PM hans  wrote:

> Hi Rob,
> I did with the attached file in another pcd-set with no other things. The
> led wichh gives the pulses show a regular (1 sec) blink but the output from
> the interrupt goes on and something off.
> Hans
>
> Op zaterdag 24 september 2022 om 20:04:23 UTC+2 schreef rob...@hotmail.com
> :
>
>> Hi Hans,
>>
>> I see that this PIC has interrupts with prioirities.
>>
>> Since you only use interrupt 0 as a regular interrupt can you change this
>> (make FALSE instead of TRUE):
>>
>> INTCON_PEIE = FALSE
>>
>> If I look in the schematic diagram of the datahseet, setting this to TRUE
>> enables the other priority interrupt vector but it does not have any effect
>> on INT0.
>>
>> Not sure if it helps but you can give it a try.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens hans <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* zaterdag 24 september 2022 19:19
>>
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Re: 18F4520 interrupt
>>
>> My last try. Loaded in another set. On the output from A 1 shows a led a
>> steady on/off. So also at the entrance of B4. The led on A0 flashes very
>> fast but there is no connection with the input
>>
>> Op zaterdag 24 september 2022 om 10:39:51 UTC+2 schreef hans:
>>
>> Hi Rob,
>> I did already but no result. A led in the interrupt and one on the pinB4.
>> The last one shows the action but the led inside teh pragme not.
>>  I have now made an procedure which i am calling on several places in my
>> program and it worked.
>> procedure DTMF_receive is
>>if portD_low != DTMF_old then
>>  DTMF = portD_low
>>end if
>>  end procedure
>>
>> Op zaterdag 24 september 2022 om 09:45:51 UTC+2 schreef
>> rob...@hotmail.com:
>>
>> Hi Hans,
>>
>> The code looks OK. Maybe as a test you can activate a LED in the
>> interrupt routine to check if it gets there.
>>
>> What exactly the behaviour?
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens hans <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* zaterdag 24 september 2022 08:33
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] Re: 18F4520 interrupt
>>
>> I have changed the program part as follows from the example port B0 ,
>> compiling is ok but no result
>>
>> -- alias the interrupt flags so they are readable.
>> alias INT_0_ENABLE_BIT is INTCON_INT0IE
>> alias INT_0_FLAG_BIT is INTCON_INT0IF
>> alias INT_0_EDGE_BIT is INTCON2_INTEDG0
>>
>> -- enable global interrupts
>> INTCON_GIE  = TRUE-- Enables all unmasked interrupts
>> INTCON_PEIE = TRUE-- Enables all unmasked peripheral interrupts
>>
>> -- define your interrupt pin
>> alias interrupt_pin is pin_B4
>> alias interrupt_pin_direction is pin_B4_direction
>> interrupt_pin_direction = INPUT -- interrupt pin is input
>> INT_0_ENABLE_BIT = TRUE   -- interrupt pin enable bit for B0
>> procedure int_on_change_b0() -- procedure is written later
>>
>> -- main interrupt handler
>> procedure interrupt() is
>>pragma interrupt
>>-- Check if interrupt pin 0 (B0) has an interrupt.
>>if INT_0_FLAG_BIT then
>>   DTMF = portD_low
>>   INT_0_FLAG_BIT = FALSE -- reset interrupt flag
>>end if
>> end procedure
>>
>> a led on the interrupt pin B4 shows the short blink as soon as a dtmf
>> tone is received. The received value remains on portD-low untill the next
>> tone. So i can read it afterwards. My idea was to wait some time before
>> reading the port.
>>
>> Op zaterdag 24 september 2022 om 08:08:47 UTC+2 schreef hans:
>>
>> Here is how i have started and having no reslut i did the (wrong??)
>> chnages
>>
>> -- choose pins to use for int on change
>> const byte int_on_change_pins[] = {"B",4}
>> include interrupt_on_change
>> int_on_change_init()
>>
>> -- interrupt for pin B4
>> procedure int_on_change_callback_0() is
>>   pragma inline
>>DTMF = portD_low
>> end 

Re: [jallib] Re: 18F4520 interrupt

[vsurducan]

Hans,
I do not see any "pragma interrupt",  it's that OK?
An interrupt procedure needs it no matter the name it has, without it there
would be no jump to the ISR interrupt vector.

This line looks strange to me here (but I'm not a master of programming):
const byte int_on_change_pins[] = {"B",4}

BTW, you do not want to use a software delay in an ISR routine, an ISR must
be fast by definition because it consumes a period of time which is lost in
the main loop. Exceptions for hardware resources of which programming time
do not interfere too much with the main loop. Check if your pic has
registers to detect which edge is used on interrupt on change. If yes you
should program those too.

I hope these would be helpful. In my opinion you should solve the problem
by yourself, is the only way you can understand.


On Sat, Sep 24, 2022 at 8:03 AM Matthew Schinkel 
wrote:

> Hi Hans, without me testing or knowing the DTMF module your using. I think
> it looks ok. It should be easy to test.
>
> Just to make your code easier to read I would alias the pins and
> directions to useful names. You read code 10 times more than you write it.
> I don't know what pin_C3 is for, and pin_C3_direction isn't being set.
>
> Looks like your code will wait for an interrupt on pin_B4 then read the
> lower 4 bits of portd
>
> If the original sample works for you, you can add a sample for 18F4520.
> The library may need to be modified to support more chips.
>
> Matt.
>
> On Friday, September 23, 2022 at 12:44:59 PM UTC-4 hans wrote:
>
>> The basic file:
>>
>>   include 18f4520 -- target PICmicro
>> --
>> -- This program uses the internal oscillator at 4 MHz.
>> pragma target clock4_000_000   -- oscillator frequency
>> --
>> pragma target OSC  INTOSC_NOCLKOUT   -- internal oscillator
>> pragma target WDT  CONTROL   -- watchdog
>> pragma target XINSTDISABLED  -- do not use extended
>> instructionset
>> pragma target DEBUGDISABLED  -- no debugging
>> pragma target BROWNOUT DISABLED  -- no brownout reset
>> pragma target FCMENDISABLED  -- no clock monitoring
>> pragma target IESO DISABLED  -- no int/ext osc
>> switching
>> pragma target LVP  DISABLED   -- 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 WDT
>> OSCCON_SCS = 0  -- select primary oscillator
>> OSCCON_IRCF = 0b110 -- 4 MHz
>> OSCTUNE_PLLEN = FALSE   -- no PLL
>> --
>> enable_digital_io() -- make all pins digital I/O
>> --
>>
>> -- DTMF programma
>> pin_D0_direction   = input
>> pin_D1_direction   = input
>> pin_D2_direction   = input
>> pin_D3_direction   = input
>> pin_B4_direction   = input -- for interrupt
>>
>>
>> var byte DTMF
>>
>>
>> -- choose pins to use for int on change
>> const byte int_on_change_pins[] = {"B",4}
>> include interrupt_on_change
>> int_on_change_init()
>>
>> -- interrupt for pin B4
>> procedure int_on_change_callback_0() is
>>pragma inline
>>pin_C3 = low
>>delay_1mS(400)
>>DTMF = portD_low
>>pin_C3 = high
>> end procedure
>>
>>
>> Op vrijdag 23 september 2022 om 14:59:53 UTC+2 schreef hans:
>>
>>> Hello,
>>> I am trying to read a DTMF module with an interrupt on a 18F4520.pin B4.
>>> I found something in the examples. Is thissufficient and  correct? Direct
>>> reading of portD_low is working correct.
>>>
>>> -- choose pins to use for int on change
>>> const byte int_on_change_pins[] = {"B",4}
>>> include interrupt_on_change
>>> int_on_change_init()
>>>
>>> -- interrupt for pin B4
>>> procedure int_on_change_callback_0() is
>>>pragma inline
>>>delay_1mS(400)
>>>DTMF = portD_low
>>> end procedure
>>> 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/df18aa34-b7fc-4d5d-bfe5-65e1a4b741d9n%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%2Bj4qsV6cc%2BBMLRvUGoXT2Jti9qa6DySc8Gsu3ajQ2Qt5mg_g%40mail.gmail.com.

Re: [jallib] Atmega programming

[vsurducan]

AFIK pony works ok on Win7. Serial programmer which steals energy from
RS232 port works OK on any computer with true RS232 interface. Perhaps an
old $30 single core computer?


On Thu, Sep 22, 2022 at 9:03 AM hans  wrote:

> I've been honoring an XP and the ancient Pony program for a long time, but
> the XP has given up the ghost. The Lunaavr program always indicates that it
> cannot find an avr config while everything is in the total folder.
> According to the builder, he has no more time to make an update... so
>
> Op donderdag 22 september 2022 om 06:18:29 UTC+2 schreef vasile:
>
>> One old laptop with win7 + one old and well known programmer?
>> Or pickit4 and a bunch of money.
>>
>> On Wed, Sep 21, 2022 at 8:44 PM hans  wrote:
>>
>>> Hi Vasi,
>>> I dont have an Arduino and the Luna Studio downloaded reports errors.
>>> I'll try to find out more.
>>> regards
>>> Hans
>>>
>>> Op woensdag 21 september 2022 om 18:02:45 UTC+2 schreef funlw65(Vasi):
>>>

 https://adduino.com/upload-hex-file-on-arduino-using-avrdude-programming-avr-boards/

 On Wed, Sep 21, 2022 at 6:35 PM vasi vasi  wrote:

> Fast answer, inside LunaAVR product (Luna Studio for AVR), you have a
> avrdude graphical interface...
> http://avr.myluna.de/
>
> Also, here you have a GUI for avrdude (you can use an Arduino as an
> ISP programmer - it is a ino sketch delivered with arduino)
> https://github.com/ZakKemble/AVRDUDESS
>
> Video tutorial as how you use an Arduino as a programmer:
> https://www.youtube.com/watch?v=muP1dp73Mdg
>


 --
 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+un...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jallib/a45fc226-5504-45a0-b198-4e7823677e53n%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/df146901-ec5a-43d8-83bd-3d1d92e617d1n%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%2Bj4qs%2BC2m7KbU3tS0fuUs3_tk8FqRH8mDN5o3zW8jj56brJA%40mail.gmail.com.

Re: [jallib] Atmega programming

[vsurducan]

One old laptop with win7 + one old and well known programmer?
Or pickit4 and a bunch of money.

On Wed, Sep 21, 2022 at 8:44 PM hans  wrote:

> Hi Vasi,
> I dont have an Arduino and the Luna Studio downloaded reports errors. I'll
> try to find out more.
> regards
> Hans
>
> Op woensdag 21 september 2022 om 18:02:45 UTC+2 schreef funlw65(Vasi):
>
>>
>> https://adduino.com/upload-hex-file-on-arduino-using-avrdude-programming-avr-boards/
>>
>> On Wed, Sep 21, 2022 at 6:35 PM vasi vasi  wrote:
>>
>>> Fast answer, inside LunaAVR product (Luna Studio for AVR), you have a
>>> avrdude graphical interface...
>>> http://avr.myluna.de/
>>>
>>> Also, here you have a GUI for avrdude (you can use an Arduino as an ISP
>>> programmer - it is a ino sketch delivered with arduino)
>>> https://github.com/ZakKemble/AVRDUDESS
>>>
>>> Video tutorial as how you use an Arduino as a programmer:
>>> https://www.youtube.com/watch?v=muP1dp73Mdg
>>>
>>
>>
>> --
>> 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/a45fc226-5504-45a0-b198-4e7823677e53n%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%2Bj4qtJipx_004GEF3ieMvxM9rGBinYJG-b7%3D%3DprYxatyawMQ%40mail.gmail.com.

Re: [jallib] Help on 12bit ADC for PIC18F2523

[vsurducan]

congrats, but it still be simplified a bit...:)

On Wed 14 Sep 2022, 5:40 PM flyway38  Hey all,
>
> Problem solved. Had to redo all ADC code.
> Here is the working code. Maybe this is usefull for the coders here;
>
> -- ok, now let's configure ADC
> pin_AN0_direction = input
> -- ADCON0 CONFIG
> ADCON0_CHS0 = OFF -- Channel at 0 (Bit 0)
> ADCON0_CHS1 = OFF -- Channel at 0 (Bit 1)
> ADCON0_CHS2 = OFF -- Channel at 0 (Bit 2)
> ADCON0_CHS3 = OFF -- Channel at 0 (Bit 3)
> -- ADCON1 CONFIG
> ADCON1_PCFG0 = OFF -- AN0 as Analog ONLY (Bit 0)
> ADCON1_PCFG1 = ON  -- AN0 as Analog ONLY (Bit 1)
> ADCON1_PCFG2 = ON  -- AN0 as Analog ONLY (Bit 2)
> ADCON1_PCFG3 = ON  -- AN0 as Analog ONLY (Bit 3)
> ADCON1_VCFG0 = OFF -- Vref+ at VDD
> ADCON1_VCFG1 = OFF -- Vref- at VSS
> -- ADCON2 CONFIG
> ADCON2_ADCS0 = OFF -- AD Conversion Clock at Fosc/64 (Bit 0)
> ADCON2_ADCS1 = ON  -- AD Conversion Clock at Fosc/64 (Bit 1)
> ADCON2_ADCS2 = ON  -- AD Conversion Clock at Fosc/64 (Bit 2)
> ADCON2_ACQT0 = ON  -- AD Acq. Time at 2xTAD (Bit 0)
> ADCON2_ACQT1 = OFF -- AD Acq. Time at 2xTAD (Bit 1)
> ADCON2_ACQT2 = OFF -- AD Acq. Time at 2xTAD (Bit 2)
> ADCON2_ADFM = ON   -- AD Result Justify at Right
> --
> const word ADC_RSOURCE = 2_500-- Input Resistance
> const byte ADC_TEMP = 85  -- PIC Max.
> Temperature
> const byte ADC_MAX_TAD = 6-- (0.8us < TAD <
> 12.5us as per
> --Datasheet, Pag.
> 41)
> -- AD ACQUISITION TIME (Original VAR: adc_conversion_delay)
> -- Tacq = Tamp + Tc + Tcoff
> const word tamp = 1 -- (=> 0.2us as per Datasheet, Pag. 30)
> const word adc_tc = 2 -- ((TEMP – 25°C)x(0.02 us/°C) => 1.2us as per
> Datasheet, Pag. 30))
> const word adc_tcoff = 2 -- (-(25 pF)x(1 kohm + 4 kohm +
> RSOURCE)xln(0.0004883)
> --  => 1.56us as per Datasheet, Pag. 30)
> const byte ADC_TACQ = byte(tamp + adc_tc + adc_tcoff)
> -- (Original VAR: adc_conversion_delay)
> --
> var word adc_word   -- return value
> var byte adc_byte[2] at adc_word-- byte array overlay
> --
> function adc_read_high_res(byte in adc_chan) return word is
> pragma inline
>--
>-- Original Code has here the Channel and L/R Justifying
>--  These parameters are set above...
>   --
>   ADCON0_ADON = TRUE  -- turn on ADC module
>--
>for ADC_TACQ loop
>   _usec_delay(1)  -- wait acquisition time
>   -- Original: _usec_delay(10)
>end loop
>--
>ADCON0_GO = TRUE-- start conversion
>while ADCON0_GO == TRUE loop-- wait until
> conversion completed
>   -- Empty loop.
>end loop
>--
>adc_byte[1] = ADRESH -- copy high order bits
>adc_byte[0] = ADRESL -- copy low order bits
>-- Choosed High Resolution options here, from Original Code...
>--
>-- Honor 2 * max Tad time. Note the value is not very accurate, but
> safe.
>_usec_delay(2 * ADC_MAX_TAD) -- As per Datasheet, Pag. 29
>--
>ADCON0_ADON = false -- turn off ADC module
>return adc_word -- back to caller
> end function
>
> Best regrads,
> FS
>
> On Wednesday, September 14, 2022 at 1:43:19 PM UTC+1 flyway38 wrote:
>
>> Hello Vasile,
>>
>> Thank you for your input.
>> About Vref it should be set to VCC (5V) and GND. It's the default anyways
>> (by the Datasheet info).
>> Have, however, noticed that the ADC initial configuration constants don't
>> match with the needed ones.
>> EX: ANSEL_ADCS, ADCON0_VCFG, ANSEL_ANS0, etc.. aren't used in ADC lib or
>> even in PIC(18F2523) lib.
>>
>> About convertion time and MAX_TAD, have already tested longer time values
>> with no sucess...
>> Any more ideas?
>> Thanks anyways.
>>
>> Cheers,
>> Filipe Santos.
>>
>> On Wednesday, September 14, 2022 at 12:57:26 PM UTC+1 vasile wrote:
>>
>>> If your Vref + is +5V and Vref- is GND, full scale means 4095 at 5V.
>>> One issue might appear if acquisition time is too short or you have
>>> messed something with references.
>>> |Vref+| - |Vref-| >=3V
>>>
>>> On Tue, Sep 13, 2022 at 4:54 PM flyway38  wrote:
>>>
 Hello all,

 New question.
 My PIC is reading ok ADC values if below 2.5V (1/2 of range VCC/GND).
 It seems like 11bit ADC behaviour.

 My code:
 -- ok, now let's configure ADC
 -- Step 1: ADC analog input pin setup
 const byte ADC_CHANNEL = 0   -- port 0 is analog
 input (default)
 pin_AN0_direction = input
 const byte ANSEL_ANS0 = TRUE -- potmeter connected
 to pin_AN0
 -- Step 2: Set VDD and VSS as Vref
 const byte ADCON0_VCFG = FALSE
 -- Step 3: Use Frc as ADC clock
 const byte ANSEL_ADCS = 0b110
 --
 const ADC_RSOURCE = 500   

Re: [jallib] Help on 12bit ADC for PIC18F2523

[vsurducan]

If your Vref + is +5V and Vref- is GND, full scale means 4095 at 5V.
One issue might appear if acquisition time is too short or you have messed
something with references.
|Vref+| - |Vref-| >=3V

On Tue, Sep 13, 2022 at 4:54 PM flyway38  wrote:

> Hello all,
>
> New question.
> My PIC is reading ok ADC values if below 2.5V (1/2 of range VCC/GND).
> It seems like 11bit ADC behaviour.
>
> My code:
> -- ok, now let's configure ADC
> -- Step 1: ADC analog input pin setup
> const byte ADC_CHANNEL = 0   -- port 0 is analog input
> (default)
> pin_AN0_direction = input
> const byte ANSEL_ANS0 = TRUE -- potmeter connected to
> pin_AN0
> -- Step 2: Set VDD and VSS as Vref
> const byte ADCON0_VCFG = FALSE
> -- Step 3: Use Frc as ADC clock
> const byte ANSEL_ADCS = 0b110
> --
> const ADC_RSOURCE = 500  -- Input Resistance
> const ADC_TEMP = 20  -- PIC Temperature
> -- We want the fastest possible ADC timing, so we specify here the
> --const ADC_MIN_TAD = 1
> const ADC_MAX_TAD = 10
> -- Now we can include the library
> include adc
> -- And initialize the whole with our parameters
> adc_init()
>
> Inside Forever Loop:
>iVal = 0 -- Its a DWord
>--
>for AdcReadings loop
>   AdcData = adc_read_high_res(AdcChnn)
>   iVal = iVal + dword(AdcData)
>end loop
>--
>mVal = word(iVal / dword(AdcReadings))
>
> Any help would be great.
> Thank you very much.
>
> Kind regrads,
> 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/5c020fb1-f8fa-4684-9284-1dc3a1793ca4n%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%2Bj4qsF_eamLFEKX07BT32tjCFNWkkVptnjmDnijcQRmnhHKg%40mail.gmail.com.

Re: [jallib] Code does no longer work when program size increases using mutiplication?

[vsurducan]

Stacks looks goodCan you resize the picture (or even to cut from it) to
fit in a smaller memory bank number? I'm saying to cut it bank by bank from
22787 down. You have to catch the bank border on one cut.  If the problem
persist no matter the size of the picture, then is not a bank allocation
issue but something else...I do not have other idea until I'll play with
your display driver. Thx.

On Sat 10 Sep 2022, 1:38 PM Rob CJ  Hi Vasile,
>
> I do not see much difference in the stack here.
>
> *Compiled witout picture:*
> jal jalv25r6 (compiled Oct 29 2021)
> generating p-code
> 16680 tokens, 581504 chars; 11716 lines; 18 files
> generating PIC code pass 1
> generating PIC code pass 2
> 312 branches checked, 0 errors
> 1775 data accesses checked, 0 errors
> 192 skips checked, 0 errors
> writing result
> Code area: 6645 of 32768 used (words)
> Data area: 222 of 4096 used
> Software stack available: 80 bytes
> Hardware stack depth 7 of 16
> 0 errors, 0 warnings
>
> *Compiled with picture:*
> jal jalv25r6 (compiled Oct 29 2021)
> generating p-code
> 16670 tokens, 581507 chars; 11716 lines; 18 files
> generating PIC code pass 1
> generating PIC code pass 2
> 328 branches checked, 0 errors
> 1901 data accesses checked, 0 errors
> 197 skips checked, 0 errors
> writing result
> Code area: 22787 of 32768 used (words)
> Data area: 229 of 4096 used
> Software stack available: 80 bytes
> Hardware stack depth 7 of 16
> 0 errors, 0 warnings
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* zaterdag 10 september 2022 06:11
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Code does no longer work when program size
> increases using mutiplication?
>
> Hi Rob, if you look after each compilation to software stack and hardware
> stack numbers perhaps you may see important differences between numbers
> when code is ok and not. I've seen something similar near HW stack fill,
> but this is dificult to debug. It looks like a jump elswere that it
> shuld...I guess interrupts are disabled in your test code.
>
> On Fri 9 Sep 2022, 8:13 PM Rob CJ 
> Hi Vasile,
>
> It sometimes goes into reset but sometimes it just hangs.It is
> unpredictable so I assume that it runs somewhere out of a range that it
> should not.
>
> How could I check the stack length?
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* vrijdag 9 september 2022 07:03
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Code does no longer work when program size
> increases using mutiplication?
>
> Rob, can you check also the stack length when pic goes in loop reset?
>
> On Thu 8 Sep 2022, 9:00 PM rob...@hotmail.com 
> Hi all,
>
> I have the following strange problem. I am working on the ILI9341 library
> and the graphics was staring to work but I could not manage to write text
> to the screen. When I tried that the PIC went haywire and sometimes came
> into some kind of constant reset state.
>
> By accident I discovered that it had to do with the size of the program.
> In the program I include a picture. When I do that the program size changes
> from 5k to 21k bytes.
>
> If I do not include the picture, printing text goes OK but when including
> the picture the PIC goes haywire again. If I leave out the printing of text
> and include only the graphics with the picture then all is well.
>
> When I look at the assembly, there is a piece of code used for printing
> fonts (using pixels) that uses multiplication. If I look at that piece of
> code in the asm file the code for multiplication is different. In the
> attached screenshot you see the code that goes wrong on the left and the
> code that goes right on the right.
>
> Has anybody experience this kind of problem before so having problems with
> a large program in combination with multiplication (I may draw the wrong
> conclusion here).
>
> Any suggestions?
>
> Hopefully it is not a compiler issue :-(
>
> 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/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
&

Re: [jallib] Code does no longer work when program size increases using mutiplication?

[vsurducan]

Hi Rob, if you look after each compilation to software stack and hardware
stack numbers perhaps you may see important differences between numbers
when code is ok and not. I've seen something similar near HW stack fill,
but this is dificult to debug. It looks like a jump elswere that it
shuld...I guess interrupts are disabled in your test code.

On Fri 9 Sep 2022, 8:13 PM Rob CJ  Hi Vasile,
>
> It sometimes goes into reset but sometimes it just hangs.It is
> unpredictable so I assume that it runs somewhere out of a range that it
> should not.
>
> How could I check the stack length?
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* vrijdag 9 september 2022 07:03
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Code does no longer work when program size
> increases using mutiplication?
>
> Rob, can you check also the stack length when pic goes in loop reset?
>
> On Thu 8 Sep 2022, 9:00 PM rob...@hotmail.com 
> Hi all,
>
> I have the following strange problem. I am working on the ILI9341 library
> and the graphics was staring to work but I could not manage to write text
> to the screen. When I tried that the PIC went haywire and sometimes came
> into some kind of constant reset state.
>
> By accident I discovered that it had to do with the size of the program.
> In the program I include a picture. When I do that the program size changes
> from 5k to 21k bytes.
>
> If I do not include the picture, printing text goes OK but when including
> the picture the PIC goes haywire again. If I leave out the printing of text
> and include only the graphics with the picture then all is well.
>
> When I look at the assembly, there is a piece of code used for printing
> fonts (using pixels) that uses multiplication. If I look at that piece of
> code in the asm file the code for multiplication is different. In the
> attached screenshot you see the code that goes wrong on the left and the
> code that goes right on the right.
>
> Has anybody experience this kind of problem before so having problems with
> a large program in combination with multiplication (I may draw the wrong
> conclusion here).
>
> Any suggestions?
>
> Hopefully it is not a compiler issue :-(
>
> 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/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "jallib" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jallib/sx0p79J2U-A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qseDr7%2BTah7FDfmX8%2B6p7GuT%3DxKpAPCfDTA1J7r4EpXAw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qseDr7%2BTah7FDfmX8%2B6p7GuT%3DxKpAPCfDTA1J7r4EpXAw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/GVXP195MB16370E83D82914789B895CE5E6439%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/jallib/GVXP195MB16370E83D82914789B895CE5E6439%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsmMr%3D%3DGFDq46Rrz1AfNotbnkN7AxTcy%3DmwDty-eHyNMQ%40mail.gmail.com.

Re: [jallib] Code does no longer work when program size increases using mutiplication?

[vsurducan]

Rob, can you check also the stack length when pic goes in loop reset?

On Thu 8 Sep 2022, 9:00 PM rob...@hotmail.com  Hi all,
>
> I have the following strange problem. I am working on the ILI9341 library
> and the graphics was staring to work but I could not manage to write text
> to the screen. When I tried that the PIC went haywire and sometimes came
> into some kind of constant reset state.
>
> By accident I discovered that it had to do with the size of the program.
> In the program I include a picture. When I do that the program size changes
> from 5k to 21k bytes.
>
> If I do not include the picture, printing text goes OK but when including
> the picture the PIC goes haywire again. If I leave out the printing of text
> and include only the graphics with the picture then all is well.
>
> When I look at the assembly, there is a piece of code used for printing
> fonts (using pixels) that uses multiplication. If I look at that piece of
> code in the asm file the code for multiplication is different. In the
> attached screenshot you see the code that goes wrong on the left and the
> code that goes right on the right.
>
> Has anybody experience this kind of problem before so having problems with
> a large program in combination with multiplication (I may draw the wrong
> conclusion here).
>
> Any suggestions?
>
> Hopefully it is not a compiler issue :-(
>
> 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/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%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%2Bj4qseDr7%2BTah7FDfmX8%2B6p7GuT%3DxKpAPCfDTA1J7r4EpXAw%40mail.gmail.com.

Re: [jallib] Intermediate results JAL library for the ILI9341 display

[vsurducan]

Vry nice Rob!
I need to look in my monkey box  someday if there is any display with this
driver...
Usually a TFT display is eating a lot of resources, so it has to display
something very beautiful to be worth the use.
Congrats!

On Sat, Sep 3, 2022 at 3:52 PM rob...@hotmail.com 
wrote:

> Hello JAL users,
>
> Just want to share the intermediate results of the JAL library for the
> ILI9341 display.
>
> It is still work in progress and the recording is not always that clear.
> At the end a small picture is shown but it is not visible. It is not
> correct anyway buy I do not yet know if that is the picture or the library..
> See: https://youtu.be/0yT5pA8968I
>
> I only created the graphics part, fonts do not yet work and I need to add
> more features of the display. After that I will add the library to Jallib
> and will see if I can implement the touch functionality which this version
> of the display also has. And since the display has a slot for an SD card I
> also want to make a sample program that copies pictures form the SD card to
> the display.
>
> 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/bacbb5a3-843d-4f9d-90c9-4ce5374dc9e2n%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%2Bj4qsQeEW%2Bmzw9iYfbY9E4nU40q4mJPFjBquMom%2BpZhSArgA%40mail.gmail.com.

Re: [jallib] PIC18F2580 ADC can't convert High Resolution

[vsurducan]

I do not think you can do a proper average on a +3V +/-1V whichever
"software tricks" you'll do.
Which amplitude do you want to measure on that signal, V+, V-, Vpp? Perhaps
an oscilloscope capture would help for a better answer.

On Wed, Aug 31, 2022 at 7:32 PM flyway38  wrote:

> Hi Vasile,
>
> Yes understand your point and thank you for your input.
> But, my problem is cannot change the hardware design. Maybe in near
> future...
> Also, it's not AC signal what I need to smooth. Its a positive oscillating
> signal, like 3V, +/-1V.
> Thanks anyways.
>
> Cheers,
> Filipe Santos.
>
> On Wednesday, August 31, 2022 at 4:26:29 PM UTC+1 vasile wrote:
>
>> :) "precision rectifier" or "zero voltage drop rectifier" not "zero
>> precision rectifier" :P
>>
>> On Wed, Aug 31, 2022 at 6:22 PM vsurducan  wrote:
>>
>>> Felipe, in my opinion you have two variants:
>>> 1. the easiest one: use a zero precision rectifier with operational
>>> amplifiers, there are several versions, then your problem will be measuring
>>> a DC signal. Beware of using adequate bandwidth OA and use precise
>>> resistors for positive and negative slopes ( if your signal is alternately).
>>>
>>>
>>> https://www.google.com/search?q=precision+rectifier=isch=2ahUKEwiHoc6_r_H5AhUThxoKHbi-Au4Q2-cCegQIABAA=precision+rectifier_lcp=CgNpbWcQAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIGCAAQHhAHMgYIABAeEAcyBggAEB4QBzIGCAAQHhAHUOCWAliipAJgo6oCaABwAHgAgAGaAYgBlwuSAQQwLjEymAEAoAEBqgELZ3dzLXdpei1pbWfAAQE=img=FnsPY4e-PJOOarj9ivAO=815=1537=firefox-b-d
>>>
>>> 2. the complicated one which will not work with jal library: sense the
>>> zero cross of the signal (if there is any), add a precise delay until
>>> you'll sample the top of the rectangular signal or the Vmax of the
>>> sinusoidal shape and sample it. You'll have to process data later. You can
>>> not sample, format and display in a loop since the time consumed by last
>>> two is much longer than the signal period.
>>>
>>> best wishes
>>>
>>>
>>> On Wed, Aug 31, 2022 at 3:13 PM flyway38  wrote:
>>>
>>>> Hey Guys,
>>>>
>>>> My bad. Sorry to make this mistaken post.
>>>> *10bit ADC is working fine.*
>>>> Problem is my code. Am trying to smooth the sinal that is read by the
>>>> ADC.
>>>> Its a fast (100KHz) oscillating signal (with vpp around 1V) that am
>>>> trying to read it like DC... Not easy I know.
>>>> My code is currently reading some hundreds times the signal, then finds
>>>> the median of all readings and then discard the final reading (make it
>>>> equal to last median value) if it changes by a small divergence (like 2
>>>> bits) from last median value.
>>>> This is what lead me to think (wrongly) that ADC was converting at 8bit.
>>>> Sorry again for posting a wrong question.
>>>>
>>>> But now this raises new question;
>>>> How to smooth an oscillating signal and make it DC reading just like a
>>>> DC-Voltmeter would do?
>>>> (Using only code... cannot change my design)
>>>> Thank you once again.
>>>>
>>>> Best regards,
>>>> Filipe Santos.
>>>>
>>>>
>>>> On Wednesday, August 31, 2022 at 9:26:23 AM UTC+1 Rob Hamerling wrote:
>>>>
>>>>>
>>>>>
>>>>> On 31/08/2022 10.21, Rob Hamerling wrote:
>>>>>
>>>>> adc_read_high_res() returns a word, but your AdcChnn is a byte...
>>>>>
>>>>> Sorry, that 'AdcChnn' is a byte isn't the relevant here. Maybe AdcData
>>>>> is a byte, but I cannot find that in the code you showed.
>>>>>
>>>>>
>>>>> --
>>>>> *Rob H*amerling, 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+un...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jallib/68dfd26e-07d1-4ba5-bf02-f41aee02c29bn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jallib/68dfd26e-07d1-4ba5-bf02-f41aee02c29bn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jallib+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/d81e0cf6-5487-4186-a961-01fbd5ba6ec4n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/d81e0cf6-5487-4186-a961-01fbd5ba6ec4n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtS%2BBC25ty-Y_K3P6nOAxiVr_9a_%2BCjdz8fzSMjf_L7DA%40mail.gmail.com.

Re: [jallib] PIC18F2580 ADC can't convert High Resolution

[vsurducan]

:) "precision rectifier" or "zero voltage drop rectifier" not "zero
precision rectifier" :P

On Wed, Aug 31, 2022 at 6:22 PM vsurducan  wrote:

> Felipe, in my opinion you have two variants:
> 1. the easiest one: use a zero precision rectifier with operational
> amplifiers, there are several versions, then your problem will be measuring
> a DC signal. Beware of using adequate bandwidth OA and use precise
> resistors for positive and negative slopes ( if your signal is alternately).
>
>
> https://www.google.com/search?q=precision+rectifier=isch=2ahUKEwiHoc6_r_H5AhUThxoKHbi-Au4Q2-cCegQIABAA=precision+rectifier_lcp=CgNpbWcQAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIGCAAQHhAHMgYIABAeEAcyBggAEB4QBzIGCAAQHhAHUOCWAliipAJgo6oCaABwAHgAgAGaAYgBlwuSAQQwLjEymAEAoAEBqgELZ3dzLXdpei1pbWfAAQE=img=FnsPY4e-PJOOarj9ivAO=815=1537=firefox-b-d
>
> 2. the complicated one which will not work with jal library: sense the
> zero cross of the signal (if there is any), add a precise delay until
> you'll sample the top of the rectangular signal or the Vmax of the
> sinusoidal shape and sample it. You'll have to process data later. You can
> not sample, format and display in a loop since the time consumed by last
> two is much longer than the signal period.
>
> best wishes
>
>
> On Wed, Aug 31, 2022 at 3:13 PM flyway38  wrote:
>
>> Hey Guys,
>>
>> My bad. Sorry to make this mistaken post.
>> *10bit ADC is working fine.*
>> Problem is my code. Am trying to smooth the sinal that is read by the ADC.
>> Its a fast (100KHz) oscillating signal (with vpp around 1V) that am
>> trying to read it like DC... Not easy I know.
>> My code is currently reading some hundreds times the signal, then finds
>> the median of all readings and then discard the final reading (make it
>> equal to last median value) if it changes by a small divergence (like 2
>> bits) from last median value.
>> This is what lead me to think (wrongly) that ADC was converting at 8bit.
>> Sorry again for posting a wrong question.
>>
>> But now this raises new question;
>> How to smooth an oscillating signal and make it DC reading just like a
>> DC-Voltmeter would do?
>> (Using only code... cannot change my design)
>> Thank you once again.
>>
>> Best regards,
>> Filipe Santos.
>>
>>
>> On Wednesday, August 31, 2022 at 9:26:23 AM UTC+1 Rob Hamerling wrote:
>>
>>>
>>>
>>> On 31/08/2022 10.21, Rob Hamerling wrote:
>>>
>>> adc_read_high_res() returns a word, but your AdcChnn is a byte...
>>>
>>> Sorry, that 'AdcChnn' is a byte isn't the relevant here. Maybe AdcData
>>> is a byte, but I cannot find that in the code you showed.
>>>
>>>
>>> --
>>> *Rob H*amerling, 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/68dfd26e-07d1-4ba5-bf02-f41aee02c29bn%40googlegroups.com
>> <https://groups.google.com/d/msgid/jallib/68dfd26e-07d1-4ba5-bf02-f41aee02c29bn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvzAMNS1Jj1XWL3M-MEyUy7G5TWmB%3DPvojJ%3D1Xg561rxg%40mail.gmail.com.

Re: [jallib] PIC18F2580 ADC can't convert High Resolution

[vsurducan]

Felipe, in my opinion you have two variants:
1. the easiest one: use a zero precision rectifier with operational
amplifiers, there are several versions, then your problem will be measuring
a DC signal. Beware of using adequate bandwidth OA and use precise
resistors for positive and negative slopes ( if your signal is alternately).

https://www.google.com/search?q=precision+rectifier=isch=2ahUKEwiHoc6_r_H5AhUThxoKHbi-Au4Q2-cCegQIABAA=precision+rectifier_lcp=CgNpbWcQAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIGCAAQHhAHMgYIABAeEAcyBggAEB4QBzIGCAAQHhAHUOCWAliipAJgo6oCaABwAHgAgAGaAYgBlwuSAQQwLjEymAEAoAEBqgELZ3dzLXdpei1pbWfAAQE=img=FnsPY4e-PJOOarj9ivAO=815=1537=firefox-b-d

2. the complicated one which will not work with jal library: sense the zero
cross of the signal (if there is any), add a precise delay until you'll
sample the top of the rectangular signal or the Vmax of the sinusoidal
shape and sample it. You'll have to process data later. You can not sample,
format and display in a loop since the time consumed by last two is much
longer than the signal period.

best wishes


On Wed, Aug 31, 2022 at 3:13 PM flyway38  wrote:

> Hey Guys,
>
> My bad. Sorry to make this mistaken post.
> *10bit ADC is working fine.*
> Problem is my code. Am trying to smooth the sinal that is read by the ADC.
> Its a fast (100KHz) oscillating signal (with vpp around 1V) that am trying
> to read it like DC... Not easy I know.
> My code is currently reading some hundreds times the signal, then finds
> the median of all readings and then discard the final reading (make it
> equal to last median value) if it changes by a small divergence (like 2
> bits) from last median value.
> This is what lead me to think (wrongly) that ADC was converting at 8bit.
> Sorry again for posting a wrong question.
>
> But now this raises new question;
> How to smooth an oscillating signal and make it DC reading just like a
> DC-Voltmeter would do?
> (Using only code... cannot change my design)
> Thank you once again.
>
> Best regards,
> Filipe Santos.
>
>
> On Wednesday, August 31, 2022 at 9:26:23 AM UTC+1 Rob Hamerling wrote:
>
>>
>>
>> On 31/08/2022 10.21, Rob Hamerling wrote:
>>
>> adc_read_high_res() returns a word, but your AdcChnn is a byte...
>>
>> Sorry, that 'AdcChnn' is a byte isn't the relevant here. Maybe AdcData is
>> a byte, but I cannot find that in the code you showed.
>>
>>
>> --
>> *Rob H*amerling, 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/68dfd26e-07d1-4ba5-bf02-f41aee02c29bn%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%2Bj4qtrvbDo8fdg_Xb8XHj67Kx6D7%2B9FsVyrBjtYivQ0%2BsupA%40mail.gmail.com.

Re: [jallib] Procedures vs Functions

[vsurducan]

I think sometimes whichever you will use procedure or function will not be
fast enough. One bad example is too long if...end if procedures containing
stuff you are not using it. The common answer you'll get is that compiler
will delete unused stuff, which is correct unless it' s about defined
registers. So when you have time constrains, already defined procedures
that you get from the libraries have to be modified and simplified on your
own need. This is totally against the jallib policy :) but is the only way
which works. One good way is to check frequently the code length when major
revisions occure. A simple pass of a variable from one procedure to other
or from a function to a procedure may substantially increase the code
length. Too structured source code in which you call a procedure from
another procedure and from another one is increasing the used stack.
Sometimes repeating a portion of code is much better than calling it within
a procedure. And so on,  things you will discover by yourself...

On Sun 21 Aug 2022, 6:04 PM Rob CJ  Hi Filipe,
>
> About 1). I am not sure, you should have a look at the assembly code. If
> you would replace a function by a procedure then you should have at least
> one parameter of the type 'out'. There is a way to speed up a function or
> procedure by declaring it 'inline'. If you do that the procedure or
> function is not called but the code is copied into the program where it is
> used. This increases the code size of your program but saves you a call to
> the procedure or function.
>
> And if you use interrupts there is an option 'fast' to speed it up but I
> never used it and you need to take some precautions if you use that.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens flyway38 <
> fsfon...@gmail.com>
> *Verzonden:* zondag 21 augustus 2022 13:46
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] Procedures vs Functions
>
> Hello Kiste,
>
> Thank you for your input.
>
> Cheers,
> FS
>
> On Sunday, August 21, 2022 at 12:03:37 PM UTC+1 Kiste wrote:
>
> 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/049c5097-750d-4cf7-845a-a89720963961n%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/365d7bab-9091-4ac5-b55f-265f5cd23104n%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/GVXP195MB1637DBE0E8F8E73A20BA5E98E66E9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
> 
> .
>

-- 
You received this message because you are subscribed to the Google 

Re: [jallib] DS18B20 was IF/END IF usage limit??

[vsurducan]

Ok, that was what you have found. :)
best wishes,

On Sun, Aug 7, 2022 at 9:26 AM Rob CJ  wrote:

> Hi Vasile,
>
> The program that did not work at 4 MHz had no interrupts or other things
> running so the limitation was really the fact that the microcontroller was
> running at 4 MHz.
>
> As far as I know this would be the only library that needs a warning not
> to be used at 4 MHz .
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens vsurducan
> 
> *Verzonden:* zondag 7 augustus 2022 06:14
> *Aan:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] DS18B20 was IF/END IF usage limit??
>
> Hi Rob,
> When using DS18B20 with an interrupted USB serial driver you also have to
> turn off the USB interrupts during communication with the sensor. This is
> mandatory if you have for example 8 sensors which are repeatedly sampled
> and readed.
> You know well that you can not turn off GIE because the USB communication
> will then be lost. :)
>
> BTW, I have an automation for two solar water heaters that I made 10 or 12
> years ago which use DS18B20 and an 8MHz PIC16F886. Display is on
> multiplexed 8 digit. I needed a long time solving an issue with the code
> length, one extra instruction in the source and the stuff was inoperable,
> no matter which was that instruction. :)  The extra time of the loop ( one
> more instruction) was killing the communication with the sensor.
>
> Perhaps multiple warnings would be necessary :) :P
>
>
> On Sat, Aug 6, 2022 at 9:02 PM Rob CJ  wrote:
>
> Hi Filip,
>
> Are you saying that the code is executing slow?
>
> If you can share your program or at least the part that is problematic (so
> it can be reproduced) that could help.
>
> BTW (for Vasile ). I recently worked on a problem of Hans using the
> DS18B20. It did work on one PIC but not on a smaller one. Finally the root
> cause was the PIC running at 4 MHz which was too slow to create the correct
> one-wire timing for the DS18B20. Switching to 8 MHz solved the problem.
> This was the first time that I encountered that a library did not work
> because of a clock speed begin to low. Maybe we should add a warning to
> that library.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens flyway38 <
> fsfon...@gmail.com>
> *Verzonden:* zaterdag 6 augustus 2022 18:39
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] IF/END IF usage limit??
>
> Hi Vasile,
>
> Thank you for the quick reply.
> Is have that feeling about something not right at some point of the code.
> In fact tried to exchange some "if/end if" for "case of" but no luck.
> Problem persists, but it seems only related to "if/end if" usage..
>
> My code reads the ADC (PIC18F2550), for 100 times in a "for/end loop".
> Then find the median of values read and send that median value to RS232.
> Also has a button to do some extra actions.
> All this code worked great even in a smaller PIC (16F18313).
>
> Now have changed PIC for the 18F2550 and wanted to add some extra code to
> manage PWM and ADC reading times to find the median value.
> Also added an oled display to show locally that value and the PWM/ ADC nr.
> of readings parameters. That's when this issue raised up.
> Simptoms are the code running sluggish, not hangging...
> Any ideas?
> Thank you very much.
>
> Cheers,
> Filipe Santos
>
>
> On Saturday, August 6, 2022 at 5:13:36 PM UTC+1 vasile wrote:
>
> This issue appears usually when you do not manage in a correct way the
> timing required by a specific hardware and the costs of your code length is
> higher than required for the device to run properly. Common workaround is
> to use interrupts or other sequential techniques.
>
> Example: DS18B20 is a temperature sensor which requires 750ms or so for a
> 12bit conversion. If you have complex software involving USB interrupts,
> real time clock generation, 7segment LED multiplexed display, etc , and
> those are not shared correctly with your resources ( aka you try everything
> to be solved in pure software) at one moment your code will freeze at a
> specific code length. Removing some lines, no matter that are if/end if or
> something else will apparently make your code functional, but the issue is
> not where you suppose it is...
>
> Instead of if/end if you may use "case of". However it will not do
> something special or different compared with if/end if, except a more
> understandable structure for your source.
> best wishes,
>
>
> On Sat, Aug 6, 2022 at 7:00 PM flyway38  wrote:
>
> Hi all,
>
> Is there any limit in using 

Re: [jallib] DS18B20 was IF/END IF usage limit??

[vsurducan]

Hi Rob,
When using DS18B20 with an interrupted USB serial driver you also have to
turn off the USB interrupts during communication with the sensor. This is
mandatory if you have for example 8 sensors which are repeatedly sampled
and readed.
You know well that you can not turn off GIE because the USB communication
will then be lost. :)

BTW, I have an automation for two solar water heaters that I made 10 or 12
years ago which use DS18B20 and an 8MHz PIC16F886. Display is on
multiplexed 8 digit. I needed a long time solving an issue with the code
length, one extra instruction in the source and the stuff was inoperable,
no matter which was that instruction. :)  The extra time of the loop ( one
more instruction) was killing the communication with the sensor.

Perhaps multiple warnings would be necessary :) :P


On Sat, Aug 6, 2022 at 9:02 PM Rob CJ  wrote:

> Hi Filip,
>
> Are you saying that the code is executing slow?
>
> If you can share your program or at least the part that is problematic (so
> it can be reproduced) that could help.
>
> BTW (for Vasile ). I recently worked on a problem of Hans using the
> DS18B20. It did work on one PIC but not on a smaller one. Finally the root
> cause was the PIC running at 4 MHz which was too slow to create the correct
> one-wire timing for the DS18B20. Switching to 8 MHz solved the problem.
> This was the first time that I encountered that a library did not work
> because of a clock speed begin to low. Maybe we should add a warning to
> that library.
>
> Kind regards,
>
> Rob
>
> --
> *Van:* jallib@googlegroups.com  namens flyway38 <
> fsfon...@gmail.com>
> *Verzonden:* zaterdag 6 augustus 2022 18:39
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] IF/END IF usage limit??
>
> Hi Vasile,
>
> Thank you for the quick reply.
> Is have that feeling about something not right at some point of the code.
> In fact tried to exchange some "if/end if" for "case of" but no luck.
> Problem persists, but it seems only related to "if/end if" usage..
>
> My code reads the ADC (PIC18F2550), for 100 times in a "for/end loop".
> Then find the median of values read and send that median value to RS232.
> Also has a button to do some extra actions.
> All this code worked great even in a smaller PIC (16F18313).
>
> Now have changed PIC for the 18F2550 and wanted to add some extra code to
> manage PWM and ADC reading times to find the median value.
> Also added an oled display to show locally that value and the PWM/ ADC nr.
> of readings parameters. That's when this issue raised up.
> Simptoms are the code running sluggish, not hangging...
> Any ideas?
> Thank you very much.
>
> Cheers,
> Filipe Santos
>
>
> On Saturday, August 6, 2022 at 5:13:36 PM UTC+1 vasile wrote:
>
> This issue appears usually when you do not manage in a correct way the
> timing required by a specific hardware and the costs of your code length is
> higher than required for the device to run properly. Common workaround is
> to use interrupts or other sequential techniques.
>
> Example: DS18B20 is a temperature sensor which requires 750ms or so for a
> 12bit conversion. If you have complex software involving USB interrupts,
> real time clock generation, 7segment LED multiplexed display, etc , and
> those are not shared correctly with your resources ( aka you try everything
> to be solved in pure software) at one moment your code will freeze at a
> specific code length. Removing some lines, no matter that are if/end if or
> something else will apparently make your code functional, but the issue is
> not where you suppose it is...
>
> Instead of if/end if you may use "case of". However it will not do
> something special or different compared with if/end if, except a more
> understandable structure for your source.
> best wishes,
>
>
> On Sat, Aug 6, 2022 at 7:00 PM flyway38  wrote:
>
> Hi all,
>
> Is there any limit in using IF/ END IF conditions?
> My code was running good untill added one more IF/END IF.
> At first didn't realize about a limit in using these conditions code, but
> then figured out that any other IF/END IF removal would let my code run ok
> again...
> Does anyone knows anything about this issue?
> Thank you very much.
>
> Cheers,
> 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/3f8189dd-fd0a-4df9-8948-518503485e61n%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 

Re: [jallib] IF/END IF usage limit??

[vsurducan]

If you send more words on RS232 repeatedly you have either to use after
each word a delay to allow completion of the transmission or to check if
the previous word transmission ended before sending the next word. There is
a bit for this on UART.

On Sat, Aug 6, 2022 at 10:00 PM flyway38  wrote:

> Hi all,
>
> Problem seems to be solved.
> It was due to using AN1 for the button (digital behaviour)...
>
> Right now am facing new problem.
> The follwing code seems not working ok;
>
> code
> serial_hw_write_word(0xEF2A + word(RlyCtl))
> /code
>
> RlyCtl is a pin (bit)
> When ON, sends to serial; EF2B (correct)
> When OFF, sends to serial; EF00 (Should send EF2A)
> Maybe some issue on receiver side, but I think that converting bit to word
> seems problematic... not sure.
>
> Before was using "serial_hw_write" byte by byte but with longer delay in
> between (longer than NOP, wich is used by word sender)
>
> Any ideas?
> Thank you very much.
>
> Cheers,
> FS
>
> On Saturday, August 6, 2022 at 7:01:57 PM UTC+1 rob...@hotmail.com wrote:
>
>> Hi Filip,
>>
>> Are you saying that the code is executing slow?
>>
>> If you can share your program or at least the part that is problematic
>> (so it can be reproduced) that could help.
>>
>> BTW (for Vasile ). I recently worked on a problem of Hans using the
>> DS18B20. It did work on one PIC but not on a smaller one. Finally the root
>> cause was the PIC running at 4 MHz which was too slow to create the correct
>> one-wire timing for the DS18B20. Switching to 8 MHz solved the problem.
>> This was the first time that I encountered that a library did not work
>> because of a clock speed begin to low. Maybe we should add a warning to
>> that library.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> *Van:* jal...@googlegroups.com  namens flyway38
>> 
>> *Verzonden:* zaterdag 6 augustus 2022 18:39
>> *Aan:* jallib 
>> *Onderwerp:* Re: [jallib] IF/END IF usage limit??
>>
>> Hi Vasile,
>>
>> Thank you for the quick reply.
>> Is have that feeling about something not right at some point of the code.
>> In fact tried to exchange some "if/end if" for "case of" but no luck.
>> Problem persists, but it seems only related to "if/end if" usage..
>>
>> My code reads the ADC (PIC18F2550), for 100 times in a "for/end loop".
>> Then find the median of values read and send that median value to RS232.
>> Also has a button to do some extra actions.
>> All this code worked great even in a smaller PIC (16F18313).
>>
>> Now have changed PIC for the 18F2550 and wanted to add some extra code to
>> manage PWM and ADC reading times to find the median value.
>> Also added an oled display to show locally that value and the PWM/ ADC
>> nr. of readings parameters. That's when this issue raised up.
>> Simptoms are the code running sluggish, not hangging...
>> Any ideas?
>> Thank you very much.
>>
>> Cheers,
>> Filipe Santos
>>
>>
>> On Saturday, August 6, 2022 at 5:13:36 PM UTC+1 vasile wrote:
>>
>> This issue appears usually when you do not manage in a correct way the
>> timing required by a specific hardware and the costs of your code length is
>> higher than required for the device to run properly. Common workaround is
>> to use interrupts or other sequential techniques.
>>
>> Example: DS18B20 is a temperature sensor which requires 750ms or so for a
>> 12bit conversion. If you have complex software involving USB interrupts,
>> real time clock generation, 7segment LED multiplexed display, etc , and
>> those are not shared correctly with your resources ( aka you try everything
>> to be solved in pure software) at one moment your code will freeze at a
>> specific code length. Removing some lines, no matter that are if/end if or
>> something else will apparently make your code functional, but the issue is
>> not where you suppose it is...
>>
>> Instead of if/end if you may use "case of". However it will not do
>> something special or different compared with if/end if, except a more
>> understandable structure for your source.
>> best wishes,
>>
>>
>> On Sat, Aug 6, 2022 at 7:00 PM flyway38  wrote:
>>
>> Hi all,
>>
>> Is there any limit in using IF/ END IF conditions?
>> My code was running good untill added one more IF/END IF.
>> At first didn't realize about a limit in using these conditions code, but
>> then figured out that any other IF/END IF removal would let my code run ok
>> again...
>> Does anyone knows anything about this issue?
>> Thank you very much.
>>
>> Cheers,
>> 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+un...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jallib/3f8189dd-fd0a-4df9-8948-518503485e61n%40googlegroups.com
>> 

Re: [jallib] IF/END IF usage limit??

[vsurducan]

This issue appears usually when you do not manage in a correct way the
timing required by a specific hardware and the costs of your code length is
higher than required for the device to run properly. Common workaround is
to use interrupts or other sequential techniques.

Example: DS18B20 is a temperature sensor which requires 750ms or so for a
12bit conversion. If you have complex software involving USB interrupts,
real time clock generation, 7segment LED multiplexed display, etc , and
those are not shared correctly with your resources ( aka you try everything
to be solved in pure software) at one moment your code will freeze at a
specific code length. Removing some lines, no matter that are if/end if or
something else will apparently make your code functional, but the issue is
not where you suppose it is...

Instead of if/end if you may use "case of". However it will not do
something special or different compared with if/end if, except a more
understandable structure for your source.
best wishes,


On Sat, Aug 6, 2022 at 7:00 PM flyway38  wrote:

> Hi all,
>
> Is there any limit in using IF/ END IF conditions?
> My code was running good untill added one more IF/END IF.
> At first didn't realize about a limit in using these conditions code, but
> then figured out that any other IF/END IF removal would let my code run ok
> again...
> Does anyone knows anything about this issue?
> Thank you very much.
>
> Cheers,
> 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/3f8189dd-fd0a-4df9-8948-518503485e61n%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%2Bj4qvj7JtkTrN%3D-fFn16sqpnf9kWrF3EMaJ96J5SvVdtg_wQ%40mail.gmail.com.

Re: [jallib] ADC value to Digits

[vsurducan]

5V/1024=0.0049 (rounded). That means it's worth it to display max 2.50,
there is no better resolution. ( 2.500, 2.505 or 2.495 are all in the same
ADC resolution error, last digit should be then absent).
Perhaps integrating your OLED library with the format library?

On Tue, Aug 2, 2022 at 1:33 PM flyway38  wrote:

> Hello All,
>
> New question.
> Sorry if asked already.
> I need to find the quickest way to convert my ADC value (10bits) into
> digits format.
> Need to show this result in an Oled Display using my digit fonts in this
> format; "X.XXX", where max value to show is 5V, so as an example and
> assuming my ADC is reading half voltage (0x0200) it would show on display
> "2.500".
> Have my code (working ok) here, but wanted to know if there is any better
> / faster way to do it;
>
> CODE:
>mmVal = (dword(mVal) * 5 * 1000) / 1024
>vShowValU = mmVal / 1000
>vShowValD = (mmVal - vShowValU * 1000) / 100
>vShowValC = (mmVal - vShowValU * 1000 - vShowValD * 100) / 10
>vShowValM = mmVal - vShowValU * 1000 - vShowValD * 100 - vShowValC * 10
>--
>
>  
> OLED_0in95_rgb_DisplayImage(10,20,byte(vShowValU),fColorH,fColorL,fColorMH,fColorML,20)
>
>  OLED_0in95_rgb_DisplayImage(25,20,10,fColorH,fColorL,fColorMH,fColorML,20)
>-- Decimal DOT
> OLED_0in95_rgb_DisplayImage(40,20,byte(vShowValD),fColorH,fColorL,fColorMH,fColorML,20)
>
>  
> OLED_0in95_rgb_DisplayImage(55,20,byte(vShowValC),fColorH,fColorL,fColorMH,fColorML,20)
>
>  
> OLED_0in95_rgb_DisplayImage(70,20,byte(vShowValM),fColorH,fColorL,fColorMH,fColorML,20)
>
> Thank you all.
> Cheers.
>
> 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/faab018f-fd46-488a-82ba-a898d98c5128n%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%2Bj4qtFO%3D-WOxiTiKGcZn_A7L7NJJ%3DaWE8W9Zvv6h6-mec0-A%40mail.gmail.com.

Re: [jallib] Wisp648

[vsurducan]

Hi Evan, I never regretted that move with pk2. :)
However, Pickit 4 is definitely much faster ( and much more expensive).
Actually nowadays it seems that electronic IC's have become really
valuable...
best,

On Sat, Jul 30, 2022 at 6:39 PM 'Evan Venn' via jallib <
jallib@googlegroups.com> wrote:

> You could try moving across to pickitplus and then it would be a lot
> faster and consistent with support across the range of supported chips
> whilst still using the pk3.
>
> --
> 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/CWXP265MB251811ED5137CB8EF0830967F9989%40CWXP265MB2518.GBRP265.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%2Bj4qux2tPUckJgYkrNKPNpWa65hOM9dT0QjOOaEX%3DpdhCp3A%40mail.gmail.com.

Re: [jallib] Wisp648

[vsurducan]

 "Gefeliciteerd"
seems ok for me. :)

BTW, if you use pickit4, you will need anyway to install the IPE to change
the supply voltage, then to plug and unplug and plug again the pickit until
IPE sees it...then fortunately to program something.  Never leave it in the
USB when you start the computer if you do not want to send it to Microchip
irish office for reflashing the Atmel inside or exchanging with a new
one... Pickit4 needs to behave with it as you'll do with eggs. On the
opposite of Pickit2/3 which can be reflashed at home...
best wishes


On Thu, Jul 28, 2022 at 8:56 AM hans  wrote:

> Hi Sunish,
> I have made my first batch:
>
> @ECHO OFF
> Echo Gefeliciteerd
> PAUSE
>
> "C:\Program
> Files\Microchip\MPLABX\v5.45\mplab_platform\mplab_ipe\pk3cmd.exe" -TPPK3
> -P%1 -MPIC -F%2 -OL
> @if ERRORLEVEL 1 pause
>
> It works but gives an error message ;
>
> Gefeliciteerd
> Press any key to continue . . .
> Illegal command line parameter T
> Press any key to continue . . .
> Op woensdag 27 juli 2022 om 17:16:30 UTC+2 schreef hans:
>
>> Hi Sunish,
>> This sounds great ! I have never made a batch file and use the Pickit not
>> for providing 5 Volt\
>> The IPE is in the regular program file, not in (86), i have foud the same
>> files you mentioned.
>> . Please give me an example how to make the batch file.
>> Thanks
>> Hans
>>
>> Op woensdag 27 juli 2022 om 14:24:59 UTC+2 schreef sunis...@gmail.com:
>>
>>> Jaledit can program using Pickit 2 and 3. You will need to install IPE.
>>>
>>> Create a batch file and paste the code - Change the path to reflect your
>>> computer's IPE installation
>>>
>>> *"C:\Program Files
>>> (x86)\Microchip\MPLABX\v5.20\mplab_platform\mplab_ipe\pk3cmd.exe"  -TPPK3
>>> -P%1 -MPIC -F%2 -OL*
>>> *@if ERRORLEVEL 1 pause*
>>>
>>>
>>> In jaledit you will have to set the path to the batch file and pass %D
>>> %F   for the PIC name and file name respectively.
>>> the /V5 is to force Pickit to provide 5V supply
>>>
>>> [image: image.png]
>>>
>>>
>>>
>>>  Regards,
>>> Sunish
>>>
>> --
> 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/f295ac0d-880c-48b4-a78d-18fc674db5cdn%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%2Bj4qtwYFn%3DGGwztsM%3DgKckT5YougcwByFt7wnPj%3DQ6qL6jXQ%40mail.gmail.com.

Re: [jallib] Pic_program_eeprom

[vsurducan]

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
> Hans
> Op 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 <
>> hanz...@zeelandnet.nl>
>> *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 <
>> hanz...@zeelandnet.nl>
>> *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 to jallib+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 to jallib+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
>> 
>> .
>>
> --
> 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/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/CAM%2Bj4qvdsrOTQ54TZ3z-SMxdSRLeqZrjWmnW-popicSPLSAkog%40mail.gmail.com.

Re: [jallib] sun power use

[vsurducan]

Hans,
if you want a long life for the acid gel (VRLA hopefully, beter lead-carbon
but I doubt you bought that one) you need to discharge it at max 50% (
better only to 80%) of it's maximum capacity. Deep discharge is the
accumulator dead no matter the lies written on battery datasheet datasheet
( 800 cycles and deep discharge).
Also check carefully the floating voltage ( near zero consumption) to not
exceed 13.3-13.6V.
Lead-acid gel has the ugly behaviour of slow voltage decrease during gel
drying. At the same time the current decreases too. Serious
charge-discharge cycles are better than float discharge.
Be happy. You have now sun power for the puppets!

On Wed, Jul 13, 2022 at 3:15 AM hans  wrote:

> Hello all,
>
> Here is the solar panel I will be using. I just went back to 12 volts and
> a small lead acid battery.
>
>  One motor drives the axis that is parallel to the Earth's axis and
> follows the sun. Actually the screen should go 24 degrees up (June) and 24
> degrees down (December) but I did some measurements and the gain is too
> small for me to do anything about it.
>
> Anyway, Jal lets things run smoothly again and now we just have to wait
> and see if the weather gods accept this thing.
>
> regards
>
> Hans
> [image: zon_set.jpg]
>
> --
> 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/1daba767-6631-47b2-aca7-8272c214a92bn%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%2Bj4qu94_XFbiv532TisNXQ9L8fcOQtNZZwh%2BB9SwakA6ndqA%40mail.gmail.com.

Re: [jallib] sun power use

[vsurducan]

ans
>>>>
>>>> Op woensdag 29 juni 2022 om 16:22:16 UTC+2 schreef vasile:
>>>>
>>>> About keeping up with consumption, PV has to (i) charge the battery and
>>>> (ii) supply your board.
>>>> If you really want to try something new, then a two axis tracking
>>>> system will improve your charging by about 40% with the same PV.
>>>> Why? Because the PV will stay oriented to the sun, except for minor
>>>> clouds and heavy rain when everything will be disintegrated :)
>>>>
>>>> https://www.banggood.com/Smart-Solar-Tracking-Equipment-Maker-Project-DIY-Kit-Technology-for-Arduino-p-1952195.html
>>>>
>>>>
>>>> On Wed, Jun 29, 2022 at 4:39 PM 'Oliver Seitz' via jallib <
>>>> jal...@googlegroups.com> wrote:
>>>>
>>>> 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 <
>>>> hanz...@zeelandnet.nl> 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 regards
>>>> Hans
>>>>
>>>> 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 <
>>>> hanz...@zeelandnet.nl>
>>>> *Verzonden:* woensdag 29 juni 2022 11:22
>>>> *Aan:* jallib 
>>>>
>>>> *Onderwerp:* Re: [jallib] sun power use
>>>> Such 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.
>>>> regards
>>>> Hans
>>>>
>>>> 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 

Re: [jallib] sun power use

[vsurducan]

ertain 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 regards
>> Hans
>>
>> 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 <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* woensdag 29 juni 2022 11:22
>> *Aan:* jallib 
>>
>> *Onderwerp:* Re: [jallib] sun power use
>> Such 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.
>> regards
>> Hans
>>
>> 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 to jallib+un...@googlegroups.com.
>> To view this discussion on the web visit
>&g

Re: [jallib] sun power use

[vsurducan]

 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 <
>>>> hanz...@zeelandnet.nl>
>>>> *Verzonden:* woensdag 29 juni 2022 11:22
>>>> *Aan:* jallib 
>>>>
>>>> *Onderwerp:* Re: [jallib] sun power use
>>>> Such 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.
>>>> regards
>>>> Hans
>>>>
>>>> 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 to jallib+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
>>>> <https://groups.google.com/d/msgid/jallib/3220a563-f63f-435b-b0a6-c088cc777aaen%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "jallib" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jallib+un...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jallib/CAM%2Bj4quz-mvFLM7nuWmPg0

Re: [jallib] Re: Lirary for TM1637.

[vsurducan]

I've looked at the datasheet but never worked with this chinese IC.
As is written, "100pF is used to reduce radio interference to communication
ports".

The values of the pull-up resistors and the capacitor are influencing the
rising and falling edges of the CLK and data signals. If capacitors are
bigger, the rising time will be longer. When such a requirement appears in
a datasheet, it might be a problem of oscillations on the bus which can be
reduced  by placing capacitors, but not necessarily to be so. You have to
check with a scope if your bus looks well or not.

The connection  length between IC and your microcontroller may be
important. So, if you do not have a software problem ( which is most
plausible to be) try to use twisted wires clk+gnd, dio+gnd without 100pF
capacitors and 10K pullups near the TM1637.  Reducing the pullup to 5k1 may
help.

On Tue, Jul 5, 2022 at 7:35 PM pinhe...@gmail.com 
wrote:

>
> Hi Rob,
>
> Thanks for that quick answer.   I will try with and without those
> capacitors, but it is still strange that they appear to be mandatory if you
> red the datasheet
> Anyway, thanks, and I'll keep you posted
>
> Kind regards,
>
> David
> Le mercredi 29 juin 2022 à 19:31:29 UTC+2, rob...@hotmail.com a écrit :
>
>> Hi David,
>>
>> I do not remember anymore but I think I read it somewhere. I do see in
>> the init function that there are pull-up resistors on the module and if you
>> also have capacitors on those line that may impact the speed.
>>
>> I did find this which also says that the capacitors may impact the speed.
>>
>>
>>
>> You can try if it works with or without the capacitors.
>>
>> Kind regards,
>>
>> Rob
>>
>>
>>
>> --
>> *Van:* jal...@googlegroups.com  namens
>> pinhe...@gmail.com 
>> *Verzonden:* woensdag 29 juni 2022 16:42
>> *Aan:* jallib 
>> *Onderwerp:* [jallib] Re: Lirary for TM1637.
>>
>> Hi Rob and all,
>>
>> I wonder about the comment in the header of the lib stating that the
>> capacitors on DIO and CLK lines should be removed from the modules, while
>> the TM1637 datasheet mentions that two 100 pF should be placed on those
>> lines.
>> Why whould I need to remove them ?
>>
>> Thanks for your opinions, and have a nice day
>>
>> David
>>
>> Le samedi 27 juin 2020 à 15:57:32 UTC+2, rob...@hotmail.com a écrit :
>>
>> Hi all,
>>
>> I created a library for the TM1637.
>>
>> For more info (with video) see:
>> http://www.justanotherlanguage.org:3389/node/320
>>
>> The library will be available in the next bee package.
>>
>> 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/71f26cac-ce26-4306-a622-362df6abe10en%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/447d9b4b-726f-4b6c-ab12-9d0af76794f4n%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%2Bj4qvM8%3D_cLeoUfzEbzghfW3jVAdZg-S4G0qtNTzJ3mOjecg%40mail.gmail.com.

Re: [jallib] sun power use

[vsurducan]

About keeping up with consumption, PV has to (i) charge the battery and
(ii) supply your board.
If you really want to try something new, then a two axis tracking system
will improve your charging by about 40% with the same PV.
Why? Because the PV will stay oriented to the sun, except for minor clouds
and heavy rain when everything will be disintegrated :)
https://www.banggood.com/Smart-Solar-Tracking-Equipment-Maker-Project-DIY-Kit-Technology-for-Arduino-p-1952195.html


On Wed, Jun 29, 2022 at 4:39 PM 'Oliver Seitz' via jallib <
jallib@googlegroups.com> wrote:

> 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 regards
> Hans
>
> 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 <
> hanz...@zeelandnet.nl>
> *Verzonden:* woensdag 29 juni 2022 11:22
> *Aan:* jallib 
>
> *Onderwerp:* Re: [jallib] sun power use
> Such 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.
> regards
> Hans
>
> 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
>

Re: [jallib] sun power use

[vsurducan]

Such solar kits usually have PWM charging, they need PV voltage higher than
the battery voltage.


On Wed, Jun 29, 2022 at 1:29 PM hans  wrote:

> 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 regards
> Hans
>
> 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 <
>> hanz...@zeelandnet.nl>
>> *Verzonden:* woensdag 29 juni 2022 11:22
>> *Aan:* jallib 
>>
>> *Onderwerp:* Re: [jallib] sun power use
>> Such 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.
>> regards
>> Hans
>>
>> 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 to jallib+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
>> <https://groups.google.com/d/msgid/jallib/3220a563-f63f-435b-b0a6-c088cc77

Re: [jallib] sun power use

[vsurducan]

It depends, Rob. With a MPPT you may use a smaller PV surface, older
technology, cheapest, with much better efficiency in the morning and in the
evening when there is only light and no direct sun. I'm very sensitive to
this because I've just finished my 2Kw real solar supply for the house and
this is crystal clear...(at least for me). :)

For Hans: A MPPT is a circuit which continuously measures both the voltage
and the current drawn from the PV. At each moment when light varies there
are a few pairs of voltage/current at the PV output which produces maximum
energy. These can be seen on the PV output characteristics and heavily
depends on load and amount of sunlight.  If you do not use the best pair,
you may lose as much as 20% to 30% of what PV can offer.
On the other hand, when the PV goes hot, it decreases its output energy
with an usual rate of 0.3% to 0.4% per each celsius degree above 25C. In
summer, a PV can easily reach 60-70C. The best monocrystalline PV
technology has today a power decrease around 0.27%/C

Of course if your load is 0.3W ( 3V/100mA) then it does not count too much,
only if your PV cell delivers enough power.
I hope this clarifies your questions about if worth or not.
best wishes,

On Wed, Jun 29, 2022 at 12:44 PM Rob CJ  wrote:

> 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:* jallib@googlegroups.com  namens hans <
> hanze...@zeelandnet.nl>
> *Verzonden:* woensdag 29 juni 2022 11:22
> *Aan:* jallib 
> *Onderwerp:* Re: [jallib] sun power use
>
> Such 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.
> regards
> Hans
>
> 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 gro

Re: [jallib] sun power use

[vsurducan]

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

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

[vsurducan]

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,
>
> @Vasile
> No complicated at all to invert signals using FT_prog;
>
> https://ftdichip.com/wp-content/uploads/2022/05/FT_Prog_v3.12.29.638-Installer.zip
> Very easy. Two clicks after installed and there you go.
> You can invert any of RS232 signals, but only TX neeeded to be inverted.
>
> @Rob
> Yes. 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 <
>> jal...@googlegroups.com> 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)
>>>
>>> -31idleframing error
>>> -21idleframing error
>>> -11idleframing error
>>>  00startbitidle
>>>  100*1+idle
>>>  211*2+startbit
>>>  300*4+1*1+
>>>  400*8=2   1*2+
>>>  500*1+1*4+
>>>  611*2+0*8=7
>>>  700*4+1*1+
>>>  800*8=2   2*2+
>>>  91Stopbit 0*4+
>>> 100startbit1*8=b
>>> 1100*1+stopbit
>>> 1211*2+startbit
>>> 1300*4+1*1+
>>> 1400*8=2   1*2+
>>> 1500*1+1*4+
>>> 1611*2+0*8=7
>>> 1700*4+1*1+
>>> 1800*8=2   1*2+
>>> 191Stopbit 0*4+
>>> 201idle0*8=3
>>> 211idleframing error
>>> 221idleframing error
>>> 231idleframing error
>>> 241idleframing 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 

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

[vsurducan]

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 <
jallib@googlegroups.com> 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)
>
> -31idleframing error
> -21idleframing error
> -11idleframing error
>  00startbitidle
>  100*1+idle
>  211*2+startbit
>  300*4+1*1+
>  400*8=2   1*2+
>  500*1+1*4+
>  611*2+0*8=7
>  700*4+1*1+
>  800*8=2   2*2+
>  91Stopbit 0*4+
> 100startbit1*8=b
> 1100*1+stopbit
> 1211*2+startbit
> 1300*4+1*1+
> 1400*8=2   1*2+
> 1500*1+1*4+
> 1611*2+0*8=7
> 1700*4+1*1+
> 1800*8=2   1*2+
> 191Stopbit 0*4+
> 201idle0*8=3
> 211idleframing error
> 221idleframing error
> 231idleframing error
> 241idleframing 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   -- 

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

[vsurducan]

You have to use a serial receiving procedure which uses interrupts. Read
carefully the serial_hw_int_cts.jal. If new to jal, remember there is a
learning curve you can not jump over it. Interrupts are not easy, usually
with issues and bugs.
Good luck!

On Sat 14 May 2022, 11:50 PM flyway38  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
> 
> .
>

-- 
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%2Bj4qv0ckWCT-XD%3DyzpCdwiMAEN_HKw0YJe_%3DjEJ9vHk_yKGA%40mail.gmail.com.

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

[vsurducan]

Why are not using an "if-then-else" syntax instead of "while loop end
loop"? 8pin PIC it's fine.

On Sun 15 May 2022, 3:02 PM flyway38  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=1
>> If 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 

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

[vsurducan]

Guys, PIC16F18313 has EUSART. Are you sure that you and Filipe are talking
the same language?
What if it's just a problem of using the wrong library?
There are several ways of decreasing the error in both sw and hw serial
communications, one of them is to use the "zero error" XTAL

best wishes


On Sun, May 15, 2022 at 6:44 PM Rob CJ  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:* jallib@googlegroups.com 
> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
> 16F18313
>
> 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 loop
> end 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_pin loop 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 

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

[vsurducan]

Can you draw a schematic of your connection by hand and post it here
together with a simple test code which does not run properly for you?
Mention also the operating system you're using on the computer.
Usually the problem is very simple, but impossible to see. All people here
had it at least once.

On Tue, May 17, 2022 at 1:48 PM flyway38  wrote:

> Hi Vasile,
>
> Thanks for the inputs here.
> In fact, theres a problem about the baud rate, but this problem lets
> project work ok using serial_software; PIC is set for 38400 and PC port
> need to be set for 57600. Don't know why, but this is the way it's working
> for several weeks of developing...
> Using serial_hardware lib, not even playing around the baud rate
> divergences makes it work correctly. No correct data arriving to PC or to
> PIC...
> Big puzzle here :D
> Thanks anyways.
>
> Cheers,
> Filipe Santos.
>
> On Tuesday, May 17, 2022 at 5:25:09 AM UTC+1 vasile wrote:
>
>> Double check if you have correct settings, baud speed, bit number, parity
>> and stop bit. Set something like 9600, 8, N, 1 for the beginning.
>> Then check that your terminal is set to display the same thing as you
>> send ( if you send hex don't expect that the terminal set for ASCII will
>> display correct your data)...
>> Last, the problem might be on the computer side as well, not necessarily
>> on the PIC...
>>
>> On Mon, May 16, 2022 at 9:27 PM flyway38  wrote:
>>
>>> Hi again,
>>>
>>> Correction to my last post.
>>> All working good using serial_software, with invert bit to false.
>>> But, still Frame or Break issues in communication using
>>> serial_hardware...
>>>
>>> Have done this Kiste test;
>>> forever loop
>>>serial_hw_data=0x22
>>>serial_hw_data=0x22
>>>delay_1s(1)
>>> end loop
>>>
>>> and here's the results;
>>> d7 00×.
>>> d5 00Õ.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d5 00Õ.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d7 00×.
>>> d5 00Õ.
>>> d7 00×.
>>> d7 00×.
>>> d5 00Õ.
>>> d7 00×.
>>> d5 00Õ.
>>> d5 00Õ.
>>> d7 00×.
>>> d7 00×.
>>>
>>> Any ideas?
>>> Thank you very much.
>>>
>>> Cheers,
>>> Filipe Santos
>>> On Monday, May 16, 2022 at 7:22:48 PM UTC+1 flyway38 wrote:
>>>
 Hey all,

 Miracles do happen.
 Maybe I have an easier way.
 Am using and FTDI cable (USB - RS232/5V) and it has a configurable
 EEprom.
 This configuration includes inversion of all RS232 signals. Have
 inverted RX and TX and this way am using now serial_software with that
 inversion bit to false.
 Computer receives good data, but it seems RX on PIC side shouldn't be
 inverted... not receiveing good data from computer.
 Can anyone confirm this? TX should be the only one to be inverted?
 Thank you very much.

 Kind regrads,
 Filipe Santos.

 On Monday, May 16, 2022 at 6:33:38 PM UTC+1 flyway38 wrote:

> Hi Rob,
>
> Yes, You're right.
> And yes, will change my design for that hardware comm line inversion.
> Then will back here for results or new issues :D
> Thank you very much for all help.
> Cheers.
>
> Kind regards,
> Filipe Santos.
>
> On Monday, May 16, 2022 at 11:41:31 AM UTC+1 rob...@hotmail.com wrote:
>
>> Hi Filip,
>>
>> If I understand you right you use inverted serial data. In the serial
>> software library everything - including the startbit - is inverted if you
>> select the inverted mode. In hardware only the data can be inverted but 
>> not
>> the startbit.
>>
>> Is it not possible to add an inverter to your board so that the data
>> is not inverted and so you can use serial hardware? You could make an
>> inverter with one transistor and 2 resistors.
>>
>> Kind regards,
>>
>> Rob
>>
>> --
>> 

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

[vsurducan]

Double check if you have correct settings, baud speed, bit number, parity
and stop bit. Set something like 9600, 8, N, 1 for the beginning.
Then check that your terminal is set to display the same thing as you send
( if you send hex don't expect that the terminal set for ASCII will display
correct your data)...
Last, the problem might be on the computer side as well, not necessarily on
the PIC...

On Mon, May 16, 2022 at 9:27 PM flyway38  wrote:

> Hi again,
>
> Correction to my last post.
> All working good using serial_software, with invert bit to false.
> But, still Frame or Break issues in communication using serial_hardware...
>
> Have done this Kiste test;
> forever loop
>serial_hw_data=0x22
>serial_hw_data=0x22
>delay_1s(1)
> end loop
>
> and here's the results;
> d7 00×.
> d5 00Õ.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d5 00Õ.
> d7 00×.
> d7 00×.
> d7 00×.
> d7 00×.
> d5 00Õ.
> d7 00×.
> d7 00×.
> d5 00Õ.
> d7 00×.
> d5 00Õ.
> d5 00Õ.
> d7 00×.
> d7 00×.
>
> Any ideas?
> Thank you very much.
>
> Cheers,
> Filipe Santos
> On Monday, May 16, 2022 at 7:22:48 PM UTC+1 flyway38 wrote:
>
>> Hey all,
>>
>> Miracles do happen.
>> Maybe I have an easier way.
>> Am using and FTDI cable (USB - RS232/5V) and it has a configurable EEprom.
>> This configuration includes inversion of all RS232 signals. Have inverted
>> RX and TX and this way am using now serial_software with that inversion bit
>> to false.
>> Computer receives good data, but it seems RX on PIC side shouldn't be
>> inverted... not receiveing good data from computer.
>> Can anyone confirm this? TX should be the only one to be inverted?
>> Thank you very much.
>>
>> Kind regrads,
>> Filipe Santos.
>>
>> On Monday, May 16, 2022 at 6:33:38 PM UTC+1 flyway38 wrote:
>>
>>> Hi Rob,
>>>
>>> Yes, You're right.
>>> And yes, will change my design for that hardware comm line inversion.
>>> Then will back here for results or new issues :D
>>> Thank you very much for all help.
>>> Cheers.
>>>
>>> Kind regards,
>>> Filipe Santos.
>>>
>>> On Monday, May 16, 2022 at 11:41:31 AM UTC+1 rob...@hotmail.com wrote:
>>>
 Hi Filip,

 If I understand you right you use inverted serial data. In the serial
 software library everything - including the startbit - is inverted if you
 select the inverted mode. In hardware only the data can be inverted but not
 the startbit.

 Is it not possible to add an inverter to your board so that the data is
 not inverted and so you can use serial hardware? You could make an inverter
 with one transistor and 2 resistors.

 Kind regards,

 Rob

 --
 *Van:* jal...@googlegroups.com  namens
 flyway38 
 *Verzonden:* zondag 15 mei 2022 21:20
 *Aan:* jallib 

 *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
 16F18313
 Hey all,

 Thank you very much to all.
 Yes, tried timeout option, but I loose alot of received data.
 I think that , for now (8 pin PIC), sending to pic dummy data to unlock
 that loop is my best option.
 This way 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