HPWM problem using the PIC12F1571

[laserline]

I am not being able to compile a simple code using the HPWM command on the PIC12F1571.
This model has a 16-bit PWM module.
Anyone knows if this could be the problem?

When the "HPWM 1,128,32000" line is present the compiler shows the messages:
- Unmatched (
- Illegal argument

...

[top204]

That anomaly was due to a typo that was missing a single closing brace from an expression placed after an assembler mnemonic, in the compiler's assembler library code for that particular device that has a different method of operating PWM. Microchip cannot quite make their mind up how some devices work, and keep changing them. Even in the same family!!!!

A correction update is downloadable from here:
Positron Corrections Update 4.0.2.3-1.1.0.9

[laserline]

Thx a lot!
Any plan to implement the use of the 16-bit capability with the HPWM on these chips?

[top204]

Any plan to implement the use of the 16-bit capability with the HPWM on these chips?

Because the compiler now has true procedures, there is no need for new built-in functions anymore, because libraries can be created by users for a particular device and feature. Also, Microchip are constantly changing how peripherals work on devices, so the built-in functions constantly have to be changed when a new device is brought out, and the logistics of doing that is out of my reach as a single developer.

That is why I was determined to create procedures in the, once flat, language.

For example, something like the code listing below, which can be altered to suite a user's requirements. It was an early experiment that I did to get the PWM1 peripheral operating as a test to see how it worked on the PIC12F157x devices, because Microchip, yet again, changed the peripheral's operating mechanism for these devices:

Code Select Expand

'
'   /\\\\\\\\\
'  /\\\///////\\\
'  \/\\\     \/\\\                                                 /\\\          /\\\
'   \/\\\\\\\\\\\/        /\\\\\     /\\\\\\\\\\     /\\\\\\\\   /\\\\\\\\\\\  /\\\\\\\\\\\  /\\\\\\\\\
'    \/\\\//////\\\      /\\\///\\\  \/\\\//////    /\\\/////\\\ \////\\\////  \////\\\////  \////////\\\
'     \/\\\    \//\\\    /\\\  \//\\\ \/\\\\\\\\\\  /\\\\\\\\\\\     \/\\\         \/\\\        /\\\\\\\\\\
'      \/\\\     \//\\\  \//\\\  /\\\  \////////\\\ \//\\///////      \/\\\ /\\     \/\\\ /\\   /\\\/////\\\
'       \/\\\      \//\\\  \///\\\\\/    /\\\\\\\\\\  \//\\\\\\\\\\    \//\\\\\      \//\\\\\   \//\\\\\\\\/\\
'        \///        \///     \/////     \//////////    \//////////      \/////        \/////     \////////\//
'                                  Let's find out together what makes a PIC Tick!
'
' Experimental procedures for 16-bit PWM1 on a PIC12F1571 device
' Written by Les Johnson for the Positron8 BASIC compiler.
'
    Device = 12F1571                                ' Tell the compiler what device to compile for
    Declare Xtal = 16                               ' Tell the compiler what frequency the device will be operating at (in MHz)
'
' Create some defines for the PWM1 peripheral
'
$define PWM1_Start() PWM1CONbits_EN = 1             ' Start the PWM1 peripheral
$define PWM1_Stop() PWM1CONbits_EN = 0              ' Stop the PWM1 peripheral
$define PWM1_LoadBuffer() PWM1LDCONbits_LDA = 1     ' Load the phase of the PWM1 peripheral
'
' Create a variable to act as a parameter alias, to save RAM
'
    Dim PWM_wParam As Word

'----------------------------------------------------------------------------
' The main program starts here
'
Main:
    IntOsc_16MHz()                                  ' Set the device to use the internal oscillator at 16MHz

    PWM1_Init()

'----------------------------------------------------------
' Initialise the PWM1 peripheral
' Input     : None
' Output    : None
' Notes     : None
'
Proc PWM1_Init()
    PWM1INTE = $00
    PWM1INTF = $00
    PWM1CLKCON = $00            ' No_Prescalar
    PWM1LDCON = $00
    PWM1OFCON = $00
    PWM1PHL = $00               ' \
    PWM1PHH = $00               ' / Phase SFRs
    PWM1DCL = $E0               ' \
    PWM1DCH = $03               ' / Duty SFRs
    PWM1PRL = $CF               ' \
    PWM1PRH = $07               ' / Period SFRs
    PWM1OFL = $6D               ' \
    PWM1OFH = $6D               ' / Offset SFRs
    PWM1TMRH = $00              ' \
    PWM1TMRL = $00              ' / PWM Timer SFRs
    PWM1CON = 0b01000000        ' Setup for an active high, standard PWM
    PWMENbits_PWM1EN_A = 1
    PWMLDbits_PWM1LDA_A = 1
    PWMOUTbits_PWM1OUT_A = 0
    PinOutput PORTA.1           ' Make the PWM1 pin an output
EndProc

'----------------------------------------------------------
' Alter the phase of the PWM1 peripheral
' Input     : pPhase holds the 16-bit phase value
' Output    : None
' Notes     : None
'
Proc PWM1_Phase(pPhase As PWM_wParam)
    PWM1PHH = pPhase.Byte1
    PWM1PHL = pPhase.Byte0
EndProc

'----------------------------------------------------------
' Alter the duty of the PWM1 peripheral
' Input     : pDuty holds the 16-bit duty value
' Output    : None
' Notes     : None
'
Proc PWM1_Duty(pDuty As PWM_wParam)
    PWM1DCH = pDuty.Byte1
    PWM1DCL = pDuty.Byte0
EndProc

'----------------------------------------------------------
' Alter the period of the PWM1 peripheral
' Input     : pPeriod holds the 16-bit period value
' Output    : None
' Notes     : None
'
Proc PWM1_Period(pPeriod As PWM_wParam)
    PWM1PRH = pPeriod.Byte1
    PWM1PRL = pPeriod.Byte0
EndProc

'----------------------------------------------------------
' Alter the offset of the PWM1 peripheral
' Input     : pPeriod holds the 16-bit offset value
' Output    : None
' Notes     : None
'
Proc PWM1_Offset(pOffset As PWM_wParam)
    PWM1OFH = pOffset.Byte1
    PWM1OFL = pOffset.Byte0
EndProc

'----------------------------------------------------------
' Setup the internal oscillator to operate at 16MHz
' Input     : None
' Output    : None
' Notes     : None
'
Proc IntOsc_16MHz()
    OSCCON = 0b01111010   ' Setup for INTOSC, SPLLEN disabled, and 16MHz HF operation
    OSCTUNE = $00
    BORCON = $00
EndProc

'----------------------------------------------------------------------------
' Set the fuses for an internal oscillator on a PIC12F1571 device
'
    Config1 FOSC_INTOSC, WDTE_OFF, PWRTE_OFF, MCLRE_ON, CP_OFF, BOREN_OFF, CLKOUTEN_OFF
    Config2 PLLEN_OFF, LVP_OFF, BORV_LO, WRT_OFF, STVREN_OFF, LPBOREN_OFF

The code needs work doing to it for refinements, but I tested it in the simulator and took a screenshot of it operating:

[laserline]

Sorry to inform but the compiler is presenting the same problem compiling a single HPWM command on the PIC12F1501 as well.

- Unmatched )
- ASSEMBLER ERRORS. HEX file not Created.

