Atmega Pins unterschiede?!

[termi (Gast)]

Hallo zusammen!

Ich bin gerade dabei eine Led-Matrix anzusteuern und habe im Moment 
folgendes Problem - vielleicht sieht ja jemand gleich meinen Fehler oder 
kann mich aufklären....

Und zwar steuere ich mit IRF9622 P-Mosfets meine Zeilen an und spalten 
über Konstantstrom-LED-Treiber-ICs. 
[http://docs-asia.electrocomponents.com/webdocs/0029/0900766b80029c31.pdf]

Gate über 47 Ohm an Pin des µC, Source an 5V und Drain an die Gemeinsame 
Anode meiner LED-Zeile.

Beim Atmega 48 (mehrere!) und einem 88 PDIP hatte ich den Port D 
verwendet, wobei PD0, PD1 & PD2 okay waren und die Zeilen ordentlich 
geschaltet haben, sind die anderen irgendwo zwischen 0V und 5V (meistens 
so bei 2V) in der Luft gehangen. (Auch beim Test, der nur jede Sekunde 
die Zeile umgeschaltet hat!)

Ich dachte mir, ich versuchs mit nem 48P in SMD...und siehe da - alle 
Pins (selbe Beschaltung, selbe Pins) können meine Zeilen schalten!

Kann es also sein, dass die internen Treiber da verschiedene Leistungen 
haben oder hab ich irgendwas anderes übersehen?

Okay...das Problem schon fast wieder verdrängt hab ich gestern die 
Endgültige Platine mit nem größeren Atmega mit mehr Pins fertig gemacht 
(Atmega1284P) und die Zeilen an Port C gehängt...und was stelle ich 
fest? Es gehen wieder nur 3 Zeilen!...Ich habe gerade gelesen, dass ich 
JTAG in den Fuses deaktivieren muss, da hier auf Port C der JTAG liegt 
und das evtl. Probleme gibt - das muss ich heut Abend nochmal 
überprüfen, aber meine Atmegs48s haben ja gar kein JTAG, dass es an 
sowas hätte liegen können...

Liegts an meiner äußeren Beschaltung, den Mosfets, an den Atmegas, an 
den Fuses, an meim Code...oder bin ich einfach zu blöd?!^^

Vielen Dank schon mal!
LG termi

Hier der relevante Code:

//define display lines
#define ROWS_PORT   PORTC
#define ROWS_DDR    DDRC

#define ROW1        PC1
#define ROW2        PC3
#define ROW3        PC5
#define ROW4        PC6
#define ROW5        PC4
#define ROW6        PC2
#define ROW7        PC0

//INIT
    //set all pins connected to line drivers as output and switch all lines off 
    ROWS_DDR |= ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
    ROWS_PORT &= ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
  
  
//ISR
    //switch to next line
    switch (line){
      case 0:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
                break;
      case 1:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
                break;
      case 2:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW2) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
                break;
      case 3:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7));
                break;
      case 4:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW6) | (1 << ROW7));
                break;
      case 5:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW7));
                break;
      case 6:   ROWS_PORT = (ROWS_PORT & ~((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7))) | ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6));
                break;
      default:  ROWS_PORT = (ROWS_PORT | ((1 << ROW1) | (1 << ROW2) | (1 << ROW3) | (1 << ROW4) | (1 << ROW5) | (1 << ROW6) | (1 << ROW7)));
                //TODO: Error-LED on
                return;
    }

btw. hat jemand ne Idee, ob man den Code noch iwie optimieren könnte? In 
Asm könnte man sich ja was mit relativen Sprüngen mit dem Wert der 
Zeilenvariablen ausdenken...wüsste nicht, dass man sowas in C auch 
hinbekommen könnte - oder?

[Jörg W. (dl8dtl) (Moderator)]

termi schrieb:

> Kann es also sein, dass die internen Treiber da verschiedene Leistungen
> haben oder hab ich irgendwas anderes übersehen?

Nein, ob SMD oder nicht, die Dies (Siliziumscheiben) da drin sind
für das gleiche Produkt auch grundsätzlich die gleichen (allerdings
gibt es sicher Unterschiede in den Exemplarstreuungen zwischen den
einzelnen Fertigungslosen).

> Ich habe gerade gelesen, dass ich
> JTAG in den Fuses deaktivieren muss, da hier auf Port C der JTAG liegt
> und das evtl. Probleme gibt

