16F1459 Uart Setup bug

[JonW]

Hi Les

Hrsout "Test" using a 16F1459 throws a compilation error : Symbol not previously defined (SPBRG).  The assembly references SPBRG but the PPI file uses SPBRGL.  It can be fixed by changeing the SPBRGL to SPBRG in the PPI file.

Assembly listing with error

_COMPILER_MAIN_START_
    MOVLB ((SPBRGL)>>7)
; UART1_ACTUALBAUD = 115384.62
; UART1_BAUDERROR = 0.16
    MOVLB 0X03
    BCF BAUDCON,PP_BRG16
    MOVLB 0XFF
    MOVLW 0X19
    MOVWF SPBRG
    CLRF SPBRGH
    MOVLB 0X03
    MOVLW 0X24
    MOVWF TXSTA
    MOVLW 0X90
    MOVWF RCSTA
    MOVLB 0X00
    CLRF BPF   

Hrsout works ok after the PPI change.

[top204]

Thanks for finding that Jon. It's been with the compiler since 2012 and has taken 12 years to spot! :-) (See that date at the top of the device's ppi file: "Creation Date 03/10/2012")

I thought I had catered for all the name changes that microchip do, but it appears I forgot one iteration of it. In the Baud caclualtor code, I have the comparisons:

Code Select Expand

//
// Find the SFR name of SPBRG1\H for the device used
//
    if(VariableExists("SPBRG1L") == true)
        {
            strcpy(SPBRG1_SFR, "SPBRG1L");
            strcpy(SPBRG1H_SFR, "SPBRG1H");
        }
    else if(VariableExists("SP1BRG") == true)
        {
            strcpy(SPBRG1_SFR, "SP1BRG");
            strcpy(SPBRG1H_SFR, "SP1BRGH");
        }
    else if(VariableExists("SP1BRGL") == true)
        {
            strcpy(SPBRG1_SFR, "SP1BRGL");
            strcpy(SPBRG1H_SFR, "SP1BRGH");
        }
    else if(VariableExists("SPBRG1") == true)
        {
            strcpy(SPBRG1_SFR, "SPBRG1");
            strcpy(SPBRG1H_SFR, "SPBRG1H");
        }
    else
        {
            strcpy(SPBRG1_SFR, "SPBRG");
            strcpy(SPBRG1H_SFR, "SPBRGH");
        }

But I forgot:

Code Select Expand

    else if(VariableExists("SPBRGL") == true)
        {
            strcpy(SPBRG1_SFR, "SPBRGL");
            strcpy(SPBRG1H_SFR, "SPBRGH");
        }

It is now corrected, and an update will be uploaded very soon.

The HSerial1_ChangeBaud command has also been corrected for the SPBRGL and SPBRGH SFRs on the enhanced 14-bit cores with different names for them.

A fruitless wish, but I wish microchip would keep to some standards! They constantly rename SFRs and SFR bits and config fuse names for no reason whatsoever. It just seems to be based on a whim for whoever they have employed third party for that particular device's data, or data update!

[JonW]

No problem, Les. I may find more as I slowly bring the peripherals up. I also forgot to mention that if you copy over one of the USB examples (Changing the appropriate commands for 16f1459) the compiler returns that the Microcontroller does not support USB.  Is there a specific reason why the USB was not added?  I know the USB works as I quickly built up a breadboarded demo while my boards are being manufactured and loaded in a hex file from a microchip CDC demo and it works.

[JonW]

A fruitless wish, but I wish microchip would keep to some standards!

I think they do it to keep you on your toes Les!

[top204]

The compiler does not support the USB commands for the enhanced 14-bit core devices, so the ppi file is set for no USB, so the USB RAM is available for users.

[JonW]

No problem, even more reason to force me to write a USB stack using procedures.

[John Lawton]

I haven't checked but Microchip may have a USB stack for these micros?

John

[JonW]

They do. John and I have tried looking at them in IDE, but there are so many files, and I have read that others have not used them due to the bloated code size.  One guy has written a stack in the assembly that is a quarter the size of a microchip's attempt, so I will use that as a backup.  I want to learn the specifics of the USB protocol and write my stack to force me to understand it.  It's not paid work, so I am happy crunching through it, I did find out that the MCP2221/A is a 1459!.  I am trying to read the USB 2.0 specs at bedtime. Unfortunately, I only get about 4 paragraphs in, and I'm asleep.

[John Lawton]

Hi Jon,

I admire your wish to understand USB workings, I wish you luck.

I don't find reading technical stuff at bedtime very restful so I prefer reading fiction, but Microchip's datasheets don't really count as that.

John

[JonW]

I have already spent a lot of money on boards, analysers, and time, so I am committed now. The £40 Alex Tardov USB packet analyser arrived and worked with wireshark. It's nowhere near as good as the Saleae decoder, but it does capture the packets ok. I will investigate more and report back.

[JonW]

Les, If the PPI was modified to enable the USB, would the libraries work for that device or is it too much trouble? I can still use the other examples and look at how you managed the stack.  Also if you have any pointers on building a stack, please fire away

Cheers

Jon

[top204]

Unfortunately not Jon.

The USB on the enhanced 14-bit core devices is different to the standard 14-bit core and the 18F devices, so one will not work for the other. Heck.... It's even different on some 18F device families.

It will require a set of library files, like the ones I created for USB on the 18F devices, quite a few years ago.

[JonW]

No worries Les I will work around it.  I'll send you a board or two when they come in.