[Erledigt] Serielle Schnittstelle und der Propeller?

Alles zum Thema Hardware rund um die Propellerchips und den Hive.
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von drohne235 »

Naja, die "doppelte" Stromversorgung brauchst du ja eigentlich auch nicht - hab mich schon ein wenig gewundert warum du das so aufgebaut hast. Der Propeller braucht nur 3,3V. Das in einigen Schaltungen noch ein 5V Regler vorgeschaltet ist leigt daran, das es in der Schaltung IC's gibt die mit 5V betrieben werden müssen. Im Hive ist das auch so, dort läuft der Max232, die RAM's und das Adresslatch mit 5V. Aber wenn du nur einen Propeller hast brauchst du natürlich auch nur einen Spannungsregler für 3,3V. Im Zweifelsfall gilt immer die Minimalbeschaltung aus dem Datenblatt welches du bei Parallax findest.

Was ist mit den zustzlichen VDD/VSS-Pins: Hast du mal mit korrekter Belegung getestet?
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
DJLinux

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von DJLinux »

Ich freue mich Euch mitteilen zu können das der Propeller endlich läuft.
Ein funktionierender Comport voraus gesetzt ;)

Die Schaltung mit 3 Transistoren sieht etwas vertrauenswürdiger aus
daher hat sie es verdient im gelötetem Zustand ihr Darsein zu fristen.

Er läuft und läuft und läuft ... (zur Not auch ohne Quartz)

Jetzt kann es endlich los gehen

Grüsse Joshy

PS. drohne235@
ich meinte nicht die 5V Stromquelle, wofür die gut ist ist mir klar.
mit "doppelte" Stromversorgung meinte ich auch die "zusätzlichen" Pins 32,29
Dateianhänge
RS232.JPG
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von drohne235 »

Hey super, halt uns auf dem laufenden! :)

> ich meinte nicht die 5V Stromquelle, wofür die gut ist ist mir klar.
> mit "doppelte" Stromversorgung meinte ich auch die "zusätzlichen" Pins 32,29

Jetzt ist es klar. ;) Aber wenn du grad mal noch einen Steckbrettaufbau hast könntest du mal testen ob die zusätzlichen Pins wirklich belegt sein müssen - nur mal so aus Interesse.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
DJLinux

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von DJLinux »

Hallo Drohne,
Pins 32,29 müssen nicht beschaltet werden
hatte ich auch nie gedacht da dort ja die 3.3V von Pin 9,12 anliegen.

Bei der eigentlich farblichen Grafikdemo sehe ich hier "nur" Gauwerte auf dem TV-Monitor
obwohl ich die passenden Wiederstände "gesteckt" habe.

naja; muss mich erst einmal einarbeiten.

Wuste garnicht das das Protokol der Übertragung von Binray's an den Prob.
veröffentlicht wurde. "PropellerLoader.spin"

Da braucht man ja "nur" den kurzen Spin-Header for dem Assembleroutput
des eigenen Compilers setzen und übertragen.

Es gibt ja schon 2 C Compiler daher werde ich wohl eine andere Hochsprache nehmen.
Warum nicht einen Spin Compiler da wird doch keiner bei Parallax arbeitslos von. :lol:
Auf dem ersten Blick finde ich Spin garnicht schlecht aber warum die bei Parallax
einen Byte Code Compiler mit Interpreter entwickelt haben erschliest sich mir nicht wirklich.

(Vielleicht sollte der BCI = Byte Code Interpreter zeigen was in 20MIPS per cog stecken)

Grüsse Joshy
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von drohne235 »

DJLinux hat geschrieben: Bei der eigentlich farblichen Grafikdemo sehe ich hier "nur" Gauwerte auf dem TV-Monitor
obwohl ich die passenden Wiederstände "gesteckt" habe.

Auf dem ersten Blick finde ich Spin garnicht schlecht aber warum die bei Parallax
einen Byte Code Compiler mit Interpreter entwickelt haben erschliest sich mir nicht wirklich.

(Vielleicht sollte der BCI = Byte Code Interpreter zeigen was in 20MIPS per cog stecken)
Den gleichen Effekt habe ich auch an meinem alten RöhrenTV hier - der kann kein NTSC sondern nur PAL. Wenn man ein wenig sucht findet man die Konfiguration des Modi im Quelltext und kann das anpassen - ich könnte dir aber jetzt nicht aus dem Kopf sagen wo ich das gemacht hab.
DJLinux hat geschrieben: Auf dem ersten Blick finde ich Spin garnicht schlecht aber warum die bei Parallax
einen Byte Code Compiler mit Interpreter entwickelt haben erschliest sich mir nicht wirklich.

