Feedback on Schematic

[LabRat]

It didn't. I was using the VPP from the JuneBug ICSP header. Ive changed it over to using the testpoint connectors. I also found that the pin I had remapped for the A0 line, was actually connected to one of my led's. Moved that over to a truly FREE line, and now there is clearly activity on the LCD. Just not valid characters (yet).

Making progress.. but not there yet.

 

[blueroomelectronics]

A typical LCD backlight will often draw more than your USB port can supply (default is 100mA). Keep the backight LEDs off if you're powering it from the Junebug.

 

[LabRat]

I will keep that in mind. These displays are old school with no backlights.
So far so good at all the "proof of concept" work. I think it might be time to start working on my board layout.

The board I want to create is slightly larger (width) than the available size for free use of Eagle. Anyone have some other recommendations short of generating 3 smaller boards (CPU, Left & Right IO devices)??

 

[LabRat]

Well... life got involved and I had to shelve this for a while. But I dug my Laptop out the other evening, and started looking into the layout (yep.. almost a year later). I was surprised to find that I had actually completed the majority of the routing on a small board, suitable for a small proto-type run. I'm just getting through the last of the DRC checks now, and was thinking sending this off to BatchPCB.

Hope you all missed me... (ok ok.. hope someone here might still remember me.. )

 

[Noggin]

Hmmm... Its probably more work than its worth, but I wonder if you could design your boards at half size and then use a gerber editor to double everything. Alternatively you could go with ExpressPCB, they have a crappy but very usable proprietary design tool. Looks like you're past that point though.

 

[LabRat]

Hmmm.. interesting ideas. Perhaps on the v4 of the boad. I opted to just route it on a small rectangle (3"x1.7"), and sent it off to BatchPCB. In "theory" I will get the results of my first PCB in about 4 weeks. Assuming all goes well, and I can get the board operational, I can then look into modifications to spin the board in a way that will properly fit the enclosure. I suspect I can do it with 2 boards, one being an "I/O" that would hold the LED's and IR sensor, and a second board containing the USB and LCD, and the PIC itself. Standard ribbon cable between the I/O and the main board.

Mind you ... submitting a PCB for production at close to 2:00 am, may not have been the smartest of moves. Time will tell if I overlooked something I shouldn't have. (though
it did pass all DRC rules etc)

Right, wrong, or otherwise here's the link:

Products

If you see a glaring error, I think I would rather not know, until I've had a chance to touch the boards. It would suck to be waiting for boards you know aren't going to work (takes all the fun out of it).

 

[LabRat]

Learning from my mistakes...

Thought I would keep this thread alive, and share my "learning experiences" in hope that others might benefit from the mistakes that I made.

My PCB's just arrived. These are a first for me, and here are some scans.

(I've flipped the bottom layer left-to-right, so that you can look at them
one above the other, and things will line up)

The third scan has certain areas highlighted, and here are the lessons learned from each of those. (I will continue to post any further snafu's as I encounter them)

1. GREEN - I went to "dry fit" the component only to find that the legs of the part were not in alignment with holes in the board. After some head scratching I went back to the Eagle library, and the picture in the library matches the datasheet... but DIDN'T match my board. I went to add (temporarily) another one of these to my design, and was shocked to see "you have one of these in you design, but the library has been updated, would you like to use the new part?"

(ARgghghgh... the original library was wrong - LESSON: Always check packages for all parts in the library (NEVER ASSUME))

[Solution: I can install the part on the solder side, and all the pins will line up correctly.]

2. RED - This is for a 2x2 LED array. Turns out the package I have is slightly wider than the pin spacing here. So the two rows of 4 are actually angling in ever so slightly. The package, therefore, can't sit 100% flush with the board. I'm sure the solder on 8 pins will hold the part, but it would have been nice to have the part smooth up against the board. LESSON: Always check packages for all parts in the library (NEVER ASSUME))

