VDI-RODERICO

[scrungy_doolittle]

ok. will post them later today or tomorrow, as I am on my way to a meeting. My reason for posting the project is to get someone who actually knows KiCad better, to add a page to the schematic, so it can be made more readable. And as for .sch file issues, all one has to do to fix that in windows, is to click on one, select open with, pick your program and click always use this to open these files. So you can easily take back control if you have let the install of KiCad associate .sch files.

In short, I need someone to add one or two sheets to the KiCad package, and then move connectors and such to the second sheet, as the PIC24FJ128GA202 component takes up almost all of the 8 x 11 sheet.....

[waltr]

I will. It will have to wait for later on this coming week.

Why don't you download KiCad, and unzip the attached zip file? You can then open the file and look at it, as well as modify it.
KiCad is free, and reasonably easy to use. It is a complete package, schematic entry, layout, pcb design and so forth. Totally unlimited and free.

http://kicad-pcb.org/download/

it installs a core set of libraries, and you can add my footprint to it.
My zip file, is essentially a complete project file. Rodrico's schematic was done in KiCad, so I simply opened his file in KiCad and worked on it.

Then it will High-Jack the *.sch files in Windows that are PCAD schematic files rendering problems with opening *.sch files in PCAD.

There was a discussion in the Tolls & Techniques sub-forum about which Cad software to post files to this forum. The consensuses is Post PDF files of schematics then Everyone can look at the schematic without install this or that cad software.

Here is the thread for your reading enjoyment:
https://www.geotech1.com/forums/showthread.php?25227-CAN-WE-SETTLE-ON-A-STANDARD-SCHEMATIC-PCB-LAYOUT-PACKAGE

I am not interested in the 'whole project' just to take a look at your schematic so I can participate in discussion.

[scrungy_doolittle]

I will. It will have to wait for later on this coming week.

Why don't you download KiCad, and unzip the attached zip file? You can then open the file and look at it, as well as modify it.
KiCad is free, and reasonably easy to use. It is a complete package, schematic entry, layout, pcb design and so forth. Totally unlimited and free.

http://kicad-pcb.org/download/

it installs a core set of libraries, and you can add my footprint to it.
My zip file, is essentially a complete project file. Rodrico's schematic was done in KiCad, so I simply opened his file in KiCad and worked on it.

[waltr]

I CAN NOT open the *.sch files ..........

PLEASE, post the schematic files as PDF so I can see them.
Thanks.

[scrungy_doolittle]

pic24 version first cut of schematic.

The attached zip file has a schematic that I worked on, and the appropriate lib and mod files for a PIC24fj128GA204 processor. http://ww1.microchip.com/downloads/e.../30010038c.pdf
These processors also have 3 rail to rail built in comparators, dma, RTC, and other items. Sure it is a bit of overkill, BUT it could evolve into a metal detector in it's own right. More on that in a different thread, but consider that it is capable of generating the transmit signal, and controlling the sampling windows for ground balance and discrimination in the IDX pro. I.E. one could use the processor to generate the sample timing for the synchronous detectors directly.
That however, is not why I am doing this. This achieves several objectives.

1. more pins so that the debug is not shared with the display.
2. much more memory
3. ability to use a spi display
4. extra pins for additional functionality such as timing generation, rotary encoder etc.
Microchips SNAP debugger can debug this part, and right now that debugger is available from microchip for under 8.00 (normally around 15, but there is a summer 2019 discount code)

I could not figure out how to add a sheet, so since the PIC24 is a larger component, I had to do a lot of packing. I tried to keep all the port defines the same, except that I used alternate pins for the debugging header, so they are not shared with the display,and I had to move CD/RS down to RA4 because RA2 and RA3 are the oscillator pins. oohh. it looks like I dripped those pins from the crystal...
What I want someone to do, is to add another sheet to this project, and move the connectors to it. I have not been able to figure out how to do that.
This is a 44 pin part and there are 16,32,64 and 128K members of the family, so there are 12 unused pins.
Once that is done, I will create an MCC3 file for it, and generate the low level drivers.
Two things I will be doing in addition to porting the code, is putting in support for a SPI display. This also has a 12 bit adc. USE A gb204 if USB is desired.
The second revision of this project will be to:
1. bring SPI out for display
2. Leave SOSC0 and 1 available for a 32 khz crystal
3. Bring a UART out to the pins, for debugging messages, or bluetooth communications.