(Vielleicht sollte der BCI = Byte Code Interpreter zeigen was in 20MIPS per cog stecken)
Naja, ich denke der Bytecode ist recht kompakt. Man könnte es ja auch über eine LMM in RISC-Maschienencode compilieren wie es dieser eine C-Compiler tut, aber dann hat jeder Befehl 64Bit. Im Extremfall bekommt man also vier recht komplexe Spinbefehle in den Speicherplatz für einen RISC-Befehl. Korrigiere mich wenn ich da falsch liege, das sind nur Vermutungen von mir. Ich hab mich am Anfang auch ein wenig gefragt was das soll, aber je mehr man damit macht wird für mich persönlich sichtbar das sich SPIN und PASM wirklich gut ergänzen. Für den größten Teil reicht halt der kompakte und recht komfortabel zu programmierende SPIN-Code und die wenigen zeitkritischen Probleme kann man in eine COG/PASM auslagern. Mal ganz davon abgesehen das man an SPIN noch einiges machen könnte, wie ja Rainer auch schon bemerkt hat (bedingte Kompilierung, automatisches auslassen unbenutzter Funktionen...), ist es eine gut benutzbare Lösung für einen Microkontroller. Ich arbeite eigendlich gern mit der IDE und ihren ganzen Features - das geht recht flott von der Hand. Und die Geschwindigkeiten sind ja auch relativ: Man müßte es mal messen, aber es könnte sein das SPIN etwa so schnell ist wie so manche alte Retro-CPU bei 1 MHz Taktfrequenz in Maschiencode.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
Rainer
Beiträge: 510
Registriert: Fr 29. Mai 2009, 16:11

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von Rainer »

Na dann will ich auch mal gratulieren :)

Zu Deinem "Farbproblem" (wenn Du die "Graphics_Demo.spin" meinst)

Du musst "mode" auf auf %0001 setzen.

Code: Alles auswählen

VAR

  long  mousex, mousey

  long  tv_status     '0/1/2 = off/visible/invisible           read-only
  long  tv_enable     '0/? = off/on                            write-only
  long  tv_pins       '%ppmmm = pins                           write-only
  long  tv_mode       '%ccinp = chroma,interlace,ntsc/pal,swap write-only
.
.
.
.viel Code hier
.
.
DAT

tvparams                long    0               'status
                        long    1               'enable
                        long    %001_0101       'pins
                        long    %0000           'mode <--- hier auf %0001
laut TV.spin steht da ob es PAL oder NTSC sein soll

Code: Alles auswählen

CON

  fntsc         = 3_579_545     'NTSC color frequency
  lntsc         = 3640          'NTSC color cycles per line * 16
  sntsc         = 624           'NTSC color cycles per sync * 16

  fpal          = 4_433_618     'PAL color frequency
  lpal          = 4540          'PAL color cycles per line * 16
  spal          = 848           'PAL color cycles per sync * 16

  paramcount    = 14
  colortable    = $180          'start of colortable inside cog
DJLinux hat geschrieben: Warum nicht einen Spin Compiler da wird doch keiner bei Parallax arbeitslos von.
Damit würdest Du wohl zum amerikanischen Volkshelden werden. Hat schon einen gewissen Reiz, schon vorhandenen Spin-Source direkt in optimierten Assembler zu compilieren :)
Allerdings würde mir auch ein guter Makroassembler für den Propeller schon reichen.

Gruß.
Rainer
"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau."
DJLinux

Re: MAX232 oder MAX3222 und der Propeller?

Beitrag von DJLinux »

Also die Kompacktheit des Bytecodes als Begründung herzunehmen halte ich etwas
für Fragwürdig bzw. da kann man sich kurz Gedanken drüber machen.

Ich möchte mich als "Propellerneuling" ja nicht so weit aus dem Fenster lehnen
aber ich programmiere seit 28 Jahren oft mehr als 8 Stunden am Tag wenn nicht
gewerblich dann als Hobby (Arbeit == Hobby) und Erfahrungen im Interpreter
und Compilerdesign habe auch schon einige Jahre.

