Testplatine für serielle/parallele Daten

Gar kein Interesse?

Vielleicht so übersichtlicher mit Schaltplan?

Das Ding hat einfach einen USB-Port, 4 StatusLEDs, Power-LED, Taster zum 
Umschalten des Zustands, parallel Port über Pfostenleiste, serielle 
Ports (CLK, DATA, Trigger)

Idee war einfach, eine möglichst kompakte Platine zu erfinden, welche 
"irgendwelche" seriellen Daten ausgibt. Letztendlich ist die 
Programmierung ja so individuell, wie man es gerade eben braucht.

Ich persönlich benötige einfach nur die Möglichkeit, zu Test- und 
Diagnosezwecken, mal SPI oder mal I2C oder auch mal USART Daten zu 
erhalten. Ob das Modul nun immer nur einen festen String sendet, oder 
sogar Daten, die über USB empfangen werden, bleibt ja dem Programmierer 
selbst überlassen. Und ob diese kontinuierlich gesendet werden, oder nur 
beim Tastendruck, oder wie auch immer, ist ja auch eine Programmsache. 
Daher ein Taster und 5 Status-LEDs...

Und um am Arbeitsplatz ohne zusätzliche Verkabelung, vielleicht sogar 
noch einer zweiten Spannung, zum Ziel kommt, der USB-Port zur 
Spannungsversorgung. Die meistens digitalen Oszis, die auf dem 
Arbeitsplatz stehen, haben ja inzwischen eh USB.

Michael Stumpf wrote:
> Idee war einfach, eine möglichst kompakte Platine zu erfinden, welche
> "irgendwelche" seriellen Daten ausgibt. Letztendlich ist die
> Programmierung ja so individuell, wie man es gerade eben braucht.


Das interessante an so einem Prokjekt wäre ja gerade die Software 
gewesen und das Userinterface.

So ist es ja nur ein MC (noch dazu ein PIC) mit Anschlüssen, der nichts 
kann, da keine Software drin ist.

Das gleiche kann ich doch mit dem STK500 machen, da habe ich auch nen MC 
drauf und die Anschlüsse rausgeführt.
Aber ich kann ihn in C programmieren, ohne ne neue CPU lernen zu müssen 
und ne neue Entwicklungsumgebung kaufen zu müssen.
Mir ist auch die UART viel sympatischer, da kann man direkt ein 
Terminalprogramm aufrufen, muß also keine extra PC-Software schreiben.


> Die meistens digitalen Oszis, die auf dem Arbeitsplatz stehen, haben ja
> inzwischen eh USB.

Wenn es ne neue Firma ist vielleicht.
Aber in der Regel haben Techniker keine Zeit, ständig neue Geräte lernen 
müssen und benutzen sie daher, bis sie auseinanderfallen.
Mein Tektronics hat nur RS-232 und IEE-488.


Peter


P.S.:
Es erging mir auch so wie Stefan, mit dem 1. Post kann wirklich keiner 
was anfangen (alles so schön bunt hier).

Peter Dannegger wrote:
> Das interessante an so einem Prokjekt wäre ja gerade die Software
> gewesen und das Userinterface.
> So ist es ja nur ein MC (noch dazu ein PIC) mit Anschlüssen, der nichts
> kann, da keine Software drin ist.

Ja, aber das Stück Software zu schreiben ist ja wahrlich keine Kunst...
Was heißt denn "noch dazu ein PIC"? Ich persönlich finde das Konzept von 
Microchip inzwischen (das mag anders gewesen sein früher) deutlich 
besser, als das von Atmel z.B.... Und der 24/7-Support von Microchip ist 
wirklich manchmal Gold wert!

> Das gleiche kann ich doch mit dem STK500 machen, da habe ich auch nen MC
> drauf und die Anschlüsse rausgeführt.

Aber dann ist das Ganze nicht so kompakt und innerhalb weniger Sekunden 
einsatzbereit und braucht immer noch eine Stromquelle, Platz auf dem 
Arbeitsplatz, jedes mal neues Flashen der Firmware (weil ja sicherlich 
das STK auch für was anderes verwendet wird), ...
Alleine nur wenn man 3-4 Mal serielle Daten braucht, ist doch der 
Aufwand, jedes Mal Kabel anzuschließen, irgendein Board rauszukramen, 
MCU flashen, ... bestimmt 10-15 Minuten. Dann hat man die paar Euro so 
eines "USB-Sticks" schon mehrfach wieder raus...

> Aber ich kann ihn in C programmieren, ohne ne neue CPU lernen zu müssen
> und ne neue Entwicklungsumgebung kaufen zu müssen.

Für die Microchip-MCUs gibts auch einen C Compiler...

> Mir ist auch die UART viel sympatischer, da kann man direkt ein
> Terminalprogramm aufrufen, muß also keine extra PC-Software schreiben.

Ist UART nicht genormt? Mit einem Terminalprogramm kann man doch auch 
"nur" einzelne Bytes an den seriellen Port senden. Nur ist das ganze ja 
nicht gedacht, um an den PC Daten zu senden, sondern für's Prototyping 
"mal eben" Daten zu haben...

