Eventually I made a thread about them some time ago.

Digged them out again, ordered some new 16F54 controllers (arrived today).

Having many blank PCBs here, I'd be interested to assemble a few + sell them.
They are very small.

How much could I charge for one?

Also the assembly is not easy. I have yesterday improved the TSSOP soldering- I get perfect alignment now. And it goes a lot faster.

With a broad tip (paid nearly 50 dollars for replacement tips), I make a big solder ball, and then touch one side of pins row with the solder ball!

Result is the IC becomes attached, without any movement. It is really bad if the IC moves just 100 micrometers- TSSOP is just 0.625 mm between each pin. The real free space between pins is about 300 micrometres!

Any misalignment, and it becomes very hard to remove the solder, even with a pump.

With the new method, I can pull off solder with the broad tip, apply flux and clean out all the gaps, and that's it!

2

The serial port is done in software, it is possible to monitor signals on the pins, and then send data just at the right time but I decided against that.

Instead, each time the display is updated, the controller chip must be reset! Then it waits for serial data. Result is, the display goes blank for 20 milliseconds. Not visible when using LCD but with a LED display, it is slightly visible.

Interface is 3-wire: RESET, DAT and CLK.

Any ideas or comments? Yes I know, hardware serial port would be better.

 

My understanding of what is appropiate for a testing/prototype circuit has changed- I changed over to use C language some time ago.

I suffered from two very common bad behaviours:

-Using assembler
-Trying to save PCB space for whatever reason

Now I have a big stack of prototype PCBs around- it simply does not matter anymore how much PCB space I use.

I tried the old circuit but it did not work, and was quite messy.

I need two programming headers- one for the master controller, one for the serial display. These also need 5v programming voltage, while later, they are powered from a 3 volts button cell.

A 16F1503 is used here for sending serial data.

I have a plan to read out the programmed image from the display, and then FLASH it back using the master PIC. A primitive programmer so to say.

Maybe it wont fit into 2K FLASH? For the image I could use a serial EEPROM.

 

It does not look like if I would sell off all of them in a few days...

I have actually put considerable effort into developing them, both time and money.

Price would be $5 considering the effort the assembly takes.

Today, I wired up the new testing programming board, found the old project too, and made the small 0805 LED blink (at 8 MHz, running from button cell), with a 2.2k resistor.

And I connected one LDR. I want to power it through IO, sample, and power off again.

One key is connected parallel to the LED. I hope with the WPU, I can switch to input, and with the LED forward voltage, still get about 2.2 volts, when the key is pressed, 0v.

And yes I want to try read out the programmed PIC, save to EEPROM, and FLASH again. 16f1503 is a bit tight, only 2K FLASH.

I want to switch the MCLR with a transistor, and connect with a PNP to proramming voltage...

A lot of plans.

Or maybe just mothball it, everyone is using nokia5110 these days...but I see people wiring up 7seg every once in a while. At least, I dont have to do that anymore.

 

Hi Takao, interesting project.

Your text rambles quite a bit! People might not be sure what the project does or WHY it is a good thing.

If I understand it right, you have made some 4 digit 7-seg modules, with a PIC built in, so it only needs 2 (or 3?) wires to control it from another PIC or another micro. Is that right?

One suggestion would be to make it accept USART serial data, so it only requires ONE digitial output pin to drive all 4 digits. Then the other micro could just send 4 serial bytes to operate the 4 digit display.

 

I don't understand why it does not keep accepting serial data instead of needing to reset each time the data changes. Is it because you cannot figure out how to multiplex the displays and get serial input as the same time?

Bob

 

I don't understand why it does not keep accepting serial data instead of needing to reset each time the data changes. Is it because you cannot figure out how to multiplex the displays and get serial input as the same time?

Bob

I can but it is too complicated, especially for people who buy these displays.

Yes I can multiplex it, turn off the displays, check for the transition on the master, then send within some time, and also the display must test if clock signals arrive within some time.

With these 16f54 displays, I will use simple as possible serial bus. It needs 3 wires.

Not sure if there is large demand for serial 7seg displays, so it could be worth it to design another with hardware serial port.

 

Are you aware there are already heaps of cheap 8-digit serial displays from China ebay sellers for $4.98?

http://www.ebay.com/itm/DIY-Kit-MAX...274?pt=LH_DefaultDomain_0&hash=item3a8b98e4f2

.

 

I've used techniques similar to those in AN510 to do software UARTs using Timer 0 to manage timing while multiplexing LED displays (and do lots of other things a the same time).

But RB's post shows that its probably not worth it any more.

Good luck!

 

