Hallo Ich brauche eine zweite UART auf dem ATTiny, die sollte so prozessorsparend wie möglich sein ;) Habe diese gefunden (http://www.siwawi.arubi.uni-kl.de/avr_projects/#softuart) aber die braucht soviel ich sehe eine hohe Prozessorlast (da Timerbasierend) Diese sieht zwar toll aus (Beitrag "Software UART mit FIFO") aber irgendwie lässt er mir die auf einem ATTiny2313 nicht compilieren vermute dem geht das eine oder andere ab oder? (zB.: T1FR1, T1M1 ... ) sonst hängt nichts auf dem tiny drann, nur die zwei UARTS (und eventuell wo ne led oder so ... ) welches nehmen?
sn00py schrieb: > Habe diese gefunden > (http://www.siwawi.arubi.uni-kl.de/avr_projects/#softuart) aber die > braucht soviel ich sehe eine hohe Prozessorlast (da Timerbasierend) Alle mir bekannten Software-UARTS laufen über Timer. Wie soll man auch sonst das exakte Timing einhalten? Diese Lösungen brauchen auch immer mehr Prozessorzeit als Hardware-UARTS. > lässt er mir die auf einem ATTiny2313 nicht compilieren vermute dem geht > das eine oder andere ab oder? Zeig mal die genauen Fehlermeldungen. Gruß Oliver
Kannst auch mal in den SW-Application Notes von Atmel schauen. Da gibt es eine in Assember geschriebene SW-UART, die habe ich auf dem recht leistungsschwachen Tiny15L schon oft erfolgreich eingesetzt. Wenn du den Code nicht findest und Interesse hast kann ich den hier posten.
JA schon klar, das es Timer benötigt, ich meinte für das RX, da gibt es ja auch den Ansatz per Interrupt oder so zu lesen, und nicht 3 so schnell wie nötig, den Eingang abfragen zu müssen ...
So, ich habe nun alle TIMSK1 durch TIMSK ersetzt, nun lässt sich das TEil kompilieren. Habe auch die Ports umgelegt auf die richtigen für den ATTiny2313. Aber in der init routine steht eine Zeile drinnen, wo er hängen bleibt (Lasse ein Led blinken, mit der Zeile, blinkts nicht mehr, ohne der Zeile passt alles) TIMSK = 1<<ICIE1^1<<OCIE1A; // enable tx and wait for start an was kann das liegen? Oder hat wer einen funktionierenden Code für den ATTiny2313?
Mit diesem Tiny kann man vielleicht 1 Euro sparen. Waere es nicht einfacher einen Mega 644, welcher von Haus aus 2 Uarts hat, einzusetzen? Ich hab sowas auch schon mal gemacht weil's um 10000er Stueckzahlen ging.
Es geht hier um die größe des Controllers der 644 ist doch shcon riesig, wenn er auch lötbar bleiben sollte ...
Schau mal im Datenblatt auf den Punkt 16.4 und insbesondere auch 16.4.1 Wenns reicht... mfg mf
Tja. Dann muss man da eben durch. Das Debuggen des Tiny ist ja auch nicht grad einfach, denn allzviele freie Pins werden's ja auch nicht sein. Ein neuer Ansatz waere zB den Simulator des AVR Studios zu verwenden. Da kann man auf Registerlevel runter zusehen was denn so abgeht.
Hmm bei mir hat da Datenblatt kein 16.4 oder 16.4.1 da gibts prinzipiell keine Kapitelnummern
Es geht mit sehr wenig Aufwand auf dem tiny:
1 | void
|
2 | sputc( |
3 | char c |
4 | )
|
5 | {
|
6 | register unsigned char i; |
7 | |
8 | outbit( 0); |
9 | for ( i=1; i; i=i*2) |
10 | outbit( c & i ? 1 : 0); |
11 | outbit( 1); |
12 | outbit( 1); |
13 | _delay_us( 1000.0); |
14 | }
|
15 | |
16 | static
|
17 | outbit( |
18 | char on |
19 | )
|
20 | {
|
21 | if ( on) PORTB |= 0x08; else PORTB &= 0xf7; |
22 | _delay_us( 101.5); |
23 | }
|
Die delays habe ich mit einem 2-Kanaler experimentell ermittelt. Vielleicht nicht die reine Lehre ... ich habe da aber auch nur ein kleines 2-Zeilen Display dran hängen.
ok danke :) leider muß ich auch das eine oder ander Byte lesen, es ist zwar 95% schreiben .... aber trotzdem acuh manchmal lesen :(
Bei mir steht da auf Seite 162: Datenblatt schrieb: > 16.4 Alternative USI Usage > The flexible Design of the USI allows it for other tasks when serial > communication is not needed. Below are some examples. > 16.4.1 Half-Duplex Asynchronous Data Transfer > Using the USI Data Register in three-wire mode it is also possible to > implement a more compact and higher performance UART than by software, > only. mfg mf PS: Weil der Text nicht kopierbar ist und nur Exorzismus-Zeichensalat erzeugt, musste ichs auch noch abtippen. Oh Mann... Aweng mitdenken, Atmel...
Hallo :( Kann mir wer noch einen Tipp geben wo und was ich noch schauen kann? Irgendwie will das alles nicht, alle soft uart sind für andere Controller, und nach dem ich alles anpasse für den ATTiny2313, funkt es leider nicht mehr. Die ATMEGA mit 2*UART sind leider zu groß, hab mir schon überlegt, ob ich einfach 2*ATTiny2313 nehmen soll, die dann per I2C oder so kommunizieren, falls das geht, aber ist ja auch nicht das gelbe vom ei oder? Hat noch wer eine Idee, wie ich zu so was komme?
Du könntest ganz einfach selbst einen eine schreiben? Zumindest TX ist kein Problem, RX gibt schon etwas mehr zu tun. Hast du ein Oszilloskop? Das ist meiner Meinung nach die Voraussetzung um so etwas umzusetzen, habe letzte Woche nur TX für einen attiny26 geschrieben. (Nicht besonders wiederverwendbar, nur zum Testen, könnte ich dir aber geben) mfg Andreas
Ich hab in meinem Tektronixtablet mit V-USB Projekt eine Software UART für den Tiny45/85. Receiver per Interrupt, Transmitter zu Fuss. Kopier dir raus was du brauchst: http://www.schoeldgen.de/avr/
Holler schrieb: > Kannst auch mal in den SW-Application Notes von Atmel schauen. Da gibt > es eine in Assember geschriebene SW-UART, die habe ich auf dem recht > leistungsschwachen Tiny15L schon oft erfolgreich eingesetzt. > > Wenn du den Code nicht findest und Interesse hast kann ich den hier > posten. @Holler: ich hätte gerne entweder source oder link..... möchte gerne an zb. NANO V40 oder UNO (ATMEGA328) GPRS-datenstream aus UBLOX-modul (TTL-seriell) auslesen und via USB/RS232 selektiv weitersenden.... nur assembler, kein C oder MBASIC o. dgl.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.