Hallo meine Lieben, Ich bin total verzweifelt mit meinem Problem hier. ich möchte eine Kommunikation zwischen einem Master und Empfänger über UART auf RS485-Basis aufbauen. Der Master ist ein AVR ATMEGA32 und der Empfänger ein PSOC-µC. Der Baudrate ist auf 9600 eingestellt beidseitig und geprüft. alles I.O. Der Master sendet ein Paket mit 8 Bit einem Start- und Stop-bit. Die kommen beim Eingang Rx_Psoc-µC ganz gut an. In einem Programm möchte ich die Daten zurücksenden an dem Master. Nun funktioniert der echo nicht ganz gut. Ich weiß nicht, ob der Psoc_Rx ordnungsgemäß die Daten aufnimmt. Denn sporadisch sendet er den richtigen Wert und manchmal was falsches. Kann mir jemand checken was ich in meinem Code falsch mache? Uart-Einstellung in Psoc: Parameters Parameters Value Clock Row_0_Output_1 ClockSync Sync to SysClk CommandTerminator 13 Enable_BackSpace Disable IgnoreCharsBelow 32 IntDispatchMode ActiveStatus InterruptAPI Enable InvertRX Input Normal Param_Delimiter 32 RX Clock Out None RX Input Row_0_Input_1 RX Output None RxBufferSize 16 RxCmdBuffer Enable TX Clock Out None TX Interrupt Mode TXComplete TX Output Row_0_Output_0 Code: While(1) { DigBuf_RS_Stop(); Driver - Empfang while(!(UART_1_bReadRxStatus()& UART_1_RX_COMPLETE)); x=UART_1_bReadRxData(); DigBuf_RS_Start(); Driver- Senden while(!(UART_1_bReadTxStatus()&UART_1_TX_BUFFER_EMPTY)); UART_1_SendData(x); while(!(bUART_1_ReadTxStatus()&UART_1_TX_COMPLETE )); DigBuf_RS_Stop(); } wäre sehr dankbar für jede Hilfe. lg Florian dielman
ja das problem ist das ich schon eine fertige platine uaf dem ich keine Quarz mehr einbauen kann. Zum anderen meine Ressource(Pins) sind schon alle besetzt. Nun kann ich nur Machen mit was ich in den Händen habe. Ist der Code so korrekt ? Danke
Man kann den internen RC-Oszillator kalibrieren, das ist dann einigermassen genau genug für UART, wenn die Temperatur nicht zuviel schwankt (sagen wir +/-20K). Das Register OSCAL ist dein Freund. MFG Falk
Man kann anhand eines empfangenen Bytes den Reloadwert für das Zählerregister errechnen. Das wäre dann so eine Art Auto-Baud-Funktion... Aber einfacher ist die Methode von Falk ;-)
@ Lothar Miller (lkmiller) >Man kann anhand eines empfangenen Bytes den Reloadwert für das >Zählerregister errechnen. Reloadwert und UART? Ahhhh, der alte 8051 Schrott. Hey, wir leben im 21. Jahrhundert. AVR rulez!
Falk Brunner schrieb:
> Hey, wir leben im 21. Jahrhundert. AVR rulez!
Und da geht das nicht mehr? Schade, schade :-/
Aber wenn ich mir das Datenblatt ansehe
1 | The USART Baud Rate Register (UBRR) and the down-counter connected to it |
2 | function as a programmable prescaler or baud rate generator. The |
3 | down-counter, running at system clock (fosc), is loaded with the UBRR value |
4 | each time the counter has counted down to zero or when the UBRRL Register is |
5 | written. |
dann hört sich das für mich nach einem Reloadwert an ;-) Andere Prozessorarchitekturen wie ST10 haben das sogar im Bootloader drin...
@ Lothar Miller (lkmiller)
>dann hört sich das für mich nach einem Reloadwert an ;-)
Lässt sich ja prinzipiell kaum vermeiden. Aber das Reloaden macht die
Hardware allein, für so einen Schnulli die CPU zu belästigen ist ja fast
strafbar. . .
MFG
Falk
> Aber das Reloaden macht die Hardware allein, Wie beim 8051, womit sich der Kreis wieder schliesst ;-)
Danke schön für Anregungen ich sehe dass es vielleicht mein Problem sein kann. Denn die Factory Calibrated Frequency ist für ein Betrieb mit 3V und hat eine Abweichung von +-10%. Ich habe auch gelesen, dass die vom User kalibrierte Frequenz zwischen 7.3Mh und 8.1MH abweicht.(ATMEGA328P Seite 317) Ist es dann damit möglichst eine genauere 8Mhz zu erzielen? zum anderem muss man nur den OSCALL am Anfang vor dem main() schreiben und ist dann alles erledigt oder?. Entschuldigung für die Fragen ich habe noch nicht ein Internen RC kalibriert. Danke
@ Florian dielman (Gast) >Ich habe auch gelesen, dass die vom User kalibrierte Frequenz zwischen >7.3Mh und 8.1MH abweicht.(ATMEGA328P Seite 317) Ist auch so. >Ist es dann damit möglichst eine genauere 8Mhz zu erzielen? Definiere genau. Man bekommt das ganze in etwa auf 0,5% kalibriert. >zum anderem muss man nur den OSCALL am Anfang vor dem main() schreiben >und ist dann alles erledigt oder?. Ja. >Entschuldigung für die Fragen ich habe noch nicht ein Internen RC >kalibriert. Ach du Ärmster. > Bitte Um hilfe ich bien schon verzweifelt. Weil du innerhalb von 2 Stunden keine Antwort bekommt? Bleib mal locker. In der Zeit hätte man es dreimal selber ausprobieren können. MFG Falk
@Florian: Bei Atmel gibt es mehrere AppNotes, die sich mit der Kalibrierung des internen Oszillators befassen (AVR351, AVR053, AVR054, AVR140). Falls Du beim Übertragungsprotokoll nicht festgelegt bist, dürfte AVR054 für Dich am interessantesten sein. Die beschreibt, wie sich ein Slave zu Beginn eines jeden Übertragungsblocks anhand eines vom Master gesendeten Bitmusters auf dessen Takt kalibrieren kann.
Bei serieller Übertragung musst Du deine Baudrate auf 1,5 bis 2,5% genau einhalten (je nach Begleitumständen). Bei zwei Geräten gilt das für die Summe der Abweichungen beider. Kannst Du das nicht einhalten, erreichst Du keine zuverlässige Verbindung -- keine Arme -> keine Kekse, in der Technik ist das so einfach. Es ist nun Deine Aufgabe, das sicherzustellen; Verzweiflungsäußerungen bringen Dich dem Ziel nicht näher. Da Du Deine Hardware am besten kennst, ist es nun an Dir, die Möglichkeiten abzuklopfen. Hast Du irgendwo eine hinreichend genaue Frequenz, auf die Du ei^H^Hkalibrieren kannst?
> Es ist nun Deine Aufgabe, das sicherzustellen; Verzweiflungsäußerungen > bringen Dich dem Ziel nicht näher. Da Du Deine Hardware am besten > kennst, ist es nun an Dir, die Möglichkeiten abzuklopfen. Wobei der erste Schritt immer darin besteht, eine Fehleranalyse zu machen. Wenn du 2 Geräte hast, von denen du nicht weißt, welches Schuld ist, dann ist eine gute Strategie zb. eines der Geräte durch ein anderes zu ersetzen, welches garantiert richtiges Verhalten aufweist. Garantie richtig gibt es selten, aber in diesem Fall kann man wohl davon ausgehen, dass die UART eines PC keinen allzugroßen Fehler haben wird. Also wird man wohl jedes der unbekannten Geräte mit einem PC verbinden und nachsehen, ob sich dort bei einem der beiden (oder bei beiden) Fehler in der UART-Kommunikation zeigen. Findet sich da etwas, hat man schon viel gewonnen. Immerhin ist das Problem dadurch schon um 50% leichter geworden. Wie Hazeh schon so richtig sagte: Verzweifeln bringt nichts. Systematisch überlegt vorgehen! Überlegen "Was könnte es sein" und daraus sofort eine Strategie ableiten, wie man diesen möglichen Fehler testen oder ausschliessen kann.
Danke für Hilfestellung und aufmunterung. ich mache mich am Werk und lass euch berichten. Danke an alle Lg Flo
Hi Leute, ich habe die mögliche Quelle meines Problem gefunden. aber weiß noch nicht wieso und warum es auftritt. Die Übetragung läuft perfekt. Der master sendet, der Slave empfängt und sendet zurück. Das Problem liegt bei der ATmel _µC und nicht beim PSOC. Die TX und RX leitung von dem ATMEGA32 sind direct auf dem Treiber MAX487 angeschlossen. Sobald ich die RX einschalte "UCSR0B |=(1<<RXEN0);" die gesamte Übertragungsweg geht nicht mehr. schalte ich RX ab läuft alles wierder wunderbar. D.h. ich kann nichts empfangen am Master. Ich habe versucht ein Verbraucher (Widerstand, Diode) zwischen RX und Eingang Treiber zu schalten , es klappt aber nicht. es wäre als ob er würde dauern die leitung auf low oder high oder weiß nicht genau ziehen und die Gesamte Übertragung komplet stören. Weißt jemand woran es liegen kann ? Danke
Bemühe dich doch mal um einen Schaltplan. Laut Datenblatt MAX487 würde ich erwarten, dass vier oder drei Leitungen zum Atmega32 gehen: DI, RO als Datenleitungen plus DE und /RE als Enable-Leitungen (#1). DE und /RE können zusammengefasst werden (#2). Daten zur Busterminierung gibt es im Beitrag "Re: RS485 mit MAX487" und im Datenblatt sind 120 Ohm in den Diagrammen eingezeichnet. #1 MAX487 http://ecee.colorado.edu/~mcclurel/max485ds.pdf #2 http://www.circuitcellar.com/avr2006/winners/DE/DE_Abstracts/AT2661_abstract.pdf
Die Verdrahtung ist genau so gleich wie auf dem gelinkten Forumbeitrag. 120 Ohm habe ich auch dran. Variert +-30 habe ich auch schon. Trotzdem. Enable-Eingänge(DE, /RE) werden zusammen angesteuert. R0 an RX und DI an TX .
Ich habe auch versucht den Pin als Eingang zu schalten, die Übertragung ist immer gestört. Enferne ich den Master Tx leitung bekomme ich das gleiche Bild als wäre RX ein . Ich vermute es wenn RX ein ist zusätzlich zu TX . collidieren die beide intern, sodass die Wirkung von Tx nicht mehr zu sehen ist. Andere Treiber holen. Klar habe ich schon gemacht . Bei dem auch das gleiche Verhalten.
> Ich vermute... Das ist m.E. nicht die richtige Vorgehensweise. > Die Verdrahtung ist genau so gleich wie auf dem gelinkten Forumbeitrag. Jaja. Welchem Teil des Beitrags? Machs doch einfach so: zeichne genau deine Beschaltung ab und poste den Plan hier. Aber bitte nicht irgendwo was herkopieren und sagen "fast genauso ähnlich". BTW: > ich mache mich am Werk und lass euch berichten. Hast du das Thema mit der Baudrate (interner Takt) inzwischen behoben?
>> Ich vermute... >Das ist m.E. nicht die richtige Vorgehensweise. Solange ich etwas nicht aufklären kann, kann ich nur Vermutungen äussern und keine feste Ursache , da ich selber nicht weiß. hier habe ich meine plan gezeichnet. > ich mache mich am Werk und lass euch berichten. >Hast du das Thema mit der Baudrate (interner Takt) inzwischen behoben? ja ich habe es gelöst. Ich habe die interne Takt so getrimmt(mit osscal-register )bis eine gesamte Übertragung von 1 Byte 833µs erreicht. Dies kommt dann beim Empfänger gut an und der Echo klappt auch gut. Nur der Master auf dem receive-Eingang macht mir nun probleme.
also wenn es bei deinem Master RX ist solltes es beim Client schon am TX angeschlossen sein. bei deinem Schaltplan ist das aber nicht so. ;)
>also wenn es bei deinem Master RX ist solltes es beim Client schon am TX >angeschlossen sein. bei deinem Schaltplan ist das aber nicht so. ;) Nein vielleicht ist eine Verwirrung. Der MAX487 hat als Bedienpin von µC aus die DI für Tx und R0 für RX. und geben auf dem Bus die invertierende Signal A und B. Es ist auf dem Bild nicht auf die lineare Anordnung von Tx bzw. A oder B aufzupassen. Dies zeigt nur den Prinzip
Nö, der "Plan" ist ja im Prinzip richtig. Es fehlen halt "lediglich" die Enable-Leitungen. Von anderen Problemen, die sich im Schaltplan oder auf der Platine befinden können nicht zu reden. Den Wert "1 Byte 833µs" kann man auch schlecht einschätzen - ist das für 2 Protokollbits plus 8 Datenbits gerechnet oder für ein Byte (8-Bit)? Ist das ein gemessener Wert für den AVR Sender und ist der Wert vergleichbar mit dem gemessenen Wert für den PSoC Sender? Die AVR UART hat einen Fehlerdetektor, was meldet der beim Empfang? Wieviel % der Zeichen sind fehlerhaft? Ändert sich die Fehlerrate mit der Art oder der Geschwindigkeit der zeichen oder mit Pausen zwischen den Zeichen oder mit der Menge der Zeichen pro Block? Wie sehen die Bitmuster der Zeichen auf dem Bus und der empfangenen, fehlerhaften Zeichen aus; Versatz? Fehlendes Anfangsbits? Wie ist die Software beim Empfänger AVR geschrieben? Ist die Umschaltung TX-Betrieb zu RX-Betrieb schnell genug? Im Plan sind noch zwei weitere "Slaves" eingezeichnet. Sind die fiktiv oder real da? Sehen die auch verstümmelte Daten oder sehen die korrekte Daten? BTW. AVR2006 Contest... Ich würde mir wahrscheinlich zum Debuggen eine solche RS232-nach-RS485 Bridge aufbauen. Mit Quarz ;-)
>Den Wert "1 Byte 833µs" kann man auch schlecht einschätzen - ist das für >2 Protokollbits plus 8 Datenbits gerechnet oder für ein Byte (8-Bit)? >Ist das ein gemessener Wert für den AVR Sender und ist der Wert >vergleichbar mit dem gemessenen Wert für den PSoC Sender? Der Wert steht für 8 Bit ohne start und Stop-Bit. und Mit kontrolbit 1ms. Diese Wert sinid vergleichbar mit dem Psoc sender. >Im Plan sind noch zwei weitere "Slaves" eingezeichnet. Sind die fiktiv >oder real da? Sehen die auch verstümmelte Daten oder sehen die korrekte >Daten? sie sind nur fiktiv da. Nun ist nur ein in meinem Aufbau vorhanden >Wie ist die Software beim Empfänger AVR geschrieben? Ist die Umschaltung >TX-Betrieb zu RX-Betrieb schnell genug? Momentan es soll zuerst mal ankommen ohne gelesen zu werden. Erst dann kann ich die entprechende While einbauen.
1 | UCSR0B |=(1<<TXEN0)|(1<<RXEN0);; |
2 | while(1) |
3 | {
|
4 | PORTB |= (1 << DDB0); //Max485 auf Senden |
5 | |
6 | while ( !(UCSR0A & (1<<UDRE0))); |
7 | UDR0 = 0x0F; |
8 | |
9 | while ( !(UCSR0A & (1<<TXC0))); //Warten bis Übertragung fertig |
10 | UCSR0A |= (1<<UDRE0); //Register leeren |
11 | |
12 | PORTB &= ~(1 <<DDB0); //Max485 auf Empfang |
13 | |
14 | |
15 | _delay_ms(4); |
16 | }
|
>Wie sehen die >Bitmuster der Zeichen auf dem Bus und der empfangenen, fehlerhaften >Zeichen aus; Versatz? Fehlendes Anfangsbits? wenn RX-enable (MAster ) Am EMpfang:fehlendes Bits, unperiodisches auftritt (nur einmal). Am Sender : kontinuerliches unregelmäsiges Bitfolges unabhängig von RS485 enable-Leitung. ich suche immer wo der Hase liegt.
> wenn RX-enable (MAster ) > Am EMpfang:fehlendes Bits, unperiodisches auftritt (nur einmal). Das ist seltsam. Werden die Bits mit dem obigen Codefetzen detektiert? da sollte man garnix sehen, denn in obigem Codefetzen ist keine Empfangsanweisung enthalten. Hast du Messequipment zum Überwachen des Bitstroms? BTW. Warum hast du diese Zeile drin? UCSR0A |= (1<<UDRE0); //Register leeren > Am Sender : kontinuerliches unregelmäsiges Bitfolges unabhängig von > RS485 enable-Leitung. Das ist seltsam. Der Bitstrom muss von den Enable-Leitung abhängig sein. Die gesendeten Daten dürfen nur auf dem Bus (A/B Leitungspaar) sein, wenn der Sender seinen MAX487 per DE enabled hat. Und der Empfänger kann den Bitstrom nur empfangen, wenn er seinem MAX487 die /RE-Leitung enabled hat. Ich würde Nägel mit Köpfen machen: 0. 8-Spur Logikanalyzer beschaffen 1. Einfaches Senderprogramm für PSoC schreiben. Einfaches Empfangsprogramm für AVR schreiben. Laufenlassen. 2. 8-Spur Logikanalyzer an die vier Digitalleitungen der beiden MAX487 hängen. Mitschnitt zeigen. 3. Einfaches Senderprogramm für AVR schreiben. Einfaches Empfangsprogramm für PSoC schreiben. Laufenlassen. 4. Schritt 2 wiederholen.
@ Stefan B. Danke für deine Hilfbereitschaft. >BTW. Warum hast du diese Zeile drin? > UCSR0A |= (1<<UDRE0); //Register leeren das problem ist, dass ich keine IMpuls am PORTB bekomme solange ich diese Zeile nicht hinzugefügt habe. Und das signal kommt periodisch alle 4 ms. Kommentiere ich diese Zeile kommt das Signal nach reset einmal sauber( ca. 1ms) und dann nur als Spitze von paar pikrosekunde. >Das ist seltsam. Werden die Bits mit dem obigen Codefetzen detektiert? ich denke der code ist sehr einfach gehalten nur für das Senden. Wenn ich für den Empfang diese Zeilen hinzufügt bleibt aber das Programm hängen
1 | //while (!(UCSR0A & (1<<RXC0)) );
|
2 | /* Get and return received data from buffer */
|
3 | x=UDR0; |
1 | while (!(UCSR0A & (1<<RXC0)) ); |
2 | /* Get and return received data from buffer */
|
3 | x=UDR0; |
Florian dielman schrieb: > das problem ist, dass ich keine IMpuls am PORTB bekomme solange ich > diese Zeile nicht hinzugefügt habe. Und das signal kommt periodisch > alle 4 ms. > Kommentiere ich diese Zeile kommt das Signal nach reset einmal sauber( > ca. 1ms) und dann nur als Spitze von paar pikrosekunde. Welchen Impuls/Signal willst du an PORTB periodisch BEkommen? TXD und RXD liegen beim Atmega32 an PORTD; die kannst du nicht meinen. Die Enable-Leitung(en) zum MAX487 sind an einen Output-Pin (PORTB.0) gekoppelt, d.h. du willst ein Signal ABgeben; den kannst du auch nicht meinen. Ist für PORTB.0 DDRB richtig auf Ausgang initialisiert? In deinem Codefetzen sieht man das nicht. > Wenn ich für den Empfang diese Zeilen hinzufügt bleibt aber das Programm > hängen So lange keiner an deinem Bus was sendet, ja. Deshalb hatte ich ja auch vorgeschlagen, dass du den PSoC nur mit der Sendeaufgabe betreust und den AVR nur mit der Empfangsaufgabe. Hast du noch einen MAX487 pkus einen MAX232 oder drei NPN-Transistoren im Lager um die RS485-to-RS232 Bridge zu bauen?
>Welchen Impuls/Signal willst du an PORTB periodisch BEkommen? das Umschaltsignal für den Treiber (DE,/RE). >Ist für PORTB.0 DDRB richtig auf Ausgang initialisiert? In deinem >Codefetzen sieht man das nicht. ja in dem Ini() hier ist der code zum senden:
1 | #ifndef F_CPU
|
2 | #define F_CPU 8000000UL // Frequenz
|
3 | #endif
|
4 | |
5 | #include <avr/io.h> |
6 | #include <util/delay.h> |
7 | #include <avr/interrupt.h> |
8 | #include <string.h> |
9 | #define BAUD 9600UL
|
10 | |
11 | |
12 | #define TEILER (F_CPU/(16UL*BAUD))-1
|
13 | |
14 | |
15 | void RS485_Init (void) |
16 | {
|
17 | unsigned int x; |
18 | |
19 | DDRB |=(1<<DDB0); //ausgang Treiberumschaltung |
20 | |
21 | |
22 | // Baudrate Einstellung
|
23 | UBRR0H = (unsigned char) (TEILER>>8); |
24 | UBRR0L = (unsigned char) TEILER; |
25 | |
26 | //Sender und Empfänger ein
|
27 | UCSR0B |= (1<<TXEN0)|(1<<RXEN0)|(1<<RXCIE0); |
28 | |
29 | |
30 | // Datenformats: 8 Datenbits, 1 Stoppbit
|
31 | UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); |
32 | x=UDR0; // Empfänger leeren |
33 | |
34 | }
|
35 | |
36 | |
37 | int main(void) |
38 | { // Kalibrierung der internen RC-Oszillator |
39 | OSCCAL = 0x6C; |
40 | |
41 | unsigned char x,k; |
42 | k=0x0F; |
43 | |
44 | |
45 | |
46 | RS485_Init(); |
47 | |
48 | |
49 | while(1) |
50 | {
|
51 | PORTB |= (1 << DDB0); //Max485 auf Senden |
52 | |
53 | while ( !(UCSR0A & (1<<UDRE0))); |
54 | UDR0 = 0x0F; |
55 | |
56 | while ( !(UCSR0A & (1<<TXC0))); //Warten bis Übertragung fertig |
57 | UCSR0A |= (1<<UDRE0); //Register leeren |
58 | |
59 | PORTB &= ~(1 <<DDB0); //Max485 auf Empfang |
60 | |
61 | |
62 | _delay_ms(4); |
63 | }
|
64 | }
|
in Projekt/ config wird Frenquency auf 8000000 eingestellt. in STK500 auf "Fuses" SUT_CKSEL : Int. RC.OSc.8MHz >Hast du noch einen MAX487 pkus einen MAX232 oder drei NPN-Transistoren >im Lager um die RS485-to-RS232 Bridge zu bauen? Max487 ja . Max232 nein. aber eine STK500 >So lange keiner an deinem Bus was sendet, ja. Deshalb hatte ich ja auch >vorgeschlagen, dass du den PSoC nur mit der Sendeaufgabe betreust und >den AVR nur mit der Empfangsaufgabe. mache ich nun auf diesem Weg.
Florian dielman schrieb: >>Welchen Impuls/Signal willst du an PORTB periodisch BEkommen? > das Umschaltsignal für den Treiber (DE,/RE). Wie vermutet ist das ein Mistverständnis. Du musst vom AVR Programm aus sorgen, dass an PORTB.0 das DE bzw. /RE Signal ausgegeben wird. Du bekommt dort kein Signal von außen. Im Programm ist das auch gemacht. > UCSR0B |= (1<<TXEN0)|(1<<RXEN0)|(1<<RXCIE0); ^^^^^^^^^^^ Wo ist die dazugehörige UART Receiver ISR? Wenn die fehlt, resettet sich der AVR beim ersten empfangenen Zeichen (also beim Echo des PSoC). Lass das |(1<<RXCIE0) weg. Rest nicht mehr angeschaut.
@ Stefan B.
es hat geklappt. ouf!
>Lass das |(1<<RXCIE0) weg.
was so eine kleines Bit(Schrift), jemand Studen kosten kann.
Aber nirgendwo habe ich deine Begründung/Erklärung gelesen. Kannst du
mir ein Link zuschicken wo sowas steht(wenn vorhanden).
vielen Dank an dir für deine Gedult.
werde nun den Code erweitern für ein Telegramm(mehrere Bit
nacheinander).
lg
Flo.
Schau dir den Artikel AVR-GCC-Tutorial/Der UART an und achte auf die "händischen" Sende/Empfangsverfahren (Polling) kontra die Interruptverfahren. Die Bedeutung des Bits steht auch im Datenblatt. Es schaltet den Interruptbetrieb der UART ein. Und der verlangt eine Routine zum Behandeln des Interrupts, die sog. ISR (Interrupt Service Routine). Wenn die fehlt und der Interrupt kommt, gibt es Chaos. ISR vergessen oder falscher Name oder unabsichtlich anschalten oder nicht anschalten sind Fehler, die 99% der Programmierer mal machen. Nächstes Mal gleich Sourcecode beibringen und auch eine echte Schaltplanskizze. Die Skizze muss nicht perfekt layoutet sein; sie darf handgezeichnet und eingescannt oder fotografiert sein. Den Bug hätten wir mit Sourcecode am ersten Abend gekillt ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.