[trastikata]

Sorry to inform but the compiler is presenting the same problem compiling a single HPWM command on the PIC12F1501 as well.

It works now on mine, did not work before that though. Maybe you can try reinstalling the update.

Edit; I missed it is about 12F1501 and did the test with 12F1571

[top204]

Yes....

There is the same typo for the 12F1501 device as well. :-( The PIC12F1571 now works perfectly, but I did not check for the typo in the other HPWM type sections of the compiler's code, because they are all based upon each other, but with slight differences for the different device types. So when I pasted the original code I created in a "if(Global_HPWM_Type == x)" section, then made changes in that section, I had the typo in there to start with. The "real world" can sometimes be a dreadful place. LOL.

I just wish microchip would stop messing around with their devies. Even devices that have the same peripheral, have different ways of manipulating them for some inexplicable reason. There is no structure to their devices now and no set format as there used to be with them. It's as if each new, third party, group that they get in to design a device based upon other devices, change things for the sake of change! Or is it deliberate, so people "must" use their C compilers and their libraries that are locked and not open to view as they used to be? You cannot put anything past a very large company ran by lawyers and money men, because nothing else matters except money to them!!!


As soon as I get the time, I will create another corections update.

[JonW]

You can always create a work around with a proc or sub. This will also get you familiar with the architecture of the specific mcu.  As mentioned in many posts the architecture of Pics seems to be somewhat random in evolution  and since the addition of procedures it's just so easy and sometimes more efficient, to create a  new command in a proc.

[laserline]

Sorry, but in my opinion, the main reason to use a BASIC based compiler like Proton is to have these functions ready to use, not spending much time to finish a simple code. If I have to write my own procedures I believe I would rather use XC8 instead.

[keytapper]

I disagree, you of course may go for the microchip tools,  just be ready to shell out a conspicuous amount of money.
Just like to choose from a simple utilitarian and a top class car. But the point is that you should appreciate this compiler for its worthiness of money.

[tumbleweed]

...just be ready to shell out a conspicuous amount of money.

they're free.

[Ivano]

Laserline,
I find this compiler fantastic and also the work of the community which always gives indications on how to solve problems.
As you can see your problem has been solved with a quick update, difficult to find such efficiency.
Positron compiler provides many powerful commands, and with procedures it is also fun to create commands, such as creating programs. Then if one wants to find everything ready without effort, he can also do without using the compiler and ask someone to build the programs ... for a fee ...
Sorry google translator

[John Lawton]

...just be ready to shell out a conspicuous amount of money.

they're free.

The Pro version with Optimiser costs £36.61 per month...

[tumbleweed]

...just be ready to shell out a conspicuous amount of money.

they're free.

The Pro version with Optimiser costs £36.61 per month...

The XC compilers allow up to optimization level 2 for free, which for most users is fine. That's one step below what you get when you pay the ridiculous fee for the "Pro version"
 

[Stephen Moss]

Sorry, but in my opinion, the main reason to use a BASIC based compiler like Proton is to have these functions ready to use, not spending much time to finish a simple code.

The fact that a compiler like Positron has many useful commands built in is certainly of benefit to beginners and can help them get off to a fast start. However, in my opinion the downside of that is that it can also result in laziness and an unwillingness in a user to learn how to read data sheets and or control a Microcontroller peripheral through register read/writes.
It is unreasonable to expect that any software has a Command or Function available to do exactly what you need. Thus learning how to understand datasheets and read/write to control registers is a useful thing to do as in addition to enabling you to do things for which there is no command, it can sometimes give you more control than an Command can, as a command may only work on a basic/fundamental level operating on only the parts that are common to all devices and so occasionally it can be better to code it yourself than use a command to set something up exactly as you need it.

Thus the macros, defines and procedure functions Positron offers that could be used to effectively create your own command is probably quite a powerful feature, if you can learn how to use it.

[JonW]

Sorry, but in my opinion, the main reason to use a BASIC based compiler like Proton is to have these functions ready to use, not spending much time to finish a simple code. If I have to write my own procedures I believe I would rather use XC8 instead.

"Using a procedure is a work around"  If its simple code then why not use XC8 and save the time learning a new compiler?  Plus knowing Microchip there could be host of hardware errata issues so understanding the hardware implementation and how to create a new procedure may actually benefit you in the long term as there is not a compiler on the planet that can work around these automatically .   

[tumbleweed]

It is unreasonable to expect that any software has a Command or Function available to do exactly what you need.

+1

That, coupled with the fact that Microchip changes peripheral functions at the drop of a hat makes it an almost impossible task to keep up with the changes, even among devices in the same family.

[RGV250]

Hi,

Sorry, but in my opinion, the main reason to use a BASIC based compiler like Proton is to have these functions ready to use, not spending much time to finish a simple code. If I have to write my own procedures I believe I would rather use XC8 instead.

I am a bit baffled by this statement, what do you consider "simple code".
What made you choose Positron in the first place, by your comment about using XC8 it implies you have used C or whatever XC8 uses and decided it is a nightmare so came to Proton/Positron. If the function is not available and you have to write your own you still have the luxury of being able to do it in BASIC which Les has taken to a new level and made that even nicer, a bit like BASIC++.
I have looked on other forums and never have I seen the developer post code examples like Les does which even if they have no use are nice to study to see how nice code should look.

The other thing I would be wary about using a free offering, in the future they may just decide to change the terms and you are trapped into either paying or starting again with a different compiler.

My 2 pennies worth
Bob

[keytapper]

they're free.

Bloatware included ?
 IMHO There's no competitors that can make a PIC working at this efficiency. With such elegant language.

[charliecoutas]

I agree with Keytapper. Proton/Positron is unique. there is nothing that gives such a fast response to requests for features and, inevitably, in resolving problems, sometimes with the compiler. If you think you can do better elsewhere then that's up to you. This forum contains a dedicated bunch of users who know what they are doing and and only too willing to help, encourage and support others.

I suspect that this is because it is driven by a desire to help and encourage rather than to boost the balance sheet.

My twopennyworth.

Thanks Les.

Charlie