@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
I am testing all the GPIO pins, by setting the next higher pin to an output and then reading for both HIGH and LOW on the present pin.
Bit strange connecting every single GPIO pin together, but it seems to work. Even spotted the error in my logic with D7. The original code connected it to D8!
I really like the new revision share particle system for when I have a problem and need help, but this program is changing very quickly I think the only way to working with it is from a github site.
Sharing a revision is probably a great way to store a working backup that people can look at.
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.
My way made a lot of sense until I saw how finicky the results were. Your way makes much more sense now. Thanks
Interesting: pulseIn() returns a number that is almost always 7.84 times the PWM value. Making it very easy to work with. Note: Both PWM 0 and PWM 255 return zero from PulseIn()
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
I have changed my plans slightly. I will use a differernt PCB / breadboard setup to test the serial connections. Presently have uART working just need to get I2C and SPI going.
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?
Since there is no Master example code I sort of found / changed this sketch
void setup ()
{
Particle.publish(“started”, “master”, 60, PRIVATE);
delay(2000);
SPI.begin(SPI_MODE_MASTER, SS);
digitalWrite(SS, HIGH); // ensure SS stays high for now
// Slow down the master a bit
SPI.setClockDivider(SPI_CLOCK_DIV8);
Particle.publish("started", "master", 60, PRIVATE);
delay(2000);
SPI.begin(SPI_MODE_MASTER, SS);
digitalWrite(SS, HIGH); // ensure SS stays high for now
}
void loop ()
{
char c;
digitalWrite(SS, LOW); // enable Slave Select
SPI.beginTransaction(settings);
c = 'A';
Looks like my serial testing board is working. Now I just have to learn Eagle software and make a PCB for both Photon PIN testing and Photon Serial testing. How hard can that be!
Here is an image of the PIN testing breadboard one of my students made:
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.