> Wenn es ne neue Firma ist vielleicht.
> Aber in der Regel haben Techniker keine Zeit, ständig neue Geräte lernen
> müssen und benutzen sie daher, bis sie auseinanderfallen.

Na OK... Aber die (brauchbaren) Geräte, die heutzutage angeboten werden, 
haben ja fast alle USB...

> P.S.:
> Es erging mir auch so wie Stefan, mit dem 1. Post kann wirklich keiner
> was anfangen (alles so schön bunt hier).

Muss ich zugeben, war nicht allzu übersichtlich...


michael

Toll. Wär's mit Mega32, dann hätte ich Dir vermutlich ein solches Modul 
abgenommen. Aber PIC muss nicht sein, da müsste ich ja wieder bei Null 
beginnen.

...

Ich hab mir mal überlegt, ob sich sowas jemals gebraucht hätte und muß 
leider  nein sagen.


Wenn ich SPI oder I2C verwende, dann habe ich ja immer auch schon einen 
MC aufm Board und da wäre es doch Blödsinn noch extra einen ranzupappen.

Und da ich seit etwa 1999 nur noch MCs verwendet, die ich downloaden 
kann, ist es auch kein Problem, erstmal nur ein Testprogramm 
einzuspielen.


Peter

A.K. wrote:
> Praktischerweise hat der FT2232C das alles drin. SPI,I2C,UART. Auf dem
> PC programmierbar. In Form vom ARM-USB-JTAG kommt da auch noch Strom für
> die angeschlossene Schaltung raus, vom Chip her oder als Modul DLP2232M
> (FTDI Shop) kann man auch Bus-Bausteine wie SJA1000 anschliessen.

An sich logisch. Aber kann man auf dem FT2232C auch Software autonom vom 
USB laufen lassen? Wenn man den USB-Port wirklich nur als 
Stromversorgung nutzt, muss das Ding ja auch irgendwie von alleine 
nutzen...

Peter Dannegger wrote:
> Wenn ich SPI oder I2C verwende, dann habe ich ja immer auch schon einen
> MC aufm Board und da wäre es doch Blödsinn noch extra einen ranzupappen.

Macht schon Sinn, aber was, wenn ich die Funktionalität des 
Prototypen-Boardes testen möchte, und dafür Daten per I2C oder SPI an 
den einen vorhandenen MC senden möchte?!

Salmonellenbekämpfer wrote:
> Ergänzung:
>
> Sowas geht beim besten Willen nicht (siehe Anhang, gelbe Kästen). Das
> mußt du noch ändern.

Wird gemacht... ;-)

Michael Stumpf wrote:

> Macht schon Sinn, aber was, wenn ich die Funktionalität des
> Prototypen-Boardes testen möchte, und dafür Daten per I2C oder SPI an
> den einen vorhandenen MC senden möchte?!


Dann würde das schiefgehen, da die MCs bei mir der Master sind. Also mit 
irgendwas zum MC hinsenden ist da nichts.

Und zum Debuggen führe ich einfach die UART raus, hat ja jeder MC.


Peter

Peter Dannegger wrote:
> Dann würde das schiefgehen, da die MCs bei mir der Master sind. Also mit
> irgendwas zum MC hinsenden ist da nichts.

Und wenn sich mehrere MCs über I2C oder SPI unterhalten?! Bzw. einzelne 
Baugruppen über I2C/SPI angesteuert werden?!

Severino wrote:
> Ich möchte noch auf den PICkit Serial Analyzer von Microhcip hinweisen,
> der samt Windows-Software daherkommt und ziemlich preiswert ist.
> 
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600
> Vielleicht gibt es die Soft- und die Firmware auch irgendwo zum
> Download, so kann man das Ding dann auch selber bauen.
> (Beim PICkit 1 ist das so).

Oh, den kannte ich noch gar nicht.
Ist ja eigentlich das Gleiche, nur im externen Gehäuse...

sowas ähnliches hab ich auch schon mit dem IOWarrior gesehen:
http://greinert.hopto.org/main/index.php?id=4tgf886kbcgftr857634
hat etwas abweichende funktionen, aber kann auch ein ganz nettes 
Spielzeug sein. (RC5 decoder, displayansteuerung vom chip unterstützt.)
Hier wird allerdings ein PC benötigt.

Michael Stumpf wrote:

> Und wenn sich mehrere MCs über I2C oder SPI unterhalten?! Bzw. einzelne
> Baugruppen über I2C/SPI angesteuert werden?!


Über SPI ist mir zu aufwendig, zu viele Leitungen und nicht Multimaster 
fähig.


Über I2C hab ich schonmal gemacht, aber ist doch recht verzwickt die 
Software (Arbitrierung, Retry, CRC).

Und wenn da jemand zwischenplappern würde, gibts nur Chaos.
Das Einschleifen eines zusätzlichen Masters in einen bestehenden Bus 
geht ja nur dann, wenn man extra dafür ein entsprechendes Protokoll 
implementiert hat.
Daher spare ich mir die ganze Arbeit und lad einfach in den Haupt-MC ne 
Testroutine.


Jetzt nehme ich zum Vernetzen mehrerer MC-Module nur noch CAN (easy 
Software, macht ja alles die Hardware).


Peter