Shin command not working 18f45k80

[Samir sayyed]

shin command working with pic 18f452 and 16f877 but not working pic 18f45k80 and 16f1789 anyone success

[RGV250]

Hi,
Have you set all the config settings etc, does the pin you are using have other peripherals on it, have you tried other pins?

Regards,
Bob

[John Lawton]

shin command working with pic 18f452 and 16f877 but not working pic 18f45k80 and 16f1789

Which port/pin are you trying to use?

[Samir sayyed]

Dataout portc.1
Datain portc.2
Clock portc.3

[John Lawton]

Do all these port lines work in the flashing a LED test?

These devices have multiple peripherals that share port lines as detailed in the datasheet(s) in the PORTS section. I would advise disabling any unused peripherals that are using these lines in case of conflicts, including analogue and comparator inputs.

[Samir sayyed]

Yes all Led work in this port

[John Lawton]

Yes all Led work in this port

Okay, maybe check that PortC.2 is working as an input? If so than I'm out of ideas except to suggest that you post some of your code.

[tumbleweed]

When building for an 18F45K80, it appears to be setting the analog/digital select registers improperly.

Code Select Expand

    setf ANCON0,1
    setf ANCON1,1
On this one, ANCONx must be set = 0 for digital mode, otherwise the pins will always read '0'.

Try adding this to your code before the SHIN:
ANCON0 = 0
ANCON1 = 0

[Samir sayyed]

Thanks sir I try it

[dionbrewington]

I have been switching from a 18f4685 to a 18f47q43 and one of the issues I came across today was that busin/busout worked fine with the 4685 but failed with the q43 part giving incorrect values.  In my case after I stripped the code down I found that after I had a minimal amount of dim variables then it started working with the q43.  I wonder if this is also affecting the shin command for you.  You might want to try a stripped down program with just the basics to test with minimal variables and see if it then works. In my case after compiling if it read 272 variable bytes or less at the bottom busin/busout worked.  Any more than that and the results were wonky.  I don't have a solution yet to my case but am just wondering if its related to your situation.

[top204]

The devices that the, possible, issues are being seen on use the same RAM architecture as standard 18F and enhanced 14-bit core devices, so the underlying library assembler code is the same because it does not use any peripherals.

This means if it works on a standard 18F device, it will work with the 18FxxK80 device and the same for the 16f1789.

Over the weekend, I'll see if I have the 16f1789 device and run some tests with a serial EEPROM, the same with the 18FxxK80. Just in case there are subtle differences that have not been clarified in the datasheet, but I cannot see any differences at all.

[Samir sayyed]

Please check asm routine 1st routine is working properly
      movlw 8
__shin_
    movwf PP3
    movwf PP3H
    setf FSR0H
    movff GEN2,FSR0L
    movf GEN2H,W
    btfsc GPR,2
    rcall __set_pin_high__
    btfss GPR,2
    rcall __pull_pin_low__
    setf FSR1H
    movff GEN2,FSR1L
    movf GEN,W
    addlw 18
    movwf FSR0L
    movf GENH,W
    iorwf INDF0,F
    movff GEN,FSR0L
    clrf PP0
    clrf PP0H
    movf PP3,W
    bz __shin_exit__
__shin_loop__
    btfsc GPR,1
    rcall __shiftX_toggle_clock__
    movf INDF0,W
    andwf GENH,W
    addlw 255
    rlcf PP0,F
    rlcf PP0H,F
    btfss GPR,1
    rcall __shiftX_toggle_clock__
    decfsz PP3,F
    bra __shin_loop__
    movf PP3H,W
    btfsc GPR,0
    bra __reversebits__16_
    movf PP0,W
__shin_exit__
    return
__shout_8_



2nd routine not working

  __shin8_
    movlw 8
__shin_
    clrf FSR0H
    movwf PP3
    movwf PP3H
    movf GEN2,W
    movwf FSR0L
    movf GEN2H,W
    btfsc GPR,2
    iorwf INDF0,F
    xorlw 255
    btfss GPR,2
    andwf INDF0,F
    bsf FSR0L,7
    andwf INDF0,F
    movf GEN,W
    movwf FSR0L
    movf GENH,W
    bsf FSR0L,7
    iorwf INDF0,F
__shin_loop__
    clrf PP0
    clrf PP0H
    btfsc GPR,1
    call __shiftX_toggle_clock__
    movf GEN,W
    movwf FSR0L
    movf INDF0,W
    andwf GENH,W
    addlw 255
    rlf PP0,F
    rlf PP0H,F
    btfss GPR,1
    call __shiftX_toggle_clock__
    decfsz PP3,F
    bra __shin_loop__
    movf PP3H,W
    btfsc GPR,0
    goto __reversebits__16_
    movf PP0,W
    return
__shout_8_
    movlw 8
  CWRITE ALSO NOT WORKING

[top204]

They are assembler files for differnt device families, so they will not be exactly the same because of the device's architecture. I can tell because the code above uses the Rlcf mnemonic and the code below uses the Rlf mnemonic.

I will be examining the issue, but they look OK and the only real difference between devices is the distance between the PORT and the TRIS SFRs, so that the indirect Port.Mask values that get sent to the routines can make pins input and output.


On the newer devices, CWrite is now a rather outdated command because Microchip keep changing the erase and write block size, and the commands were originally created when the devices were much more stable and a flash memory byte/word could be erased, and written a byte/word at a time, or all of them had a fixed block size. The CWrite command is more generic, so cannot always cater for the querks in the newer devices.

My recommendation for writing to flash memory is to examine the datasheet and make sure you understand the erase/block size and create a procedure to cater for the device's querks. This way you can tailor your program to suit better, and have a better understanding of the device's architecture.

The CWrite command is something I am considering getting rid of because of the complexities that are now in each individual device and the differences between devices of the same family even!