www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mudulare Entwicklungsumgebung: Wer baut mit


Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Mich nervt immer mehr, das ich für neue Projekte immer neue Platinen
entwerfen und neue Software schreiben muß obwohl 80% der Funktionen im
Prinzip immer die gleichen sind (z.B. IO, serielles interface, etc.).
Desshalb werde ich ein modulares Stecksystem auf der Basis von ATMEL
Tiny MUC aufbauen. Ich habe dabei eine Reihe sehr kleiner Platinen (so
ca 5*3cm) im Sinn, die jeweils über einen 8PIN Tiny MUC verfügen und
über einen I2C/TWI-Bus miteinander Verbunden sind. Diese Platinen
können dann beliebig ineinandergesteckt werden. (Spielt also keine
Rolle ob ich 10 oder 100 IO-Kanäle brauchen - solang die Bandbreite
mitmacht)

Das Initalwerk besteht aus folgendem:

- Grundmodule Layouten (das mache ich sobald ich mal wieder ein Bischen
Zeit habe - in meinem Kopf sind die schon fertig)
- Ein einfaches und flexibles high-level Protokoll entwickeln da I2C
soviel ich weiß keine Fehlerkorrektur/Parity funktionen anbietet.
- Die entsprechende Software fuer die Module schreiben.

Folgende Module werde ich als erste Implementieren (auch als
Evaluierungsplattform Gedacht:
- IO Modul mit 2*8 IO Kanälen.
- Stromversorgungs Modul - bestehend aus einem Festspannungsregeler und
ein bischen Stabilisierungskram
- Eine "general purpose" Modul: die verbleibenden 6 PINS des AVR
werden auf eine Steckerleise führt (kann dann alles mögliche sein - von
Display interface bis I2C HUB - ja nach Software).

Ich hoffe das es ein paar Leute interessiert!

Als Fernziel soll ein pool von Modulen (USB, IRDA, RS232, Relaismodule,
Displaytreiber Graphisch/Alphanumerisch...) inclusive Software entstehen
aus dem einfach jeder schöpfen kann. Dann bestehen auch aufwendige
Projekte aus dem Anpassen von wenigen Softwareteilen und
Zusammenstecken von ein paar Modulen.

Was ich mir von diesem Forum erwarte ist eine sachliche Diskussion über
Mögliche highlevel Protokoll um einen I2C Dynamisch adressierbar und mit
Fehlerkorrektur zu bekommen sowie am besten einen Haufen
Hardwaredesigner die Berge von Modulen entwickeln und Software dafür
schreiben soweit die Spezifikationen stehen.

Gruß

Dom

P.S.: Ich will keine standard I2C IO Bausteine verwenden, da diese
extern ihre Adresse angelegt haben wollen - ich will den Bus jedoch mit
Dynamischen adressen.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An so etwas ähnlichem bastle ich schon eine Weile - leider z.Zt.
eingestellt wegen zeitmangels.
Meine Idee basiert auf einem Interface für Funktionsmodelle
(fischertechnik), auch vernetzt mit I²C. Da es Probleme mit der
Bandbreite gibt, wenn man viele Zähleingänge für Positionsgeber
verwendet, soll jedes Modul diese Zähleingänge selbst verwalten, d.h.
es werden nur die Soll-Positionen per I²C gesendet, das Modul macht den
Rest (Motorsteuerung + Impulse zählen). Die Module bauen auf den Mega-8
auf und stellen 4 Motor-Ausgänge + 8 Eingänge zur Verfügung.

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
was soll so ein system denn an effektiven nutzen bringen?
wenn ich einen µC irgendwo einsetzten will dann hat das ding eine
aufgabe und die passenden schittstellen in die realität.
Um die ganze geschichte für den endverbraucher so günstig wie möglich
zu machen wird halt ein kleines PC entwickelt wo je nach anwendungsfall
auch nur das oben ist was man braucht.
In spezialfällen habe ich schon paltinen mit 2 bestückungsvarianten
gemacht, aber ein modulares system ist doch totaler overkill. Man hätte
dann 2 mal einrichtungskosten für eine maschiene beim bestücker, 2mal
test und verpackung 2x pcb .... und dann der mehrauffwand bei der SW.
So kann man je nach andendungsfall eine passende MCU auswählen.

MfG
Sebastian

Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Also der Sinn besteht darin kleine Steueraufgaben kostengünstig und
einfach zu implemtieren.
Beispiel: ich will ein 8 Füßigen Laufrobotter bauen. Ergibt
beispielsweise ein IO Modul für generelles Zeug wie kollisonsmelder etc
und 16 PWM kanäle für die Aktoren (2 Achsen pro Bein), ein Display als
userinterface und dann noch n paar Tasen zum interagieren.
Natürlich kannst Du das alles auf eine Platine bauen - ist aber höchst
unflexibel. Wenn Du es modular aufbaust ist es nachher Wurscht ob Dir
noch einfällt das Du ja eigentlich noch nen Gelenkt an jedem Fuß haben
willst - dann steckst Du halt nochmal n paar PWM -Kanäle drauf.

Zu den Kosten:
Ich gehe mal davon aus das ich ca. 15 Module auf eine Europlatine
bekomme. Wenn ich die bei PCB pool äzen lasse kostet das 50EUR - selbst
wenn ich alle Module für ein Projekt brauche (was relativ unrealistisch
ist) ist das mit Bauteilen immer noch 2-4 mal billiger als nen PC zu
nehmen (und viel kleiner).

Ich stell mir das so vor das eben später der Nutzer eine Palette von
Layouts im Internet angeboten bekommt und einfach die die er braucht
auf eine Platine packt und diese zum Äzen bringt (so a la cut n paste).

Ich gehe übrigens von einem Preis von 5-8 EUR (je nach Modul) aus -
teurer darf das nicht werden.

Gruß

Dom

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du schreibst du willst ein modul für ca 5-8 euo anbieten wäre das
ja in der summe auch nicht viel günstiger wenn man 4 karten baucht.
ich gehe mal davon aus wenn ich platz für 1/2 eurokarte habe bekomme
ich problemlos 2 Mega128 inkl. 2x uart 4-8 analog in mit jumper 0-10V
oder 4-20mA. Spannungsregler und pegelwandler. und aller noch benötiger
perepherie. man kann ja ein PCB von oben und unten mit Smds bestücken,
und ich habe dann immer noch ein flexibles Board, eventuel igendwann
benötigte HW kann ich per Uart, SPI und I2C anbinden. Und selbst in
diesem fall braucht man auf dieses Board nur das bestücken was man
wirklich braucht.
Was nützt es wenn ich 5 leiterplatten habe mit den ich alles machen
kann, es aber viel overzize in der SW kostet und dann noch mechanisch
zum problem wird.

Sebastian

Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dazu kann ich nur sagen das ich einfach die Erfahrung gemacht habe das
ein Monolithischer Ansatz wie Du ihn favorisierst funktioniert aber
eben einfach unfelxibel ist. Du kannst unmöglich alle eventualitäten
auf Deinem Board im Voraus einplanen. Was passiert wenn Du mit dem PC
drauf zugreifen willst und eine RS232 Schnittstelle implementierst und
dann doch USB oder IRDA willst - dann kannst Du Dein Board schlicht
wegschmeißen.
Natürlich haben modulare Konzepte einen overhead (schau Dir den Linux
Kernel an). Der Vorteil ist aber das sie immer genau so groß sind wie
man sie braucht und erweiterbar sind.

Ich möchte die Diskussion über dieses Thema hier eigentlich beenden -
wenn Du mit Deinem Ansatz glücklich bist freut mich das - ich bin es
nicht und ich werde diese Hardware genau so entwickeln - mir geht es
eigentlich nur um Input/Feedback zum Thema Protokoll und Leute die
Software für die Module schreiben wollen.

Gruß

Dom

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite auch an so etwas (was'n dingen) habe aber
bisher noch keinen passenden Bus dazu gefunden. Einen
seriellen Bus zu verwenden finde ich schon gut. In der
Regel benötigt man keine besonders große Geschwindigkeit
für die Module untereinander. Aber I2C finde ich nicht
so witzig da ich das ganze recht variabel halten möchte
(auch mal 2 oder 3 gleiche Komponenten anschließbar) und
die I2C IDs ja nicht unbegrenzt zur vefügung stehen. Man
möchte ja auch einmal einen simplen LM75 anschliessen
können ohne sich mit seinen eigenen Komponenten in die
Quere zu kommen.
Bei mir wirds aber wohl kein Amtel sondern ein PIC system,
aber bei gleichen Bus macht das ja gar nichts.

Gruß Martin

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe es auch so, das haarigste an der Sache ist die
Vernetzungssoftware. Ich kann aus eigener Erfahrung sagen, das ist
nichts für Anfänger.


Ehe du also umsonst viele Module entwickelst, würde ich empfehlen,
erstmal ein paar Chips auf eine Lochrasterplatine draufpappen und die
Software zum Laufen zu bringen.


Die 8-Pinner sind außerdem ware Einzelkämpfer, sie haben einfach zu
wenig Ressourcen, um nebenher noch ein Protokoll zu fahren.
Das Minimum für eine einigermaßen stabile Vernetzung dürfte der Mega8
sein.

Als Hardware entweder I2C oder die UART.
Um mit der UART das Protokoll einfach zu halten, bietet sich die
Ringschaltung an (TXD an RXD des nächsten usw.), dann gibts keine
Kollisionen.


Peter

Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Danke Martin und Peter für die Anregungen

Zu Martin: Der i2c adressraum ist 7 (bzw. 11) Bit - das sollte
meinermeinung nach völlig ausreichen - die Bandbreite wird
warscheinlich viel früher einen Strich durch dir Rechnung machen.
Standard ics kannst Du natürlich noch anschließen - Du must eben nur
drauf achten das sich die Adressen nicht beißen. (Das high level
Protokoll das ich angesprochen habe ist ja nicht zwingend - es dient
nur dazu eine Fehlerkorrektur anzubieten (wenn man sie braucht) und die
Adresse abzuändern bei den Devices die es unterstützen.
Wenn Du das ganze auf PIC basis machen willst ist das kein Problem (ist
eher von vorteil - wird das ganze vielseitiger). Wir sollten uns dann
über das BUS-System (ich favorisiere klar I2C), Protokoll und
Stecksystem klar werden - dann sollten PICs und AVRs problemlos
zusammenarbeiten.

Zu Peter:
Du hast recht - ich hab gerade nochmal ne weile gelesen und es sieht so
aus als ob ein Tiny ohne großen codeoverhead nicht als I2C slave
functioniert ( http://www.avrfreaks.net/Tools/showtools.php?ToolID=77 )
-> also megaavr (ich hab mir da mal den Mega8 angeschaut). Das sollte
von größe (tiny *2) + preis( 3EUR) her immernoch akzeptabel sein.
Zu der Software: Ich bin kein Anfänger (keine Angst ;-) und ich hab mir
auch schon grob ein paar protokolle überlegt - ich will hier nur eine
fruchtbare Diskussion anzetteln um solches nette feedback wie von Euch
zu bekommen.

Gruß

Dom

Autor: Andreas Auer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi.

Also ich find die Idee interessant!! Mich nervt es auch, wenn ich ne
Schaltung bauen will und ich muss ständig irgendwo auf Lochraster oder
Steckboard meine Peripherieschaltung aufbauen, weil auf dem
Mikrocontroller Board das Zeug einfach nicht drauf ist. Find also die
Idee super - vorallem im Entwicklungsstadium von Projekten sollte sowas
hilfreich sein!

Was mich ein bisschen "beunruhigt" ist, dass manche Module (z.B. USB)
ja wesentlich schneller sein werden, als der I²C Bus das erlauben wird.
Bei anderen Modulen (z.B. IO Modul) wäre das natürlich wieder was
anderes. Hier werden hohe Geschwindigkeiten meist nicht gebraucht ->
also ohne weiteres I²C möglich.

Als zentralen uC würde ich demnach einen nehmen, der ein externes SRAM
erlaubt - irgendeinen in Richtung Mega162, oder so!
Dann könntest neben deinem I²C BUS System auch den externen Memory Bus
verwenden und per Memory Mapped Mode einige Module implementieren. Der
Vorteil daran liegt, dass du Module mit höherer Geschwindigkeit (USB,
Compact Flash, ...) auch einfach dranstecken kannst und keinen
Geschwindigkeitsverlust durch das Protokoll hast!

mfg
Andreas

--
Andreas Auer            aauer1 (at) sbox.tugraz.at
Student of Telematics   http://home.pages.at/aauer1
Graz, University of Technology

Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas

Also da bin ich völlig offen. Der Bus ist als reiner Kommandobus
gedacht (ein MP3 player beispielsweise wird dann zwangsweise noch
zusätzlich einen schnellen Datenbus benötigen) das userinterface und
konfiguration von decoder etc. kann man aber problemlos so managen.

Was den MCU angeht steht es jedem völlig frei jeden erdenklichen
kontroller zu verwenden - solange er I2C spricht. Mir geht drum mal
eine guideline zu entwickeln wie das Stecksystem aussehen muß und eben
ein einfaches Protokoll mit fehlerkorrektur und dynamischen adressen.

Gruß

Dom

P.S.: Ich hoffe das ich am Wochenende dazu komme mal ein paar designs
zu machen das Ihr mal ne Idee bekommt wie das Stecksystem für mich
aussehen sollte.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"...Tiny ohne großen codeoverhead nicht als I2C slave
functioniert..."

Als nur Slave müßte auch der Tiny26 gehen (habs nicht probiert), der
hat ja Start-Stop-Erkennung und ein Byte-Schieberegister.

Als Master geht der Tiny26 nicht bzw. dann wieder zu Fuß, jede
Taktflanke in Software.


@Martin,

welchen PIC hast Du denn für die Slaves geplant ?


Peter

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominic:
<Zitat>
Zu Martin: Der i2c adressraum ist 7 (bzw. 11) Bit - das sollte
meinermeinung nach völlig ausreichen - die Bandbreite wird
warscheinlich viel früher einen Strich durch dir Rechnung machen.
Standard ics kannst Du natürlich noch anschließen - Du must eben nur
drauf achten das sich die Adressen nicht beißen
</Zitat>

Genau bei dem "Adressen nicht beißen" habe ich bei i2c ja das
Problem wenn ich mit vorgefertigten Bausteinen arbeiten will.
Nehmen wir einmal an das ich mit einem DIP8 PIC eine kleine Platine
mit 4 PWM Ausgängen baue (der PIC im DIL8 Gehäuse hat max
6 I/O Leitungen frei, 4 PWM + 2 Bus passt also), dann soll das Ding
einmal komplett fertig gemacht werden. Mit Programm und allem gedöns.
bei i2c wird dessen slave Adresse also im Programm stehen müssen und
ich kann nicht mehr einfach einmal 2 Module anschliessen (z.B. weil
ich nun doch mehr PWMs brauche) sondern muß den Modulen
unterschiedliche Programme geben (wegen den adressen) oder irgendwie
aufwendig eine Hardwarlösung auf jedem Modul haben mit dem ich die
gewünschte Adresse vorwählen kann und welche sich das Modul beim
start zieht.
Und genau da suche ich etwas schöneres! Any Ideas?

@peter:
egal, was gerade anliegt oder was für die Funktion des Modules
notwendig erscheint. Ich habe keine Probleme damit viele PICs zu
vernetzen, im Gegenteil sehe ich das oft sogar als eine saubere
Lösung an. Es ist manchmal sinnvoller fertige Funktionen in MCs
auszulagern als fertige Routinen so zusammen zu kopieren das sie
ein einem größeren PIC laufen. Wer weis immer welche seiteneffekte
oder
Zeitprobleme man sich da einhandelt. Der einzelne PIC wird seine
Funktion immer sauber durchführen können und lässt sich von anderen
nicht beeindrucken.

Gruß
  Martin

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"bei i2c wird dessen slave Adresse also im Programm stehen müssen und
ich kann nicht mehr einfach einmal 2 Module anschliessen"

-> serielles eprom

Autor: Dominic Buchstaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Martin

Zum Thema Adressen. Wie ich oben schon geschrieben habe muß jedes Modul
eine Funktion bieten (am besten im high level Protokoll verankern) die
interne Adresse zu verändern. Das ist im einfachsten Fall eifach ein if
I2C eingangsregister = 00000000 (Befehl) dann lese nächstet Byte vom bus
und schreibe eingangsregister nach i2c addressregister und EEPROM.

Ich verstehe das so das jedes Modul beim reset erst mal seine Adresse
aus dem EEPROM liest und dieser EEPROM inhalt eben per Kommando
verädert werden kann.

Beim Flashen setzt Du das auf einen Initialwert und "buchst" dann
Deinen Baustein in Dein System ein.

Was natürlich am schönsten wäre wenn sich jede Komponente eine freie ID
sucht und sich dann irgendwo registiert - das ist aber der totale
overkill für den Zweck - dann können wir schon fast mit TCP und DNS
anfangen (also bitte keine Dikussion darüber - ich weiß das man TCP
auch über I2C fahren kann - dann ist der Effektive Datendurchsatz dann
wohl bei 5Kbit oder so).

Gruß

Dom

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hallo Martin

"Ich habe keine Probleme damit viele PICs zu
vernetzen, im Gegenteil sehe ich das oft sogar als eine saubere
Lösung an."

Vor einiger Zeit habe ich hier mal eine komplette Schaltung für ein
Digitalscope mit 12 Bit Auflösung vorgestellt (allerdings mit dem
68HC811E). Das Gerät wird hier im Institut (5 Stück) eingesetzt und
arbeitet auch zu Aller Zufriedenheit.
Deine Idee mit den vernetzten PIC's habe ich in Entwicklung für die
Aufbereitung der verschiedenartigen analogen Daten der 8 Eingangskanäle
(momentan hat jeder Kanal nur einen ordinären Abschwächer mit
Lageregelung).
Um hier sehr flexibel zu sein und extrem kleine Platinchen (ausgelegt
als aktive Tastköpfchen) zu bekommen, werde ich die neuen 5 poligen
SOT23 PIC'S einsetzen. Auf solch kleine Teile warte ich schon lange,
für solche kleinen Aufgaben sind die prima geeignet.

Zu Deinem eigentlichen Entwicklungsvorschlag kann ich nur sagen, daß
eine modulare Konstruktion nur für Grosserien (aus Fertigungsgründen)
lohnt. In meiner langjährigen Praxis ist selten etwas so entwickelt
worden, daß es mit einfachen Umbaumaßnahmen zu übernehmen gewesen
währe. Mit einer Neuentwicklung ging es meistens schneller. Man fängt
ja nicht wirklich ganz neu an (jedenfalls nicht im Kopf, dort baut man
doch auf dem letzten Wissensstand auf). Module machen Sinn wenn sie
immer wiederkehrende Funktionen übernehmen können und das läßt sich ja
auch über einen der seriellen Daten/Adressbusse erledigen. Trotzdem
viel Erfolg für Dein Projekt, ich werde das sicher weiterverfolgen.

MfG  Manfred Glahe
MfG  Manfred Glahe

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"eine modulare Konstruktion nur für Grosserien (aus Fertigungsgründen)
lohnt."

Da kann ich Manfred nur zustimmen.

Ich habe die Modulbauweise nur deshalb gewählt, weil unsere Geräte sehr
kundenspezifisch angepaßt werden und weil ich mir damals noch nicht über
den nötigen Softwareentwicklungsaufwand im Klaren war.

Im Nachhinein hat es sich aber doch gelohnt, die Kundenanpassungen
gehen nun sehr schnell.

Um die Busauslastung gering zu halten, habe ich auch die
Multimastermethode gewählt.

D.h. die Bedien-CPU schickt eine Anfrage an ein Modul und das startet
dann z.B. die AD-Wandlung und schickt das Ergebnis zurück, sobald sie
fertig ist. Es enstehen also keine unnützen Wartezeiten.

Auch können die Module selber Statusänderungen senden, d.h. die
Bedien-CPU muß nicht ständig alle Module abfragen.



Rein von der CPU-Auslastung habe ich noch nie eine Modularisierung als
nötig angesehen. Und zum Verdrahtung sparen und als Porterweiterung
sind die guten alten 74HC595 und 74HC165 bestens geeignet, da beliebig
kaskadierbar.

Es ist immer wieder erstaunlich wieviele Sachen ein einzelner MC
parallel ausführen kann.
Man muß bloß erstmal den geeigneten Programmierstil finden, z.B. alle
Wartezeiten gnadenlos ausmerzen und wieder dem Hauptprogramm als
Rechenzeit zur Verfügung stellen.
Man sieht aber leider viele Programme, die zu 99%..99,9% nur Nichts tun
und dann wird gemeckert, die CPU sei zu langsam.



Peter

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter,

"Man sieht aber leider viele Programme, die zu 99%..99,9% nur Nichts
tun
und dann wird gemeckert, die CPU sei zu langsam."

das sehe ich auch so!

Aber um externe Hardware wie AD/DA oder RAM'S usw. mit maximaler
Geschwindigkeit ansteuern zu können würde ich mir auch bei den
"relativ" langsamen µP's folgende hardwaremäßig implementierte
Funktion wünschen:

Einen setzbaren Zähler der vom Prog den Startpunkt, den Endpunkt oder
die Anzahl der Takte liefert und diese dann mit ebenfalls setzbarer
Taktrate, bis rauf zum Quarztakt, ausführt. Wenn ich also einen
seriellen 12 Bit ADW betreibe, dann wird dieser mit 12 Takten/Anweisung
in Oszillatorgeschwindigkeit ausgeführt. Viele Applikationen (solch eine
Forderung ist heute ja in fast allen Anwendungen drin) müssen das in
externer Logik unterbringen (nicht immer sind CPLD's mit ihrer
schieren Pinzahl die bessere Lösung).
Damit ließe sich auch der SPI Bus erheblich beschleunigen.
Jedenfalls währe mir solche Zusatzfunktion willkommener als irgendein
zusätzlicher exotischer Bus im µP.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will ja auch die die CPU Auslastung durch Verwendung von
mehreren CPUs Modularisieren sondern Module mit verschiedenen
Funktionen erstellen. Egal ob die nun eigene CPUs haben oder nicht.

@Dominic
An den Einsatz des EEProms für die Moduladresse hab ich noch
gar nicht gedacht :-o

Für einen seriellen Lowspeedbus könnte ich mir auch so etwas
vorstellen wie Maxim das bei dem MAX7219 LED Driver macht. Jedes Modul
hat ein Data/Clk und CS Signal, dazu noch einen CS Ausgang der immer
um eins verzögert das CS weiter gibt. Hat man mehrere von den Dingern
werden Data und clk parallel angeschlossen und cs des einen chips
kommt an den cs-ausgang des vorgängers. Jeder Chip kennt einen NOP
Befehl damit man den "überspringen" kann. Damit kann man die Chips
hintereinander beschreiben (fast) egal wie viele da sind.

Gruß
  Martin

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dominic,

gibt's denn schon erste Ergebnisse? Würde mich interessieren.

Stefan

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.