Which chip are you using, the 18/20 pin 16F54? What clock speed? How many digits are you driving, 3 or 4?

One method I've used for bit-banged serial RX was to sample the RX pin at 3x the bit rate (34.5 usecs for 9600 baud). With an 8-MHz clock an RX state machine uses ~14 cycles of each 69 cycle sample interval which leaves plenty of time to process serial data and refresh a display.

Would you like some help?

 

Which chip are you using, the 18/20 pin 16F54? What clock speed? How many digits are you driving, 3 or 4?

One method I've used for bit-banged serial RX was to sample the RX pin at 3x the bit rate (34.5 usecs for 9600 baud). With an 8-MHz clock an RX state machine uses ~14 cycles of each 69 cycle sample interval which leaves plenty of time to process serial data and refresh a display.

Would you like some help?

Thanks, I appreciate you offer for assistance.
Generally, I dont do cycle counting or any assembler coding.

And I use a small 22uH coil, not a crystal, I dont actually know the frequency, it could be about 10 MHz.

It is a 20pin TSSOP 16f54.

For asynchronous serial port I'd need a crystal, guess. Coils are cheaper, smaller, and dont need capacitors.

Both 3 digit and 4 digit displays are possible.

It is possible to sell them at 3.98 but I'd prefer $4.98

The chinese displays are much larger, after all.

Best would be to mass produce the carrier PCBs, using blank die's- I could use a 28 pin PIC, and external EEPROM table, so they can be good for any 7seg display.

Preprogram a number of common 7segs into an EEPROM or the internal FLASH, and have PCB pads for another EEPROM.

Guess LED 7segs are not all that important anymore, many people use small TFTs now, low price, and more flexible.

To get back on MMcLarens reply, a future revision likely will be based on a PIC with hardware serial port, and SOIC instead of TSSOP.

The problem with the 16F54 is that it has no interrupt, so if there is a transmission error, the display would hang.

Resetting the controller frequently, it will only go blank for a second or two in case of a transmission error.

What controller do you use for your serial display? What crystal? 8 MHz?

 

I use a small 22uH coil, not a crystal, I dont actually know the frequency, it could be about 10 MHz.

For asynchronous serial port I'd need a crystal, guess. Coils are cheaper, smaller, and dont need capacitors.

Could I recommend using something like a Murata 8-MHz ceramic resonator? It's cheap (21 cents), small, doesn't require capacitors, and it would provide the frequency tolerance (0.5%) that would allow you to bit-bang async serial.

What controller do you use for your serial display? What crystal? 8 MHz?

Plenty of choices. Devices with an internal oscillator should work fine. A UART peripheral, even better.

At ~50 cents a piece, I suppose a 16F54 would be ok, after adding a 21 cent 8-MHz resonator, as long as you can get by with only 512 words of memory, 25 bytes of RAM, and 12 I/O pins (not to mention other limitations in 12-bit core devices).

For just 19 cents more (90 cents) you could get a 14-pin 16F1503-I/SL (SOIC) which is a 14-bit core device with 2-kWords program memory, 128 bytes RAM, a 16-MHz internal oscillator, 12 I/O pins, and more peripherals than you can shake a stick at.

Thanks, I appreciate you offer for assistance.
Generally, I dont do cycle counting or any assembler coding.

Well the offer still stands. If you decide to add the resonator, I would be happy to help you with a bit-banged 9600 baud program to drive your 3 or 4 digit display. Program code to duplicate your "reset" feature is optional (grin)...

Good luck on your project.

Cheerful regards, Mike

 

Could I recommend using something like a Murata 8-MHz ceramic resonator? It's cheap (21 cents), small, doesn't require capacitors, and it would provide the frequency tolerance (0.5%) that would allow you to bit-bang async serial.
...

I will second that idea. You can get 3-pin resonators by the bag quite cheap if you keep your eyes open. They don't need caps and will be plenty stable enough for serial comms.

It does not matter what speed the resonators run at because you can manually setup the serial comms baudrate anyway, but personally I would look for resonators close to 20MHz so your PIC will run near its max speed, making coding much easier. There's no advantage to this application of running at less than max speed.

If you check the surplus suppliers for "end of production run" parts you might be able to get a bag of 100 resonators for a few pennies each.

 

I will second that idea. You can get 3-pin resonators by the bag quite cheap if you keep your eyes open. They don't need caps and will be plenty stable enough for serial comms.

It does not matter what speed the resonators run at because you can manually setup the serial comms baudrate anyway, but personally I would look for resonators close to 20MHz so your PIC will run near its max speed, making coding much easier. There's no advantage to this application of running at less than max speed.

