Pin Usage Questions

[gogol]

Hello,

I try to get the real overview, which pins can be used for what purpose. I find dissenting information in the forum here.
The very best information i found in this thread: http://digistump.com/board/index.php?topic=455.0
where semicolo delivers with DigisparkPinout.pdf a very useful document, which should be included to the core-documentation of the get-started page in the Wiki!
I found there the following informations:

• P5 has a weak drive, current is limited to a few mA, high level voltage is 3V @1mA and 2.5V @2mA

• P4 is connected to a zener diode for USB, the internal pullup is too weak to set the pin to HIGH

• P3 has a 1.5KΩ pullup

• P0 or P1 (see model below) is connected to the onboard led, which interferes with the internal pullup

In the thread: http://digistump.com/board/index.php?topic=33.0 bluebie (a very serious contributor) writes:

PB3 and PB4 are used for the USB connection and have some zener diodes and things which limit their voltages.
This leaves PB0, PB1, PB2, and PB5 completely free when using the USB interface. Two 8-bit PWM channels, a USI port which can do SPI, Serial, and I2C stuff, differential analog input with optional 20x gain, analog reference input, hardware interrupt INT0, pinchange interrupts, two regular analog inputs...

In the RGB tutorial I found the following information:

While the red and green LEDs are connected to pins that support PWM, the blue LED is not - this is because the third PWM pin is used by the USB communications and we figure most will want to use the RGB shield with USB communication. See Examples→DigisparkRGB→DigisparkRGB or Examples→DigisparkUSB→DigiBlink for examples of using software PWM for pin 2 (blue LED).  If you are not planning to use USB communication: If you want to connect the blue LED to P4 instead of P2 - flip the shield over and you'll see two solder jumpers, one has a little trace connecting its two pads, the other does't - cut the one with the trace and bridge the other with solder this will disconnect the blue LED from P2 and connect it to P4.

What I am now really searching is a table, stating which Pin can be used for which purpose.
Do I have four, three or only two PWM capable pins?
semicolo marks in his document 4 pins as PWM capable, bluebie writes about two, and the RGB-tutorial about possible 3.

In semicolos paper, I miss a statement, if the zener-diode on Pin4 interferes as well with PWM or has only an impact, with the high-level.

Currently I would like for one project to use USB only for programming, but three PWM outs and three analog ins.

I think it would be perfect, if we could get all information about pin-usage together and if semicolo could expand his PDF with an table, showing the possible usage per PIN.

regards

  Gogol

[dougal]

There are four pins *capable* of hardware PWM (P0, P1, P3, and P4).


If you need to use USB communications in your project, P3 and P4 will be needed for USB, and so will be unavailable for PWM, leaving you with P0 and P1 as your only available hardware PWM pins.


If you are using SPI, that will take up P0, P1, and P2, leaving you P3 and P4 for hardware PWM.


If you are doing I2C, that will take up P0 and P2, leaving you P1, P3, and P4 for hardware PWM.


I've gotten any of that wrong, I trust someone will post a correction.


Also, I am unsure of the effects of the interference from the onboard LED on P0 (assuming rev B board), and the zeners on P3 and P4. I would be interested in more details about how these things could affect either how we attach hardware, or the software we write against them.

[semicolo]

You only need to care about the onboard led and zener if you use the corresponding pins as inputs AND you enable the chips internal pullup.
In the case of the zener, the current that flows through it is enough that it pulls what should be a high state to a low state, in that case you can just add an external pullup.
It may be the same for the led, I just resumed everything that was said on the forums or the official doc into a paper.

[dougal]

I can say that though the docs for the LCD shield warn that the onboard LED might interfere with the I2C interface, I haven't had any problems with it on my 'sparks.

[MichaelMeissner]

I can say that though the docs for the LCD shield warn that the onboard LED might interfere with the I2C interface, I haven't had any problems with it on my 'sparks.

You probably have a new-style board with the LED on P1.  I think the first batch of sparks had the LED on P0, but when they were shipping out sparks to satisfy the kickstarter backers, they made sure that anybody who got an I2C shield or LCD got the boards with the LED on P1.  On the old style boards, I believe you had to cut the trace for the LED to use I2C.

[dougal]

Ah, you're right. I was remembering it backwards. It's confusing that rev2 => Model A board instead of Model B. But my sparks are definitely rev2 with the LED on pin 1. I should have remembered that.

[gogol]

Looks like, P4 is not capable of analog input. Maybe, that is related to the zener.
I have written a very simple test program, where i try to read 3 analog values (in that case a 4k7 potentiometer, providing 0-5V)
and use that for 3 PWM output-channels controlling leds.

Code: [Select]

int led1 = 0;
int led2 = 0;
int led3 = 0;

void setup() {
  pinMode(2, INPUT);
  pinMode(4, INPUT);
  pinMode(5, INPUT);
  pinMode(0, OUTPUT);
  pinMode(1, OUTPUT);
  pinMode(3, OUTPUT);
  analogWrite(0, 255);
  analogWrite(1, 255);
  analogWrite(3, 255);
  delay(2000);
 
}

void loop() {
 led1 = analogRead(0);
 analogWrite(0, led1 / 4);
 led2 = analogRead(1); 
 analogWrite(1, led2 / 4 );
 led3 = analogRead(2); 
 analogWrite(3, led3 / 4);
}

P4 which is analog 2 just switches from 0 to 1023 around 2.7V

Has someone made similar experiences?

.g

[gogol]

Hi,

after some more research, i figured out, that both USB-Pins, P3 and P4 are not usable for analogRead().
P4 works just digital, while P3 works exponential (because of the additional R3 with 1k5 on the zener).

With my pins numbers i refer to semicolos document http://digistump.com/board/index.php?action=dlattach;topic=455.0;attach=92
where he numbers the pins from 0 to 5.

In the schematics https://s3.amazonaws.com/digistump-resources/files/97a1bb28_DigisparkSchematic.pdf
the pins are numbered from 1 to 6.

@semicolo:  can you add some more special notes into your paper:  P3 has not only the pullup, but also an zener connected.  Both are having difficulties for analogRead().

@digistump: have you ever thought, increasing the pcb about 2mm and place two micro-jumpers for the usb-zeners? What are advantages/disadvantages ?

regards

  gogol

P.S.
I added an diagram showing the current on the pins 2,3,1 of the attiny (PB3, PB4, PB5), while there is an 4k7 potentiometer as a simple linear analog sensor replacement connected to the pins P3, P4 and P5 of the digisparc.
As you can see, P5 has the expected linear behaviour, P4 and P3 are influenced by the zener and the pull-up, making the usage of analogRead() for many use-cases impossible.

[semicolo]

I've changed the note for P3.

P4 is supposed to work as anolog input, maybe there's a bug in the core library (but even if it does work it's be disrupted just like P3), I'll try to do some tests when I get 5minutes.

[semicolo]

The digispark I tried seems to be able to use P4 as an analog input (connected a trimmer on P5,P4,P3 and played with it, got values in the 300 to 500 range, 0 when unplugged).
I didn't check for linearity but it didn't seem to be 0 or 1023.
Sometimes the value would jump, probably when there's USB transmission since I used digiUSB to send the values to my PC.

[gogol]

Thanks semicolo for updateing your document!

As you can see in my diagram, P4 is linear nearly up to 70%, than not following the input almost till 99% and jumping up to 100%. Its much better than P3, and it seems to be a workaround possible: When you know the range of your sensor (e.g. 0 to 5k) you can just add an 2k2 resistor  in series to the trimmer and use only the values from 0 to 700 as min and max. In this way, the sensor (trimmer/potentiometer in test case) stays in the linear 70%, because the remaining 30% are eaten up by the resistor.  The drawback is, that you have not 1024 steps but only around 700 to 720 steps for your range, however almost linear.   However that works only for P4, as that is linear in the first 70%.

Because I had problems getting the values out too, i just ended up, measuring the current to see the effect of the zener and the resistor.

Another idea is, that i may try to kill the zeners and the resistor with a sharp knife in that cases, where i need three analog in and outs.  For programming i could extend the Digispark Programming Tool with those three parts. Are there other possibilities?


regards

  gogol

[semicolo]

You could use a lookup table to correct the values but you lose accuracy anyway.

[CBcracker]

I think best way to do the D- pullup would be in the usb code instead of hardware.  There's no point in the host recognizing the digiSpark until it's booted, at which point the usb code can set D- high.
http://www.beyondlogic.org/usbnutshell/usb2.shtml#Electrical

[gogol]

That sounds like an question to Erik himself and Bluebie.  Removing the resistor would really make the IO-port much more valuable for in and out.

[digistump]

If the bootloader ever supports using the on chip pull-up then I'd likely remove it from the board - that said we achieve the Digispark price by producing runs of 10,000 or more so any change will take awhile to reach production.