1. Da jedes Byte einzeln gelesen und Interpretiert werden muss findet das ja nicht
im viel schnellerem Cog RAM statt.
(Klar der Vorteil liegt im globalem Zugriff des langsameren Speichers.)

2. Wenn dann der "kompakte" Code gelesen und interpretiert wurde
sagen wir mal eine Addition dann "springt" der Interpreter innerhalb
der Virtuellem Maschine zur der Stelle die halt für Additionen zuständig ist.
Egal ob Addition einer 9 Bit Konstante oder die Addition eines Registerinhaltes 9 Bit
oder über die indirekte Addition über Pointer es endet immer im nicht mehr
kompackten 32 Bit Assembler Befehl und dann natürlich wieder der "Rücksprung"
zum laufendem Interpreter.

Ich habe mir die Quellen des hive Forth'es noch nicht angeschaut aber viel
anders wird das dort wohl auch nicht sein.

Als ich mal einen Compiler für eine BASIC ähnliche Hochsprache für PIC's
geschrieben hatte, der ziemlich kleinen optimierten Code erzeugt hat,
wollte ich ihn "PICCOLO" nennen. Habe Ihn dann aber inkl. aller Rechte
an meinen damaligem Auftraggeber veräusert.

Für eine künftige grössere Zielgruppe sollte es schon eine leicht zu lernende
Hochsprache sein aber natürlich mit der Möglichkeit von Inlineassembler.

Schade das man in der PropellerTools IDE keine eigene externe Programme eintragen kann.
Aber eine neue IDE braucht man nicht mann könnte für den Propeller ein Plugin
für die Code::Blocks IDE erstellen inklusive Syntax Highlighting.

So genung vom Zukunftsgeschwafel jetzt werd ich mich erst mal auf Proppeler Assembler stürzen.

PS. Natürlich habe ich den Video Mode Parameter angepast aber mein Commodore 1702
zeigt trotzdem "nur" Grautöne. Auf der Rückseite hat er auch noch zwei getrennte
Eingänge für Chroma und Luminanz. Da müste man das zuvor über Wiederstände gemischte
Signal wieder in zwei seperate Signale auftrennen. Aber da habe ich noch keine Ahnung von.

Ich habe mir für schlappe 4€ ein kleines neues TFT Farbdisplay gekauft (1€ pro Zoll)
natürlich bekommt man für so viel Geld auch noch Stereo Lautsprecher Helligkeits
und Kontrastregelung und ein 12V Adapter gehört selbstverständlich auch noch dazu. ;)

Alle Details über das Display (PAL, NTSC, FBAS, SCART RGB, Auflösung)
kann man in diesem Monster-Thread nachlesen.
http://www.mikrocontroller.net/topic/109865

Grüsse Joshy
Dateianhänge
HPIM0908.jpg
27.10.2008_Displayplatine_3_012.jpg
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Serielle Schnittstelle und der Propeller?

Beitrag von drohne235 »

> Also die Kompacktheit des Bytecodes als Begründung herzunehmen halte ich etwas
> für Fragwürdig bzw. da kann man sich kurz Gedanken drüber machen.

Ist ja wirklich ein interessantes Thema, wobei wir erstmal die Begriffe definieren müssen: Mit Kompaktheit meine ich den geringen Speicherverbrauch des resultierenden Codes, nicht die Geschwindigkeit. Ist es denn nicht so das ein Befehl in einigen Fällen wirklich nur einen Byte groß ist? Wenn ja dann ist er halt viermal kleiner als jeder PASM-Befehl, welche ja konstant 32 Bit breit sind. Aber vielleicht ist das auch ein Trugschluß wenn man es nur oberflächlich betrachtet, denn man muß ja auch noch den Wasserkopf der Objektstruktur mitrechnen und auch sehen das viee SPIN-Befehle letztlich mit den Daten letztlich auch mehrere Byte lang sind. AUfder anderen Seite muß man auch sehen das jeder PASM-Befehl z.B. bedingt sein kann und ähnliche Besonderheiten hat. Also ich persönlich habe zwar schon einige CPU's in Assembler programmiert - nicht immer professionell, aber dennoch soweit um zu verstehen wie es funktioniert - aber den PASM finde ich immer noch einigermaßen sonderbar - zumindest zu sonderbar um es mit SPIN zu vergleichen... ;) Zumal ja wirklich bei voller Geschwindigkeit immer noch eine Begrenzung auf die maximal 512 RISC-Befehle einer Cog besteht. Insofern fehlt mir der Überblick um zu entscheiden ob ein nativer Compiler, welcher ja nur mit einer LMM möglich wäre, einen kompakteren (im Sinne kleineren) Code erzeugt könnte. Ich denke schneller wäre ein solcher Code in jedem Fall, aber ob es in bestimmten Anwendungen eine bessere Skalierung gibt, wenn man ein kleines langsames (SPIN) mit einem schnellen aber begrenzten (PASM) Code kombiniert, ist ja die Frage deren Antwort sich mir ob ihrer Komplexität verschließt.
Das der Bytecode letztlich Routinen in 32Bit-Risc-Code referenziert ist mir schon klar dabei, aber genau diese Faktorisierung bringt doch die Kompaktheit im Sinne eines speichersparenden Codes.

