CCS News

The Microchip PIC^® Microcontrollers (MCUs) have become the most popular choice for new 8 bit embedded designs. Other features include running at a speed of up to 280 million instruction per second, a low cost of some under $1, and large number of interfaces like USB, Ethernet and analog signals are useful features of PIC^® MCUs.

The C programming language, originally developed by AT&T Labs by authors Brian Kerninghan and Dennis Ritchie, known as K&R C, became an international standard by ANSI in 1989. The C programming language syntax is the core of many newer programming languages. In 2003 a new standard derived from C defined the C++ language. C++ has some complex language elements that make it impractical for use on a microcontroller as opposed to a desktop PC. C is now the most popular language for programming microcontrollers and it is important for students to learn.

Whether you are an instructor looking to teach embedded C programming in a classroom setting, or a hobbyist looking to learn a new skill, Embedded C Programming:Techniques and Applications of C and PIC^® MCUs by Mark Siegesmund is a great resource. It provides hands-on introductory concepts of C programming using PIC^® microcontrollers with the CCS C compiler. The book demonstrates programming methodology and tools used by professionals in the field of embedded design by using a step-by-step approach. The writing is reader-friendly and the principles of the C programming language are introduced gradually. Each chapter builds on concepts introduced in the previous chapter, forming a strong foundation in embedded C programming.

There are endless possibilities in the field and the book encourages readers to alter, expand, and customize code for use in their own projects. The book focuses on real-world applications, programming methodology and tools, and best-practice techniques. Some other key features include:

Back in 1995 the most popular web browser company in the world, Netscape, decided to use asymmetric encryption to allow people to safely enter credit card numbers in the web browser. Mathematicians started talking about asymmetric encryption in the late 70's. There are two keys, one to encrypt and a different one to decrypt. It is very difficult to figure out one key unless one has the other. This way a website can send an encrypt key to the browser and the browser can encrypt the data to be sent. Even if someone is able to see the encrypted data and the encrypt key, the data can not be decrypted without the decrypt key. Part of the magic involves very large prime numbers and complex equations.

That is not all the browser did for SSL (Secure Socket Layer, AKA https). This also created the idea where each SSL website would have a certificate issued by a trusted authority. That certificate indicates the web site domain is encrypted by the authority. The browser can decrypt the certificate to learn the verified name of the company that is running the web site. In this case, it is the encrypt key that remains secret. The idea was to prevent a user from being spoofed into entering their credit card on a web site that appears to be a well known site, but is not.

It is that second use that caught the eye of Microsoft in the XP days. They decided to use the certificate concept to add a signature to executable files loaded by Windows. It works like this: A software publisher gets a certificate from a trusted authority, the same people doing web site certificates. Using a tool from Microsoft, a signature using the certificate with the company name and a CRC of the executable file is appended to the file. When the OS loads the file, it can decrypt the signature, verify the CRC and decide how trusted the file is. For example if a message like "This program was published by CCS, Inc; if you trust that company press continue."

The only encryption algorithm used up to 2001 was called SHA1. In 2001 a new algorithm called SHA2 (AKA SHA256) came out that was considered harder to break with the newest fast computers. XP SP3 would accept either encryption but the older XP versions would only take SHA1. One could sign a file with two signatures, SHA1 and SHA256 and it would all work, so this became the norm.

Starting with 64 bit Windows 7 Microsoft began requiring all drivers be signed with a certificate traceable to an authority they approved of. The way these certificates work is company A can issue a certificate to you and they have a certificate issued by company B and they have one issued by company C. This chain of certificates is all part of the signature. Microsoft maintains a list of the large handful of top level certificate issuers it trusts. Drivers were considered sensitive because they often operate in kernel mode where they can access any memory in the PC.

