@rocksetta, making a jig with a known-good Photon and a target Photon makes sense. For UART testing, a simple loopback (TX connected to RX) is all that’s needed on the tested Photon. Otherwise, a simple echo test between the testing and the tested Photon is good as well.
The Photon now supports both SPI and I2C slave modes so the master would be the testing Photon and the slave the tested Photon. Modes can be reversed as long as hookup is done correctly. GPIO is straight forward as is ADC. The testing Photon could put out a voltage on its DAC that is used as inputs to the tested Photon ADCs. PWM output could tested with pulseIn() on the testing photon.
The testing board may need analog/digital multiplexers (CD4067) to configure different pin arrangements. It would be interesting to hear from the Particle folks on their test jig experience. @rickkas7 or @KyleG, can you help with that?
So I have started to design my Photon Testing PCB board. Actually presently working on the code to flash to the Photon in question. I really want to be able to test a photon that has cloud connectivity but perhaps a dead pin.
Question: What is the most likely pin to die? Anyone at Particle know what is the most common dead pin (probably caused by user error). Not sure who works in customer support but they should have an idea of this issue.
Would you expect Digital pins, Analog (non 5V tolerant pins…), PWM or Serial. What would people expect to burn out most without totally destroying the Photon? Possibly this is one of those things that no one person has enough information to answer.
I guess I will just have to test all pins for every ability
So I have PWM and AnalogRead Photon testing working on A5-A1 and A4-A0. Still makes me nervous connecting all these pins together by setting them to INPUT when not using them, but it seems to work.
The basic concept here is to use PWM to turn on an LED to 3 levels, then use- AnalogRead to read the levels from a photoresistor and a bit of fuzzy logic to check if the values are good. I needed to use my own photoresistor (inside a cylinder to block stray light) since the ones that came with the Photon were not sensitive enough.
@rocksetta, you could simply connect an analog (PWM) output to a digital input and use pulseIn() to measure the pulse width for different analog output values. Or use interrupts to measure the ON/OFF times. This is more accurate and simpler than your proposed approach IMO.
I have expanded my DAC test to test all the analog pins. My code for both DAC1 and DAC2 works great to test all of the other analog pins (So I use DAC1 to test A3 and DAC2 to test A6). But strangely I can’t run both tests one after the other, as if once DAC1 is activated it messes up DAC2 somehow.
I know that at analogWrite(DAC1, 0); still generates about 50 mV. So I am using pinMode(pin, INPUT) to reset my pins but I am not really sure if it works on the DAC’s. I also need to have all GPIO pins interconnected (Yes I find that troubling ).
The DOCS for DAC and analogRead get a bit confusing about AN_INPUT and INPUT
So working on breadboards now: Happens to coincide with my students making a few mistakes in class and frying a few Photons. The Photon-alone.ino and breadboard is currently working. I am still testing all the serial breadboards which eventually will be rolled into one (have I2C and uART working, still confused with SPI, the code not the breadboard).
Here is the github again:
Photon-alone testing Breadboard
uART Serial (GND, RX to TX and TX to RX)
I2C Serial (3V3, GND, D0, D1 both with 4.7 K ohm pullup resistors to 3V3 )
For your setups with a second Photon I can’t see how you power the second device? You have GND connected, but you might also want Vin or 3v3 connected.
For I2C you want 4k7 pull-ups not 470Ohm.
while(1) is usually used to trap your code in an eternal loop in case of an error condition.
But in this case it’s meant as a very tight loop to avoid any overhead introducted between loop() - but this will only work with non-AUTOMATIC SYSTEM_MODE()
Presently I just have them both powered by a usb cable, but you are correct If I use a PCB board I should use only one power source. On second thought for one of the serial connections I need the master to start before the slave which will be difficult if they are both powered together. I guess the reset button can achieve the same results.
Found this post
Looks like I will change it to 4.7 K ohm. Thanks @ScruffR
That may explain my problems with SPI. I really don’t want to switch off AUTOMATIC SYSTEM_MODE(). I have several SPI programs to test from Arduino’s and Raspberry Pi’s, sure wish someone had already got the SPI Master and Slave working on a Photon.
@avtolstoy or @mdma either of you want to add your two cents. I am trying to make some very simple: photon to photon SPI slave and master sketches. Not finding much examples so I have started my own.
I just want to send one byte from the slave to the master and one byte from the master to the slave as simply as possible. For the easiest code do you have to use onSelect and onTranserFinished as the DOCS example shows just below this link?
Now I just need some broken Photon’s that actually still have working Wifi. This is actually a bit of a problem since most of my 11 broken Photon’s don’t load Wifi . No mater how many times I tell the students not to hook a non-micro servo up to the Photon, every few weeks some creative student gives it a try.
Can’t blame all my dead Photons on the kids, I have released my fair share of magic smoke.