I tried Tubular's approach and finally got a 603 to slide in, but ran into problems when I got to the soldering part. I have a microscope... what I don't have at the moment is a soldering iron that actually gets hot at the very tip.
Instead, I used conductive ink(CircuitWriter from Craig Laboraties)... placed very carefully in the beginning(by placing tiny amounts with a 24 gauge wire) to avoid having capillary flow across the whole resistor and shorting the pin to ground. AND... IT SEEMS to work.
Cog0's green led lights immediately and I have instant recognition by PropTool. Of course I have no way to know if I have simply shorted the pin or if it is actually connected correctly through the resistor... time will tell:) I am optimistic because I proceeded very slowly, one thin layer at a time until the final droplet, which I placed with the pen, itself.
Edit: If I were to do this again, I think I would start by using cyano-acrylate to seal up around the 603 and the gap between the FPGA and the board in the area around the arrow. This would leave me with no doubt that the final connection was not a short. I would use the glue before removing the solder resist layer so that if too much got onto the board, it could be scraped off without touching the copper.
Interesting idea with the Conductive ink! It makes me wonder if you could use the ink by itself. Draw a hair-thin ink trace from the PLL to an adjacent ground...
Interesting idea with the Conductive ink! It makes me wonder if you could use the ink by itself. Draw a hair-thin ink trace from the PLL to an adjacent ground...
Interesting idea with the Conductive ink! It makes me wonder if you could use the ink by itself. Draw a hair-thin ink trace from the PLL to an adjacent ground...
? The spec calls for 2k 1% I think ?
Ohh, that's right. I was thinking it was 200 ohms. Well, regardless, it might still be easier to run an ink trace out to a larger SMD instead of jamming a smaller one under. Based on Chip's original test, it seems the resistance value tolerance is a bit wider than 1%.
I think Chip said he was happy with 1.5k... my 603 is 5% but if 25% less is ok... the resistor tolerance shouldn't matter... right?
One way or another you have to jam something in there blind. None of the leads on my wired resistors would actually fit. And you have to do something that won't move... so you have a ball that you can't see and it has to be in good contact with something to bring the connection out.
I think the 603 solution is perfect.
I had to swing the 603 from side to side to get it to go in. Other than that, easy peasy.
What you could do... that I didn't... is scratch the solder resist off somewhere else... quarters are a little tight near that corner... and then use conductive ink to get to that scratched off area.
So, it looks like my RGB LEDs are partially failed as well. I was thinking of letting the MTR guys at work take a crack at applying the PLL fix, but I'm wondering how I will verify the fix.
Also, for the LEDs, has anyone been able to verify if they are actually damaged, or just need to be resoldered?
Tubular noticed on his board that the faulty led was "milky" in appearance.
All the leds on my board were faulty.
Tubular replaced them all and they all work fine now.
I didn't check the removed leds as the board was now working.
In hindsight probably should have....
Tubular noticed on his board that the faulty led was "milky" in appearance.
All the leds on my board were faulty.
Tubular replaced them all and they all work fine now.
I didn't check the removed leds as the board was now working.
In hindsight probably should have....
It sounds like they don't survive reflow very well. Do you think anybody would miss them if we got rid of them?
You can probably get rid of them (for the A9 version, I'm assuming). If it weren't for the discussion about testing the PLL fix with them, I wouldn't be paying them any attention at all.
(I don't suppose someone threw together a little bit of verilog that will use the PLL to blink one of the other LEDs at a fixed rate, or something like that?)
Keep 'em. Why? This chip is going to be impressive for its analog functionality, and anything that can do 'shades' and not just 0's and 1's will be invaluable. This is an argument also for being able to add a pot, ldr, temp sensor, or at least pads for them
If anyone wants spare ws2812b's I'm happy to post them
It sounds like they don't survive reflow very well. Do you think anybody would miss them if we got rid of them?
They certainly are not mission critical, but LEDs are very useful indicators and the Prop is going to be doing Colour a lot.
Didn't someone (Ken?) say they have improved the handling of the diodes ?
Maybe the led die are soldered down with std solder, and are lifting during reflow, which would remove LED die cooling and then they could 'go smokey' ?
An alternative is to ditch the RGB LEDS and move to a footprint for a more useful and P2 focused OLED module, that still gives Colour display...
Coupling a decent display with touch, gives a stable reference platform and if you look forward a little, to the Prop2 silicon version of 'STM32F746G-DISCO' then it makes sense to standardize on a good display now.
4.3-inch 480x272 color LCD-TFT with capacitive touch screen is a good size, and that eval board with screen included for sub $50 is good value.
Actually, the assortment of interesting I/O is one of the things I liked about the 1-2-3 board. Maybe just abandon the entire board and use an off-the-shelf FPGA board that will be more affordable for P2 testers?
I think I've heard that Parallax uses lead-free reflow.
This very eco-friendly but very difficult.
I tried very hard with my setup here but couldn't make it work.
Couldn't get all solder to melt without melting plastic...
I know Parallax has much better tools, but still, I'm sure it's not easy to find the right temperature profile...
I have no problem with my reflow oven using lead free solder.
But I do know from past experiences many moons ago that some LEDs have heat issues.
Perhaps the cycle is too long at high temps although I would expect the BGAs require longer that QFPs etc.
Actually, the assortment of interesting I/O is one of the things I liked about the 1-2-3 board. Maybe just abandon the entire board and use an off-the-shelf FPGA board that will be more affordable for P2 testers?
Certainly the BeMicro CVA9 has made that possible, but that lacks DACS and ADCs etc .
Question comes down to the expansion connectors on the CVA9, "two 40-pin I/O headers and 80-pin MEC-style edge connector"
and does enough connect thru that, to allow a daughter card, which could be a design fork of the 123-A9 ? (add connector(s) and do not fit A9+PSU's)
addit: I remember Chip said the Prop1 based loader on 1-2-3 loads much? faster than Altera's CPLD, which means someone rather goofed at Altera in the CPLD/SW chain. ( IIRC both use the FT245 USB-FIFO)
I remember Chip said the Prop1 based loader on 1-2-3 loads much? faster than Altera's CPLD, which means someone rather goofed at Altera in the CPLD/SW chain. ( IIRC both use the FT245 USB-FIFO)
Yeah that's really embarrassing for Altera since the Prop1 will be bit-bashing the whole process on both ends.
I remember Chip said the Prop1 based loader on 1-2-3 loads much? faster than Altera's CPLD, which means someone rather goofed at Altera in the CPLD/SW chain. ( IIRC both use the FT245 USB-FIFO)
Yeah that's really embarrassing for Altera since the Prop1 will be bit-bashing the whole process on both ends.
Now that we are loading larger images (~5MB) into the FPGA, the speed difference is not as great as I originally thought.
Using Quartus' built-in programmer to program the DE2-115 takes 211 seconds. Power must be cycled to load the new image from the flash into the FPGA. That takes maybe 1 second.
Using our Prop123 board and sending a similarly-sized flash image takes about 55 seconds, then another 13 seconds to load from the flash into the FPGA.
To load the same-sized image directly into the FPGA, bypassing the flash, takes only 25 seconds.
Powering up and loading the FPGA from the flash takes about 12 seconds.
So, we are faster to download, but slower to configure from the flash image. Our load-from-flash time could be cut to 4 seconds if we used QUAD SPI mode in the 8-pin flash chip. When I wrote the code the Prop123, it was enough challenge to get it working using the less-complicated single-bit SPI protocol.
Our download speed is limited by the 2M-baud FTDI chip. It goes to 3M-baud, but is extremely flakey at that speed, so we are limited to 2M-baud, or 200KB/sec. 5MB / 200KB = 25 seconds, which is exactly how long we take for a transfer straight into the FPGA.
Powering up and loading the FPGA from the flash takes about 12 seconds.
Wow! I didn't realize that boot up would be so slow. Maybe this suggests that an add-on board for an off-the-shelf FPGA board like the BeMicro A9 board would be a better solution?
I just got my Propeller 1-2-3 A7 FPGA board and I don't see any evidence that the A1 resistor has been added. How can I verify that this fix was done?
Edit: Support at Parallax just verified that they did not apply the A1 resistor fix before shipping my board. I'll be sending mine back for the resistor to be installed.
Now that we are loading larger images (~5MB) into the FPGA, the speed difference is not as great as I originally thought.
Using Quartus' built-in programmer to program the DE2-115 takes 211 seconds. Power must be cycled to load the new image from the flash into the FPGA. That takes maybe 1 second.
Using our Prop123 board and sending a similarly-sized flash image takes about 55 seconds, then another 13 seconds to load from the flash into the FPGA.
To load the same-sized image directly into the FPGA, bypassing the flash, takes only 25 seconds.
Powering up and loading the FPGA from the flash takes about 12 seconds.
So, we are faster to download, but slower to configure from the flash image. Our load-from-flash time could be cut to 4 seconds if we used QUAD SPI mode in the 8-pin flash chip. When I wrote the code the Prop123, it was enough challenge to get it working using the less-complicated single-bit SPI protocol.
Our download speed is limited by the 2M-baud FTDI chip. It goes to 3M-baud, but is extremely flakey at that speed, so we are limited to 2M-baud, or 200KB/sec. 5MB / 200KB = 25 seconds, which is exactly how long we take for a transfer straight into the FPGA.
Splitting this info, I think you are saying: (for DE2-115 ? any numbers for A9 ? )
Flash -> FPGA Image load :
DE2-115: 1s
Prop123:12s
Code -> FLASH P2 verilog download
DE2-115: 211s
Prop123:55s to Flash or 25s to FPGA
P2 image load will be relatively rare, so speed there is less important than re-boot times.
The QuadSPI change (12s -> 4s?) is a simple P1 firmware update, right ?
IIRC this uses FT245 ? - Sounds like the flash Erase/PGM times are the limits, since it already takes 55s vs 25s ? (Altera maybe have to use smaller buffer pages via their CPLD ?)
Some numbers on a CV A9 would be nice, to compare apples with apples ?
I just got my Propeller 1-2-3 A7 FPGA board and I don't see any evidence that the A1 resistor has been added. How can I verify that this fix was done?
Edit: Support at Parallax just verified that they did not apply the A1 resistor fix before shipping my board. I'll be sending mine back for the resistor to be installed.
My fault, Dave. I had been meaning to tell them, but I never did. We'll pay for all the shipping. Sorry about this.
The -A9 board is going to be done in a few weeks, anyway. If playing with Prop2 is your intent, you could stay busy on that board at 50Mhz, and then swap it out for the -A9 when it's available. Whatever you want to do.
I just got my Propeller 1-2-3 A7 FPGA board and I don't see any evidence that the A1 resistor has been added. How can I verify that this fix was done?
Edit: Support at Parallax just verified that they did not apply the A1 resistor fix before shipping my board. I'll be sending mine back for the resistor to be installed.
My fault, Dave. I had been meaning to tell them, but I never did. We'll pay for all the shipping. Sorry about this.
The -A9 board is going to be done in a few weeks, anyway. If playing with Prop2 is your intent, you could stay busy on that board at 50Mhz, and then swap it out for the -A9 when it's available. Whatever you want to do.
Thanks Chip. I guess if I'm going to swap my board for an A9 anyway and the A9 will be available in a few weeks, there's probably no point in sending my A7 board back. I'll just use your images that make use of the 50mhz clock until I can get the A9 board. Thanks for suggesting that option.
I just got my Propeller 1-2-3 A7 FPGA board and I don't see any evidence that the A1 resistor has been added. How can I verify that this fix was done?
Edit: Support at Parallax just verified that they did not apply the A1 resistor fix before shipping my board. I'll be sending mine back for the resistor to be installed.
My fault, Dave. I had been meaning to tell them, but I never did. We'll pay for all the shipping. Sorry about this.
The -A9 board is going to be done in a few weeks, anyway. If playing with Prop2 is your intent, you could stay busy on that board at 50Mhz, and then swap it out for the -A9 when it's available. Whatever you want to do.
Thanks Chip. I guess if I'm going to swap my board for an A9 anyway and the A9 will be available in a few weeks, there's probably no point in sending my A7 board back. I'll just use your images that make use of the 50mhz clock until I can get the A9 board. Thanks for suggesting that option.
Comments
Instead, I used conductive ink(CircuitWriter from Craig Laboraties)... placed very carefully in the beginning(by placing tiny amounts with a 24 gauge wire) to avoid having capillary flow across the whole resistor and shorting the pin to ground. AND... IT SEEMS to work.
Cog0's green led lights immediately and I have instant recognition by PropTool. Of course I have no way to know if I have simply shorted the pin or if it is actually connected correctly through the resistor... time will tell:) I am optimistic because I proceeded very slowly, one thin layer at a time until the final droplet, which I placed with the pen, itself.
Edit: If I were to do this again, I think I would start by using cyano-acrylate to seal up around the 603 and the gap between the FPGA and the board in the area around the arrow. This would leave me with no doubt that the final connection was not a short. I would use the glue before removing the solder resist layer so that if too much got onto the board, it could be scraped off without touching the copper.
Didn't think of conductive ink, but good idea.
Are your ws2812 leds working ok?
? The spec calls for 2k 1% I think ?
Ohh, that's right. I was thinking it was 200 ohms. Well, regardless, it might still be easier to run an ink trace out to a larger SMD instead of jamming a smaller one under. Based on Chip's original test, it seems the resistance value tolerance is a bit wider than 1%.
One way or another you have to jam something in there blind. None of the leads on my wired resistors would actually fit. And you have to do something that won't move... so you have a ball that you can't see and it has to be in good contact with something to bring the connection out.
I think the 603 solution is perfect.
I had to swing the 603 from side to side to get it to go in. Other than that, easy peasy.
What you could do... that I didn't... is scratch the solder resist off somewhere else... quarters are a little tight near that corner... and then use conductive ink to get to that scratched off area.
Also, for the LEDs, has anyone been able to verify if they are actually damaged, or just need to be resoldered?
All the leds on my board were faulty.
Tubular replaced them all and they all work fine now.
I didn't check the removed leds as the board was now working.
In hindsight probably should have....
It sounds like they don't survive reflow very well. Do you think anybody would miss them if we got rid of them?
(I don't suppose someone threw together a little bit of verilog that will use the PLL to blink one of the other LEDs at a fixed rate, or something like that?)
Led indicators are always useful.
If anyone wants spare ws2812b's I'm happy to post them
They certainly are not mission critical, but LEDs are very useful indicators and the Prop is going to be doing Colour a lot.
Didn't someone (Ken?) say they have improved the handling of the diodes ?
Maybe the led die are soldered down with std solder, and are lifting during reflow, which would remove LED die cooling and then they could 'go smokey' ?
An alternative is to ditch the RGB LEDS and move to a footprint for a more useful and P2 focused OLED module, that still gives Colour display...
Some examples are here
http://www.newhavendisplay.com/oled-color-oleds-c-119_626.html
eg 160x128 pixels, 262K allow some quite impressive demos. $25 is tolerable.
Good demos are going to matter for design-win ramping.
I also like the direction ST took here,
http://www.digikey.com/product-detail/en/STM32F746G-DISCO/497-15680-5-ND
- there is a shipload of Eval boards out there now, lots of them me-too ones.
Coupling a decent display with touch, gives a stable reference platform and if you look forward a little, to the Prop2 silicon version of 'STM32F746G-DISCO' then it makes sense to standardize on a good display now.
4.3-inch 480x272 color LCD-TFT with capacitive touch screen is a good size, and that eval board with screen included for sub $50 is good value.
This very eco-friendly but very difficult.
I tried very hard with my setup here but couldn't make it work.
Couldn't get all solder to melt without melting plastic...
I know Parallax has much better tools, but still, I'm sure it's not easy to find the right temperature profile...
But I do know from past experiences many moons ago that some LEDs have heat issues.
Perhaps the cycle is too long at high temps although I would expect the BGAs require longer that QFPs etc.
Certainly the BeMicro CVA9 has made that possible, but that lacks DACS and ADCs etc .
Question comes down to the expansion connectors on the CVA9,
"two 40-pin I/O headers and 80-pin MEC-style edge connector"
and does enough connect thru that, to allow a daughter card, which could be a design fork of the 123-A9 ? (add connector(s) and do not fit A9+PSU's)
addit: I remember Chip said the Prop1 based loader on 1-2-3 loads much? faster than Altera's CPLD, which means someone rather goofed at Altera in the CPLD/SW chain. ( IIRC both use the FT245 USB-FIFO)
Yeah that's really embarrassing for Altera since the Prop1 will be bit-bashing the whole process on both ends.
Now that we are loading larger images (~5MB) into the FPGA, the speed difference is not as great as I originally thought.
Using Quartus' built-in programmer to program the DE2-115 takes 211 seconds. Power must be cycled to load the new image from the flash into the FPGA. That takes maybe 1 second.
Using our Prop123 board and sending a similarly-sized flash image takes about 55 seconds, then another 13 seconds to load from the flash into the FPGA.
To load the same-sized image directly into the FPGA, bypassing the flash, takes only 25 seconds.
Powering up and loading the FPGA from the flash takes about 12 seconds.
So, we are faster to download, but slower to configure from the flash image. Our load-from-flash time could be cut to 4 seconds if we used QUAD SPI mode in the 8-pin flash chip. When I wrote the code the Prop123, it was enough challenge to get it working using the less-complicated single-bit SPI protocol.
Our download speed is limited by the 2M-baud FTDI chip. It goes to 3M-baud, but is extremely flakey at that speed, so we are limited to 2M-baud, or 200KB/sec. 5MB / 200KB = 25 seconds, which is exactly how long we take for a transfer straight into the FPGA.
Edit: Support at Parallax just verified that they did not apply the A1 resistor fix before shipping my board. I'll be sending mine back for the resistor to be installed.
Splitting this info, I think you are saying: (for DE2-115 ? any numbers for A9 ? )
Flash -> FPGA Image load :
DE2-115: 1s
Prop123:12s
Code -> FLASH P2 verilog download
DE2-115: 211s
Prop123:55s to Flash or 25s to FPGA
P2 image load will be relatively rare, so speed there is less important than re-boot times.
The QuadSPI change (12s -> 4s?) is a simple P1 firmware update, right ?
IIRC this uses FT245 ? - Sounds like the flash Erase/PGM times are the limits, since it already takes 55s vs 25s ? (Altera maybe have to use smaller buffer pages via their CPLD ?)
Some numbers on a CV A9 would be nice, to compare apples with apples ?
My fault, Dave. I had been meaning to tell them, but I never did. We'll pay for all the shipping. Sorry about this.
The -A9 board is going to be done in a few weeks, anyway. If playing with Prop2 is your intent, you could stay busy on that board at 50Mhz, and then swap it out for the -A9 when it's available. Whatever you want to do.
We got solutions. We got problems.