Man müsste wirklich mal eine kleine Vergleichsroutine in SPIN mit einem Code aus einem nativen Compiler wie dem ImageCraft-C vergleichen um zu sehen welcher Code letztlich kleiner ist. Wenn es denn sowohl schnell als auch speicherplatzsparend geht wäre das natürlich echt eine tolle Sache.

Sind die Bilder schon mit dem kleinen 4"-Display und dem Prop realisiert? Wo bekommt man so ein Display?
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
DJLinux

Re: Serielle Schnittstelle und der Propeller?

Beitrag von DJLinux »

Hallo drohne
nicht das wir aneinander vorbei "schreiben" natürlich meine ich mit kompaktheit den Speicherverbrauch.

Es gibt nur long word CPU Code also 4 Bytes pro Instruction Richtig (1.)?

Wenn ein Byte Spincode bedeutet Addiere zur nächsten Variable die nächste Konstante
dann muss ja irgend wo im Interpreter der 4 Byte Maschinencode für ADD var,#const
stehen.

Ach so Du meinst wohl mit Kompacktheit weil Du den Speicherverbrauch
des Spin Interpreters im ROM nicht mit zählst. Richtig (2.) ?

PS. Ich kenn die Farbringe für Wiederstände doch noch nicht gut genug
mit den richtigen Werten habe ich auch ein Farbbild bei der gfx demo.

Das 3.99€ TFT Display ist noch verpackt ich muss nur einen Stecker "basteln".
Sonst gibt es da als PAL TV ersatz bzw. RGB SCART TV keine Probleme.
Da ein 12V Autoadapter dabei ist sehe ich in der Stromversorgung auch kein Problem.

Der Thread auf microcontroller.net ist ja nur so lang weil die mit dem AVR einen
Display Controller realisiert haben also ganz ohne der original Platine und dann
wird es echt kompliziert wie die Signale mit gewissen DC Offset muduliert sein müssen.
Abgesehen von den verschiedenen Spannung die man dann selber erzeugen muss.

Aber da kennst Du Dich 1000 mal besser aus als ich.

Das Playstation 2 Slim Car Display hab ich von eBay meines heist BigBen TFT.
Es gibt zig Lieferanten für Playstation 2 Slim TFT's oft auch unter anderer Bezeichnung.

Auf Amazon gibt es die TFT's auch NEU bei 11 Anbietern für 3,99€ GEBRAUCHT für 7,99€ :?
click Amazon:

Auf eBay gib es die auch im 10 Pack für 39,99.- € bei kostenlosem Versandt.
click eBay

Grüsse Joshy

Nachtrag:
Hier die Pinbelegung des AV Multi Connectors
http://pinouts.ru/Multimedia/PlayStationAV_pinout.shtml

Ich habe einfach mal Prop. Masse an Pin 1 gehalten und TV out an Pin 5
man konnte die Geometrie der Animation auf dem Display erkennen.
Werde die Tage mal versuchen vorhandenen TV oder VGA Code an
Display anzupassen.

Im übrigen http://pinouts.ru sollte man sich mal merken
ist mit über 1000 Abbildungen die umfangreichste Sammlung
an Pinbelegungen die ich je im Netz gesehen habe.
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Serielle Schnittstelle und der Propeller?

Beitrag von drohne235 »

DJLinux hat geschrieben:
Ach so Du meinst wohl mit Kompacktheit weil Du den Speicherverbrauch
des Spin Interpreters im ROM nicht mit zählst. Richtig (2.) ?
Genau, den Tokeninterpreter hab ich da jetzt nicht mitgezählt. Der ist ja ressourcenschonend im ROM verfügbar.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Antworten