ok this one has the option to display the frame only (i.e. without the battery voltage):
Announcement
Collapse
No announcement yet.
VDI-RODERICO
Collapse
X
-
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.
Comment
-
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.
Comment
-
Originally posted by scrungy_doolittle View PostAs I have stated, sharing the debug pins with display control lines is a no no for debugging.
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.
Comment
-
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.Attached Files
Comment
-
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.
Comment
-
Originally posted by scrungy_doolittle View PostI 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.
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.
Comment
-
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.....
Comment
-
Originally posted by scrungy_doolittle View PostHere is the pdf.
As you can see it is pretty crowded, which is why I would like someone to turn it into a multi sheet project (at least 3 sheets)
that doesn't look too crowded if that is all there is. It actually looks very good and I can not see any value of splitting this onto multiple sheets.
A little trick is not putting every name for each processor pin on it's schematic symbol. 2 or 3 primary pin names is enough to draw and show a schematic. The processor schematic symbol is then smaller (narrower, it can be 1/3 the current width) allowing more room.
Then use Net Label/Names to label wires going to the processor that are specific to the design makes it very readable.
Example: pin 19 can be simply "RA0/VREF+". The data sheet and a spread sheet is used if other pin functions are used. The way it is currently drawn it is not totally clear as what pin 19's internal function is. Pins 3, 2, 36,... are clear that these are digital inputs so use function RC7, RC6, RC3,...
Comment
-
>>>>.that doesn't look too crowded if that is all there is. It actually looks very good and I can not see any value of splitting this onto multiple sheets.
Because 1. it is to cramped to add new features. There are some things I want to do with this, one of which is use the VDI to generate specific tones, but that requires a small amp and speaker. I agree that perhaps for the vdi this might do, but for me, this is just a starting point for other features.
[QUOTE]A little trick is not putting every name for each processor pin on it's schematic symbol. 2 or 3 primary pin names is enough to draw and show a schematic. The processor schematic symbol is then smaller (narrower, it can be 1/3 the current width) allowing more room. [\QUOTE]
When I pulled the 44 pin template in, that is how big it was, and I don't know how to fix that.
Then use Net Label/Names to label wires going to the processor that are specific to the design makes it very readable.
I will note that there are a couple of changes that would have to be made to pin mapping in the current source code, but it should be a fairly painless port.
The main issue is that the OSC pin was in conflict, and the debug pins need to be separate.
Example: pin 19 can be simply "RA0/VREF+". The data sheet and a spread sheet is used if other pin functions are used. The way it is currently drawn it is not totally clear as what pin 19's internal function is. Pins 3, 2, 36,... are clear that these are digital inputs so use function RC7, RC6, RC3,...
Comment
-
I have just read the messages and I see there is a lot of progress in the pic24 port, but I cannot open the *.sch files either in kicad 5, maybe you already have an updated and working version so if you could possibly upload them again I could also have a look...
Comment
Comment