With all the websites in the world a lot of companies were issuing a lot of certificates and some of these authorities were not doing much to check for who they were issuing them to. The concept of an Extended Validation certificate (EV) was created where it requires a great deal of verification to ensure the certificate holder is who they say they are. Microsoft uses this in their SmartScreen web browser download checker. It flags any software without a EV certificate as suspicious.

This was all well and good until the release of Windows 10 that first was sent out October of 2020. Microsoft decided drivers loaded into Windows would only be accepted if they were signed by Microsoft. The way this worked is the software publisher would first sign the driver with an EV certificate, then send it to Microsoft. If approved, the publisher signature was stripped and a Microsoft signature applied. They would then send the package back to the publisher. So the whole world did not grind to a halt, they have exceptions as a part of a roll out plan. In general, right now anything signed in 2021 needs a Microsoft signature and most older files are accepted.

So here come the headaches for CCS. First I should point out even though we have a yearly developer subscription with Microsoft we did not get the memo about this new rule. In the old days Microsoft published a newspaper sent via snail mail to all developers. The last one we got was October of 2000. For a while we got news by CD and then that was replaced with a slew of online blogs.

Microsoft does not update all machines at the same time, so early this year we started getting some calls of trouble but not enough to be very concerned. There seemed to be work-arounds that got people going. Only new drivers had a problem and only on machines that did not have the driver previously installed. The error did not say "Sorry this driver must be signed by Microsoft", it did say "Invalid signature hash."

We put in a support ticket with Microsoft in May and were then told about the new rules. Our first step was getting an EV certificate. We had been using the ordinary certificates (OV) since the beginning but never bothered with the EV. It then took over two months and a pile of tickets in attempts to log into the Microsoft driver signing website. The problem turned out to be another account with the same company name was taken out 10 years ago and not used since. The error was not "Company name already used", it was "Something went wrong, try again later." The next problem was our files were not being accepted. Another dozen tickets and we found out the reason our certificate was not working was the authorities started issuing SHA3 certificates and the Microsoft website could not handle those yet. Windows is OK with SHA3 but not the website that accepts the driver submittals. After making a special request for an SHA2 certificate and another couple of weeks to figure out what the special website wanted, we started getting Microsoft signed drivers.

So far we have not been able to figure out how to append additional signatures on to the files so it seems we need to have new and old style drivers depending on the OS.

Many of our customers are using USB CDC drivers to talk to the PIC^® MCU. This creates a COM port in Windows that can use the normal serial API functions. The driver for a CDC device is just a .inf file with VID, PID and company information, plus the .cat file with the signature. In Windows 10 no driver is required for CDC devices. You do need it for older versions of Windows. If you do want to use a .inf for a CDC device in Windows 10 then it does need the Microsoft signature even though the driver file is optional.

It is possible to load a driver into Windows that has a bad or wrong signature. This link details the procedure:
https://www.howtogeek.com/167723/how-to-disable-driver-signature-verification-on-64-bit-windows-8.1-so-that-you-caninstall-unsigned-drivers/

The procedure will not work if you have secure boot enabled and on some PC's you need a password to disable secure boot. This also will not work on PC's that are in S-Mode. Only software products in the Microsoft store can be installed in S-Mode. This might be a hint that new rules for normal executable are coming.

Microsoft is evolving with encrypted certificates as are web browsers. If you ever try powering up a old PC you may find it can no longer browse the web because it uses an older encryption method and most websites are now the newest https. Asymmetric encryption technology can be used to send encrypted data to anyone you have not previously made secure contact with. It is finding use in a large variety of applications. One big use, that would not otherwise be possible, is cryptocurrency.

We are sorry for the inconvenience to customers who were trying to use our products during this adventure (nightmare). Many customers were able to use the above workaround and others returned product out of fear of damaging their system. We are now back to normal and everyone should be able to install our drivers.



Like us on Facebook. Follow us on Twitter.

About CCS:

CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC^® MCU and dsPIC^® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.

PIC^® MCU, MPLAB^® IDE, MPLAB^® ICD2, MPLAB^® ICD3 and dsPIC^® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.

