Jump to content
 

N9WXU

Member
  • Content Count

    106
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by N9WXU

  1. Back in the good old days™, real programmers used a modem to dial into BBS's and share programs. A little while later, we used our modems to dial into the University VAX or Unix machines to do our programming assignments. In those days, we interacted with the servers via text terminals and sometimes with graphics terminals over the serial connections (before we had ethernet in the dorm rooms). The interactivity included cursor movements, windowed screen scrolling and even COLOR!!!. I am here to tell you that these wonders are still available today through the magic of the terminal emulation modes built into most every serial terminal program. (that is why they are called terminal emulators). So here is a crash course in using this information. First: the raw data can be had here: https://en.wikipedia.org/wiki/ANSI_escape_code There are a number of terminal emulations but the most common ones were VT100 and ANSI. These were related so most codes do work. Here is how to use them in your program: First let us setup some constants 1 2 3 4 5 6 7 8 9 10 // A selection of ANSI Control Codes #define RESET "\33[0m" #define CLS "\33[2J" #define HOME "\33[1;1H" #define RED "\33[31m" #define GREEN "\33[32m" #define BLUE "\33[34m" #define WHITE "\33[37m" #define INVERSE "\33[7m" #define NORMAL "\33[27m" Next let us use them with some print commands. 1 printf(RESET GREEN "Hello" BLUE "_" RED "World" CSI_RESET "%d\n",5); Notice, that C will automatically concatenate strings when you place them all next to each other. This will issue a RESET to the terminal to ensure all other formatting like double high, flashing or inverse text are all removed. Then It sets the text color to green, prints Hello, sets it to blue and prints the _ finally red for the World, clears the formatting and prints the integer 5. That should be enough of an example for you to go wild. Each control code is about 4-5 bytes long so it does not add much to your program but it sure does make error messages stand out. Good Luck
  2. I was reviewing a Cypress data sheet for the CYW4390 and saw a line in the UART chapter saying that the total baud rate error budget for both ends had to be less than 2%. With a large dependence upon internal oscillators these days, it seemed a good time to discuss these error budgets. Is 2% reasonable or conservative? First here is a quick back of the envelope calculation for link budget for UARTS. I will assume "perfect" rise & fall times, and 8, none, 1(8n1) framing. There are a total of 10 bits in a byte with 8n1 so each bit is 10% of the total byte time. If your link budget is larger than 10%, you will miss a bit. BUT WAIT... all UART implementations I am aware of try to sample in the center of the bit. Generally, this is done by oversampling 16x and using the center 3 samples as a majority detect. If you consider that slipping the byte time by 1/2 a bit time will cause a missed bit, our link budget is now 5%. If you KNOW you are talking to a PERFECT receiver, then you can accept the entire 5% error. (Of course, you can assume your design is perfect and pass the blame to the other side, but then you would not be reading this.). I am sure that perfect transmitters & receivers are not possible, so we shall reasonably accept 1/2 the responsibility for the link budget, making our baud rate error specification 2.5%. Hmm. Something still seems rotten. The data sheet states that the TOTAL budget is 2%. Our envelope scribblings say 5%. What gives? Here is a good writeup by Maxim Integrated (https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141) that adds some more details. Essentially, you have an uncertainty of ±1 sample-time detecting the START bit and a terrible link would have a 50% chance of detecting the midpoint of the stop bit. The short of the story is a ±3 sample-time error budget out of a needed 152 sample-times (160 sample times less 1/2 a bit time) or ±2% error budget for the link. That assumes you are over sampling 16x. On a PICmicrocontroller, the UART has a high speed mode (BRGH = 1) which changes the sampling rate to x4 instead of x16. This can have a profound effect on the error budget due to the ±1 bit sampling uncertainty. So here are a few recommendations: 1) Always use the MAXIMUM sampling rate available in your UART. 2) Consider a crystal (20ppm) or a resonator (0.5%) or if you must use an internal oscillator, I hope your temperature & power supply is stable so your oscillator accuracy is good. 3) Consider using the auto baud features and internal oscillator tuning features if they are available in your controller. Good Luck
  3. This is the first of a 5 part article where I will explore some different ways to tokenize keywords. This is a simple and common task that seems to crop up when you least expect it. We have all probably done some variation of the brute force approach in this first posting, but the posts that follow should prove interesting. Here is the sequence: Part 1 : STRCMP Brute Force and the framework Part 2 : IF-ELSE for speed Part 3 : Automating the IF-ELSE for maintenance Part 4 : Perfect Hash Maps Part 5 : Trie's Feel free to skip around once they are all published if there is an interesting topic that you want to learn more about. In this first posting I will be building a complete testable example so we can do science rather than expounding upon our opinions. About The Test Data I am currently working on a GPS project so I am being subjected to NMEA sentences. (https://en.wikipedia.org/wiki/NMEA_0183). These sentences are quite easy to follow and you generally get a burst of text data every second from your GPS module. The challenge is to quickly & efficiently extract this information while keeping your embedded system performing all the tasks required and do this with the smallest possible program. As far as stream data is concerned, NMEA sentences are remarkably well behaved. Here are a few sample messages from my new Bad Elf GPS Pro +. $GNGSA,A,3,32,14,01,20,18,08,31,11,25,10,27,,1.19,0.61,1.02*16 $GNGSA,A,3,65,66,88,75,81,82,76,67,,,,,1.19,0.61,1.02*13 $GPGSV,4,1,14,14,73,336,25,32,60,023,31,18,52,294,20,51,51,171,30*7A $GPGSV,4,2,14,31,47,171,34,10,44,087,33,11,30,294,26,01,26,316,15*78 $GPGSV,4,3,14,20,20,108,34,22,19,304,16,08,13,247,21,27,08,218,18*7A The pattern is: $<IDENTIFIER>,<COMMA SEPERATED DATA>*<CHECKSUM> The work of separating out the parts of a sentence is called parsing. We will not be fully parsing the NMEA sentence but if we wanted to, there are many useful tools like BISON that can automate this job. Each of the automated tools has a minimum price of entry in terms of code size and CPU cycles. This brute force approach has the benefit of simplicity, maintainability and a low initial size/speed cost. So let us press on and establish a performance baseline. Our Test Program The program we are about to construct works like this: Like all instructors I will concentrate on the necessary parts of the lesson and leave all the processing as an exercise for the student. Once you have identified the sentence is easy to apply a suitable sscanf to or strtok to process each sentence individually. The actual part we are going to measure is Identify The Keyword but Find a Keyword is a necessary first step and a little bit of wrapper/measurement code is needed to complete the experiment. Parsing out our Keywords To get the identifier all I need to do is discard characters until I see a '$'. Then collect characters until I see a ','. That is easy code to write so here is a quick version: char * NMEA_getWord(void) { static char buffer[7]; memset(buffer,0,sizeof(buffer)); do { serial_read(buffer,1); } while(buffer[0] != '$'); for(int x=0;x<sizeof(buffer)-1;x++) { serial_read(&buffer[x], 1); if(buffer[x]==',') { buffer[x] = 0; break; } } return buffer; } I did not try to collect the entire NMEA sentence, validate the checksum, handle line noise. So this is not a complete application. It does fill a buffer with the NMEA sentence quickly and legibly. One more note: the buffer is 7 bytes large because my Bad Elf GPS sends PELFID as the FIRST sentence upon connection. If I wanted to decode this sentence, the buffer needs another byte. This simple function will be used for all the testing in this series of articles so it is worth understanding. So here is a description of each line of code: the function will take no parameters and return a pointer to a NMEA sentence. It will block until it has such a sentence so it assumes a continuous data stream. There is a static buffer of 7 characters. A pointer to this buffer will be sent to the caller with every iteration. The buffer is 7 characters to allow for the 6 character message from my GPS and a null terminator. Because this is a static buffer we cannot initialize it in the definition. So every time this function is called, we will clear out the buffer to 0's The do/while loop reads single characters from the serial port (provided by the user) until a '$' character is received. The getchar() pattern may have been a better abstraction for the serial port but I was originally planning to receive 5 bytes after the $ with a single call. The 6 byte PELFID changed my mind. The for loop simply reads UP-TO sizeof(buffer) -1 bytes unless the received byte is a ','. I prefer to use sizeof whenever possible to make the compiler do the math to determine how big arrays are. if a ',' is received, we convert it to a 0 and break. lastly we return the buffer pointer. The next piece of housekeeping we should discuss is the main function. This is a simple test application that will provide the framework for evaluating ways of detecting text strings and timing their impact. int main(int argc, char **argv) { if(serial_open()>0) { for(int x = 0; x < 24; x ++) { char *w = NMEA_getWord(); enum wordTokens t = NMEA_findToken(w); printf("word %s,",w); if(t >= 0) printf("token %d\n",t); else printf("no match\n"); } } serial_close(); return 0; } Like before, I will give a quick line-by-line explanation This is the standard main declaration for ALL C programs. For embedded systems we often ignore the parameters and return values but I like to do it for test programs simply because I generally prototype as command line programs on my Mac. serial_open is a simple abstraction that is easy to adapt to any system. It will prepare the serial input from my GPS. The version attached to this project will work on a Linux or Mac and open a specific /dev/cu.<device> that is hardcoded. This is appropriate for such a test application where knowledgeable users can easily edit the code. Obviously a robust version would pass the serial device in as a command line parameter and an embedded system would just activate the hardware. This program will decode 24 keywords. That makes a simple limit to run in the simulator or on my Mac and is sufficient for these tests. Now we run the test. First, get a keyword Second find the keyword and return the token Third display some output Repeat Finally we close the serial port. Often I will skip this step but on a PC program, leaving the port open will cause an error on the second run of the program until the port times out and closes automatically. By closing I save time for the user. For an embedded system, the serial_close function is usually left empty. For the simulator I would add a while(1) line before the return 0. This will freeze the simulation and allow us to study the results. Otherwise, XC8 may simply restart our application from the beginning and fill up my log file with repeat runs. This covers all the code except for the bit that we are interested in. For these type of experiments I like to be as agile as possible. This is about failing fast so we can discard bad ideas as quickly as possible. We should never invest so much of our energy in a bad idea that we emotionally feel obligated to "make it work at all costs". I have seen too many bad ideas last for too long due to this human failing. So lets briefly talk about findToken The function NMEA_findToken takes a pointer to a possible keyword (as identified by NMEA_getWord) and returns an integer (enum really) that identifies it as a number to the rest of the code. I will leave as an exercise to the student the work of doing something useful with a token id. In the future we can replace this function with different techniques and so long as the interface stays constant, we can simply insert the code and measure the performance. For today's test, we will simply apply a brute force strategy. We have a list of words: const char *wordList[] = {"GPGGA","GNGSA","GPGSV","GPBOD","GPDBT","GPDCN"}; and a matching enumeration: enum wordTokens {NO_WORD = -1,GPGGA,GNGSA,GPGSV,GPBOD,GPDBT,GPDCN}; All we need to do is compare our test word to each word in the list until a match is found. The C standard library provides a useful string compare function strncmp. But XC8 does not include it (it arrived with C99) so we will use its predecessor strcmp and press on. We will just be very careful not to loose our terminating character. enum wordTokens NMEA_findToken(char *word) { enum wordTokens retValue = NO_WORD; for(int x=0; x < sizeof(wordList)/sizeof(*wordList);x++) { if(strcmp(word,wordList[x])==0) { retValue = x; break; } } return retValue; } Here is the blow-by-blow: This function will take a pointer to a string and return a token. Initialize the return value to the no_word value Step through the word list Test each word looking for a match on a match, set the return value and leave the loop Return the value to the caller I ran it on my Mac and it runs fine identifying GPS strings from my GPS. I also ran it in the PIC16F1939 simulator so I could measure the CPU cycles and code size for a baseline. For the testing I am looking for 6 words which were carefully chosen to have some missing characters, overlapping characters, and matching words at the beginning and end of the list. Analysis Before I show the measurements we should make this scientific and formulate a hypothesis. My test sequence is GNGSA, GPGSV, GLGSV, GPRMC, GPGGA The words in the list are in this order : GPGGA, GNGSA, GPGSV, GPBOD, GPDBT, GPDCN So I expect the first word to fail at the P in GPGGA, then pass GNGSA. This will be a total of 7 tests to execute. The second word will fail GPGGA on the third test, fail GNGSA on the second test and then pass for a total of 10 tests to execute. GLGSV will require 12 tests to fail. In every word it will fail the second test. GPRMC will require 14 tests to fail GPGGA will require 5 tests to pass. The most number of tests required to pass or fail is equal to the number of characters in the entire list. That assumes that the list is constructed so the only differences are in the last letter so a possible word must go through the entire word of the entire list before determining if it is a match or fail. For our little test, that is not possible, but if the list were different it would take 30 tests. So I expect it to be O(n) where n is the total character count in the word list. Results Here is the actual data for executing NMEA_findToken in cpu instruction cycles on a PIC16F1939. The data was taken using the MPLAB X simulator. Word STRCMP Cycles Notes GNGSA 399 Second word in the word list GPGSV 585 Third word in the word list GLGSV 724 Not in word list GPRMC 899 Not in word list GPGGA 283 First word in the word list The program did include printf and some buffers so the program did end up large at 2153 bytes of flash memory. Improvements: If you decided that this was the strategy for you, then you can make some improvements simply by carefully ordering the list so the most frequent words are first. But after looking things over, it would be nice if we could do our search where we did not need to repeat letters. i.e. all the words start with G, so if the first letter is not a G we can stop the entire process. We will explore one way to accomplish this optimization next time. For now, take a look at the attached files and I welcome's any suggestions for improvements to this strategy. Good Luck example1.c serial_port.h nmea_stimiulus.txt serial_pic.c
  4. If you experience strange behavior with MPLAB double check your simulator stimulus files for bad syntax. I just created a stimulus file for a blog post that will hit tomorrow morning. I inadvertently placed two sequential quotation marks at the start of a string. like this: ""lots of stuff to send" As soon as the simulation was started, MPLAB went into the weeds. Some stuff could be clicked on, but in the end I had to kill the process and restart. Only by checking everything with a second pair of eyes was the problem detected.
  5. Sadly, free mode is embarrassing and pro mode is expensive. It has been for a long time.
  6. N9WXU

    The Story of Mel

    This brings back memories. As I developed as a programmer, the role of Mel (and his suitability as a role model) has also shifted. Of course we all strive to be Mel when we start out. The idea that we have such in-depth knowledge of our system that we can create the tightest possible code and take advantage of the most esoteric of "features" seems like the epitome of super programmers. Of course as I matured, I learned that this knowledge was incredibly powerful and certainly the ability to use it was an asset but like the old saw, "with great power comes great responsibility". Today, I think the best analogy would be "absolute power corrupts absolutely". I would love to manage a software team with the knowledge and experience of Mel, but I would hate to manage Mel, because in the end, he would cost me a huge amount in future maintenance costs as only another Mel + lots of time could possibly support his work and no program ever survives contact with the users so the inevitable new feature would be a disaster. That aside, be sure to read the detailed explanations. They are as fascinating as the original story. https://jamesseibel.com/the-story-of-mel/ https://medium.freecodecamp.org/macho-programmers-drum-memory-and-a-forensic-analysis-of-1960s-machine-code-6c5da6a40244
  7. I am shocked that O'Reilly would publish such a shallow book. I have a number of their books and I have always found them very useful for technical topics.
  8. My favorite part of this book are the scripts between the programmers and the managers. It immediately became clear to me how I was doing a bad job at informing my manager of my progress and why even crude estimates are so important.
  9. Everything in your list of requirements looked pretty reasonable for the PIC16 until you said wireless. For wireless, a lot depends upon the details. Bluetooth, WiFi, Subgig, LoRa, etc will all require some kind of RF module. Each RF module generally comes with a co-processor that handles the heavy lifting for the wireless protocol, however... Each wireless module will still have demands upon the host processor. For example, the WINC1500 wifi driver on an ATMEGA4808 took around 10k. After reviewing the driver, it would be possible to shrink the code quite a lot but it would be at the expense of supporting the code for the duration. That is not to suggest that wirelesss is not appropriate for a PIC16, it is just that wireless often comes with additional expectations that are not immediately apparent. Here are a few: 1) Security, most wireless applications require a secure and authenticated connection to the host. 2) phone interface, many wireless applications seem to be tied to iOS and Android. This generally implies BLE4.2 but could mean wifi. 3) IoT. Obviously wireless existed before the internet, most of the wireless customer discussions ended up being Internet of Things discussions. This drove the security requirements. 4) Over the air update. because security and wireless standards are moving fast, most customers end up requiring the ability to update the software to adapt with the times. When you start going through these requirements you can quickly find yourself in a 128k MCU and that will be a PIC18 or AVR in 8-bit land. A reasonable rule of thumb with these kinds of applications is the PIC16/18 will require 2x the FLASH as an AVR for the same application. The details on why this is true would be a future technical post.
  10. In general any PIC16Fxxx device such as the PIC16F887 can effectively be migrated into a PIC16F1xxxx design (such as the PIC16F18877) as that was a key objective of the F1 redesign. Immediate advantages that you will see are more FLASH, more RAM and more peripherals. Other advantages are very important but can be a little subtle unless you are an assembly programmer. In C, these additional advantages tend to reveal themselves in code that is as fast and a little smaller than the same code on a PIC18. These other advantages are a flat memory map across FLASH & RAM (at least for pointers), 2 FSR's (pointers) and more efficient banking. The PIC16F1's have 31 banks to solve the problem of a 512byte RAM/SFR limit. The new limit is 4K and there are a number of PIC16F1's that make that available. The PIC18 also has a 4K RAM limit but its FLASH limit is 2MB. There are no PIC18's with 2MB but there are many with more than 56KB (The PIC16F1 limit). The new PIC18FxxK42 family has lots of new features and more RAM but there are not very many of the new PIC18 CPU available yet. Welcome aboard and we are very interested in what you are doing with your project.
  11. Every Christmas I always have some project that I want to do but then then time flies and I can't get it finished. Last year, I decided to actually finish one project and I built the best Christmas lights ever. This was a quick and easy project that needed the following ingredients. You will need multiple LED strings depending upon the size of your tree. Here is 1 LED on the string: You can see the ribbon cable connecting them together. Each LED is about 12mm in diameter. The ribbon cable hides well, but perhaps one day I will paint the wire. One LED, the power supply and the Arduino are inside this box. I used the first LED in the box to light the box and to strain relief the cable. You can pass a USB cable inside if you want to reprogram it. The box is a simple laser cut 6mm plywood box. The HEX hole pattern was overkill and almost caused a fire in the laser! Of course I have a laser cutter in my shop. Everyone should have one. Currently I am simply running the demo code which cycles through a number of animations. One day I plan to add a DMX software in the arduino and a raspberry pi as the controller. Then I can be lazy and write code on the couch via WiFi to change the animations. IMG_0044.mov
  12. frame rate seems like 30-60 fps but there is definitely a time-of-flight lag.
  13. The camera looks EXACTLY like the one I have. It works ok for a basic microscope but not great for working under. Mine is USB 2.0 but the lag and the lack of focal length really hurts it.
  14. My 7 year old wants to be an engineer. She loves robots and programming. Just the other day, she asked how she "could be an engineer because I don't know everything". So for Christmas I gave her one of these: This was just perfect. It displaced one doll on her bed. It can be driven around with an IR remote control, but it can also record your button presses (i.e. be programmed) and then play them back. This sort of programming is just her speed. Here is a picture of Veronica studying her new programming book with the robot looking on.
  15. I need to upgrade my microscope. I have a nice binocular dissection microscope that works well but it takes a lot of desk space and it does not allow me to take pictures of my work. I often use the zoom function of my iPhone which works remarkably well but it is not a microscope. So I bought a basic USB microscope. It shows up on my PC & Mac as a basic webcam and works with any of the webcam applications. I thought all was well but I ran into a few snags. 1) It is laggy. It is very hard to solder under this microscope because the lag is probably 200msecs. 2) The focus & the zoom are interrelated. When you get an acceptable zoom factor, (i.e. move the unit closer or farther from the work) you must then focus at that distance. This often leaves me with only 50mm or so of room under the scope to work with. 3) It came with a goofy stand that does not weigh enough so I 3d printed something slightly better. It needs some lead to hold it steady. So now this is in my parts pile waiting for some future need (perhaps automated case inspection for my shooting hobby) and I am looking for a new unit. Any ideas?
  16. Your pro-tip for the day. If you use this code from MCC on a PICmicrocontroller, the function i2c_ISR must be duplicated due to the way the C stack is implemented on a PICmcu. If you want to save code space, simply decide how you want your code to run (interrupt or polled) and remove the call to i2c_isr from the master interrupt code or remove the test in master_operation. Either one will remove the duplication because the function i2c_ISR will not exist in both contexts. (interrupt and "main")
  17. The XPRESS boards do NOT have a debugger. However, they are being replaced with CURIOSITY nano boards. The Curiosity Nano PIC16F18446 and the Curiosity Nano 4809 both raise the XPRESS hardware to the next level. https://www.microchip.com/developmenttools/ProductDetails/DM164144 https://www.microchip.com/DevelopmentTools/ProductDetails/DM320115 The on-board debugger used by these nano boards is also present on the AVR IoT WG development kit. Expect to see lots of new development hardware with on-board debugging in the future. They include : 1) CDC serial port 2) Mass Storage Drag and drop hex file programming 3) Mass Storage drag and drop serial messaging (send a text file with a keyword and it goes out the serial port) 4) MPLAB support with native programming & debug The AVR versions are also supported by Studio. For those with AVR memories, these are updated versions of the old EDBG debuggers. The updates add PICmcu support but they are still CMSIS based debuggers. Here is a project I built using a PIC16F18446 Curiosity Nano directly. This is a model rocket launch controller. More information on the rocket controller is here: https://workspace.circuitmaker.com/Projects/Details/joseph-julicher/rocket-controller
  18. It is too bad the angular timer only exists on the PIC16F161x family. It can automatically give you events on any phase angle and synchronize these phase events to pulses on an I/O pin (or comparator). It sure does save a lot of math. But the PIC16F161x only has 20 pins so debugging BLDC systems gets challenging. Also, it has 2 CCP's and 2 PWM peripherals for a total of 4 PWM's but they are of different types. To drive a 3phase motor we played lots of games with the PPS to steer the PWM's to the needed MOSFET pairs. It worked, but some of the savings from the angular timer went into PPS games. It may have been easier to use 2 PWM's and 1 CCP. Here's hoping we get a high pin-count, high PWM device with an angular timer.
  19. I posed this question because I have seen it about as often as I have seen questions about boot loaders. LVP is a fantastic choice for programming a PICmicro used in this situation. Doing so will require a few things: 1) A hardware connection to the PICmcu from the host. 2) A host driver that can do the work. Let us take these requirements in order. First, the connection: While almost all the functions on a current generation PICmicro have selectable pins through the PPS feature, the LVP pins are NOT re-mappable. That means you must hook them up first and then you can use PPS to steer some other interface onto the pins for the "normal" behavior. Second, the software interface. While Microchip Technology has never published a programming library for a host CPU, there are some interesting sources of information. The best solution would be to adapt the software found here -> https://github.com/MicrochipTech/XPRESS-Loader Specifically, https://github.com/MicrochipTech/XPRESS-Loader/blob/master/MPLAB.X/lvp.c The interface to the I/O pins is not well abstracted (assumes a PICmcu) but it would be trivial to the average user to create some init/set/clear functions and use those. As a bonus, LVP and HV programming is identical except for the programming mode entry. If your PICmcu does not have LVP and you have an easy way to apply 9-12v to the MCLR pin, then you can simply adjust the ICSP_init and ICSP_Release functions. For the nitty-gritty of programming a PICmcu, you can look for programming specifications on Microchip's website. Here is a link to a typical specification: http://ww1.microchip.com/downloads/en/DeviceDoc/41397B.pdf
  20. I have a system where I am using a PICmcu as an I/O processor handling lots of real-time activities. My main processor is some larger ARM (like a Raspberry Pi). I could implement a boot loader on the PICmcu but that is very complex and uses code space. I would like to simply use low voltage programming (LVP) and teach my host CPU to program the PICmcu directly. How do I do this?
  21. In circuit debugging a PIC microcontroller requires 3 features from the chip in both hardware and software. 1) a Debug Exec (software) 2) In Circuit Debug Hardware (ICD) (silicon) 3) a method of communicating with the debugger (I/o pins) The software is a special "debug exec" that is placed in special test memory by the debugger. This "debug exec" provides the serial interface to the debugger and follows the debugger's commands to interact with the hardware debugging support. The "debug exec" uses some CPU resources like 1 level of stack and a few bytes of RAM in addition to some program memory. On the "enhanced" PIC16's (all the PIC16F1xxx devices) additional stack, ram and flash memory is added so there is no memory penalty for using the debugger. The hardware is a number of silicon features like address/data match comparators that implement the breakpoints. The number of hardware breakpoints is related to the number of these comparators that are physically implemented in the silicon. The breakpoints must be implemented in hardware if they are to have zero impact on your code. Software breakpoints are literally extra instructions inserted to perform the breakpoint and they cannot be "turned on/off" and they will affect the program size/timing. The I/O pin requirement is for a communications path to the "debug exec" and for an external way to trigger a manual "HALT". This is done through the PGC/PGD pins so no additional pins are "wasted" beyond what you need for programming. Because the hardware portion of debugging requires additional silicon area and only the developers will ever need it, many of the lower cost devices remove it to save cost. Instead a special version of the device is created and sold on a debug header. The debug header (part number AC162059 for the 12F508) provides the ICD silicon so the volume production does not need to pay for a feature they will never use. For low pin count devices such as the 12F508, it is extra tricky because with only 8 total pins and 5 I/O pins, it is not reasonable to build an application and use debug as that will leave 3 I/O pins for your "secret sauce". For these devices the special part on the debug header is actually in a larger package with 8 pins exactly the same as the target device and additional pins to implement programming & debugging. This allows a nearly zero impact solution to debugging but does require buying an additional device. If you are a maker and are concerned with the minimum size option, I recommend you get good at soldering QFN packages. For the same size as an SOIC 8, you will get 20 pins and in a PIC16F1xxx device you will also get debugging, more memory, better peripherals and a lower cost. Good Luck
  22. I have an older 8-pin device (12F508) and I am unable to enter debug mode with my PICkit. What is going on?
  23. I will ALWAYS try to keep code running on more than one platform even if the second platform is just a different compiler. The second platform provides additional opportunities to catch mistakes like this one simply because different compilers or systems have different constraints. In the past I would keep my code running on a Motorola 68000 and an Intel 80x86 simply because the endian differences would always reveal themselves and keeping the code portable kept silly math errors away.
  24. Sometimes it is not appropriate for voltages greater than VDD to be applied to a system. For these cases, there is a low voltage programming option available on most of the PICmicrocontrollers. The low voltage programming (LVP) option is triggered with a special LVP pin that must not be used for other functions. The LVP pin triggers the same programming functionality typically caused by high voltage (VPP) applied to the MCLR pin. LVP is enabled by default on all supported PICmicrocontrollers, but it can be enable/disabled by setting the LVPEN bit in a configuration fuse. To use LVP you must: 1) have the LVP function enabled 2) configure your programmer to use LVP by setting the programmer options in MPLAB. CAUTION: You can inadvertently disable LVP by releasing a HEX file with the LVP fuse disabled. The only recovery method in this case would be high voltage programming. NOTE: When LVP is enabled, high voltage is STILL enabled and can always be used. Good Luck
  25. I have an application using a PICmicrocontroller that cannot tolerate high voltage being applied to the circuit board for any reason. I want to program the PICmicrocontroller in the final circuit. Can I program a PICmicrocontroller without high voltage?
×
×
  • Create New...