Here us an updated schematic with Common_V??_FB net names shown. Also, AUX USB DP and DM are now going to P57 and P56, respectively. Still need to get the LED resistor values higher.
VonSzarvas is using Diptrace and he has to do something in order for all the net names to appear in the .pdf. Sounds like a pain. Anyway, he'll get the schematic spruced up tomorrow.
I recommended the LEDs all be given 1k resistors. Does anyone think they will be too bright? Blindingly bright LEDs are no good.
Here us an updated schematic with Common_V??_FB net names shown. Also, AUX USB DP and DM are now going to P57 and P56, respectively. Still need to get the LED resistor values higher.
VonSzarvas is using Diptrace and he has to do something in order for all the net names to appear in the .pdf. Sounds like a pain. Anyway, he'll get the schematic spruced up tomorrow.
I recommended the LEDs all be given 1k resistors. Does anyone think they will be too bright? Blindingly bright LEDs are no good.
I'd at least use 3K3 at an absolute minimum unless you are using crappy LEDs (which I doubt). While the relative current is minimal, it is a saving. I've used 3K (on 5V) since 1992 for modems with light pipes.
0402 is a tad small for many. Can it at least just be a solder blob gap instead?
like just include the resisters and then add a gap between them and the pins that can be connected with a solder blob.
Again, a header spot would be even better then the user could choose which pins to connect them too. The header doesn't have to be populated, it would just be a spot for the user to put a header in.
Again, I would not have aux DP/DM connected directly to P56/57 by default. They should be unconnected.
You are asking for trouble otherwise.
Just have them go to a jumper/header and let the user connect them to the pins.
The user would have to solder on some 27-ohm 0402 resistors.
How many users are going to have 0402 resistors let lone solder them? Just place the resistors but have another 0402 footprint in series with it so that the user can jumper that with a warm solder blob.
Although LED resistors values can be quite high and still be bright enough, the problem is when the activity on the line is transient in which case you need the LEDs brighter. I just use 1k resistors but always make sure that the LEDs aren't too close together that it becomes difficult to distinguish especially with light bleed as to which ones are on or off.
Given the internal pin driving resistance, does it matter that those 2 pins have a (comparable) series resistance added? I can't imagine much wouldn't work, we're talking 45 ohms instead of 18 ohms on all the other pins.
Another point, are these to impedance match 50 ohm cable, or some other reason? If its impedance matching and we're shooting for 50 ohms total, 33 ohms is probably closer (due to P2's stronger than average drive capability)
0402 is a tad small for many. Can it at least just be a solder blob gap instead?
like just include the resisters and then add a gap between them and the pins that can be connected with a solder blob.
Again, a header spot would be even better then the user could choose which pins to connect them too. The header doesn't have to be populated, it would just be a spot for the user to put a header in.
Believe me that there is no pleasant room for a header. Just getting the fan header worked out was an ordeal.
Given the internal pin driving resistance, does it matter that those 2 pins have a (comparable) series resistance added? I can't imagine much wouldn't work, we're talking 45 ohms instead of 18 ohms on all the other pins.
Another point, are these to impedance match 50 ohm cable, or some other reason? If its impedance matching and we're shooting for 50 ohms total, 33 ohms is probably closer (due to P2's stronger than average drive capability)
I was thinking the same thing. Maybe just blob the 0402.
Here is a newer schematic showing R304 = 240 ohms and LED resistors being 1k ohms.
I just checked the Prop123-A9 board and we used 270 ohm resistors for the amber LEDs. This was from 3.3V, though, which is much closer to the Vf of the LED than 5V is. And those LEDs are just about right in brightness.
Didn't see the usual P1 transistor reset circuit. Did I miss it?
A negative transition on the USB chip's DTR output capacitively couples to RESn.
A negative DTR transition (ie DTR becomes active) is the opposite edge that you are using on the P1 and Windows.
I think this is a good test to see if we can remove the transistor requirement, but what if it isn't reliable???
Should the footprint be on-board just in case?
The DDTC113ZUA-7-F has inbuilt 1K/10K bias resistors internally.
Believe me that there is no pleasant room for a header. Just getting the fan header worked out was an ordeal.
Thus, in order to avoid the presence of those 5V_Commom voltages at the 2x6 headers, the solely options left would be applying heat with a soldering iron tip, while pulling them (dangerous: solder pads tubing could be also get partially or even totally pulled, during the procedure) or clipping them with a side cutter?
Didn't see the usual P1 transistor reset circuit. Did I miss it?
A negative transition on the USB chip's DTR output capacitively couples to RESn.
A negative DTR transition (ie DTR becomes active) is the opposite edge that you are using on the P1 and Windows.
I think this is a good test to see if we can remove the transistor requirement, but what if it isn't reliable???
Should the footprint be on-board just in case?
The DDTC113ZUA-7-F has inbuilt 1K/10K bias resistors internally.
Unbeknownst to me, they had been making things like the Propeller FLIP module use the DTR-cap-RESn technique. My Windows app only raises DTR for 10ms before dropping it:
Believe me that there is no pleasant room for a header. Just getting the fan header worked out was an ordeal.
Thus, in order to avoid the presence of those 5V_Commom voltages at the 2x6 headers, the solely options left would be applying heat with a soldering iron tip, while pulling them (dangerous: solder pads tubing could be also get partially or even totally pulled, during the procedure) or clipping them with a side cutter?
If 5V got sent to an I/O pin, it probably would just have the effect of lifting that group of 8 pins that share a VIO. I bet nothing would happen, but 9V or 12V would certainly cause damage.
Hey Peter, all those LEDs go to 5V, not 3V3, (now) with 1K.
I'll need sunglasses Maybe in Queensland you are used to the bright sun
Yow! that'll be bright at 5V. But that's something to check when they make up the first board. You know you can always change the value then.
Chip, if the LEDs are rotated 90' and placed end-to-end then there is no light bleed from the sides of the LEDs thus making it easier to distinguish those that are on or just appear to be on.
BTW, I have used simple RC reset on P1 on many occasions without any problems.
Hey Peter, all those LEDs go to 5V, not 3V3, (now) with 1K.
I'll need sunglasses Maybe in Queensland you are used to the bright sun
Yow! that'll be bright at 5V. But that's something to check when they make up the first board. You know you can always change the value then.
Chip, if the LEDs are rotated 90' and placed end-to-end then there is no light bleed from the sides of the LEDs thus making it easier to distinguish those that are on or just appear to be on.
BTW, I have used simple RC reset on P1 on many occasions without any problems.
Peter, that is good advice about the resistors. I will tell VonSzarvas about this. Maybe we can rotate them.
Didn't see the usual P1 transistor reset circuit. Did I miss it?
A negative transition on the USB chip's DTR output capacitively couples to RESn.
A negative DTR transition (ie DTR becomes active) is the opposite edge that you are using on the P1 and Windows.
I think this is a good test to see if we can remove the transistor requirement, but what if it isn't reliable???
Should the footprint be on-board just in case?
The DDTC113ZUA-7-F has inbuilt 1K/10K bias resistors internally.
Unbeknownst to me, they had been making things like the Propeller FLIP module use the DTR-cap-RESn technique. My Windows app only raises DTR for 10ms before dropping it:
The DTR-cap-RESn method adds maybe a few milliseconds to the startup delay after reset.
Chip,
This is my understanding as to why the reset circuit is required.
When Windoze programs switch, Windows resets DTR briefly (ie DTR# TTL level goes high for a brief time, and then returns to 0V). I don't know if Windoze 10 still does this.
So, programs like PST do not set DTR so that when PST loses focus, DTR was OFF, and remains OFF (ie TTL high) during the program switch.
The transistor reset circuit fires when DTR turns OFF (ie TTL goes high). So the transistor circuit prevents the propeller from resetting between programs switching.
Now, if you only run a single program with the Propeller you will not notice a thing. But we seem to be headed where we will have multiple programs, one for the editor, one for the compiler, one for the downloader, one for the serial terminal, and perhaps more, I wonder if might raise its head?
Cluso99, I think there's almost no winning with this DTR issue. I believe someone said they were able to go into the driver configuration in Windows and inhibit this DTR toggling, but that's maybe the only hope.
Given the internal pin driving resistance, does it matter that those 2 pins have a (comparable) series resistance added? I can't imagine much wouldn't work, we're talking 45 ohms instead of 18 ohms on all the other pins.
Another point, are these to impedance match 50 ohm cable, or some other reason? If its impedance matching and we're shooting for 50 ohms total, 33 ohms is probably closer (due to P2's stronger than average drive capability)
It's common to have those, either internally, or externally.
They reduce the ringing on the cheap cables, and improve the ESD tolerance.
Simplest solution is as suggested above, include two 0402 footprints in series, one is 27/33R and the other is a jumper.
Didn't see the usual P1 transistor reset circuit. Did I miss it?
A negative transition on the USB chip's DTR output capacitively couples to RESn.
A negative DTR transition (ie DTR becomes active) is the opposite edge that you are using on the P1 and Windows.
I think this is a good test to see if we can remove the transistor requirement, but what if it isn't reliable???
Should the footprint be on-board just in case?
The DDTC113ZUA-7-F has inbuilt 1K/10K bias resistors internally.
Unbeknownst to me, they had been making things like the Propeller FLIP module use the DTR-cap-RESn technique. My Windows app only raises DTR for 10ms before dropping it:
The DTR-cap-RESn method adds maybe a few milliseconds to the startup delay after reset.
Hi,
I didn't used the transistor in my P1 design, and yet it worked with absolute success (see the schematic). What I did was to simply use the FT230X chip, with the respective Vcc_IO pin supplied with 3,3V. Thus, you won't damage the Propeller MCU. In fact, on of the strong points of this design is that you can access the serial with any application where the DTR signal is not to meant to be inverted (note that I'm using RTS instead, but it is the same thing).
I've tried it with HyperTerminal on Windows, and with PuTTY on both WQindows and Linux. It also works with SimpleIDE. If I use my Parallax Propeller dev board, or the Prop Plug, I cant access what is being sent to the terminal, unless I use SimpleIDE (because SimpleIDE expects the RTS and DTR signals to be inverted).
I think the same idea can be used with the P2. Of course, the obvious disadvantage I see with this it the capacitor being discharged via the !RES pin of the MCU. I did measure the voltage on that pin, and the spike gets chopped when RTS raises. I rather prefer having the serial com working with any application, instead of implementing the transistor solution.
Comments
VonSzarvas is using Diptrace and he has to do something in order for all the net names to appear in the .pdf. Sounds like a pain. Anyway, he'll get the schematic spruced up tomorrow.
I recommended the LEDs all be given 1k resistors. Does anyone think they will be too bright? Blindingly bright LEDs are no good.
You are asking for trouble otherwise.
Just have them go to a jumper/header and let the user connect them to the pins.
The user would have to solder on some 27-ohm 0402 resistors.
I'd at least use 3K3 at an absolute minimum unless you are using crappy LEDs (which I doubt). While the relative current is minimal, it is a saving. I've used 3K (on 5V) since 1992 for modems with light pipes.
like just include the resisters and then add a gap between them and the pins that can be connected with a solder blob.
Again, a header spot would be even better then the user could choose which pins to connect them too. The header doesn't have to be populated, it would just be a spot for the user to put a header in.
How many users are going to have 0402 resistors let lone solder them? Just place the resistors but have another 0402 footprint in series with it so that the user can jumper that with a warm solder blob.
Although LED resistors values can be quite high and still be bright enough, the problem is when the activity on the line is transient in which case you need the LEDs brighter. I just use 1k resistors but always make sure that the LEDs aren't too close together that it becomes difficult to distinguish especially with light bleed as to which ones are on or off.
Another point, are these to impedance match 50 ohm cable, or some other reason? If its impedance matching and we're shooting for 50 ohms total, 33 ohms is probably closer (due to P2's stronger than average drive capability)
Believe me that there is no pleasant room for a header. Just getting the fan header worked out was an ordeal.
I was thinking the same thing. Maybe just blob the 0402.
I just checked the Prop123-A9 board and we used 270 ohm resistors for the amber LEDs. This was from 3.3V, though, which is much closer to the Vf of the LED than 5V is. And those LEDs are just about right in brightness.
A negative DTR transition (ie DTR becomes active) is the opposite edge that you are using on the P1 and Windows.
I think this is a good test to see if we can remove the transistor requirement, but what if it isn't reliable???
Should the footprint be on-board just in case?
The DDTC113ZUA-7-F has inbuilt 1K/10K bias resistors internally.
I'll need sunglasses
Thus, in order to avoid the presence of those 5V_Commom voltages at the 2x6 headers, the solely options left would be applying heat with a soldering iron tip, while pulling them (dangerous: solder pads tubing could be also get partially or even totally pulled, during the procedure) or clipping them with a side cutter?
Unbeknownst to me, they had been making things like the Propeller FLIP module use the DTR-cap-RESn technique. My Windows app only raises DTR for 10ms before dropping it:
The DTR-cap-RESn method adds maybe a few milliseconds to the startup delay after reset.
If 5V got sent to an I/O pin, it probably would just have the effect of lifting that group of 8 pins that share a VIO. I bet nothing would happen, but 9V or 12V would certainly cause damage.
I wish these were 0805 or 0603...
Sounds like he's going to make them 0603's with a center pad for easy solder blobbing.
Yow! that'll be bright at 5V. But that's something to check when they make up the first board. You know you can always change the value then.
Chip, if the LEDs are rotated 90' and placed end-to-end then there is no light bleed from the sides of the LEDs thus making it easier to distinguish those that are on or just appear to be on.
BTW, I have used simple RC reset on P1 on many occasions without any problems.
Peter, that is good advice about the resistors. I will tell VonSzarvas about this. Maybe we can rotate them.
Chip,
This is my understanding as to why the reset circuit is required.
When Windoze programs switch, Windows resets DTR briefly (ie DTR# TTL level goes high for a brief time, and then returns to 0V). I don't know if Windoze 10 still does this.
So, programs like PST do not set DTR so that when PST loses focus, DTR was OFF, and remains OFF (ie TTL high) during the program switch.
The transistor reset circuit fires when DTR turns OFF (ie TTL goes high). So the transistor circuit prevents the propeller from resetting between programs switching.
Now, if you only run a single program with the Propeller you will not notice a thing. But we seem to be headed where we will have multiple programs, one for the editor, one for the compiler, one for the downloader, one for the serial terminal, and perhaps more, I wonder if might raise its head?
Guess we can try and see what happens.
It's common to have those, either internally, or externally.
They reduce the ringing on the cheap cables, and improve the ESD tolerance.
Simplest solution is as suggested above, include two 0402 footprints in series, one is 27/33R and the other is a jumper.
Hi,
I didn't used the transistor in my P1 design, and yet it worked with absolute success (see the schematic). What I did was to simply use the FT230X chip, with the respective Vcc_IO pin supplied with 3,3V. Thus, you won't damage the Propeller MCU. In fact, on of the strong points of this design is that you can access the serial with any application where the DTR signal is not to meant to be inverted (note that I'm using RTS instead, but it is the same thing).
I've tried it with HyperTerminal on Windows, and with PuTTY on both WQindows and Linux. It also works with SimpleIDE. If I use my Parallax Propeller dev board, or the Prop Plug, I cant access what is being sent to the terminal, unless I use SimpleIDE (because SimpleIDE expects the RTS and DTR signals to be inverted).
I think the same idea can be used with the P2. Of course, the obvious disadvantage I see with this it the capacitor being discharged via the !RES pin of the MCU. I did measure the voltage on that pin, and the spike gets chopped when RTS raises. I rather prefer having the serial com working with any application, instead of implementing the transistor solution.
Kind regards, Samuel Lourenço
Reliability = 1/Complexity
Have the Amkor-packaged chips come in? What's the target date for getting the eval boards?