Ever wonder how much time it took to code and debug a project? The Project Watch utility within the CCS C-Aware IDE makes keeping track of project development easier than ever!

The Project Watch tool provides the user detailed log information on the current working project. Time-management can be viewed through either a 'Daily Activity' log, including total editing and debugging time, or 'Specific Activity' log containing time the specific activity occurred.

Long periods of time where the keyboard is not used are excluded from the times.

View logs, contained in the Project Watch tool by selecting between two view modes: 'Selected Date(s)' or 'All Entries'. The 'Selected Date(s)' view shows the log information for the currently selected day(s) on the calendar. The 'All Entries' view shows the entire log that has been collected for the project, including a summary of the log and detailed information separated by each day.

Do you maybe have a lot of projects named "main"? How about one source base that through conditional compilation could produce any one of six hex files? Maybe you just need to know exactly what version the hex file for a project is from? This article describes the technique to get specifically named hex files, different from the project name.

The fundamental principle is to use #export to define the name of the hex file. The simple syntax is:

Almost every new PIC® microcontroller Microchip has released in the last few years has a peripheral called the Peripheral Pin Select (PPS) peripheral. This peripheral is used to assign what pins are used as the peripheral pins for most digital peripheral. This means instead of a specific pin or pins that has to be used with a peripheral you can choose the pin or pins to use with it. This is very useful on low pin count devices were a single pin would have had multiple peripheral functions on a single pin causing you to choose which peripheral to use. The way the PPS peripheral works for peripheral pins that are outputs, the UART TX pin for example, the peripheral is assigned to the pins, and for peripheral pins that are inputs, the UART RX pin for example, the pin is assigned to the peripheral. Because of this it's possible to assign multiple pins to the same output peripheral, but only one pin can be assigned to an input peripheral.

To assign a pin as a peripheral pin the CCS C Compiler has several methods to do this. The primary method is the #pin_select directive. The #pin_select directive is a preprocessor directive used to assign pins at compile time. The format for the #pin_select directive is as follows:

#pin_select xx=yy

With xx being the peripheral to assign the pin to, see the PIN_SELECT section of the device's header file for a list of the peripherals pins can be assigned to, and yy being one of the pin defines in the device's header file. The following is an example of how to assign the UART1 TX and RX pins using the #pin_select directive:

#pin_select U1TX=PIN_C6
#pin_select U1RX=PIN_C7

However not all pins can be assigned as a peripheral pin, to determine which can be assigned under the PIN_SELECT section of the device's header is a list of pins that can be assigned as peripheral pins. Additionally not all valid pins can be assigned to every peripheral, some device only allow certain port pins to be assigned to a specific peripheral were as some other devices only allow some pins to be assigned as input peripheral pins. This is device dependent and the device's data sheet should be checked carefully when laying out the peripheral pins for device with a PPS peripheral. The #pin_select directive does have checks to make sure a pin can be assigned to a peripheral, and will generate a compiler error if a pin can't be assigned to a peripheral or if the pin isn't a remappable peripheral pin.

Another method the CCS C Compiler has for assigning pins as peripheral pins is the pin_select() function. The pin_select() function can be used to assign pins at run time. This is useful in cases were more then one pin needs to be assigned to a single output peripheral, if a single pin needs to be used by multiple peripherals or if the pins assignments need to changed, for example, in a case were the code needs to support multiple hardware configurations. The format the pin_select() directive is as follows:

pin_select("xx", yy, aa, bb);

With xx being the same peripheral names used by #pin_select and yy being one of the pin defines in the device's header file. Additionally aa and bb are optional parameters used to specify whether to do or not to do the unlock and lock procedures, TRUE does the procedure and FALSE doesn't to the procedure. With aa specifying the unlock procedure and bb specifying the lock procedure. When the aa and bb parameters are not specified in the function call the lock and unlock procedures are both performed by default. These optional parameters are most useful when using the pin_select() function to assign multiple peripheral pins sequentially. For example, the following is an example of of how to assign the UART1 TX and RX pins at run time:

pin_select("U1TX", PIN_C6, TRUE, FALSE);
pin_select("U1RX", PIN_C7, FALSE, TRUE);

Another useful feature of the pin_select() function is that it can be used to unassign the peripheral pins. The format of the function call depends on the whether unassignment is for an output peripheral or an input peripheral pin. To unassign an output peripheral pin the following format is used:

pin_select("NULL", yy);

With yy being the one of the pin defines in the device's header file. To unassign an input peripheral pin the following format is used:

pin_select("xx", FALSE);

With xx being same peripheral names used by #pin_select. For example, the following is an example of unassigning the previously assigned UART1 TX an RX pins:

pin_select("NULL", PIN_C6, TRUE, FALSE);
pin_select("U1RX", FALSE, TRUE);

The final method has for assigning the peripheral pins is some for the #use directive can make the peripheral pin assignments, the #use pwm() directive, for example. For #use directive that this is supported with the format is similar to the following, see the help file entry for the #use directive for the exact format:

#use pwm(CCP1, output=PIN_B0)

The above will make the assignment of PIN_B0 as the CCP1 output pin. This method is currently not supported by all of the #use directives, currently only the #use pwm() and #use capture() directives support this feature. For the other #use directives #pin_select should be used to assign the peripheral pins before the #use directive line. The #use rs232() is an example were the pins should be assigned using the #pin select directive before the #use rs232() line if the hardware UART pins are to be used on a PPS device were the UART pins are remappable peripheral pins. Without the assignments the compiler will implement a software RS232 instead. For example, the following will assign the UART1 TX and RX pins and setup the RS232 to use the hardware UART peripheral:

#pin_select U1TX=PIN_C6
#pin_select U1RX=PIN_C7

#use rs232(xmit=PIN_C6, rcv=PIN_C7, baud=115200, stream=U1_STREAM)



Like us on Facebook. Follow us on Twitter.

About CCS:

CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC^® MCU and dsPIC^® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.

PIC^® MCU, MPLAB^® IDE, MPLAB^® ICD2, MPLAB^® ICD3 and dsPIC^® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.

The latest version of Windows, Windows 11, will be rolling out to the public in the near future. Here is what you need to know in order to take advantage of the newest version of the OS while continuing to use CCS, Inc. products.

Most PCs on the market right now will be able to support Windows 11. For those that want to know if their current PC is supported, Microsoft has released the minimum system requirements for installing Windows 11 which are as follows:

The .sym compiler output file provides a good overview of the build. When you archive your source code and hex file saving the .sym file as well can be helpful. The .sym file has the following information:

The Capture Compare (CCP) peripheral of the PIC16 and PIC18 PIC^® MCUs and the Input Capture (IC) peripheral of the dsPIC and PIC24 PIC^® MCUs allow the MCU to capture and hold a timer value when a specific input pin reaches a user defined state. This peripheral is useful for measuring the duration between events, or determining the frequency or duty cycle of an incoming signal. This peripheral operates independent of the MCU operation, meaning it can trap the timer on the input signal without the developer having to block code execution waiting for the input signal to happen.

Version 5 of the CCS C Compiler has added a #use capture() library that makes it easy to use the CCP or IC peripheral. The API for this library provides an easy to use method for using and configuring the peripheral and timers, while also being portable from one PIC^® MCU device to another. Here is an example of its use:

#use capture(CCP1, input=PIN_C2, capture_rising, stream=CAPTURE1)

unsigned int16 WaitForEvent(void)
{
while(!get_capture_event(CAPTURE1));
return(get_capture_time(CAPTURE1));
}

#use capture() configures a CCP or IC peripheral for use, and by using the STREAM option several peripherals can be configured with several instances of #use capture(). #use capture() also provides a method of configuring the timer peripheral to use and the tick rate of the timer. Several other configuration options exist, see the compiler help manual for documentation.

get_capture_event() returns TRUE if the CCP or IC peripheral has trapped an event that can be read, and get_capture_time() returns the time the event happened.

The CCS C Compiler provides an example of using this library, ex_use_caputure.c which can be found in the examples directory of the CCS C Compiler. This example can be used on any PCM, PCH or PCD version 5 CCS C Compiler.



Like us on Facebook. Follow us on Twitter.

About CCS:

CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC^® MCU and dsPIC^® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.

PIC^® MCU, MPLAB^® IDE, MPLAB^® ICD2, MPLAB^® ICD3 and dsPIC^® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.

Easily setup your PIC^® MCU clock with #use delay(). This article takes a deeper look at how to set the various oscillator fuses and oscillator registers to get the clock speed specified in #use delay(). Projects get a jump start with #use delay() accepting simple keywords: CRYSTAL, OSCILLATOR, INTERNAL and RC in addition to, or in place of, the keyword CLOCK to setup the clock.

By using one of these keywords with the clock, speed causes the compiler to set the appropriate oscillator related configuration fuses and registers to automatically achieve the specified speed with the specified clock source. The following #use delay() examples demonstrate how to set up the PIC^® MCU to run at 8MHz from an external crystal and at 4MHz from the internal oscillator:

#use delay(clock=8MHz, crystal)
#use delay(crystal=8MHz) //same as above line

#use delay(clock=4MHz, internal)
#use delay(internal=4MHz) //same as above line

Devices that have a PLL, the #use delay() has an easy mechanism for setting up the PIC^® MCU to run from use of it. This is easily done by setting the CLOCK option to the PLL clock speed and the CRYSTAL or OSCILLATOR option to the speed of the external clock source. For example, the following #use delay() line will set the clock to run at 32 MHz from an 8 MHz external oscillator using the PLL:

#use delay(oscillator=8MHz, clock=32MHz)

Devices with an USB peripheral, CCS has added the keywords USB, USB_FULL (same as USB) and USB_LOW. By using one of these keywords in #use delay() it causes the compiler to set the device's configuration fuses for the USB clock to be setup for either FULL or LOW speed. For example, the following line will set up the PIC^® MCU to run at 48MHz from a 20MHz crystal and setup the USB clock for FULL speed:

#use delay(crystal=20MHz, clock=48MHz, USB_FULL)

By default, the compiler turns off the clock output that is available for some oscillator modes. If your application requires the clock output turned on, do something like this:

#use delay(internal=4MHz, clock_out)

When using the #use delay() to configure your oscillator it is not recommended to include oscillator related #fuses in your code or the use of setup_oscillator() unless you need to change the oscillator run-time.



Like us on Facebook. Follow us on Twitter.

About CCS:

CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC^® MCU and dsPIC^® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.

PIC^® MCU, MPLAB^® IDE, MPLAB^® ICD2, MPLAB^® ICD3 and dsPIC^® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.

In standard C, basic I/O are handled by functions like getc(), putc() and printf() and the formatting of data is handled by functions like atoi(), atof(), strotul() and sprintf(). For example, reading a floating point number from the user over RS232 would require a combination of gets() followed by atof(). While CCS includes an input.c library that accomplishes many of these tasks, the input.c library uses a fixed RS232 stream and does not work with Keypad/LCD or USB without modification. CCS has added some support for the C++ stream operator to make it easier to handle routine user input and output.

One of the key features of this new feature in the CCS C Compiler is the way it automatically handles the conversion based upon the data types of the variables passed. These conversions are done automatically, no other helper functions like atof() need to be called. For example, if a variable is of float type the compiler will properly convert it from string to float on an input or convert float to string on an output.

The two new operators added are the extraction operator and the insertion operator:
Operator Symbol
Operator Name