www.picgraphic.com

[normnet]

I think @normnet hasn't downloaded the library yet because then he would have seen that the file he is looking for, fat.inc, is in the SDcard directory.

Johan

No problems. Thanks Johan. I had mistakenly downloaded TFT_DEV_BOARD.rar as I didn't click on the "current version 1.02" link until now.

[Peter Truman]

After trying to make sense of the Proteus files (I find Proteus clunky and hard to work with, I'm sure it's fine if that's what you are used to, but not at all intuitive for me!) - I gave up and recreated the design in Diptrace from Transtikatas schematic! I got lazy and laid this out on a 4 layer board (extra cost is minimal). I also added a couple of touches of my own, including a debugging output (only for the 18F67k22) and a buzzer. Since my standard ICSP pins differ from the original design, I've added 2 sets (Transtikata's and mine)

I bought 2 x each of the Recommended Displays from Ali Express - total cost less than A$60 including freight!

I'll be having these made at PCB Cart in China (My regular Board House and I can run the freight cost in with other jobs) - since there are limited options here in Australia.

Little more work to do just to make sure I have translated the netlist properly, but otherwise ready to go.

If anyone is interested in the Diptrace files I'm happy to share (no - I don't work for Diptrace :-)

I've done this for a couple of reasons - one is that my wife is very ill at the moment and laying out boards is simply the best way of distracting myself, the other is that I'd be surprised if there weren't several people on the forum who would want to experiment with Transtikata's library - and this would be ideal hardware to do it with (since Transtikata only had a few boards left over). Let me know if you are keen!



 

[trastikata]

Hello Peter,

nice looking boards. One thought, however - I saw the 3d pictures and it looks like you have installed buttons for the PIC reset. If you intend on using 8b and 16b chips at the same time, you need to hold one in reset state while the other is active, that's why I used a jumper.

[Peter Truman]

Hello Peter,

nice looking boards. One thought, however - I saw the 3d pictures and it looks like you have installed buttons for the PIC reset. If you intend on using 8b and 16b chips at the same time, you need to hold one in reset state while the other is active, that's why I used a jumper.

Ah.. understood! - I'll change them to jumpers - hold one PIC in reset while programming and experimenting with the other. Makes sense. Thanks for the tip.

[Peter Truman]

Just a quick question - On the PIC18F67k22 you appear to have pin 38 and 13 tied together - with pin 25 on the DSPIC - all driving the test LED & F_CS (on the 3.5inch display)? is there any reason for that?

[trastikata]

Just a quick question - On the PIC18F67k22 you appear to have pin 38 and 13 tied together - with pin 25 on the DSPIC - all driving the test LED & F_CS (on the 3.5inch display)? is there any reason for that?

You probably meant PIN28 and PIN13 on PIC18F67K22?

PIN28 (TEST_LED) - goes to the test LED.
PIN13 (F_CS) - goes to the F_CS bus which is connected to the Chip Select pin for screen built-in FLASH memory SMT slot which some screens with parallel port have.
PIN22 (MEM_CS) - is the Chip Select for the on-board Flash memory chip since not all screens have a built-in memory slots.

The PIC18F67K22 is a 64-pin device has free pins enough for all lines, so all lines are separated. The DSPIC33EP128MC504 is a 48-pin device and does not have enough pins for all lines.

I did not plan on using F_CS just for one or two screen models only and I 'd rather use the universal on-board FLASH memory i.e. the MEM_CS line for all models. So the F_CS shares a pin with the TEST_LED on the smaller device (DSPIC33EP128MC504) just in case if I ever had to test the screen built-in FLASH memory SMT slot.

[Peter Truman]

28 and 13 correct - fingers are too fat for the keyboard :-) my apologies.

The net I have (from Proteus) is

Test_Led,7
Test_Led,OT
F_CS,OT
R3,PS,1
U5,IO,28
U5,IO,13
LCD1,PS,32
U3,PS,25

So from a hardware perspective, pin 28 and 13 on the PIC18F are tied together - also connected to pin 25 on the DSPIC and pin 32 on the 3.5inch LCD

Sorry if this is a silly question but, If you are are using the test led while the SPI is running data, wouldn't that corrupt the signal - since any module with built in flash will think it is being accessed while you are pulling the led signal low?

Doesn't sound like it's a biggie but I did want to check before I commit the boards.

