CCS News

The CCS C Compilers have a unique feature called Data Streaming, where an ICD unit is used as a TTL to USB translator. This can do printf()'s and getc()'s through the programming pins to the PC. Many of our users have been using data streaming not only for debugging, but for diagnostics, factory test and calibration.

Using this same interface, the compilers have the ability to inject code to send data out this port at specific points in the code. This information can include a timestamp, as well as, text data. This forms the infrastructure of the code profiling feature in the IDE.

For example, in the code one needs to only add these lines:

The CCS C Compiler from the beginning has made it easy to communicate over an RS232 like port. Many of our users have used this extensively, not only for communicating with serial devices but also for diagnostics and debugging. Now, PC's and many other devices have replaced their RS232 ports with USB ports. The USB hardware and software is much more complex than RS232. This has discouraged many from migrating over or they have used a crutch like an external chip to do the USB magic (like FTDI). This article shows how to easily add a USB port to your PIC^® MCU application.

HARDWARE
Microchip has a number of chips with built in USB. For example, the PIC16F1459 ($1.38/100) or PIC18F14K50 ($1.79/100). Here is an example schematic: (note: pin numbers apply to PDIP, SOIC, and SSOP packages)



Shown here is a USBmicro style connector. The more common type B connector is the same pinout except there is no pin 5 and 4 is the ground. The D+ and D- pins are for the data and sometimes there will be a 27 ohm series resistor and/or zener protection diodes on those pins. When using a peripheral device, pin 1 will supply 5 volts (up to a half amp). The board can be powered from that 5 volts; however, in this schematic it is to simply detect if the USB cable is plugged in. Although users can do that from the data lines, it is easier to detect the 5 volts like this. Sometimes users will put series coils on the 5 volts and ground to reduce noise.

The Vusb on this chip simply needs a cap for an internal voltage regulator. Some chips have a dedicated Vbus pin for the 5 volts detect. Careful with the pin names, as they are not consistent between chips.

HOST SOFTWARE
The USB bus has a number of protocols that can be used, each with many options and configurations. HID (human Input device) is used for keyboards and mice and is easy to use on any OS because the drivers are built in. There is a data limit however, (like 8 bytes per ms) that makes it impractical for many applications. CDC is a protocol designed to emulate an RS232 port. The Windows drivers will create a virtual COM port for a CDC USB device so the PC application can use COM1... just like an RS232 port.

When a Windows 10 sees a CDC device, it automatically installs a driver for it. For older versions of Windows, users need a short .inf file to describe their device and include the device VID (vendor ID) and PID (product ID). Examples .inf files are in the CCS C Compiler examples directory. Every USB device is supposed to have a unique VID/PID and serial number. If users have two of the same devices plugged in, the VID/PID will match but they are differentiated by serial number. To get a VID users need to register with the USB standards organization.

USB is point to point and one point is a host and the other a device. Hub's can also be involved but that is beyond our concern for this article. The host initiates all activity. For example, a PC is a host and it will poll every device about once a millisecond and transfer any data needing transferring. When the device is first plugged into a port, there is a handshaking that takes place that involves the device identifying itself along with the protocol it will use and various parameters. For example, how much current it expects to draw off the bus. This handshake is called enumeration. In Windows users know it happened by the beep.

Some PIC24 parts have USB hardware that can also be a host. For example, this might be used to read a USB flash drive.

PIC^® MCU SOFTWARE
The CCS C Compiler has several example programs for CDC as well as the required drivers. The following are the key declarations you need for a USB CDC program:

The SENT (Single Edge Nibble Transmission) protocol is a relatively new protocol used in the automotive industry for transmitting sensor data to a controller. The SENT protocol is a one-way asynchronous voltage interface which requires three wires, a signal line, a supply voltage line and a ground line. SENT uses pulse width modulation to encode 4 bits (1 nibble) of data per symbol.

The basic unit of time in SENT is a tick, which can be between 3-90us. Each SENT message contains a sync period, made up of 5 low ticks and 56 high ticks, followed by up to 8 nibbles of data. Each data nibble is transmitted with a fixed-width low period of 5 ticks, followed by a variable-length high period from 12 to 27 ticks representing a nibbles value from 0 to 15. The data portion of the SENT message is make up of a status nibble, 1 to 6 nibbles of sensor measurements and a CRC nibble. Additionally, an option pause pulse can be used to compensate for variable message lengths.

Some of Microchip's newer PIC^® microcontrollers, the dsPIC33EV256GM106 family for example, comes with a build-in SENT peripheral for transmitting or receiving SENT messages. The CCS C Compiler has build-in functions for setting up and using the SENT peripheral For these devices. The devices that have a SENT peripheral, the following functions will be available in the compiler for setting up and using the SENT peripheral: setup_sent(), sent_putd(), sent_getd() and sent_status().

