Hallo, ich habe hier das Testboard STK500 in dem ich den Prozessor ATMEGA128 mit 8Mhz laufen habe. Nun dachte ich ich könnte mehrere RS232 Schnittstellen mit dem Prozessor über die normalen IO Pins durchschalten. Eine Messung der IO Leistung gibt bei mir aber nur eine Frequenz von 10kHz und das obwohl der Prozessor mit 8Mhz takten sollte (intern laut Fuse Bits) Mit 10khz kann ich ja nichmal eine 38400Baud Schnittstelle übertragen? Hat jemand ne idee ob das so nicht geht? Bei einem 8Mhz Prozessor sollte doch eine Übertragung von ein paar Seriellen Schnittstellen kein Problem sein. Ich messe am Porte.0 Hier mein Testprogramm mit Basecom: $regfile = "m128def.dat" ' test Geschwindigkeit Config Porta = Input Config Portb = Input Config Portc = Output Config Portd = Output Config Porte = Output Dim In1 As Bit Dim In2 As Bit Dim In3 As Bit Dim In4 As Bit Dim In5 As Bit Dim In6 As Bit Dim In7 As Bit Dim In8 As Bit Dim In9 As Bit Dim In10 As Bit Dim In11 As Bit Dim In12 As Bit Dim In13 As Bit Dim In14 As Bit Dim In15 As Bit Dim In16 As Bit 'Start Schleife Do ' Eingang einlesen In1 = Pina.0 In2 = Pina.1 In3 = Pina.2 In4 = Pina.3 In5 = Pina.4 In6 = Pina.5 In7 = Pina.6 In8 = Pina.7 In9 = Pinb.0 In10 = Pinb.1 In11 = Pinb.2 In12 = Pinb.3 In13 = Pinb.4 In14 = Pinb.5 In15 = Pinb.6 In16 = Pinb.7 'Werte ausgeben Portc.0 = In1 Portc.1 = In2 Portc.2 = In3 Portc.3 = In4 Portc.4 = In5 Portc.5 = In6 Portc.6 = In7 Portc.7 = In8 Portd.0 = In9 Portd.1 = In10 Portd.2 = In11 Portd.3 = In12 Portd.4 = In13 Portd.5 = In14 Portd.6 = In15 Portd.7 = In16 Toggle Porte.0 Loop End
Das wäre vermutlich wesentlich schneller, wenn du nicht jedes Bit einzeln speichern und übertragen würdest.
1 | ' Eingang einlesen |
2 | In1 = Pina.0 |
3 | In2 = Pina.1 |
4 | In3 = Pina.2 |
5 | In4 = Pina.3 |
6 | In5 = Pina.4 |
7 | In6 = Pina.5 |
8 | In7 = Pina.6 |
9 | In8 = Pina.7 |
10 | In9 = Pinb.0 |
11 | In10 = Pinb.1 |
12 | In11 = Pinb.2 |
13 | In12 = Pinb.3 |
14 | In13 = Pinb.4 |
15 | In14 = Pinb.5 |
16 | In15 = Pinb.6 |
17 | In16 = Pinb.7 |
18 | |
19 | |
20 | 'Werte ausgeben |
21 | Portc.0 = In1 |
22 | Portc.1 = In2 |
23 | Portc.2 = In3 |
24 | Portc.3 = In4 |
25 | Portc.4 = In5 |
26 | Portc.5 = In6 |
27 | Portc.6 = In7 |
28 | Portc.7 = In8 |
29 | Portd.0 = In9 |
30 | Portd.1 = In10 |
31 | Portd.2 = In11 |
32 | Portd.3 = In12 |
33 | Portd.4 = In13 |
34 | Portd.5 = In14 |
35 | Portd.6 = In15 |
36 | Portd.7 = In16 |
Nach was langsameres um einen 8-Bit Port komplett einzulesen ist dir nicht eingefallen?
1 | PortC = PinA; |
2 | PortD = PinB; |
> Eine Messung der IO Leistung gibt bei mir aber nur eine Frequenz > von 10kHz und das obwohl der Prozessor mit 8Mhz takten sollte > (intern laut Fuse Bits) Auch ein Porsche fährt mit angezogener Handbremse nicht schneller als 30.
Man könnte die Bits in einem Array speichern um es NOCH langsamer zu machen.
Versuchs mal mit Assembler. Schliesslich rennt ein 100m Läufer auch nicht mit Sicherheitsschuhen für Waldarbeiter. Gruß, Udo
Na ja, aber unabhängig von Basic oder nicht, ist eine Software-UART gar nicht so trivial, höhere Baudraten kann man da ohne Interrupts vergessen. Nicht umsonst gibt es Controller mit mehreren Hardware-Uarts. Aber soweit ich weiß, hat Bascom dafür doch eine fertige Funktion. Was tut die denn, und was sagt die Doku zur max. Baudrate und der maximalen Anzahl? Oliver
Wenn ich den TE richtig verstanden habe, möchte er Software-UARTs erstellen. Ein Testprogramm, das bitweise liest und schreibt, scheint zur Abschätzung nicht völlig ungeeignet. Ungeeignet erscheint mir das Tool, das er sich für den Job ausgesucht hat.
Oliver schrieb: > Na ja, aber unabhängig von Basic oder nicht, ist eine Software-UART gar > nicht so trivial, höhere Baudraten kann man da ohne Interrupts > vergessen. Nicht umsonst gibt es Controller mit mehreren Hardware-Uarts. Es gaht ja gar nicht um eine Software UART. Es geht einfach nur darum einen Eingangsport komplett auf einen Ausgangsport durchzuschalten. Was die Pegel bedeuten interessiert in diesem Beispiel nicht. Wahrscheinlich wird er da jetzt noch eine Schaltfunktionalität hinzufügen wollen, mit der er einzelne Kanäle abschalten kann. Interessant wird es auch, wenn er dann einen 'Kreuzschienenverteiler' machen will.
Der AVR ist nicht so der Bitschubser, d.h. bei Bitmanipulationen im SRAM siehts stockfinster aus. Da mußt Du besser nen 8051 nehmen (z.B. AT89LP4052), der hat 128 Bitvariablen (= 16 Byte) im SRAM. Und Bascom dürfte gegenüber C oder Assembler nochmal nen ordentlichen Overhead haben. Was soll das überhaupt werden? Wenn man das weiß, gibts bestimmt auch deutlich effizientere Lösungen. Peter
Hallo, wow hier ist ja was los. So viele Antworten hatte ich nicht erwartet. Für kleine Lösungen haben ich immer Basecom genommen. Allerdings hatte ich bisher nichts zeitkritisches. Komme halt vom Sinclair ZX81 und da war halt Basic drauf. Es sollte eine RS232 Kreuzschiene werden. 8 x 8 Da habe ich mir gedacht das es bei 8 Mhz doch gehen müsste ohne großen Jitter. Habe hier ein IC gefunden - vielleicht funktioniert so was besser. http://www.analog.com/en/switchesmultiplexers/digital-crosspoint-switches/ad8150/products/product.html
Man sollte möglichst keine Bitvariablen nehmen. Um einzelne Bits einer Varible zu handeln kann man auch folgendes schreiben: Bsp.: dim in as byte <- hier sind die Ports 8 Bit-Variablen Portd.3 = in.4 <- Bit 4 der in-Variable Selbstverständlich auch in 16Bit möglich.... Anselm p.S.: Jeder deiner Bitvariablen wird intern als 8Bit behandelt, welch eine Verschwendung.
Btw.: Kann ein XMega nicht DMA? Wenn ich es richtig weiss kann man da ohne den Prozessorkern zu belasten einen Port auf den anderen umleiten.
Ein AVR sollte eigentlich auch schnell genug sein. Aber nicht, wenn man so wie oben einzelne Bits umschaufelt...das ist ja grausam.
Wobei die Aufgabenstellung nicht uninteresant ist. Wie macht man einen frei konfigurierbaren Kreuzschienenverteiler in Software, der auch noch möglichst schnell ist.
8 Signale eines Ports auf 8 Signale eines anderen Ports beliebig abzubilden, braucht im günstigsten Fall der mir einfällt 19 Takte. Dazu müssen aber die Positionen als "1" Bits in verschiedenen Registern (z.B. r16-r23) bereitliegen:
1 | in XL,inport ;1 |
2 | clr XH ;1 |
3 | sbrc XL,0 ;1/2 |
4 | or XH,r16 ;1 Ausgangskonfiguration für Eingang 0 |
5 | ... |
6 | sbrc XL,7 ;1/2 |
7 | or XH,r23 ;1 Ausgangskonfiguration für Eingang 7 |
8 | out outport,XH ;1 |
Mit Sprung wären das dann 21 Takte, das wären ungefähr 380KHz Abtastrate bei 8MHz Taktfrequenz. Jörg
So - nachdem sich viele aufgeregt habe das das einlesen besser mit Byte passieren soll habe ich ich mal ausprobiert. Nun messe ich ca 20khz Ist immerhin eine Verdopplung der IO Leistung. ' Eingang einlesen In1 = Porta In2 = Portb 'Werte ausgeben Portc.0 = In1.0 Portc.1 = In1.1 Portc.2 = In1.2 Portc.3 = In1.3 Portc.4 = In1.4 Portc.5 = In1.5 Portc.6 = In1.6 Portc.7 = In1.7 Portd.0 = In2.0 Portd.1 = In2.1 Portd.2 = In2.2 Portd.3 = In2.3 Portd.4 = In2.4 Portd.5 = In2.5 Portd.6 = In2.6 Portd.7 = In2.7 'Messausgang für IO Leistung Toggle Porte.0
Hi ZX81 hatte ich auch mal und da ging es nur schnell, wenn man die Z80 Hex-Codes in den Speicher "gepoked" hat. Assembler ist gar nicht so schwer.... und viel scheller wie Basic. Außerdem siehst du dann auch was du machst. Es wär dir aufgefallen, wie du die Bits einzeln auf den Port schreibst. Gruß oldmax
Das ist am schnellsten mit ner Tabelle: Jeder Ausgang hat 8 mögliche Eingänge, d.h. für 8 Ausgänge braucht man 64 Tabellen a 256 Byte = 16kB. Ein ATmega32P reicht dann. Peter
Könnte man in Bascom nicht einfach Portc = Pina schreiben ? das kopiert 8 Bits auf einmal. Kenne Bascom aber aber nicht, und die genaue Aufgabenstellung ist auch unklar.
doc schrieb: > Könnte man in Bascom nicht einfach > > Portc = Pina > > schreiben ? das kopiert 8 Bits auf einmal. > > Kenne Bascom aber aber nicht, und die genaue Aufgabenstellung ist auch > unklar. Die genaue Aufgabenstellung lautet, dass während dieser Umkopieraktion die Bits auch noch systematisch umgeschaufelt werden müssen. Und das macht das ganze dann etwas komplexer, wenns schnell sein soll.
>Es geht einfach nur darum einen Eingangsport komplett auf einen >Ausgangsport durchzuschalten. In seinem Beispiel wird nur Port A nach Port C , und Port B nach Port D geschaufelt. Also geht es ganz einfach Byteweise.
@Peter: allein bei einer 1:1 Zuordnung braucht es schon 40320 Bytes in der Tabelle (8*7*6*5*4*3*2*1). Jörg
Für eine 8zu8-Zuordnung reicht doch eine Tabelle mit 256 Bytes. Diese müsste halt im RAM liegen und dann je nach gewünschter Zuordnung neu erstellt werden.
Stefan Ernst schrieb: > Für eine 8zu8-Zuordnung reicht doch eine Tabelle mit 256 Bytes. Diese > müsste halt im RAM liegen und dann je nach gewünschter Zuordnung neu > erstellt werden. Stimmt, die Tabelle muß im RAM liegen. Dann ist die Durchlaufzeit:
1 | loop: |
2 | in yl, PINA |
3 | ld yl, y |
4 | out PORTB, yl |
5 | rjmp loop |
= 6 Zyklen = 666kHz bei 8MHz Peter
@Jörg, erlär mir mal bitte wie Du auf diese Lösung kommst??? Wenn es darum geht eine feste Verdrahtung dür jeden der 256 Inputwerte zu haben reicht die 256Byte Tabelle. Wenn allerdingsabhängig von unbekannten Faktoren abhängt wie die Zuordnung zu den Ausgangswerten sein soll, dann hängt es von der Anzahl an möglichen Kombinationen der Faktoren ab vieviel Platz du für dann n Tabellen benötigst. Aber nochmal, wenn der OP vor 25? Jahren Basic gelernt hat, dann kann er sich doch nach so langer Zeit mal an was neues wagen. Nicht soviel Angst vor Assembler. C plus die C Eigenarten bei Controllerprogrammierung ist meiner Meinung nach viel schwieriger, ausser man kann schon C perfekt. Gruß, Udo
Hallo, es ist ja nur ein Testbeispiel. Es sollten später jeder Eingang mit jedem Ausgang verbunden werden können. Das würde ich schon hin bekommen - über Variablen. Der Test sollte mir zeigen das ich keine Probleme bekomme und hat mir aber genau das Gegenteil gezeigt. Nun habe ich hier mehrere Anregungen und bin noch am überlegen was ich als nächstes ausprobiere. Basecom und ATmega128 scheint nicht schnell genug zu sein. 1. Ich bleibe beim ATmega und versuche mich in Assembler 380KHz Abtastrate wie einer genannt hatte würden hoffentlich ausreichen. Wobei ich glaube dann hätte ich maximal einen Fehler von 10% Jitter. Ich glaube 1% ist nur erlaubt?? 2. Ich bestelle ein spezielles IC wie zB: http://www.analog.com/en/switchesmultiplexers/digital-crosspoint-switches/ad8150/products/product.html Scheint aber keiner Erfahrungen damit zu haben und keine Ahnung wo ich das her bekomme. 3. Ich besorge mir alles für einen CPLD. 5 bis 10 ns sind bestimmt schnell genug und benutzte den AtMega nur zur Steuerung. Vielleicht hat da jemand einen guten Link mit Infos wie man da am besten vorgeht.
doc schrieb: >>Es geht einfach nur darum einen Eingangsport komplett auf einen >>Ausgangsport durchzuschalten. > > In seinem Beispiel wird nur Port A nach Port C , und Port B nach Port D > geschaufelt. > > Also geht es ganz einfach Byteweise. Du musst auch das Fernziel im Auge haben. Und das Fernziel ist nun mal ein Kreuzschienenverteiler. Und den kriegst du mit Byteweise Kopieren nicht hin.
@ Frank T. (Gast) >1. Ich bleibe beim ATmega und versuche mich in Assembler >380KHz Abtastrate wie einer genannt hatte würden hoffentlich ausreichen. >Wobei ich glaube dann hätte ich maximal einen Fehler von 10% Jitter. >Ich glaube 1% ist nur erlaubt?? Kommt auf die Baudrate an. 9600 Baud sind kein Problem, 115200 kann man da vergessen. Ich würde den AVR generell vergessen. Das ist schlicht der falsche Ansatz. >2. Ich bestelle ein spezielles IC wie zB: Naja, ist halt was exotisches, schwer zu bekommen. >3. Ich besorge mir alles für einen CPLD. 5 bis 10 ns sind bestimmt >schnell genug Selbst der langsamste CPLD den die Welt je gesehen hat kann das. Da reicht auch die 15ns Version. > und benutzte den AtMega nur zur Steuerung. Tu das. >Vielleicht hat da jemand einen guten Link mit Infos wie man da am besten >vorgeht. http://www.mikrocontroller.net/articles/Programmierbare_Logik Mal peilen. Für die 8 Ausgänge braucht man 8 8:1 Muxe, das schafft eine Makrozelle. Für die Selektion braucht man 3 Bit, sprich 3 Makrozellen. Wenn man das seriell laden will/muss ohne die aktuelle Konfiguration zu stören, braucht man nochmal je drei Bit, sprich Makrozellen. Macht in Summe 7 Makrozellen/Kanal = 56 Makrozellen. Also tuts ein 64 oder 72 Makrozellen CPLD. Der XC9572XL ist dein Freund. http://www.reichelt.de/?;ARTICLE=40158 MfG Falk
>Und das Fernziel ist nun mal ein Kreuzschienenverteiler. Und den kriegst
okay, hatte ich übersehen.
Falk Brunner schrieb: > Kommt auf die Baudrate an. 9600 Baud sind kein Problem, 115200 kann man > da vergessen. Hab ich doch oben gezeigt, geht prima in Assembler. Das Delay ist <10% Bitzeit, auf 10 Bits gerechnet <1% Baudratenfehler, also voll im grünen Bereich. Das Delay akkumuliert sich ja nicht. Natürlich kann der AVR nichts anderes machen, also einfach nen AVR dafür abstellen, z.B. ATmega48. Die Einstellungen kriegt er über I2C gesagt. In der Regel ist ein AVR kleiner, billiger und stromsparender als ein CPLD. Der einzige Nachteil zum CPLD ist, daß wärend des Umschaltens zum Berechnen der neuen Tabelle alle 8 Kanäle kurzzeitig unterbrochen sind. Peter
Hi! >Nun dachte ich ich könnte mehrere RS232 Schnittstellen mit dem Prozessor >über die normalen IO Pins durchschalten. Man beachte das RS232 eigentlich bidirektional ist, die Gegenrichtung also auch noch mit verbunden werden muss, und wenns ganz verrückt wird: In1->Out3 / In5->Out1 Das ist dann schon richtig hohe Schule wenn es über einfache Bitschubbserei gehen soll. Mein Ansatz wäre da eher: mehrere kleine AVRs(8) mit Hardwareschnittstelle und ein Master zum Verteilen(SPI/I2C oder wenn ganz schnell, paralell) Ein Haken wäre allerdings, die Baudraten. Obwohl, die könnte der Master eigentlich auch mit übergeben. Na dann, Viel Spass, Uwe
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.