[waltr]

As I have stated, sharing the debug pins with display control lines is a no no for debugging.

Absolutely, you do 'lose' two pins but worth it it in-circuit debugging is needed.

and use RB0,1,and 2 for the switches. This keeps them on consecutive bits at the ls 3 bits of the port, simplifying reading them.

This also allows using the IOC (interrupt on Change) feature.

[scrungy_doolittle]

I have opened the ide in kicad, and am working on creating some custom symbols for a couple of different flavors of PIC24's trying to keep the port definitions the same. What kind of display are you using?
(I am wondering if it has a 4 bit mode, rather than an 8 bit mode). One real issue is the sharing of the debug lines with the display. This basically makes it impossible to run the vdi on a debugger. I notice that there is one spare bit. unfortunately the pic18 does not have PPS mapping.
As an embedded guy, I see a number of problematic issues with the schematic. So I will share with you what I think it should be, but not criticizing the creator.

The EN line to the display, should always be tied enable, since you have other means of blanking it with commands and turning it off with commands, this frees up one more pin.
As I have stated, sharing the debug pins with display control lines is a no no for debugging.

So. make it a 4 bit interface, using D0-D3 (really simple in software). That frees up B6 and B7 for debugging, and gives you two spare I/O pins.

OR

I would allocate RC0-7 as the data lines for the display, and use RB0,1,and 2 for the switches. This keeps them on consecutive bits at the ls 3 bits of the port, simplifying reading them. I would use RB3 fro K-, RB4 for RW, RB5 for rst, RA4 CS1 RA5 for CS2, and tie enable permanently active.
The rational:
3 switch bits on the same port.
B6 and B7 available for debugging, without worrying about interfering with the display.
8 bits on the same port for Data lines to the display.
IF the display supports 4 bit mode, then it would be preferable to use 4 bit mode. It really is not much slower. rather than
Port=Data
clock hi
clock low
you have
port= data & 0x0F
clock hi
clock low
port = data >>4
clock hi
clock low.

The loss of processor time more than offsets the ease of debugging.
On a 44 pin PIC24, you also could set it up to use a SPI display, and indeed you could also use a spi display with the current connector, just use the D2 and D2 (pin 22 and 23) for the spi port.

[scrungy_doolittle]

sigh. yet another release without the source code. PLEASE ALWAYS include both the source and binary, so changes can be tracked. It helps folk understand the code.

[scrungy_doolittle]

Roderico, next board layout, please put the ICSP 6 pin header on the board. The problem with these pics, is that while I have an ICD3, a PICKit 2 adn PICKit 3 programmers, I don't have the wherewithal to make a zif socket programming header, and it would be better to be able to solder the PIC in place, and program it directly through the 6 pin header.

[kroman01]

"glcd_21beta4kroman01-5" checked out, looks and works great, my recognition for you

[roderico]

ok this one has the option to display the frame only (i.e. without the battery voltage):

[kroman01]

why I will lose my batteries in the current view
"Glcd_21beta4kroman01-4" exists under the name "frame", we leave it unchanged, I thought about adding an additional element in "idle" without displaying the battery for this place VDI can be "--" when no reading and STR can be 0.00V

[roderico]

in this case you could use another symbol to indicate "undefined", i.e. when X and Y are both 0 (inactivity), e.g. "??", "--", "..",... but you would lose the battery...

[kroman01]

aluminum foil rarely reads VDI 00 but between -05 ~ 05 depending on the distance from the coil, although STR after reading <0.01 V it should be stated that we have the correct VDI indication and can be seen in the histogram view

[roderico]

I see, but this is misleading IMO because 00 (as in the Lugatek) also means foil so you also need to check 0V in the STR and that there is no clear signal in the display to find out that 00 means other thing (not from foil)...