USB_help

[hans]

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

[hans]

Another addition:
At the bottom of the series of samples are files with the addition usb. I can't detect any USB function in this. Aren't these normal blink-a-led files?
regards
Hans

Op vrijdag 9 december 2022 om 16:42:37 UTC+1 schreef hans:

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

--
You received this message because 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.

[Rob CJ]

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 <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: vrijdag 9 december 2022 18:12
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] USB_help

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4quO70sp3CP%2BezE5_6jDU%2BpsJ2D7-MAU9bzRm1U1RbmACA%40mail.gmail.com.

[hans]

Hello,
Thank you. I did what you recommended. Last Bee and tip from Vasile. Same message from windows, not recognized and causing a malfunction. Pffffff/
regards
Hans

Op vrijdag 9 december 2022 om 18:43:24 UTC+1 schreef rob...@hotmail.com:

[Matthew Schinkel]

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.

[Matthew Schinkel]

Also use the code in 18f455_blink_hs_usb.jal

You are missing this one:

OSCCON_SCS = 0                      -- select primary oscillator

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/df1d95ac-2ed5-46e2-80c6-47021bf19395n%40googlegroups.com.

[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:

[hans]

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:

[Matthew Schinkel]

Hi Hans, what chip is it working on?

Is anyone else able to test the 18f4455 blink usb sample?

[hans]

Hi Matt,
I first tested with the 18F4455. It does not work with both the sample 18F4455-blink_hs.jal and the 18F4455_blink_hs_usb.jal. With Bert's old Picdev2, I did without changing the pcb.
Now I have exchanged the pic for the 18F4520 and the blink does not work there either with the 18F4520_blink_hs.jal.
  I can't test that in the Bert environment because  this pic was not included in his package.
I do use the wisp for programming.
Hans
Bert's program:

--JAL2.4j
include 18f4455_bert
--
pin_A0_direction = OUTPUT    -- for led
--
forever loop
   pin_A0= ON
   _usec_delay(100_000)
   pin_A0 = OFF
   _usec_delay(400_000)
end loop
-- main loop

Op zondag 11 december 2022 om 04:17:43 UTC+1 schreef mattsc...@hotmail.com:

[vsurducan]

Hans, you have to check carefully if USB has indeed 48MHz clock. The jal package sample is supposing you are using 20Mhz crystal, there is PLL and correct divisor. If is not so, the USB will not work with the config parameters in the sample.

Read first the USB operating theory and clock from datasheet and how to set your fusible for the right clock.

Then blink a LED but with the clock intended for USB ( below) , not other sample.

good luck!

include 18f4450                     -- target PICmicro
--
-- This program assumes that a 20 MHz resonator or crystal
-- is connected to pins OSC1 and OSC2, and USB active.
-- But PIC will be running at 48MHz.
pragma target clock 48_000_000      -- oscillator frequency
--
pragma target OSC      HS_PLL                    -- HS osc + PLL
pragma target PLLDIV   P5                        -- 20 MHz -> 4 MHz
pragma target CPUDIV   P1                        -- Fosc divisor
pragma target USBDIV   P2                        -- USB clock selection
pragma target WDT      CONTROL                   -- watchdog
pragma target XINST    DISABLED                  -- do not use extended instructionset
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED                  -- no clock monitoring
pragma target IESO     DISABLED                  -- no int/ext osc switching
pragma target VREGEN   ENABLED                   -- voltage regulator used
pragma target LVP      ENABLED                   -- low voltage programming
pragma target MCLR     EXTERNAL                  -- external reset

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/d6f2eb77-c5dc-4518-8560-fd45bf6a854fn%40googlegroups.com.

[Rob CJ]

Hi Hans,

I am not at home the coming week so I am not able to test but I assume it should work since blink samples are at least tested once when a new device is added.

Maybe somebody is able to help you, otherwise I can test it next weekend on a PIC18F4550 (same family).

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>
Verzonden: zondag 11 december 2022 10:07
Aan: jallib <jal...@googlegroups.com>
Onderwerp: Re: [jallib] USB_help

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/d6f2eb77-c5dc-4518-8560-fd45bf6a854fn%40googlegroups.com.

[hans]

Blink a led tested with an old sample, this works :

-- ------------------------------------------------------
-- Title: Blink-a-led of the Microchip pic18f4455
--
-- Author: Rob Hamerling, Copyright (c) 2008..2011, all rights reserved.
--
-- Adapted-by:
--
-- Revision: $Revision: 2902 $
--
-- Compiler: 2.4o
--
-- This file is part of jallib  (http://jallib.googlecode.com)
-- Released under the BSD license (http://www.opensource.org/licenses/bsd-license.php)
--
-- Description:
-- Sample blink-a-led program for Microchip PIC18f4455.
--
-- Sources:
--
-- Notes:
--  - File creation date/time: 7 Dec 2011 14:14:17.
--
-- ------------------------------------------------------
--
include 18f4455                    -- target PICmicro

--
-- This program assumes that a 20 MHz resonator or crystal

-- is connected to pins OSC1 and OSC2.
-- (unspecified configuration bits may cause a different frequency!)
pragma target clock 20_000_000     -- oscillator frequency
-- configuration memory settings (fuses)
pragma target OSC      HS               -- HS crystal or resonator
pragma target PLLDIV   P1           -- no divide
pragma target CPUDIV   P1           -- no Fosc divisor
--pragma target WDT      disabled     -- no watchdog
pragma target XINST    disabled     -- not supported by JalV2
pragma target DEBUG    disabled     -- no debugging
pragma target LVP      disabled     -- no Low Voltage Programming
pragma target MCLR     external     -- reset externally
-- These configuration bit settings are only a selection, sufficient for
-- this program, but other programs may need more or different settings.
--
enable_digital_io()                -- make all pins digital I/O
--
-- Specify the pin to which the LED is connected.
-- A low current (2 mA) led with 2.2K series resistor is recommended
-- since not all pins may be able to drive an ordinary 20mA led.
alias   led      is pin_A0
pin_A0_direction =  output
--
forever loop
   led = on
   _usec_delay(250_000)
   led = off
   _usec_delay(250_000)
end loop
--

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

[Rob CJ]

Hi Hans,

One of the differences is the use of Low Voltage Programming (LVP).

I think the Wisp does not support that, does it? Did you try programming it with a PICKit2 or PICKit3?

A few years ago all blink samples changed to LVP for those devices that support this.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>

Verzonden: zondag 11 december 2022 10:26

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/30b9e9b5-47be-4a79-84b0-bb6e3d7f8af2n%40googlegroups.com.

[hans]

Hello Rob,
That's right. Turned off LVP and the blinkers work. The USB does not work. I will order a pair of 16F1455 in hopes that will work.
regards
Hans

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

[Rob CJ]

Hi Hans,

The USB driver should work for the 18F.

It is important that the PIC runs at 48 MHz for the USB to work correctly. In the sample program that you use, you have to connect a 20 MHz crystal in order to let the PIC run at 48 MHz.

Are you using a 20 MHz crystal?

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>

Verzonden: zondag 11 december 2022 12:37

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/e5ad4404-21b0-49a0-9f99-8cbc9fa000e3n%40googlegroups.com.

[hans]

Hi Rob,

on the xtal is written 20.000, how can i know if this is true?

regards

Hans

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

[Rob CJ]

Hi Hans,

If it is printed on the crystal you may assume that it is correct. 

Met vriendelijke groet,

Rob Jansen

---

From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of hans <hanz...@zeelandnet.nl>
Sent: Sunday, December 11, 2022 7:56:54 PM
To: jallib <jal...@googlegroups.com>
Subject: Re: [jallib] USB_help

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/98e423f1-d9b9-4c3e-acdb-d732c44b71b3n%40googlegroups.com.

[Oliver Seitz]

Hi Hans,

to be really sure, put something like this to the beginning of your program:

for 10 loop

  LED=on

  _usec_delay(100_000)

  LED=off

  _usec_delay(900_000)

end loop

Compare the flashes with a ticking clock: If there's one flash per second, you've checked that

1. the PIC runs at all

2. the PIC runs at the speed the compiler assumes it to

3. the crystal is fine

Like every other thing in the world, also crystals may break. But, if they break, they're usually not 1% or 2% off of their rated frequency, but 50% or more. You would see such a wrong frequency with this test.

If, however, the crystal oscillator is loaded with wrong capacitors (say, 2x100pF instead of 2x27pF), there might result a frequency which "looks" right, but is out of spec for USB, which requires very small tolerances.

Greets,

Kiste

Am Montag, 12. Dezember 2022, 07:15:49 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:

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

[hans]

Hi Kiste/Rob
I have two PCB's on which the PIC should work, both fail. It seems strong to me that both the xtal would not be good. All the things I try work with it. Unfortunately I only have one PIC18F4455
I have already ordered the 16F1455's.
greetings and thanks for your response
Hans

Op maandag 12 december 2022 om 07:39:47 UTC+1 schreef Kiste:

[zet.weeh]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1c3098ea-5a51-4e41-a148-9782036d4b34n%40googlegroups.com.

[hans]

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:

[Rob CJ]

Hi Hans,

Can you share the schematic diagram for the 16F1455? I assume you used the standard sample program for the 16F1455.

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>
Verzonden: vrijdag 16 december 2022 14:20

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4a8e384e-f796-4b51-b9ea-ab93e2336a96n%40googlegroups.com.

[vsurducan]

Hi Hans,

could you test the following code? Just change the include PIC18F2550 with PIC18F4550

-- -------------------------------------------------

include 18f2550

-- even though the external crystal is 20 MHz, the configuration is such that
-- the CPU clock is derived from the 96 Mhz PLL clock (div2), therefore set
-- target frequency to 48 MHz
pragma target clock       48_000_000


-- fuses
pragma target PLLDIV        P5          -- divide by 5 - 20MHZ_INPUT
pragma target CPUDIV        P1          -- [primary oscillator src: /1][96 mhz pll src: /2]
pragma target USBDIV        P2          -- CLOCK_SRC_FROM_96MHZ_PLL_2
pragma target OSC           HS_PLL
pragma target FCMEN         DISABLED
pragma target IESO          DISABLED
pragma target PWRTE         DISABLED    -- power up timer
pragma target VREGEN        ENABLED     -- USB voltage regulator
pragma target VOLTAGE       V43         -- brown out voltage
pragma target BROWNOUT      DISABLED    -- no brownout detection
pragma target WDTPS         P32K        -- watch dog saler setting
pragma target WDT           CONTROL     -- watchdog software controlled
pragma target CCP2MUX       pin_C1      -- CCP2 on pin C1
pragma target PBADEN        DIGITAL     -- digital input port<0..4>
pragma target LPT1OSC       LOW_POWER   -- low power timer 1
pragma target MCLR          EXTERNAL    -- master reset on RE3
pragma target STVR          DISABLED    -- reset on stack over/under flow
pragma target LVP           DISABLED     -- allow low-voltage programming
pragma target XINST         DISABLED     -- extended instruction set
pragma target DEBUG         DISABLED    -- background debugging
pragma target CP0           DISABLED    -- code block 0 not protected
pragma target CP1           DISABLED    -- code block 1 not protected
pragma target CP2           DISABLED    -- code block 2 not protected
pragma target CP3           DISABLED    -- code block 3 not protected
pragma target CPB           DISABLED    -- bootblock code not write protected
pragma target CPD           DISABLED    -- eeprom code not write protected
pragma target WRT0          DISABLED    -- table writeblock 0 not protected
pragma target WRT1          DISABLED    -- table write block 1 not protected
pragma target WRT2          DISABLED    -- table write block 2 not protected
pragma target WRT3          DISABLED    -- table write block 3 not protected
pragma target WRTB          DISABLED    -- bootblock not write protected
pragma target WRTD          DISABLED    -- eeprom not write protected
pragma target WRTC          DISABLED    -- config not write protected
pragma target EBTR0         DISABLED    -- table read block 0 not 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  = 0xFFFF_FFFF
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

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4a8e384e-f796-4b51-b9ea-ab93e2336a96n%40googlegroups.com.

[hans]

Hi Vasile,

With this the connection is accepted. i see a new com port and on a terminal a bunch of values.

 I have to disconnect the Pickit. 

Can you complete this with the example in the sample ?

great

Hans

Op vrijdag 16 december 2022 om 15:46:26 UTC+1 schreef vasile:

[vsurducan]

Hans,

I think you are doing in this way:

1. USB connection is kept permanently between your board and PC

2. your board is programmed with pickit and after programming you expect to see immediately the pic USB device in your PC

right?

After programming you have to disconnect your PC from USB and connect it again, wait a bit until the computer sees your device.

I think the original sample will work in this way, however below is the the sample (using interrupts) which should work without disconnecting your PIC from USB after programming ( please note I did not tested, no PIC18F4450 or PIC2550 available now).

Finally you may comment the 5s delay if you wish, but you may loss the " JALLIB USB Serial Demo" string.

Hopefully will work for you.

-- ---------------------------------------

include 18f4550

-- even though the external crystal is 20 MHz, the configuration is such that
-- the CPU clock is derived from the 96 Mhz PLL clock (div2), therefore set
-- target frequency to 48 MHz
pragma target clock       48_000_000


-- fuses
pragma target PLLDIV        P5          -- divide by 5 - 20MHZ_INPUT
pragma target CPUDIV        P1          -- [primary oscillator src: /1][96 mhz pll src: /2]
pragma target USBDIV        P2          -- CLOCK_SRC_FROM_96MHZ_PLL_2
pragma target OSC           HS_PLL
pragma target FCMEN         DISABLED
pragma target IESO          DISABLED
pragma target PWRTE         DISABLED    -- power up timer
pragma target VREGEN        ENABLED     -- USB voltage regulator

pragma target VOLTAGE       V21         -- brown out voltage

pragma target BROWNOUT      DISABLED    -- no brownout detection
pragma target WDTPS         P32K        -- watch dog saler setting
pragma target WDT           CONTROL     -- watchdog software controlled
pragma target CCP2MUX       pin_C1      -- CCP2 on pin C1
pragma target PBADEN        DIGITAL     -- digital input port<0..4>
pragma target LPT1OSC       LOW_POWER   -- low power timer 1
pragma target MCLR          EXTERNAL    -- master reset on RE3
pragma target STVR          DISABLED    -- reset on stack over/under flow

pragma target LVP           ENABLED     -- allow low-voltage programming

pragma target XINST         DISABLED     -- extended instruction set
pragma target DEBUG         DISABLED    -- background debugging
pragma target CP0           DISABLED    -- code block 0 not protected
pragma target CP1           DISABLED    -- code block 1 not protected
pragma target CP2           DISABLED    -- code block 2 not protected
pragma target CP3           DISABLED    -- code block 3 not protected
pragma target CPB           DISABLED    -- bootblock code not write protected
pragma target CPD           DISABLED    -- eeprom code not write protected
pragma target WRT0          DISABLED    -- table writeblock 0 not protected
pragma target WRT1          DISABLED    -- table write block 1 not protected
pragma target WRT2          DISABLED    -- table write block 2 not protected
pragma target WRT3          DISABLED    -- table write block 3 not protected
pragma target WRTB          DISABLED    -- bootblock not write protected
pragma target WRTD          DISABLED    -- eeprom not write protected
pragma target WRTC          DISABLED    -- config not write protected
pragma target EBTR0         DISABLED    -- table read block 0 not 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 delay
include usb_serial
include print

-- constants
const  byte str_welcome[] = "JALLIB USB Serial Demo app\n"

-- variables

-- interrupts? No thanks
-- INTCON_GIE = false

-- setup the USB serial library
usb_serial_init()

var bit has_shown_welcome_msg = true
var byte ch

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
   

    -- check if USB device has been configured by the HOST
if ( usb_cdc_line_status() !=  0x00 )  then
if !has_shown_welcome_msg then
has_shown_welcome_msg = true
print_string( usb_serial_data, str_welcome )
end if
else
has_shown_welcome_msg = false
end if

-- check for input character
if usb_serial_read( ch ) then
-- echo input character
usb_serial_data = ch
end if

end loop

-- -------------------------------------------------------

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4c0c588f-12b8-47cb-a9c3-e8f21dd63f9an%40googlegroups.com.

[hans]

Hello Vasile
I have always worked as you indicated. Program, unplug everything and then plug it back in. prompt response that the case was not recognized. See my previous message.
Now your latest version, does nothing at all. Loaded the previous version again and it works as stated before.
regards
Hans

Op vrijdag 16 december 2022 om 18:07:52 UTC+1 schreef vasile:

[Rob CJ]

Hi Hans, Vasile,

What has been changed that it now works?

If I look at the setting for the chip I do not see a difference with the program that Hans had sent before.

I see in the program below a delay of 5 seconds but that will cause a problem.

There are two ways to use the USB library, without interrupt (which used to be the only way to use it) and with interrupt.

If you use it without interrupt you have to call the usb_serial_flush() routine regularly otherwise the USB wil stop working. 

If you cannot serve this function regulary then you should use the library in the mode that is uses the interrupt which I see is being used in the last example.

If this 5 seconds delay was in the previous program then that may have caused the USB problem.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>

Verzonden: vrijdag 16 december 2022 18:52

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/7ae2a91b-f74b-43f5-b14a-247a8d6afa20n%40googlegroups.com.

[hans]

Hi Vasile, Rob,

Having often problems with the LVP I often disable this. I did this in the first program from Vasile and have forgotten this to mention. 

Doing the same in the last version and ....................IT WORKS !!!!!!!!!!!!!!!!!!!

But i had to start the PICKIT several times again with all trics i know. GRRRRRR

regards

Hans

Op vrijdag 16 december 2022 om 20:02:47 UTC+1 schreef rob...@hotmail.com:

[vsurducan]

Aleluia! Say thanks to Rob which adjusted the usb serial lib with interrupts.

The serial usb connectivity depends also on laptop and terminal. Use a terminal which does not hang in a bunch of data. Do not disable intcon_gie if use usb serial with interrupts. Do not expect to solve fast things in pic while usb communication works. Maibe packing data and send it all from time to time.

Nothing more to say.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/6413a27f-5df9-44d0-a18c-7040f7fedc94n%40googlegroups.com.

[vsurducan]

It seems to me that flushing was the problem. It works with interrupts but jal 1.7.0 seems to not have the usb serial interrupt sample for pic18f4550?

That delay is ok if you program the pic while is connected to usb. It tooks a while until pc see the pic, but that depends on pc, os, etc. If you send only once a text (as the sample is), there are big chances to not see it on pc. 

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

[Rob CJ]

Hi Vasile,

Thanks for the update. I can add a sample for the PIC18F4550 to the new Jallib release.

@Hans. Can you send the version that works OK?

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>

Verzonden: zaterdag 17 december 2022 08:00

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvs42vwf5kURjTKqZgpjdnakLP5HmTzce91CZxtzxfevw%40mail.gmail.com.

[vsurducan]

Hmm, let me find an 18F2550 and check.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/7ae2a91b-f74b-43f5-b14a-247a8d6afa20n%40googlegroups.com.

[hans]

Hi Vasile,
I have now discovered that if I turn off the LVP all examples work. Apparently, activating the lvp causes both the Wisp and Pickit3 to interact with it, causing this problem.
I'm going to always turn off the LVP from now on (if I don't forget!!)
Greetings and thanks again for all your responses.
Hans

Op zaterdag 17 december 2022 om 17:39:22 UTC+1 schreef vasile:

[hans]

Another addition Vasile, I also tested with the pickitminus, but the case does not work with or without the LVP.
I'm now looking for a cure for programming headaches.
Maybe I'd better go back to the antique things that I've been able to experience so much for years.
regards
Hans

Op zaterdag 17 december 2022 om 18:33:20 UTC+1 schreef hans:

[vsurducan]

I never experienced this problem, so I'm useless for LVP/USB interaction.

What I know for sure is this: once USB works for you, save in a separate folder ALL libraries related to your test program and the compiler, test carefully that compilation works only from that folder and write a note named maybe "warning.jal" describing clearly what was the issue and how you solved it. In this particular way you will never encounter a similar issue using the same compiler revision.

Of course you will see other issues...:)

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/62213503-a53a-4c65-b7db-25d3b8b25187n%40googlegroups.com.

[hans]

Hi Vasile,

Your message has made me think and it brings me to a phenomenon that I have paid little attention to until now.

I'll try to explain.

1. I have several complete JAL packages on my PC. If a newer version is available I will keep the old one. Including the complete package from Bert's book because I have made a lot of things with it.

2. When I start something new I create a new folder, put a copy from the sample list in it and only if I change something from the lib list do I put that in there too.

3. Here's the thing: For example, if I want to view and edit something in an older Jal package and I click the OPEN function, Jaledit shows me the file map I've been working on recently.

4. If I then go to another package and do the same there, it shows the list of recent files from the other package.

5. So somewhere there must be a link between all those packages. So it could very well be that jaledit is using the wrong link

6. I will change my method and put everything in one folder as you indicated.

 

I hope you understand my story.

regards

Hans

Op zondag 18 december 2022 om 07:20:46 UTC+1 schreef vasile:

[Rob CJ]

Hi Hans,

If you install a new bee package then it should carry the same name as your previous Jallib directory. This because JALEdit will always point to the name of that directory and searches for the libs there.

In the tools --> Environment options window of JALEdit you find something like this (directory names will be different on your machine):

So if you download a bee-package and put it in a name with a different directory, JALEdit will still use the older Jallib version.

This is what I do:

1. Download the bee-package to the download folder of Windows
2. Extract the zip file with the destination directory Jallib
3. Delete C:\Jallib
4. Move Jallib from the download folder to C:\Jallib

You then always have the most recent libraries and compiler version.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens hans <hanz...@zeelandnet.nl>
Verzonden: zondag 18 december 2022 08:46

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/fb15b457-7816-410f-9ec4-7a2e65ca550cn%40googlegroups.com.

[hans]

Hello Bob,
I think you didn't understand me, sorry.
All references are in the tools as you indicated.
EXAMPLE:
1. I have done some things in Bert's package where all references to this package are in the tools.
2. I close the case and open another Jal package (e.g. the latest version). All references are listed there as well.
3. When I then use the OPEN button, I get to see the list of files from Bert's package.

Op zondag 18 december 2022 om 09:58:49 UTC+1 schreef rob...@hotmail.com:

[hans]

Forgot to specify that the two packages are on different disks.

Op zondag 18 december 2022 om 10:29:40 UTC+1 schreef hans:

[hans]

I KEEP ON CRACKING!!!
I have completely reset a WIN 10 laptop to the factory setting and put the latest JAL on it.
  If I now put the 16F1455 usb-serial via the pickitminus on my test pcb, both the version with and without the LVP work.

 I really don't understand why I have to turn off the LVP on my PC, which has several Jal packages on it, to get a working program.
I'm going to check everything again closely.
regards
Hans

Op zondag 18 december 2022 om 11:44:27 UTC+1 schreef hans:

[rob...@hotmail.com]

Hi Hans,

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.

This is only needed for PICs that have this separate PGM pin. Other (newer?) PICs without PGM and LVP do not require that.

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.

If there is a preference by other Jallib users, let me know. I attached a screenshot from a datasheet that show this LVP set-up with the PGM pin.

Thanks to the other Rob for finding this out.

Kind regards,

Rob

Op zondag 18 december 2022 om 12:13:56 UTC+1 schreef hans:

[Rob Hamerling]

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 Hamerling, Vianen, NL

[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: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: dinsdag 3 januari 2023 16:59

Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] USB_help

--

You received this message because 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/bcc403f2-6580-1d18-0d8a-25109e7a933d%40gmail.com.

[Rob Hamerling]

Hello RobJ,

I think your interpretation of the datasheet (Programming Specifications) is wrong.
The comment should inform the user that with LVP ENABLED a pull-down resistor is required on the PGM pin.

Regards, Rob.

On 03/01/2023 17.36, Rob CJ wrote:

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: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: dinsdag 3 januari 2023 16:59
Aan: jal...@googlegroups.com <jal...@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 Hamerling, Vianen, NL

--
Rob Hamerling, Vianen, NL

[hans]

Hi Robert and Rob,
A cry from THE RETIRED HOUSE.:
Two possibilities in my opinion, depending on the target group of the samples. If most of that group apply the LVP then leave the LVP ON and warn the others. Or conversely set it to OFF and alert the LVPers.
Not a problem for me, I just turn it off for a long time (usually !!).
Happy New Year.
Hans

Op dinsdag 3 januari 2023 om 20:50:34 UTC+1 schreef Rob Hamerling:

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

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

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

[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: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: woensdag 4 januari 2023 07:49

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.

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

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

[Rob CJ]

Hi Vasile,

I understand what you are saying. With a very small correction in the blink-a-led.py script I was able to add the following to the blink samples that have the option to use LVP and that have a PGM pin.

For those PICs it says:

pragma target LVP      ENABLED                   -- low voltage programming, pull PGM pin LOW for normal operation

For all other PICs it remains:

pragma target LVP      ENABLED                   -- low voltage programming

It is a small fix and I add this easily.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>

Verzonden: donderdag 5 januari 2023 06:25

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4quKe-rUVhVrrtHZW06zGAiYuOUjp042drzn%2BrZPF0-Otw%40mail.gmail.com.