The hard part for me will be figuring out how to use the Firmware! (haven't really looked at it yet) My plan is to try this all out while using the Positron Studio IDE - nothing like jumping in at the deep end!

Thanks again Transtikata - no way I would have done this on my own.

The end result has to be well worth the effort - I have several projects that will be significantly enhanced over my standard 4 button, 2x16 LCD HMI approach and it's time I got with the program!

[trastikata]

If you are are using the test led while the SPI is running data, wouldn't that corrupt the signal - since any module with built in flash will think it is being accessed while you are pulling the led signal low?

Hi Peter,

you are right that in HW both pins are tied together. I was tired when I designed the board one late evening and first did the 64 pin device, then started the 48 pin device and got mixed what I was going to do, left it for the next day and then forgot to isolate the line with a 0-ohm resistor jumper.

The LED is there actually only for debugging purposes while developing the library. So far I have not used the TFT Flash SMT pads because it is really impractical soldering/desoldering multiple Flash ICs where slots are available and for the rest of the displays which lack those slots I would have used the on-board flash anyway.

So the F_CS was there just in case I ever decided to use it and I keep the F_CS pin on the 64 pin device as input and the led is rarely used, mostly for debugging.

P.s. I saw the 3d PCB design and noticed the nick-name in the credits is misspelled, but there's really no need for that on the PCB, I wouldn't object if you remove the credits from there  .

[Peter Truman]

oops - apologies once again.

I try always to give credit where it is due - it's a product of being a complete imposter in this business and being very aware there are many things I can't do without the input of others!

I just googled 'Trastikata" and found an eda blog - which I presume is you? It looks very useful so I registered, never being one to miss an opportunity! Chat GPT didn't come with an origin of the word and, ironically, suggests I may have misspelled it!

Thanks again

[Peter Truman]

Fixed - I compromised with the credit thing - just made it smaller :-)
 

[trastikata]

Peter, I was looking at the ICSP pinout on your board and I was wondering why this order? I've always been following the standard PICkit ICSP  header:

[Peter Truman]

I'm afraid it's just a legacy thing - way back when I was just starting (as a hobby) I had barely the faintest idea of what I was doing. I was experimenting with ICSP (prior to that I was using a ZIF connector for programming and sockets for the PIC), I found myself with this configuration. Since I was only 'messing about' it didn't seem important so I never changed it. As time went on I figured I should change to meet the standard, but never got around to it. Now, Many thousands of boards made later - I'm stuck with a mistake I made about 26 years ago! So I guess you could say it's proprietary, designed to catch the unsuspecting hacker! (but that would be a lie). I could of course just make up a new cable but, for the sake of a 5 pin header, I didn't even think about it.

More recently I've been designing boards that use the PIC32MZ - they have the 6P6C jack to suit the MPlab ICD4 programmer - but I only do the hardware for these so I do what the dev tells me to do.

I did consider changing to the Jtag programming header - but I found it bulky and inconvenient - so I just stuck with what I have been using all this time.

How do you get on with the Pickit 3?, I read somewhere that it was slow. I still use the MeLabs U2 programmer which I bought way back (I have several now) because it has served me so well.

[John Lawton]

I still use the MeLabs U2 programmer which I bought way back (I have several now) because it has served me so well.

I've also used the U2 for many years, before that the EPIC, but it doesn't work for me with the dsPIC33EP devices I tried it with so I had to get an NSDS programmer (NSDSP-2-X) which does.

John

[trastikata]

TFT Graphic Library has been updated to v1.03

- Add SPI DIO (single Line) read pixel - TftReadPixelSda()
- Add SPI DIO (single Line) "screenshot" to BMP file in SD card - TftBmpScreenshotSd1()
- Add SPI DIO (single Line) "screenshot" to BMP file in Flash memory - TftBmpScreenshotMem1()
- Add Pixel Verification for screen boundaries - $define TftPixelCheck
- Add driver RAM offset - $define TftWidthOffset & $define TftHeightOffset
- Add driver for ST7789 (graphic IC)     
- Add driver for ST7735S (graphic IC)
- Add driver for ILI9488 (graphic IC)   
- Add driver for GC9A01 (graphic IC)
- Add driver for ST7735 (graphic IC)
- Fixed a bug in "screenshot" to BMP file in SD card
- Fixed a bug in "screenshot" to BMP file in Flash memory
- Updated ST7789V driver for better contrast
- Updated ST7796S driver for better contrast
- Review some common screens

About Pixel Verification and Screen to Graphic RAM Misalignment read at the bottom of this page: https://picgraphic.com/Howtostart1.html

Some screens use a single bi-directional SDA (Serial Data) line for both input and output. In such cases, you must use the dedicated bi-directional SDA line functions provided in the library to read data from the screen: TftReadPixelSda() / TftBmpScreenshotSd1() / TftBmpScreenshotMem1()

Review of some common inexpensive displays: https://picgraphic.com/GraphicIC.html