If you check the surplus suppliers for "end of production run" parts you might be able to get a bag of 100 resonators for a few pennies each.

I got a generous tape cut with small 18uH SMD inductors recently.

I tried them on the board, they need a 6mm wire piece on one end, but still easier than to fit the TH coil.

-sometimes the coil breaks, about one in ten or 15.
-sometimes one of the holes clogs from the TSSOP soldering, and then the wire needs to be heated and pushed into the hole.

using the small SMD coil gets rid of that, as well I have nearly run out of these 22uH inductors (the small color wheel inductors variant is harder find).

There is a even more smaller variant of color wheel inductors, sometime lime green (not teal), I saw it sometimes on TV PCBs, but almost impossible to remove.

That said, I made the new carrier board working.
Removed the brightness control from the firmware, as well to query the timer at all, result: totally flicker free now (why for whatever reason, wait until a timer cycle completes before refreshing??).

As well DAT and CLK are swapped, the imprint on the PCB is for ICSP of the PIC 16F54.

3 or 4 digits both work, the 3 digit display simply starts displaying as soon as the data has been clocked in.

I like these displays, somehow, less effort to wire than a Nokia 5110, and smaller.

And they do work even at 2.2 volts, from a button cell, the green LED nearly goes off, but the LED 7seg is still visible.

 

Here an update with pictures, and source code for testing.

The source code is here: http://aranna.altervista.org/dragonsnest/serial-7segment-led-display-module/

Also obviously, there is no glass so the module does not break as easily as a LCD, TFT or OLED.

In the picture, the voltage is close to 2.0 volts, so the display isnt very bright.

I did not assemble them anymore because TSSOP is difficult, but as said, recently improved on TSSOP handling.

 

Code for the 16F54 LED Display seems to missing on that page...

 

Code for the 16F54 LED Display seems to missing on that page...

Yes it is not included. Should I include it?
Then everybody can just rebuild it.

It's not that complex, occupying about half of the 512 words FLASH memory.

Maybe I put it here on the forum:

#include <xc.h>         /* XC8 General Include File */
#include "system.h"        /* System funct/params, like osc/peripheral config */
#include "user.h"          /* User funct/params, such as InitApp */

// 3 digits
// 18 bits

const unsigned char ph_PORTA[]={0x00,0x02,0x00};
const unsigned char ph_PORTB[]={0x80,0x00,0x01};

const unsigned char dig_PORTA[]={0x0,0xc,0x4,0x4,0x8,0x1,0x1,0x4,\
                                 0x0,0x0,0x0,0x9,0x1,0xc,0x1,0x1};

const unsigned char dig_PORTB[]={0x28,0x6e,0x58,0x4a,\
                                 0x0e,0x0a,0x08,0x4e,\
                                 0x08,0x0a,0x0c,0x08,\
                                 0x38,0x48,0x18,0x1c};
unsigned char v_digits[3];
unsigned char v_phase,v_refresh,v_PORTA,v_PORTB;
unsigned char v_digit_data,v_digit_data2;
unsigned char i;

#define clk PORTBbits.RB7
#define data PORTBbits.RB6

void get_serial()
{unsigned char i;
unsigned char sh_val=1;

    v_digit_data=0; // 6 bits transmission

    for(i=0;i<6;i++)
    {
    while(!clk);if(data)v_digit_data|=sh_val;
    while(clk);
    sh_val<<=1;
    }
}

void refresh()
{
         v_digit_data2=0xff;

	 v_digit_data=v_digits[v_phase];
	 if(v_digit_data&0x20)v_digit_data2=0xf7;
	 v_digit_data&=0x1f;

          v_PORTA=ph_PORTA[v_phase]|dig_PORTA[v_digit_data];
          v_PORTB=(ph_PORTB[v_phase]|dig_PORTB[v_digit_data])&v_digit_data2;

	 TRISA=0xff;TRISB=0xff;
         PORTA=v_PORTA;PORTB=v_PORTB;
	 TRISA=0;TRISB=0;
         v_phase++;if(v_phase==3)v_phase=0;
}

void main(void)
{
    TRISA= 0xff;
    TRISB= 0xff;
    v_phase=0;
    v_refresh=0;

    for(i=0;i<3;i++)
    {
    get_serial();
    v_digits=v_digit_data;
    }

    PORTA=0;
    PORTB=0;
    TRISB=0;TRISA=0;
    OPTION=4;

    while(1)
    {
          refresh();
    }

 

Thanks for the info.

Good luck on your project.

Regards, Mike

 

Thanks for the info.

Good luck on your project.

Regards, Mike

It's not a new project, just digged it out again.