[Note: Due to the pinout of the part, I can actually install this from the solder side as well, and have the LED's run beside the IR receiver (see Note 1 as to why)]

3. PINK - Silkscreen atop of conduits - I should have noted this and moved those Rx labels

4. YELLOW - This is a "what was I thinking" moment. I have a trace leaving a through hole pin, travelling about 1mm, and then going through a conduit to the other side of the board. (Spotted this as I was re-working the design for a TSOP part. Can't believe I did that)

5. TEAL - This is actually a design issue, and not with the R4 that is highlighted. R4 is a pull-up on the SDL line of the I2C bus. As I was perusing the datasheets for the temperature sensor, I found that I should have pull-ups on the SDA, and the ALERT lines back from the part. Luckily I have the I2C breaking out to a header, and so adding a pullup (for the SDA at least) will be trivial.

Lesson: RTFM - read the *FULL* manual

6. BLUE - This is meant to be a "power" connector as found on 3.5" drives etc. I had thought to canabalize some old drives to get the connector. When I went to do this, I found that they all were 90-degree connectors, and thus wouldn't fit on my board. So my plans to use "old stuff off my workbench" fell flat. I'm going to have to purchase a couple of connectors... NEW eek.

LESSON: Make sure you have the parts, before putting them in your design.

Solution - either buy new parts, or consider running that "90-degree" connector off the bottom side of the board (I see a trend here). What the heck I can put the switches (RESET/PROG) on the bottom as well. Not quite the original intent, but should still function quite well as the "first" proto-type.

I will keep you posted as I work my way through.

 

[LabRat]

This weekend's board "bring up" efforts...

a. D+/D- on the USB connector are reversed
b. There is no item 'B'. Just checking if anyone is reading this.
c. I2C SCL/SDA are reversed (this one is so GLARINGLY obvious.. that's what I get for
working on this in the wee hours)
d. PROG button - my pull-up is missing (somehow it was deleted from the schematic)

Lucky for me, my design has Oh-so-many conduits, that barnacling the board is relatively easy.

Still haven't got the I2C talking properly yet. I tried using my Junebug to monitor the I2C lines, but I think the pulldown on the Junebug is overpowering the pullups on the I2C. Using a small LogicAnalyzer instead (miniLA), and I can now see the bit in question, while debugging via the ICSP header from the Junebug to the micro.

 

[LabRat]

Follow up - discovered why my PROG pull-up was missing. Bill recommended that I remove it and set the internal pull up via software. (See .. it helps to re-read these
forums).

I will have a got at that, on the second board, and see if I can do without that pull-up barnacle.

 

[LabRat]

2:00 am progress..

Another evening's work recorded here in my "Board Bring Up Diary".

a. 9:00 - i2c - read through the 18f2455 datasheet section on i2c (in detail this time, not relying on sample code). With some tweaks to the sample code, I finally got this working. I'm starting to see data coming back from the TMP101. A little *range* adjusting, and I can now view the temperature through the PICDEM PC application.

b. 10:30 Lcd - back to looking at the LCD.

• I was seeing "flickering" on the display, and if I halted the CPU I could
  see some data. (non-standard characters, all over the display)
• checked the timings, and revisited the online timing calculator
  (everything looked right) Tried some LARGER delays, but not change.
• carefull review of my sample code, and I noted that the original
  LCD command sequence was based on using A1 - A4, and thus
  the commands written to the port were actually shifted left by 1.
  (to send 0x03, a value of 0x06 was written to port A - I fixed this
  but still not dice)
• by single stepping I could see that the command to move the cursor to
  the second line was working. I put the same command byte, in series
  series with my sample string. It should have been sent as "data" and
  not as a "command". If the cursor moved, it had to be a problem with
  the A0/RS line. (it moved)
  - Discovered that my sample code was actually changing the CS, when
  it should have been toggling the RS line. This might explain why no "data"
  was ever sent. (still not working)
• Logic probe on A0 showed that it wasn't toggling at all while the LCD was running.
• 2:00 am as I was trying to step through code I noted that whenever
  I stepped in the code, the RS line would toggle for a moment. I also noted that the RED led on the Junebug would flash at the exact same time.
  Then I had one of those moments... where everything becomes clear
  ... and you realize you solved the last issue about 2 hours earlier ...
  but that you the line you are probing is actually one of the three lines
  for the ICSP...
• Disconnected the Junebug and reset the board... and read my samlpe
  message.

IR receiver next...

 

[Mike - K8LH]

one good thing about these hard earned lessons is that you never forget them and it will only take a few minutes to solve related problems in the future.

remember, have fun.

 

[LabRat]

Alrighty.. Status update (and Lessons learned report)


IR receiver: [Working] - Difficulty Level: HARD (took quite some time)
1. There are CONFIG options that will alter some the PORTB pins from/to being digital inputs. Get these RIGHT or you won't see ANYTHING on the port.
2. Probing the output of the IR Receiver will be enough to influence the signal and thus you won't see anything. Bill posted an IRBridge code sample previously. This is very
usefull as it will poll the bit and echo it to a pin that you CAN probe.
3. Watch those timing parameters, as clocking at 48Mhz is very different that clocking
at the internal oscillator 8Mhz. (really messus up that sample code I had working on the JuneBug)

The Fan: [Untested]
1. Discovered that my bag of fans are all 12v and I designed the board for 5v. Not sure if I really want to go cutting traces in order to run 12v from the floppy drive power connected, through the 2n2222 to the FAN.

That's it so far. Now I need to put all these bits of code together into one library so the kids can link against it.