As there are no more castellated pins on the left side of the board, maybe you could change the double pin io ports to single ones to gain a bit more room on the board? Might give space for a full sized prop plug header or a led or dip switch?
Going to single pins would break compatibility with Pi Pico accessories. If the design works out I plan to squish it back down.
Do you really want a prop plug connector or would on board USB to serial work? I was able to fit an FT231 on board. I'll see how it works when I build it. I really like a board with a single USB connector for power and data.
The board has one LED, connected to P30. It will have a reset button like the teensy series.
Do you care about the color? I will probably order these in purple. But I could also get red cheaply. Green is of course an option, but this would have to be imported for the price I'm willing to pay.
Are you going to do anything critical with the ADCs? There are no LDOs here like the edge has. I don't consider this a big deal as the Pico doesn't have any LDOs either.
Saucy, if you don't have the means to bring out all of the pins, then overlay groups of 8 together (ie P0&P8, P1&P9, P2&P10, ...). This will allow you to add really nice monitoring capabilites, like logic analyzer and SCOPE ADC w/triggering. I wish I had made the silicon more like this, because it would have been nice to standardize diagnostics.
I was able to fit an FT231 on board. I'll see how it works when I build it. I really like a board with a single USB connector for power and data.
Good!!!
The board has one LED, connected to P30. It will have a reset button like the teensy series.
Yeah!
Are you going to do anything critical with the ADCs? There are no LDOs here like the edge has. I don't consider this a big deal as the Pico doesn't have any LDOs either.
I think, Pico has LC filter for the Ref voltage? Perhaps that would be good for one group of pins too?
Board is in production. Time to order the parts. #4 is the only one that affects my ordering. The big decision is #5.
I have orange LEDs, but there is still time to order another color.
PSRAM
4A. No PSRAM
4B. *16MB PSRAM, 8 bit bus
4C. EXPERIMENTAL 32MB PSRAM, 8 bit bus
4D. 8MB PSRAM, 4 bit bus
Headers
5A. breadboard mode P2 up
5B. breadboard mode P2 up, EVAL header
5C. breadboard mode P2 down, all pins labed on silkscreen
5D. no headers installed
Header Type
6A. Square header
6B. *Round header "machine pin"
P24-P31
7A. *microSD interface, data lines connected to headers
7B. microSD interface, data lines excluded from headers
7C. GPIO, P31 as power switch, 4.7uF-9.4uF capacitance
7D. GPIO, P31 as high current PWM, freewheel diode, no capacitance
7E. GPIO, P31 as GPIO
7F. GPIO low capacitance, P31 routed to pin marked P34
Already found a design flaw. Background: I have an old prop plug that seems to draw just enough power from the serial pins to trigger a reset pulse. The new prop plug has logic chips to block this current flow. Space is tight here so I want to do it with as few parts as possible. I thought I had a clever idea: just power the FT231 from VSYS instead of VBUS. If it has a good power source it shouldn't generate reset pulses. Unfortunately this limits VSYS to 5.5v. The regulators I chose are good for 17v.
But the FT231 has a option to run on 3.3v. I could cut the trace supplying 5v power and put a jumper wire in to supply 3.3v. edit: This also solves the lack of a nearby bypass capacitor for the 5v.
Another option would be to keep the 5.5v limitation and use the FT231 3.3v LDO to feed a bank of pins for cleaner analog. This would require changes to the board and would not be possible to do with jumper wires. But long term, I want to eliminate the FT231.
@SaucySoliton said:
Parts ordered. Boards should arrive soon.
Exciting!
But the FT231 has a option to run on 3.3v. I could cut the trace supplying 5v power and put a jumper wire in to supply 3.3v. edit: This also solves the lack of a nearby bypass capacitor for the 5v.
I have built 1 board. The on-board programmer works. It's immune the PLL noise issue when toggling p28-31. SD card works super fast, 27MB/sec. PSRAM works at clk/3, not terrible, not great.
@Wuerfel_21 said:
@evanh said:
I think the downloaders have been optimised early on for Eval boards, which uses the FT323 direct drive (non-inverted) wiring. And later boards using the Propplug became second citizens. Edge Cards have probably had oddball download issues all along.
I have a number of boards that (under Linux with loadp2) reset when the port is closed. IIRC there's a Linux kernel issue where the flow control signals change when the port is closed that doesn't exist on WinNT (this has been discussed before!). I'd have to dig them all out again to test, but IIRC the EVAL is one of the few that works correctly.
Thank You for this info! For this board I copied the rev E prop plug circuit. I use loadp2 on Linux. Programs do not run unless I enable terminal mode. The board resets immediately when I close the terminal.
It's a trade-off. With the prop-plug design the reset happens when closing the terminal. With the eval design the reset happens when opening the terminal. I think it could be useful to be able to open the terminal and Maybe the optimal solution is a filter that resets the chip only if there are 2 edges in a short time.
No, the optimal solution is a native USB connection.
@SaucySoliton said:
Thank You for this info! For this board I copied the rev E prop plug circuit. I use loadp2 on Linux. Programs do not run unless I enable terminal mode. The board resets immediately when I close the terminal.
@SaucySoliton said:
Thank You for this info! For this board I copied the rev E prop plug circuit. I use loadp2 on Linux. Programs do not run unless I enable terminal mode. The board resets immediately when I close the terminal.
Interesting, can you test with Spin Tools IDE ?
Ah, nevermind, I found that I have a udev rule that prevents the reset on port close:
-hupcl disable the "hangup" signal when the last program closes the tty, without that rule the Propeller resets on port close also with the previous prop-plugs.
@SaucySoliton said:
I have built 1 board. The on-board programmer works. It's immune the PLL noise issue when toggling p28-31. SD card works super fast, 27MB/sec. PSRAM works at clk/3, not terrible, not great.
A good start anyway. Did you try the higher speeds for PSRAM? I've always been able to get clk/2 transfers in my 16 bit variants up over 300MHz (so PSRAM clock is at 150MHz) even with very average routing (and via P2-EVAL and pin headers etc). Your RAM looks very close to the P2 unless the RAM pins are also routed elsewhere and create stubs etc. Hopefully you have sufficient bypassing for sudden power transients due to high speed bus switching.
No, the optimal solution is a native USB connection.
Wouldn't that have been a nice option - instead of the Forth ROM. Also I really like the simplicity of file drag/drop on the Pico boards. But I understand why we have what we have and I remember the last minute rush to get that boot code all done for the silicon deadline. It'd be rather difficult to test and get a USB serial / mass storage client up and running before the chip is even made using Smartpins and driver code. Did the FPGA test variant even have all the USB Smartpin functionality inside it or did some of come in later? One day I guess a future ROM spin could potentially do this if something stable got developed or we could still use a boot flash image to start the USB client listening though that does create a chicken/egg problem initially where serial boot is needed to install the boot flash image.
@macca said:
-hupcl disable the "hangup" signal when the last program closes the tty, without that rule the Propeller resets on port close also with the previous prop-plugs.
Nice!!!
@SaucySoliton said:
I have built 1 board. The on-board programmer works. It's immune the PLL noise issue when toggling p28-31. SD card works super fast, 27MB/sec. PSRAM works at clk/3, not terrible, not great.
Comments
As there are no more castellated pins on the left side of the board, maybe you could change the double pin io ports to single ones to gain a bit more room on the board? Might give space for a full sized prop plug header or a led or dip switch?
Going to single pins would break compatibility with Pi Pico accessories. If the design works out I plan to squish it back down.
Do you really want a prop plug connector or would on board USB to serial work? I was able to fit an FT231 on board. I'll see how it works when I build it. I really like a board with a single USB connector for power and data.
The board has one LED, connected to P30. It will have a reset button like the teensy series.
Do you care about the color? I will probably order these in purple. But I could also get red cheaply. Green is of course an option, but this would have to be imported for the price I'm willing to pay.
Are you going to do anything critical with the ADCs? There are no LDOs here like the edge has. I don't consider this a big deal as the Pico doesn't have any LDOs either.
Saucy, if you don't have the means to bring out all of the pins, then overlay groups of 8 together (ie P0&P8, P1&P9, P2&P10, ...). This will allow you to add really nice monitoring capabilites, like logic analyzer and SCOPE ADC w/triggering. I wish I had made the silicon more like this, because it would have been nice to standardize diagnostics.
I was able to fit an FT231 on board. I'll see how it works when I build it. I really like a board with a single USB connector for power and data.
Good!!!
Yeah!
I think, Pico has LC filter for the Ref voltage? Perhaps that would be good for one group of pins too?
USB will work nicely. LED and reset button are super. Any colour is fine with me. No adc plans.
The whole thing is starting to sound awesome!
Board is in production. Time to order the parts. #4 is the only one that affects my ordering. The big decision is #5.
I have orange LEDs, but there is still time to order another color.
PSRAM
4A. No PSRAM
4B. *16MB PSRAM, 8 bit bus
4C. EXPERIMENTAL 32MB PSRAM, 8 bit bus
4D. 8MB PSRAM, 4 bit bus
Headers
5A. breadboard mode P2 up
5B. breadboard mode P2 up, EVAL header
5C. breadboard mode P2 down, all pins labed on silkscreen
5D. no headers installed
Header Type
6A. Square header
6B. *Round header "machine pin"
P24-P31
7A. *microSD interface, data lines connected to headers
7B. microSD interface, data lines excluded from headers
7C. GPIO, P31 as power switch, 4.7uF-9.4uF capacitance
7D. GPIO, P31 as high current PWM, freewheel diode, no capacitance
7E. GPIO, P31 as GPIO
7F. GPIO low capacitance, P31 routed to pin marked P34
Recommended*
My favourite combination:
4B 5A 6B 7A (edit: changed to 5C->5A)
And a purple board with orange LED, dazzling 👍
Parts ordered. Boards should arrive soon.
Already found a design flaw. Background: I have an old prop plug that seems to draw just enough power from the serial pins to trigger a reset pulse. The new prop plug has logic chips to block this current flow. Space is tight here so I want to do it with as few parts as possible. I thought I had a clever idea: just power the FT231 from VSYS instead of VBUS. If it has a good power source it shouldn't generate reset pulses. Unfortunately this limits VSYS to 5.5v. The regulators I chose are good for 17v.
But the FT231 has a option to run on 3.3v. I could cut the trace supplying 5v power and put a jumper wire in to supply 3.3v. edit: This also solves the lack of a nearby bypass capacitor for the 5v.
Another option would be to keep the 5.5v limitation and use the FT231 3.3v LDO to feed a bank of pins for cleaner analog. This would require changes to the board and would not be possible to do with jumper wires. But long term, I want to eliminate the FT231.
Exciting!
That sounds better, IMHO
Maybe a CH340E or CH9102F etc. to lower the cost?
I have built 1 board. The on-board programmer works. It's immune the PLL noise issue when toggling p28-31. SD card works super fast, 27MB/sec. PSRAM works at clk/3, not terrible, not great.
Thank You for this info! For this board I copied the rev E prop plug circuit. I use loadp2 on Linux. Programs do not run unless I enable terminal mode. The board resets immediately when I close the terminal.
It's a trade-off. With the prop-plug design the reset happens when closing the terminal. With the eval design the reset happens when opening the terminal. I think it could be useful to be able to open the terminal and Maybe the optimal solution is a filter that resets the chip only if there are 2 edges in a short time.
No, the optimal solution is a native USB connection.
Interesting, can you test with Spin Tools IDE ?
Ah, nevermind, I found that I have a udev rule that prevents the reset on port close:
-hupcl disable the "hangup" signal when the last program closes the tty, without that rule the Propeller resets on port close also with the previous prop-plugs.
A good start anyway. Did you try the higher speeds for PSRAM? I've always been able to get clk/2 transfers in my 16 bit variants up over 300MHz (so PSRAM clock is at 150MHz) even with very average routing (and via P2-EVAL and pin headers etc). Your RAM looks very close to the P2 unless the RAM pins are also routed elsewhere and create stubs etc. Hopefully you have sufficient bypassing for sudden power transients due to high speed bus switching.
Wouldn't that have been a nice option - instead of the Forth ROM.
Also I really like the simplicity of file drag/drop on the Pico boards. But I understand why we have what we have and I remember the last minute rush to get that boot code all done for the silicon deadline. It'd be rather difficult to test and get a USB serial / mass storage client up and running before the chip is even made using Smartpins and driver code. Did the FPGA test variant even have all the USB Smartpin functionality inside it or did some of come in later? One day I guess a future ROM spin could potentially do this if something stable got developed or we could still use a boot flash image to start the USB client listening though that does create a chicken/egg problem initially where serial boot is needed to install the boot flash image.
Nice!!!
OMG OMG OMG build another one