User Programmable Standards Converter

[Mike Watterson]

Those LCDs last forever and are easier to read. They are not expensive.
The OLED is more a size for a wearable. The cheap OLED have shorter life than ones in phones and deteriorate in storage. There is a reason they are really cheap! The OLED are really organic compound printable dots as an Electroluminescent material that happens to behave like a diode. Then colour is added by phosphors sometimes aided also by colour filters. The small ones use cheap packages. The LCD uses glass and decent seal with glass balls in the glue so the panels are accurately spaced.

I've used the LCD graphic panels when the 16 x2 is too limited. I think 128 x 64. Programmed in JAL using an 18F series PIC.
I've done both kinds as a serial terminal in s small hand held case with a 4 x 4 key pad, 4 coloured buttons under the display for menus and sometimes other buttons too. Keyboard scan and display drive sharing output pins.

[`FRANK.C]

I didn't know that they are that bad. It's good to know at this stage. I think I will stick with the old faithful 16 X 2  LCD.

The reason I would like to stick with the same size PCB and case is it will cut down on the amount of work needed to be done. Also keeping the PCB size below 100 mm X 100 mm keeps them cheap. Go above that size and the price jumps.

It's not a big problem. A 16 x 2 LCD display  and two rotary encoders will just fit on the front panel of the original Hedghog case. The PCB will need to be shortened to accommodate the display.

Frank

[`FRANK.C]

Just a little update.
Before I went any further with programming I wanted to move to the FPGA that I will be using which is a EP4CE6 as it is a smaller one than the one that I started off with a EP4CE10. I got a PCB made up. It isn't the final version. I have gone back to a LCD display. So now any 16 X 2 display that uses the HD44780 or equivalent control chip should be able to use with it. The cut out in the PCB is large enough for some smaller LCD displays to fit in it.
This is one example https://www.mouser.ie/ProductDetail/763-...FSWFBW33V3

I just need to get on with the programming now.

Frank

[ppppenguin]

If there's not much price difference between the two FPGAs and final cost isn't too critical always use the bigger part. It allows for new ideas later.

[Freya]

Board layout is looking very good Frank, what's the total current consumption with the additional components and LCD now ?

[`FRANK.C]

Good point Jeffery
The EP4CE6 is about half the cost of a EP4CE10.
https://ie.rs-online.com/web/p/fpgas/7293757/
https://ie.rs-online.com/web/p/fpgas/7716724/
A EP4CE15 has approximately 50% more Logic Cells and more memory than a EP4CE10 but cost about the same.
https://ie.rs-online.com/web/p/fpgas/7716727/


Hi Stephen
I wont know what the maximum consumption until is it is fully functional and it will depend a little on what display is used.
But currently it is drawing around 320 mA.

Frank

[ppppenguin]

In my professional designs I've been in trouble too often for not using a bigger device. Sometimes it was because I was already using the biggest device in a family. Sometimes it was fear of specifying a more expensive device or moving to a more advanced and more expensive family. Sometimes it was because the client wanted new features in an existing design and I had to squeeze them in. Trying to squeeze a design into a crowded device is no fun at all. I've done it too often. It will usually fit, but the timing requirements go bad very easily.

As for power estimation, there are software tools for doing that but I don't really trust them. It can be worth putting very low value resistors in series with each power rail in order to monitor current. They need to be fitted in an approximation to a 4 terminal resistor to get reliable readings. Unless you're under severe cost and/or space constraints, always overdesign the power supplies. Saves a lot of trouble later.

[Nick]

+1 to all of that.

I always leave at least 25% free space in any programmable device on a board (processor, eeprom etc). I also over design the power delivery and am fairly paranoid about ESD protection and RFI filtering around any external interface on a board (usb, ethernet, power, JTAG...). Muntzing these things is generally a very bad plan.

Commercial constraints may of course alter these priorities 

[`FRANK.C]

No one could argue with any of that.

So far in the FPGA I am using 55% of the logic elements and 24% memory
In the microcontroller less than 9% used of both program memory and RAM. Not using any of the EEPROM yet but I will be.

The 2.5 V, 1.2 V and 1.8 V regulators are all 300 mA devices . The 2.5 V and 1.2V regulators supply only the FPGA and the 1.8V only the video decoder.
All IO's are 3.3 V.
The 3.3 V reg is a 500 mA device and supplies everything apart from the modulators which are supplied from the 5V rail.

The 7805 does most of the grunt work dropping the incoming supply down to 5V.
The 7805 would normally have a heat sink but currently hasn't as I am just running it from 7.5 V.


Frank

[`FRANK.C]

One of the things I wanted to do after moving to the new PCB was sync the output to the input at frame rate. It was difficult to do on the old set up on account of how the clocks were arranged.
As the old setup was not synced it would drop a frame every so often. This would not be noticed on a test card but on a moving picture it had a horrible effect of the picture been split horizontally. The split been where the frame is skipped. I found it incredible how far even slow moving objects travel in just one frame.

As the  output clock is derived from the input clock it should be a simple job to sync them. I took a frame reset pulse from the input side put it through a 2 flipflop synchroniser and chose a suitable place on the output to sync to. It just took a couple of minutes to do.
But it could be easily seen it wasn't syncing properly as there was hooking at the top of the picture. The degree of hooking varied depending on the settings of front porch, sync, back porch, number of lines etc. At some settings it even appeared to sync properly.

The output clock is calculated as
Frequency in Hz = (front porch + sync + back porch + active line) * no. of lines * frame rate
Frequency in Hz is then multiplied by a coefficient. The result is used as the DTO  coefficient.
I was suspicious of the coefficient that gets multiplied as it was of a relatively low number of bits and may be the cause of an inaccurate clock frequency.
I recalculated it to be sure it was correct and increased the number of bits but that made little if any difference.

To narrow things down I displayed the calculated frequency on the LCD and monitored the actual clock frequency and they tracked perfectly.
I then removed the frame sync and monitored the output side frame frequency. The frame frequency should remain constant but it wandered all over the place as the settings were changed even though the clock frequency was tracking correctly.

This would suggest that the problem lay with the counters in the FPGA.
But the counters are the same as what is used in all the Hedghogs and I never had a problem with them.
To get from clock frequency to frame frequency there are only 2 counters. The half line counter and the vertical counter.
It then dawned on me what was happening. As the half line counter reset value is got from  (number of cycles in a full line / 2) if the number of cycles in a full line is odd the half line counter cant reset at the correct time so the line frequency will be off which in turn will put the frame frequency off.

The solution is to ensure that the number of cycles in a full line is even.
This I have done within the microcontroller. Before the clock frequency is sent to the FPGA. The full line value is checked to see if it is even. If it is not a cycle it added to or subtracted from the number of cycles in the sync pulse. This will then make the full line value even. A note is kept of whether a cycle has been added to or subtracted from so that the next time an adjustment is made the opposite can be done. This keeps the number of cycles in the sync hovering around the desired value.

Frank