Maximum current draw per I/O pins

ul5255

Dear all,

I found a place which mentions that I can draw only 100mA per 8 pins:

http://tymkrs.tumblr.com/post/12472034125/propeller-chip-specifications-part-iii

I can't find this in the Propeller data sheet. If this is true then does this
mean that is applies to an arbitrary group of 8 pins or is it max. 100mA
per pins 0 .. 7 then another 100mA for pins 8 .. 15 a.s.f. ?

I do know that I can have at most 40mA per pin and 300mA per whole chip
of which cogs and PLLs will consume some. I want to figure out how much
is left to drive pins. My rough estimation is for 3.3 Vcc, 80MHz (5MHz crystal):

• each cog in assembler endless loop ~ 5mA
• each PLL ~ 1.2mA
• crystal drive current is neglectible

So if I use 5 cogs and 8+1 PLLs (one PLL for system clock generation) then
I will consume at least 5x5mA + 9x1.2mA ~ 36mA and have max. 264mA left
to drive pins, right?

Cheers,
ul5255.

Mark_T

The Prop datasheet gives absolute maximum ratings as +/- 40mA per I/O pin and 300mA for each of the supply rails. Not sure where the 100mA/group of 8 pins figure comes from.

Your analysis seems sound, calculate the max internal current draw, subtract from 300mA and you have the current left over for pins.

Remember that pins driven HIGH are taking current only from Vdd supply and pins driven LOW take current from Vss - you can have abs max of 600mA I/O current if split equally between HIGH and LOW pins (and not pulling significant internal current load).

Peter Jakacki

It looks like 9ma/cog for assembler loop but what I want to know is why is this important that you get maximum current? We have plenty of threads where the OP asks a very narrow question and then it turns out that it's the wrong question even though they get a lot of right answers for the wrong question. So, what are you trying to do? Broaden the scope of your question by giving us some background detail of your objectives.

ul5255

Hi Peter,

I am using the Prop as an 80m ham radio transmitter. My goal is to run it without an external power amplifier.

To this end I already measured into which load a counter generating differential-PLL RF signal delivers maximum
power. This is 82Ohms and ~24mA. Yesterday I figured out how to phase-align two PLLs in one cog (to minimize
the phase noise) so I can double the RF power output. Eventually I want to arrive at as many I/O pins driving the
same phase-aligned RF signal as possible. I hope that tonight I can figure out how to sync 4 cogs.

I already designed/simulated an output low pass filter with good harmonics attenuation. Input is a broadband
trifilar wound transformer which takes the 82Ohms on Prop side down to ~20Ohms. After the LP filter it delivers
42mW into a 20Ohm load. If I can use 8 PLLs in parallel then the prop can deliver max. 336mW power into
a ~10Ohm load. This will save me the broadband input transformer to my LP filter (which must be recalculated
to 10Ohm input impedance).

From my back of the envelope calculations it seems I can go easily as high as 8 differential PLLs giving an
impressive (theoretical) 336mW RF output with almost no external parts. Further the power efficiency of this
should be pretty good as most power is consumed driving the pins (PLLs and cogs don't use that much).

Cheers,
ul5255.

jmg

The spectrum of such a signal will be terrible, so the mW should be kept as low as possible, unless you really want to annoy other users.

Peter Jakacki

This sounds like a really cool project, wow. You know you can write your own "datasheet" as long as you are prepared to burn a few chips, and I don't mean the loading new firmware burning either. For these limits I would really be stressing the chip and then seeing if it behaves the same way on other chips etc. But it's not just the load current that the chip has to endure because the switching frequency is very high and I can smell smoke already. But go for it I'd say. Prove the concept, refine the technique.

ul5255

Dear jmg,

Why would you think the spectrum will be terrible?
The LP filter does remove the strongest harmonics down to -50dBc.
Phase-aligning the PLLs will also minimize the phase noise.

Mike Green

It depends on how you're doing the PLL. PhilPi has done some spectrum analysis on using the video generator to produce an FM signal and has found that there's a lot of jitter unless the output frequency is a binary multiple of the crystal frequency and the jitter cannot be filtered out. Have a look at this thread.

ul5255

I had some interaction with PhilPi yesterday to figure out how to phase-align two PLLs.
Basically now I have the NCO feed the PLL at 3.56MHz with the PLLDIV set to 16. This
is slightly out of spec but the PLL locks onto 3.56MHz. Those signals look a lot cleaner
on the scope than the raw signals from the NCO. Also this is all way below the maximum
128MHz the PLL can run so I expect the jitter not to be objectionable. I recall that the amount
of jitter is also a function of the number of bits in PHSx between the highest and lowest 1
bit, so if I sacrifice some tuning resolution I shall be able to find PHSx values which make
it easier for the PLL.
Another idea is to use another cog to constantly fine-tune the FRQx registers to better
phase-align the PLLs although I am not sure if this works.

jmg

The way to reality check this, is to find what the NCO really outputs, and at what rates the jitters occur.
If we take as an example of 3.56Mhz and 40.96MHz, that divides by 11.5056179775280898
- since it cannot really divide by a fraction, what really happens is it divides by 11, or 12, and alternates.
So the actual Fo frequencies are 4.5965 % too high, and 4.29687% too low, but the average is 3.56Mhz


If you pop the fraction into wolfram alpha, it gives 11 45/89, or 11 + 1/2 + 1/178, so it will divide alternately by /11/12/11/12//11
until every 179 cycles,when it divides by 12
This you can also write as
(11*88/178+12*89/178) + 12*1/178)
so taking a frame rate of 178, which will repeat, it divides by 11 in 88 of those, and 12 in 89+1 of those.
( or a frame of 89, and /12 45 times, and /11 44 times )

So any filter, has to remove two dominant 4.5% shifted stubs, and another less dominant 1.12% stub - not impossible, but clearly not your average low pass filter, and any buried PLL filter you have no control over.

An external PLL with a very long time-constant could work in this instance, as our frame example here is 40kHz, but you then get the phase noise of the VCO as an issue.
A good quality LC VCO will be better than a generic RC VCO, and I guess you can tolerate the narrower range of a LC VCO.

That external VCO/PLL also needs to be capable of correct average lock with considerable phase jitter on the input.
Thinking some more, you might be able to use the Prop PLL, which is essentially free, as a jitter reducer, to drive an external 'better' PLL, and there you can probe the VCO control voltage filter, to see the FM modulation corrections.

I don't know of cheap a single-chip LC.VCO.PLL but you could use (eg) 74HC/HCT6323A + 74AUP1T58 + Varicap + Highest Q inductor you can source.
or, if you want full control, and still a LC VCO, I see the ADF4360-9, is not too expensive.
That gives a true charge pump, 1.1MHz..200MHz, and dividers to choose PFD.

That fast-divide-frame will not always be the case, but you could limit your choices to higher-frame frequencies.

ul5255

jmg,

Why did you calculate with 40.96MHz (f_cpu / 2)?

Independent of this my assumptions are that (a) the PLL de-jitters the NCO signal to
some extend (thus taking away some of the energy concentrated in the stubs you
mentioned and (b) running many PLLs in parallel will additionally concentrate more
of the energy at the average 3.56MHz while stubs due to jitter of individual PLLs
will *not* add up since the PLLs will not be 100% phase-aligned.

Yesterday night I managed to sync the PLLs of two cogs. I must clean up the
software so it scales to four cogs / 8 PLLs and then add a properly terminated
LP filter. Then I hope to get hold of a spectrum analyzer at the office and see what
comes out.

Cheers,
ul5255.

jmg

ul5255 wrote: »

jmg,
Why did you calculate with 40.96MHz (f_cpu / 2)?

I just took a guess, based on your Xtal. x2 does not change the divide-alternate nature of the NCO maths.

ul5255

short update:
I meanwhile have 4 cogs / 8 PLLs generating the 3.56MHz square wave. I also added a 10 Ohm in/out LPF on the breadboard which I terminated with a 20Ohm Cermet trim pot. I simulated the circuit in LTSpice which suggested I can hope for ~72mW output power. Now on the breadboard I get around 18 .. 20mW for pot values between 10 .. 14Ohm. If I increase the load, power output drops (e.g. 12mW into 50Ohm).
So I will commit the Propeller now and solder everything on a stripe PCB (I assume I have quite some losses due to the breadboard and jumper wires). I spotted a Tek TDS 2012 C at the office so I can have a look at the spectrum next week (another update coming)