The setup_sent() function is used to setup the SENT peripheral and has a parameter for setting up as an asynchronous SENT transmitter, synchronous SENT transmitter or a SENT receiver and the number of data nibbles to sent or receive. Other settings include whether to use the pause pulse.

The sent_putd() function is used to load the data nibbles to transmit when the peripheral is setup as a SENT transmitter, and the sent_getd() function is used to retrieve the data nibbles when the peripheral is setup as a SENT receiver. Finally, the sent_status() function is used to get the status of the SENT peripheral, for example what nibble it is currently transmitting or receiving.

The CCS C Compiler also provides two examples ex_sent_transmitter.c and ex_sent_receiver.c showing how use the SENT peripheral and built-in functions. ex_sent_transmitter.c is an example demonstrating how to setup and use the SENT peripheral as an asynchronous SENT transmitter, and ex_sent_receiver.c is an example show how to setup and use the SENT peripheral as a SENT receiver.




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.

LoRa is low-power wide-area network protocol that can be used to periodically communicate sensor data. LoRa uses a proprietary spread spectrum modulation that is similar to and a derivative of Chip Spread Spectrum (CSS) modulation. This allows for long-range transmission, up to 15 km, with low power consumption. This makes it ideal for battery applications that only need to periodically transmit sensor data.

There are two types of networks that can be built using LoRa modulation. The first is a peer-to-peer or point-to-point network. This is the simplest network that can be created only requiring a minimum of two devices with LoRa radios to develop. In this type of network, each device's radio must set to use the same LoRa settings frequency, coding rate, spreading factor, etc. This type a network is good for small networks with only a few devices that periodically need to transmit data to each other.

The second network type of network described in this article using LoRa modulation is a LoRaWAN network. LoRaWAN is a upper level network protocol, developed by the LoRa Alliance, that uses LoRa modulation for creating a cloud-based network. In LoRaWAN networks end-devices periodically send messages to a gateway, which then forwards to a network server, which forwards it to an application server. Any response is then forwarded back in the reverse order. In order for a device to communicate on a LoRaWAN network it must first join that network, additionally for security purposes the data being sent and received on a LoRaWAN network is encrypted twice. First, the application payload is encrypted with an application key that is only known by the device and application server. Second, the network payload, which includes the application payload, is encrypted with a network key that is only know by the device and the network. This ensures that the data being sent by the end-device to the application is secure.

When developing a LoRaWAN network it requires at least one end-device with a LoRa radio, a gateway, a network server and an application server. However, it is possible to purchase or build a gateway that have the network and application servers built-in to it. Additionally there are several service providers, The Things Network for example, that have public gateways operating in many areas of the world that can be used to receive messages and forward them to your application server. See thethingsnetwork.org for more info about their service. This allows building a LoRaWAN network quickly without investing a lot of time and money in developing and maintaining the network infrastructure. However these services are not required, it is possible to build a private network from the ground up using your own gateways and servers.

Devices that communicate using LoRa modulation requires a LoRa radio, for that purpose Microchip developed the RN2903 module. The RN2903 modules is designed to communicate using LoRa modulation using the US frequency band, additionally the RN2903 module has a built-in stack for connecting to and communicating on a LoRaWAN network.

CCS created a driver for the RN2903 module to assist in development, rn2903.c, for communicating with and controlling the module. The rn2903.c driver is a low level driver that uses serial messages to communicate with and control the RN2903 module. It also has specific functions for controlling RN2903 module's radio, which are used for doing peer-to-peer, point-to-point, communication, and for controlling the RN2903 module's LoRaWAN stack, which is used for connecting to and communicating on a LoRaWAN network. In addition to the rn2903.c driver, CCS also created two additional drivers, lora.c and lorawan.c. The lora.c driver was developed by CCS to use the rn2903.c driver to do peer-to-peer, point-to-point, communication. This is designed so that two or more PIC^® MCU devices with RN2903 modules can communicate with each other. The lorawan.c driver was developed by CCS to use the rn2903.c driver to connect a PIC^® MCU device with an RN2903 module to a LoRaWAN network. All three of these driver come with the the current version of the CCS C Compiler. CCS will be releasing a LoRa development kit in the near future.


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.

Many of our loyal compiler customers may not be aware that 10 years ago, CCS bought another company that now operates out of our same location. West Mountain Radio ("WMR") manufactures accessories for the Amateur (HAM) radio and DC power markets. We know many of our customers are Electrical Engineers and most EE's seem to at least be knowledgeable about HAM radio even if they do not indulge themselves. Since the beginning, HAM's have been on the cutting edge of RF technologies, electronic design, computers and software. While the rest of the world is downloading apps, HAMs have been using DSP's to replace most analog components in radios. Software defined radios do tuning, bandwidth control, modulation, demodulation and much more all in software. Digital transmissions are used not only for voice, but modes similar to texting, and e-mail, as well has hybrid communications systems using both RF and the internet. HAMs were experimenting with phone line patches to radios before we had cell phones. HAM radio was truly made for tinkerers.

