The power supply circuit that I copied from the Propeller Platform calls for 47uf caps. Will I run into trouble if I use bigger caps? What about 100uf?
Found some 47uf caps and wired the power supply. Both the 5V and 3.3V supplies seem to work and light the power LED. I guess I can try the basic Propeller circuitry to see if that works now.
The basic Propeller circuit seems to work. I was able to run the 16x2 LCD sample program. I'm going to try installing the EEPROM next to see if I can program it. The next time I need to put a reset button on the board.
Sorry for the blow by blow status updates but I just tried the EEPROM circuit and that seems to work. I'll try the circuit that drives the strips of RGB LEDs next.
Nothing like missing a days worth of comments....
@david, how ya gonna find the faults if you don't load it up and test it. I would assume that you checked all the connectons against a net list prior to sending your order, and you were sure by that time your logic was correct, at least enough to be sure you weren't wasting time and money on the spin. Load it up, use sockets for the expensive parts (the ones that cost more than the socket) and test it out. Use the data you collect as proof of the working parts, and analyze what you expected vs. what you actually got to figure out what did not work and why for the next iteration. Maybe you will need to cut and green-wire some things.
I just tried the SPI flash circuit and it seems to work. I can no run PropGCC xmmc programs! The circuit to drive the WS2812 LEDs also seems to be alive although I'm not absolutely sure it completely works yet. I have to find the resistors to complete the rotary encoder circuit so I can attempt to run my entire application. So far so good though.
Here is a picture of my board. I finished populating it and it seems to be sort of working. It can control an LED ring and the rotary encoder, encoder LEDs, and encoder switch are working. The rotary encoder itself seems to be behaving a bit oddly and the LED ring doesn't seem to respond to the controls the way I expect so I think I have more debugging to do.
Looks good for your first board David. Congratulations.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
Looks good for your first board David. Congratulations.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
I was just referring to the Xtal pins, (2 pins). I agree with getting rid of sockets as a whole, except for xtal.
Looks good for your first board David. Congratulations.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
I was just referring to the Xtal pins, (2 pins). I agree with getting rid of sockets as a whole, except for xtal.
I used sockets because I don't have a big stock of the chips and ordering small quantities is expensive. I did have a bunch of sockets though.
I need to write some test code to diagnose what is happening with the rotary encoder. All I did for my initial test was run the code I wrote for my prototype and that is too complicated to use to diagnose hardware issues.
Looks good for your first board David. Congratulations.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
I was just referring to the Xtal pins, (2 pins). I agree with getting rid of sockets as a whole, except for xtal.
Digikey and Mouser have nice xtal socket pins. IIRC they require a 0.040" pcb hole and are wuite expensive. Since the pitch is 0.2", machine pin sockets may work (I haven't tried to fit a xtal in one) by removing the centre pin.
Looks good for your first board David. Congratulations.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
I was just referring to the Xtal pins, (2 pins). I agree with getting rid of sockets as a whole, except for xtal.
Digikey and Mouser have nice xtal socket pins. IIRC they require a 0.040" pcb hole and are wuite expensive. Since the pitch is 0.2", machine pin sockets may work (I haven't tried to fit a xtal in one) by removing the centre pin.
My problem is that I stupidly put in a footprint for an SMT crystal so I had to solder it oddly.
Don't forget that Tachyon is super for testing hardware as it will automatically report I2C devices and I/O states and it has Flash support too. One liners can help diagnose hardware problems. I have some encoder software you can use too etc etc
I just found my first PCB error. The rotary encoder doesn't work because I swapped two pins. That may not be the only problem though as I cut a couple of traces on the board and added wires that should make things work again but they don't. I'm worried I may have damaged the Propeller with the incorrect wiring. Maybe I'll take Peter's advice and try probing the hardware with Tachyon.
Well it’s easy enough to put 3v3 on a pin and check for a 1 then put GND on a pin and look for 0.
Actually, I don't think it's the Propeller pin after all. I switched the signal to another pin and it behaves the same. I'll try playing with Tachyon tomorrow.
I got the encoder working. It turns out that not only did I connect two pins of the encoder backwards, I also have a driver that assumes that the A and B encoder outputs are on adjacent pins with A first followed by B and I reversed that order as well. Once I fixed those problems the encoder started working as well as it did in the prototype which wasn't all that good to begin with. I think I posted a schematic of this in one of my initial messages. I'll look again to make sure though. Here is the code I'm using for reading the encoder.
Comments
I feel the pain, too.
@david, how ya gonna find the faults if you don't load it up and test it. I would assume that you checked all the connectons against a net list prior to sending your order, and you were sure by that time your logic was correct, at least enough to be sure you weren't wasting time and money on the spin. Load it up, use sockets for the expensive parts (the ones that cost more than the socket) and test it out. Use the data you collect as proof of the working parts, and analyze what you expected vs. what you actually got to figure out what did not work and why for the next iteration. Maybe you will need to cut and green-wire some things.
Re sockets. FWIW Machine pins are expensive, so be careful not to use them if the ic is more expensive than the socket
Note the cheap single wipe sockets are not reliable, particularly after a number of insertions. We dumped sockets back in the 80's and noticed a huge reduction in field faults, and these were reasonable quality (expensive) sockets.
I was just referring to the Xtal pins, (2 pins). I agree with getting rid of sockets as a whole, except for xtal.
I need to write some test code to diagnose what is happening with the rotary encoder. All I did for my initial test was run the code I wrote for my prototype and that is too complicated to use to diagnose hardware issues.
Here's a direct link to a recent V5.2 binary (80MHz)