Adressierung von 64 LED´s

[Bubi_00]

hmm ich bekomms ned zusammen.. irgendeinen fehler hab ich drinnen...
kannst du mal dein Programm posten Felix bitte ?
wäre sehr nett...
mfg

edit hier mal meins.. : aber nix besonderes sondern einfach nur abgearbeitet wies im bericht steht

	DDRC = (1<<0);
	PORTC = (0<<0);
	
	DDRB = (1<<5);
	PORTB = (1<<5);
	
	delay_ms(10);
	
	DDRB = 0;
	PORTB = 0;
	
	i=0;
	while(PORTB & (1<<5) == (1<<5))
	{
		i++;
		delay_us(100);
	}
	
	printf("lol:%d\r\n", i);

Achso und hier mal der aktuelle Schaltplan

Bild hier  

[Felix G]

Also wenn du die LEDs wirklich multiplexen möchtest, wirst du auf die 74xx245 nicht verzichten können. Die sind nötig um die inaktiven Spalten vom Controller zu trennen. Wenn du die LEDs aber nicht multiplexen möchtest, sondern die Kathoden direkt an den µC anschliessen, dann kannst du nicht nur auf die 74245 verzichten, sondern auch auf die 74244 und 7404.


Naja, hier mal mein Programm das allerdings etwas komplizierter ist, da ich Interrupts verwendet habe (T0 Overflow, T1 Overflow und T1 Input Capture).

#include <avr/io.h>
#include <avr/interrupt.h>

volatile int timestamp = 0;

void init(void)
{
	//2ms: TCCR0 =	0x04; TCNT0 = 0x83;
	TCNT0 =	0x06;

	//1ms: TCCR1B = 0x01; TCNT1 = 0xC180;
	TCCR1A =	0x00;
	TCNT1 =	0xC180;

	TIMSK =	0x25;
	TIFR =	0x00;

	GICR =	0x00;
	GIFR =	0x00;
	MCUCR =	0x00;

	sei();
}

SIGNAL (SIG_INPUT_CAPTURE1)
{
	timestamp = ICR1;
}

SIGNAL (SIG_OVERFLOW1)
{	
	//T1 stop
	TCCR1B =	0x00;
	TCNT1 =	0xC180;
	
	//reverse bias
	DDRD =	0x60;
	PORTD =	0x40;
	
	//T0 start
	TCCR0 =	0x04;
}

SIGNAL (SIG_OVERFLOW0)
{
	//T0 stop
	TCCR0 =	0x00;
	TCNT0 =	0x83;
	
	//discharge
	DDRD =	0x20;
	PORTD =	0x00;
	
	//T1 start
	TCCR1B =	0x01;
}

int main(void)
{
	init();
	
	DDRC =	0xFF;
	PORTC =	0x00;
	
	//reverse bias
	DDRD =	0x60;
	PORTD =	0x40;
	
	//T0 start
	TCCR0 =	0x04;
	
	for(;;)
	{
		PORTC = timestamp >> 8;
	}
}

Als Controller habe ich einen ATmega32 verwendet, die Kathode der LED kommt an PD6(ICP1), die Anode an PD5 (hätte sie aber bei meinem ersten Test auch genausogut direkt an GND hängen können). Damit klar ist wie die LED angesteuert wird, habe ich in den Kommentaren die Bezeichnungen aus der pdf-Datei benutzt. (also "reverse bias" für den Ladevorgang und "discharge" für die Messung)

[Bubi_00]

arg stimmt, seh ich erst jetzt, dank dir.. Sonst hab ich ja immer GND Potential am µC.
Zum Programm hmm ich sehe jetzt keinen Unterschied du hast auch nichts besonderes drinnen. Hmmm morgen mal ein anderes µC Board versuchen... irgendwas passt nicht... Dank dir erstmal ich melde mich wieder

Bild hier  

ich lande immer wieder bei deinem layout kann nix optimiern..
scheint perfekt zu sein... gratuliere aber vl finde ich nen baustein der auf masse ziehn kann

[Bubi_00]

So, eine Messung mit HIlfe eines Oszi hat NICHT funktiniert.
Dazu mal eine Frage: hast du das LED kurz leuchten lassen ? angeblich MUSS das sein ?! Bei dem Oszi versuch konnten wir zwar ein Kurve sehn aber keinen Unterschied in der Geschwindigkeit ...

[Felix G]

Also bei meinem Test verwende ich die LED nur zur Messung, sie wird zu keinem Zeitpunkt in Durchlassrichtung betrieben. Möglich daß das Verfahren besser funktioniert wenn man die LED zwischen den Messungen auch einschaltet, aber nötig ist es definitiv nicht. (Ich habe beim ersten Test darauf verzichtet um das Programm möglichst einfach halten zu können)

Was ich allerdings feststellen musste:
ich habe hier 3 Arten von LEDs, nämlich rot diffus, grün diffus und blau klar. Die Messung funktioniert aber nur bei den grünen LEDs, und das obwohl die blauen aufgrund des klaren Gehäuses eigentlich besser geeignet sein sollten. Bei direkter Bestrahlung mit einem roten 1mW Laser zeigte keine der LEDs eine Reaktion (obwohl die grüne ein diffuses Gehäuse hat ist definitiv ein erheblicher Anteil des Lichts auf dem Kristall gelandet), bei einem grünen 5mW Laser reagierte nur die grüne LED.

Für erste Tests halte ich es daher für essentiell notwendig die Schaltung auf ein Minimum zu reduzieren, um die Anzahl möglicher Fehlerquellen klein zu halten. (heisst im Klartext: LED + Vorwiderstand direkt am Controller, ohne weitere Elektronik dazwischen)

ich lande immer wieder bei deinem layout Smile kann nix optimiern..
scheint perfekt zu sein... gratuliere

Danke für die Blumen, aber das würde ich so nicht behaupten...
Meine Lösung hat zwar den Vorteil, daß nur wenige Ports am µC benötigt werden, ist aber deutlich unflexibler als die Variante mit mehreren µCs bei der jede LED einen Pin belegt. (außerdem entstehen Geschwindigkeitsprobleme, wenn die Anzahl der LEDs so groß wird daß es nicht mehr ausreicht nur 8 parallel auszulesen)


Gruß,
Felix