CCS bought WMR to help smooth out the income stream as the PIC market fluctuates. The company had innovative products and is well respected in the market. What CCS could bring to the table was microcontrollers. Many of the products were crying out for microcontrollers to bring the product line to the next level. This is something our CCS engineers can do in their sleep (or spare time between projects). It also helps to keep our guys on top of the development tool needs for real world applications. As a simple example, WMR has a line of DC power strips. CCS was able to add Ethernet and WiFi to some of these power strips so the voltage and current can be monitored and controlled from any web browser. This is a huge help for unmanned radio stations on a mountain top or for those operating a home station remotely from work.

Many of the traditional WMR products that had clever analog circuits have been upgraded to a small micro. This reduced the number of parts, increased the accuracy and reduced the need for calibration and eliminated drift. On some products, we also put in a small internal USB port so the user could change trip points or just monitor the device status.

We have been a little surprised to find many of our long term customers were also a WMR customer or simply HAM operators. We expect to be showcasing more compiler projects that have HAM radio applications. A new development board is also on the drawing table. Educational package offerings normally reserved for students and schools are being extended to licensed HAM operators.

The HAM radio community is very social. Clubs can be found in any medium to large size city in the US. It is even more popular in other countries. These local clubs will usually sponsor a get together called a HAMFEST. This is an event that has educational seminars, a flea market, license testing and much more. Even if you are not a HAM operator these events are a great place to buy vintage computer equipment, electronics of all types or just have a good high tech conversation with like minded people. WMR sets up a booth at approximately 10 of these shows a year. Sometimes we put out a demo and information on our development kits and compiler. We are considering trying a microcontroller seminar to see what the interest is.

Many of the WMR products have applications well beyond HAM radio. For example, the product line includes sophisticated battery testing, DSP based audio processing for noise reduction, and many DC power related products. The DC power products are special because of the high current they can handle. All the products can deal with at least 40A. A licensed HAM can transmit up to 1500W so high current is important. Beyond HAM radio however, our battery testers can be set up to simulate a specific load pattern to figure out how long a battery will last under a certain scenario. They can also be used just as an electronic load to test a power supply, connectors or just traces on a PCB. If you have some high current designs coming up consider WMR for some of your test equipment.

Let us know if you want to learn more about HAM radio, connect with a local club or just meet us at a show.

To sign up for our WMR newsletter go to:
http://www.westmountainradio.com/content.php?page=newsletters


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.

All Globals:
Here we can see all the functions and global variables in the program. Click on any one to get a cross-reference.

Software developers will sometimes notice a variable has an unbelievable value. In a debugging situation, the value is checked right after it is written, and the value is good. If every place it is written is checked, then it appears as though somehow the variable value is changing not as a result of intentional C code. This application note covers some basic techniques to locate the problem.

1. The first step is to open the .SYM file and locate the variable in question. This memory map shows where the variable sits in relation to other variables. The compiler will share the same memory location between variables that should not be active at the same time. For example, the main program calls function A and it calls function B. The A function has a local variable called LA and B has a local called LB. Because function A and function B are not running at the same time, the compiler might put LA and LB in the same memory location.

Check the other variables in the same memory location and confirm those variables are not active at the same time. Remember that local variables that are not marked static may have garbage in them each time the function starts. In the rare case the compiler places two variables that could be active at the same time in the same memory location report it to CCS Support.

2. Check nearby variables, especially arrays. An index out of range could cause accessing the array to overwrite another variable. If re-arranging your variables or otherwise changing the code makes a problem come and go, then look at how your problem variable moves in the memory map.

3. Look at the wrong data and see if you recognize it as belonging somewhere else. A bad pointer could place good data in the wrong location.

4. If this is a multi-byte data item and it is accessed inside and outside a interrupt function, then make sure your code logic has protection against the variable being partially updated when an interrupt happens.

5. Check the chip errata. Sometimes chips have bad behavior at certain voltages, temperatures or clock speeds.

6. Check to see if your chip allows for data breakpoints. If so, and your application is debugger capable, you should be able to find the problem using the debugger. Set a data breakpoint at the location of the problem variable. Run the program and each time it breaks, check the variable value. When it is bad, look to see where in the code you are. If you see something like the following:

The CCS C Compiler provides an extremely flexibly serial library; it has the ability to use the hardware peripheral or bit bang the pins, to control and monitor flow control, to specify parity, to use a one wire bus, and more. One feature it has is the ability to specify a receive buffer, and the library will automatically use the receive interrupt to buffer incoming characters. Here is an example of creating a stream called STREAM_UART1 on the UART1 hardware peripheral with a 16 byte receive buffer:

The CCS C Compiler has added built-in Local Interconnect Network (LIN) bus support to the #use rs232() library. LIN bus is an inexpensive serial communication protocol used primarily in the automotive industry to complement the existing CAN Bus network. The LIN bus network contains one master node and up to 15 slave nodes for a total of 16 nodes, and supports bit rates up to 20 kbit/s.

The LIN bus protocol's message frame consist of two parts, the header and the response. The header is always sent by the master node, meaning all communication is initiated by the master node. After the header is sent only one node sends the response. The header consists of three main fields, the break field, the sync field and the identifier field. The break field is used to get the attention of all LIN slave nodes on the network. The sync field is the hexadecimal value 0x55 used by the slave nodes to determine the current bit time of the bus. Finally the identifier field is used to determine which node will respond during the response part of the frame. The response consist of two fields, the data field and the checksum field. The data field contains 0 to 8 bytes and the checksum field is one byte. Depending on the LIN bus protocol specification being used the checksum is either the checksum of the data field bytes, or the identifier field and the data field bytes.

The following options have been added to the CCS C Compiler's #use rs232() library to enable LIN bus master or slave protocol support, LIN=MASTER and LIN=SLAVE. Additionally the options LIN_CHECKSUM=LEGACY or LIN_CHECKSUM=ENHANCED can be used to select which checksum type is used by default by the functions. Legacy checksum only uses the data field when calculating the checksum, and enhanced uses both the identifier field and the data field when calculating the checksum.

Whether a device can use the library's built-in LIN bus protocol support depends on the mode being used and configuration. When setup as a LIN bus master both software and hardware configurations are support, the only limitation is that when using the hardware UART peripheral the device is required to have an advanced UART peripheral or an UART peripheral with built-in protocol support. When setup as a LIN bus slave it's only supported when using the hardware UART peripheral on devices that have an advanced UART peripheral or an UART peripheral with built-in protocol support. For devices that have a hardware UART peripheral, most devices have a UART peripheral that will work with the #use rs232() library's built-in LIN bus protocol.

When built for a LIN bus master the following functions are added by the #use rs232() library: linbus_header(), linbus_rx_response(), linbus_tx_response() and linbus_checksum_type(). The linbus_header() function is used to by the master to send the header part of the LIN bus message frame, the parity bits of the identifier field is automatically calculated by the function. The linbus_rx_response() function is used by the master to receive the response from one of the slave nodes during the response part of the LIN bus message frame. The linbus_tx_response() function is used by the master to transmit the response during the response part of the LIN bus message frame, the master node only sends the response when the identifier it sent indicates that it should transmit the response. Finally the linbus_checksum_type() function can be used to change how the linbus_tx_response() function calculates the checksum that it sends when used to send the response part of the LIN bus message frame.

When built for a LIN bus slave the following functions are added by the #use rs232() library: linbus_header_hit(), linbus_header_get(), linbus_rx_response(), linbus_tx_response() and linbus_checksum_type(). The linbus_header_hit() function is used to determine if the header as been received. For devices that have a UART with build-in protocol support this function returns TRUE after the entire header as been received, and for devices with an advanced UART it returns TRUE after the first 8 bits of the break byte is received. The linbus_rx_header() function is used to retrieve the identifier field of the received header, the parity bits masked off. Additionally for devices with an advanced UART peripheral this functions also sets up the UART peripheral to receive the sync field. The linbus_rx_response() function is used by the slave to receive the response from another node during the response part of the LIN bus message frame. For devices with a UART peripheral with built-in protocol support this function only needs to be called if the received identifier indicates that the message is to be received by that node. For devices with an advanced UART this function should be called for all messages were the received identifier doesn't indicates that the node should transmit the response. The linbus_tx_reponse() function is used by the slave to transmit the response during the response part of the LIN bus message frame. This function should only be called when the received identifier indicates that the node should transmit the response. Finally the linbus_checksum_type() function can be used to change how the linbus_tx_response() function calculates the checksum that it sends when used to send the response part of the LIN bus message frame.


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 http://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.

Do you remember when you learned programming languages and your teacher or instruction materials told you to never use a GOTO because it could lead to code that was difficult to understand? Here is something that you might not have been warned about - Duff's device. Duff's device was created by Tom Duff, and its design was to unroll and speed up loops by removing conditional statements from the loop. By doing this, the execution time of the loop is decreased. A Duff's device is basically a switchcase statement, with the break operations removed so the code can continue by falling to the next case. Let us look at how it works and look at some real measurements of speed increases on a PIC18F MCU.

Before jumping into a Duff's device, it would be useful to review the switch-case statement in C: