Two digit (8 bit) hex display using a PIC16F18446 microcontroller
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
schematic.pngPortable Network Graphics (PNG) - 334.77 kB - 05/17/2021 at 22:03 |
|
|
top.jpgJPEG Image - 3.09 MB - 05/17/2021 at 20:32 |
|
|
side.jpgJPEG Image - 2.69 MB - 05/17/2021 at 20:31 |
|
|
pinout.pngPortable Network Graphics (PNG) - 152.26 kB - 03/15/2021 at 00:44 |
|
|
TL;DR When adjusting parameters in the MPLab IDE's Code Configurator (MCC) then simply saving the settings is not enough, you MUST hit Generate to recreate the generated config files
---
I my previous videos about this module I'd made a comment about the displays not being that fast however, the 75Hz display refresh rate was irritating me because it flickers in the camera but also because I was frustrated that the numbers I was seeing just didn't add up.
I was convinced that I had the clock set to 4MHz and that should have been plenty fast to avoid flicker but I didn't have the data to prove it.
Double check ..
.... so I should be seeing sometihng like 1100 loops per second; therefore approx 1100 refreshes per second.
? 75Hz is a long way off.
I then noticed that the system.h generated file had a "#define SYS_FREQ 250000".
Putting these numbers back into the equation ...
I checked back on the settings in the MPLab IDE and it was definitely saying 4MHz. .. so confused.
A few hours later, and really annoyed, I realised that it had been so long since I'd used the IDE that I I'd forgotten that changing the settings in the MPLab Code Configurator (MCC) alone isn't enough to make the MCC settings take effect, and I also had to clock the "Generate" button. My PIC's had been running at 250KHz for weeks and not MHz. Having done the Generate the same file was updated to "SYS_FREQ 4000000".
Outcome
All files pushed to https://github.com/Johnlon/SevenSegmentModule
Here I fix the brightness bug.
Subsequent to the video I removed the "debounce" logic entirely as it had the effect of causing the display to update only intermittently if the signal was changing frequently. Of course when it was changing frequently I couldn't read it anyway but the random frequency updates weren't nice aesthetically.
If however one wanted a display that periodically sampled a fast changing digital value then those waits were a good idea (I don't)
During recording I noticed a bug in the display - likely the software - it's possible to see in the vide. Easy to fix and I might also add a latch function when fixing it.
The photos below show the evoluton of this module.
On the right there's the original DM9368 based module and the two on the left use the PIC.
It's a much cleaner design with the PIC and much smaller too.
The 3D design helps...
These boards work really well. Need to pick an appropriate resistor value for the LED and this requires experimentation; blue vs red s greem being quite different. The one here is using 1k and is red.
This setup gives me a really minimalistic dual 7 seg module that has no need of clocks or anythng like that so it's a great fit for my needs.
The PICs inputs have pullups turned on so when the inputs are disconnected or high-Z then it shows "FF".
I noticed that in use the hi digit seemed to flicker even though in testing the 8 input bits ought have been typically 0 or momentarily high Z. Also, when the bus was switching between some known values I noticed flickers on segments that should have been constant on or off.
I figured that the samplng rate of the PIC was seeing those high Z moments, or sampling half way though switching delays, and displaying unwanted values.
I "fixed" this by adding a loop to the code where it only changes it's displayed value if the value on it's inputs was stable for a millisecond (or something like that). This way short blips and switching randomness don't mess up the display. Given that the high-Z moments are very short.
You can see what the V1 construction looks like here ...
The outline is pretty small.
The V2 board is in the post from China, but here's an image with the main points about the V1 board.
Like I said in the previous post this is still a bit too big for my liking.
I got the boards for my new 7 seg modules, but whilst they are small and versatile I immediatley decided I also wanted a super "tiny" variant. Super tiny meaning no bigge than the necessary footprint of the two 7 seg displays themseves.
So last night I redrew the board so that the entire PCB sit's within the outline of the two 7 segment displays.
What had stopped me before was that the need to connnect the module to the breadboard meant using a further row of pins (and more real estate). My existing design used long stackable headers for that purpose and is as I say pretty versatile as the stackable headers mean I can wire up the modules from above using jumper wires. I'll solder one up to show later this weel.
But last night it occured to me that if I mount the PIC using wire wrap SIL turned pin headers then the pins of the "ic socket" itself would be long enough to make the breadboard connection. No need for further rows of long headers.
I also decided to mount the two current limiting resistors underneath the PIC chip. If the the PIC is sitting in some SIL headers then there's loads of space for a couple of resistors sitting underneath the PIC.
This meant that I could cram then entire thing into a 25mm x 19mm board.
JLCPCB made another £10.62 out of me and I'm having a whiskey sour to celebrate.
It' pretty tight but I like the look of this....
TL;DR buy a cheap PicKit3 and use it to program your PIC via a breadboard
Things I learned ...
DO NOT try a TL866II programmer.
Somehow when I ordered these devices I had the idea I could program them in the TL866. .But that didn't stop me trying. The TL866 does support some PIC16's so I selected one from the config and put in my own PIC and tried programming. No joy. Given that te pinout was completely different this isn't surprising.
I then recalled that the TL866II has an ICSP port that might be used to program things like the PIC.
DO NOT try to use the TL866II ICSP port either
There's no point trying to use the ICSP port if the programmer doesn't undertand what the PIC16F18446 is. Apparently each family of PIC can have a different programming protocol on the ICSP lines so really wiring it up isn't enough. Perhaps they will add the PIC16F18446 to the TL866 in future. But for not it's hopeless.
At this point I figured that I have killed the two PIC's I'd been experimenting with.
Over on the EEVBlog someone told me to save misery and invest in a PIC programmer. On AliEpress (or via Ebay) it's possible to get a PicKit3 for £7 but I didn't want to wait a month for delivery. Instead I found one for three times the price but with next day delivery.
DO USE a PikKit3 programmer
With my new PicKit3 in I got no instructions but it did come with a board carrying a ZIF socket.
I found that on the bottom there was a stencil that indicate where to place the chip in the ZIF.
DO NOT use the PicKit3 ZIF board!!
So again hoping for the best I put a PIC into the socket where it indicated a 16F device and tried programming.
What I found was that the PIC got extremely hot!
It got so hot that the ZIF socket got quite warm and I was also worried that I'd probably killed the programmer device.
Another dead PIC probably.
I realised that to use the PicKit3 ZIF board I'd need some doco, so I gave up with it and decided instead to wire up the ISCP port pins of the PicKit3 to the PIC chip via a breadboard.
DO wire the PIcKit3 up to a breadboard.
With the five ICSP wires of the programmer hooked up to the PIC16F18446 the Mocrochip programer sofware was finally able to recognise the PIC device.
DO USE the MPLAB IPE to program your PIC16F18446.
The Hex file was created by the MPLAB IDE using (I will upload the project) but to program the hex file into the PIC you need to use the MPLAB IPE (integrated programming env) which is simply the Microchip provided control software for programming PIC's via various hardware interfaces. My hardware interface was the PicKit3 and the IPE was able to immediately recognise the PicKt3.
To program the PIC I turned on the option for the PicKit3 to provided power tio the PIC. Note: In the image below you can see a breadboard PSU on the right end of the breadboard howevert this is wired up to the LED on the left and plays no part in the PIC programming.
IF NECESSARY turn down the supply voltage
I got a warning about the PicKit3 not being able to supply 5v to the PIC but since the PIC will run at much lower voltages I went into the options on the IPE and turned the voltage down to 4v. With this change I was able to program the device successfully in a few seconds each time.
In the IPE loaded up the hex file produced by the build of my project and then hit the program button.
PAY ATTENTION to the supply pins
I burned out one chip by putting the supply the wrong way. The GND is pin 20 where 5v would be on a TTL chip. The 5v supply is on pin 1
---
Success.
I now have six PIC16F18446 chips programmed as dual digit seven segment display controllers.
Beautifully simple approach. There are 7 output pins driving the anodes of the LED's in parallel and the common cathode of each digit returns via a resistor to a dedicated output pin for each digit. 9 output pins in total.
8 input pins provide the pair of nybbles needed for the pair of digits.
Each digit is turned on 50% of the time and with the microcontroller running with it's internal clock set to 1MHz the digit refresh rate is flicker free at 150Hz.
I now have to wait for the PCB's to arive in a few days before I can have any more fun.
This design is even more compact than my last one.
The PCB below looks realy cluttered and it is - because the PIC microcontroller and the 7 segment displays occupy the same space.
The PIC microcontroller is mounted at the centre of the board horizontally and the two displays will directly on top but they are mounted into a line of pin headers. The pin headers jack up the displays sufficiently that the PIC can sit underneath them direclty on the PCB.
So this is a kinda 3D design.
It wasn't so hard to work out how to use the IDE. I've started using the Microchip MPLab X IDE rather than their online web offering because the native install includes simulation capability. I was wrong when I earlier thoughts that there was a charge for the local install and or the XC8 compiler. There is no charge. I installed the XC8 first then I installed the IDE and it was no effort.
I read the bit of guide http://microchip.wikidot.com/xpress:gpiointroduction explaining how to select which pins will do what and setup the device as shown below. (See document chapter "Locking pins as GPIO")
Once that was done I figured out how to generate a starter project and then wrote a very simple program wth a control loop that read the 8 bit input and setup the display control lines.
See https://github.com/Johnlon/SevenSegmentModule/blob/main/main.c
I need to get on with creating a PCB for this and I'll take some design elements from my previous seven segment module plus improvements.
Keep watching!!
Create an account to leave a comment. Already have an account? Log In.
@Ken Yap I was initally a bit put off by the provided Microchoip tooling - but I went back and found that the XC8 compiler is actually free and the locally installed (not web) IDE was actually pretty decent. With the local install you can actually simulate the chip / program, tweak pins and watch outputs. So writing the program without the hardware wasn't too bad.
Ordered the PCB's last night and the chips last week.
Fingers crossed.
@Ken Yap , having used the Microchip IDE I've found it really pretty goodf The hardware sim and logic analyser work well.
Become a member to follow this project and never miss any updates
I thnk there's a free less capable version of the IDE and compiler (installed separately) but it can be confusing to work out what can be used without a license.
You can also use SDCC to compile for PIC, see the end of my page here: https://hackaday.io/page/7182-hacking-on-teds-led-clock-software Hopefully that PIC model is supported. But I only generated the code and don't actually have any PICs to download to so you would have to figure out how to do that without the MPLab IDE. Often I find working with the CLI and Makefiles more straightforward than a huge IDE. But I think MPLab has simulation and debugging support. And lots of hand holding while developing.