Es gibt nicht nur „eventuell“ Probleme, sondern auf jeden Fall.
Solange JTAG aktiv ist, überschreibt das die normalen Portfunktionen.

Deaktivieren kann man es übrigens auch zur Laufzeit mit dem JTD-Bit,
also ganz ohne Fuses.

> btw. hat jemand ne Idee, ob man den Code noch iwie optimieren könnte?

Zusätzlich zur Variablen "line" noch eine mit dem jeweils aktiven
Bitmuster mitschleifen.  Dann kannst du schreiben:

  uint8_t tmp = ROWS_PORT;
  tmp &= ~ALL_ROWS;
  tmp |= lines_pattern;
  ROWS_PORT = tmp;

  if (lines_pattern == LAST_PATTERN)
    lines_pattern = FIRST_PATTERN;
  else
    lines_pattern <<= 1;

[Klaus Dieter (Gast)]

Gibts davon auch einen Schaltplan den man sich mal angucken könnte? Sind 
alle VCCs und GNDs geschaltet?

[termi (Gast)]

Jörg Wunsch schrieb:
> Nein, ob SMD oder nicht, die Dies (Siliziumscheiben) da drin sind
> für das gleiche Produkt auch grundsätzlich die gleichen (allerdings
> gibt es sicher Unterschiede in den Exemplarstreuungen zwischen den
> einzelnen Fertigungslosen).

Das dachte ich mir eigentlich auch, deswegen kann ichs mir eben nicht 
erklären, warum es so einen unterschied gemacht hat zwischen m48 pdip 
und m48p tqfp. Was ich eigentlich noch meinte war der Unterschied 
zwischen den einzelnen Portpins untereinander, wobei da das Datenblatt 
was anderes sagt: "The Port B output buffers have symmetrical drive 
characteristics with both sind and source capability...."

> Es gibt nicht nur „eventuell“ Probleme, sondern auf jeden Fall.
> Solange JTAG aktiv ist, überschreibt das die normalen Portfunktionen.
>
> Deaktivieren kann man es übrigens auch zur Laufzeit mit dem JTD-Bit,
> also ganz ohne Fuses.

Ja, das ist mir, wie gesagt, auch heut erst aufgefallen und würde mein 
Problem erklären.

>> btw. hat jemand ne Idee, ob man den Code noch iwie optimieren könnte?
>
> Zusätzlich zur Variablen "line" noch eine mit dem jeweils aktiven
> Bitmuster mitschleifen.  Dann kannst du schreiben:

So wie ich das sehe, geht das auch nur, wenn ich in der "normalen" 
Reihenfolge die Pins mutliplexen will - also 0 - 1 - 2 - 3... was bei 
mir aber durch das Layout einfach nicht der Fall ist. Ich möchte halt 
einfach auf Geschwindigkeit soweits geht optimieren, weil die internen 
8Mhz waren einfach zu wenig und bei 20 Mhz gehts, wobei vermutlich nochn 
paar Zeilen Code dazu kommen werden.

Die Mosfets und die 47 Ohm haltet ihr für geeignet für die 
Geschwindigkeit bei 5V?

Achja ich hab heut von 10pF bis 60pF einige Werte ausprobiert, aber 
keine Besserung. Auf dem Pollin Evalboard Läuft der µC mit 
16Mhz...vorhin ist er mal kurzzeitig auch auf meinem Board gelaufen bis 
ich ans Quarz gefasst hab um zu schaun, ob des Ganze störanfällig ist :D 
...er is dann einfach stehen geblieben (LED hat nicht mehr geblinkt).
Ein anderes Quarz hab ich auch noch ausprobiert, auch nichts.

Ah lustig...während dem Schreiben hatte ichs grad am Strom und siehe da 
- ab und zu blinkts mal 1-2 Sekunden und dann steht wieder alles.

Den relevanten Schaltplanteil hab ich angehängt.

Danke & Grüße,
termi

[Spess53 (Gast)]

Hi

>> Deaktivieren kann man es übrigens auch zur Laufzeit mit dem JTD-Bit,
>> also ganz ohne Fuses.

>Ja, das ist mir, wie gesagt, auch heut erst aufgefallen und würde mein
>Problem erklären.

Nein. Der ATMega48P hat kein JTAG.

MfG spess