-
        

Ergebnis 1 bis 10 von 10

Thema: AVR und Python/PyMite

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    16.02.2010
    Beiträge
    5

    AVR und Python/PyMite

    Anzeige

    Hallo liebe RN-Gemeinde,
    ich möchte mit Python/PyMite (super) Mikrocontroller von ATMEL programmieren.
    Mit Assembler (soolala) und Bascom (besser) über STK500 geht das.
    Geht das auch mit Python über Bascom oder ATMEL-Studio und dem STK ?
    Klaus

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    16.02.2010
    Beiträge
    5
    Hallo,
    ich komme immer besser mit Bascom klar.
    Nun ist es meine Vorstellung ein 'Hausnetz' mit einem Master und vielen Slaves zu 'bauen'.
    Auf dem Master soll ein Menue, Anzeige und Verarbeitung laufen und die Slaves machen dann die 'Arbeit'.
    Mal soll etwas geschaltet, mal Werte ermittelt und an den Master zur Weiterverarbeitung übermittelt werden und mal ein Motor in Geschwindigkeit und Richtung gesteuert werden. Eben alles mögliche.
    Meist 4adrige Postkabel liegen schon zu den meisten Türen und Fenster, zur Heizung auf den Boden, zu den Fühlern in allen Zimmern und Draussen, zur Hofeinfahrt und Garage usw. Eben überall wo es was zu Erfühlen oder Steuern gibt.
    Ich denke das der 'Ein-Draht-Bus' die gängiste Möglichkeit sein müsste (Länge viel zig Meter). I2C soll ja nur für sehr kurze Entfernungen geignet sein und andere Bussysteme scheiden wegen der wenigen Leitungen aus. Ich muss ja auch die Versorgungsspannung mit leiten.
    Für den Master würde ich mir ein RN-Control-Bord mit LCD und für die Slaves Tiny's vorstellen können.
    Ich habe nun in diesem und anderen Foren gelesen das "Dallas" auf dem 1wire-Bus seine Hand drauf hat und es keine "SelstbauSlaves" gibt.
    Meine Frage ist nun, sind meine Vorstellungen realistisch? Kann man solche Slaves selbst programmieren?
    Danke für Eure Meinungen. Klaus

  3. #3
    Moderator Robotik Einstein Avatar von HannoHupmann
    Registriert seit
    19.11.2005
    Ort
    München
    Alter
    34
    Beiträge
    4.528
    Blog-Einträge
    1
    @KlausiK51 theoretisch ist sowas schon möglich, gibt zumindest keine physikalischen Gesetze die dagegen sprechen. Es ist halt sehr aufwendig eine entsprechende Infrastruktur in der Praxis auch wirklich zu realisieren. RS232 kann glaub ich noch relativ lange Strecken und brauch nur 3 Adern.

    Abgesehen davon weis ich nicht ob man die ATMEL Dinger überhaupt mit
    Python programmieren kann (wenn ja würde mich das auch interessieren).

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Ich habe so etwas über RS485 gemacht klappt locker bis über 1200m.
    Mann muß sich allerdings ein eigenes Protokoll schreiben damit die
    Bustreiber bei Bedarf die Richtung umschalten. Der Master sendet wenn
    er lesen will ein Bestimmtes Zeichen und schaltet den Bustreiber auf lesen.
    Der adressierte Slave schaltet auf senden, überträgt die Daten mit anzahl
    der Datenbytes und schaltet wieder auf Empfangen....u.s.w

    Gruß Richard

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Kandel
    Alter
    29
    Beiträge
    1.220
    Python ist eine interpretierte Sprache, ich halte es daher für relativ aufwändig, Python auf einem AVR zum laufen zu bringen.
    Es gibt wohl PyMite, das braucht aber mindestens 64KiB Flash und 4KiB SRAM ... soviel Ressourcen mit einem C-Programm zu verheizen erfordert schon einiges an Arbeit/Vorsatz.
    Es gibt nun Mal einfach Sprachen, die für den Einsatz auf AVRs eher schlecht geeignet sind ...

    mfG
    Markus

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    16.02.2010
    Beiträge
    5
    Hallo Hanno, Richard und Markus,
    ich danke euch für Eure promte Antwort.
    Mit meinem ersten Beitrag hatte ich schon gemerkt, das Py.. nicht so richtig ankommt. Das ist auch nicht Bedingung. Wollte nur mal wissen, ob es damit überhaupt geht, da ich mit den Programmieren in Py.. recht gut zurande gekommen bin. Wie gesagt ich hatte und habe schon viel mehr in Basic (C64) und jetzt in Bascom gemacht. Doch zur Sache.
    Hanno, die Infrastr.. wie Kabel, Kontakte, Brandmelder, Bewegungsmelder, Dämmerungsschalter, Schaltschrank usw sind zum größten Teil vorhanden. Was spricht gegen einen 1wire-Bus zumal ich ja gerne die Temparaturfühler von Dallas (DS1820) benutzen wollte. Meine jetzigen Fühler mit Diode sind nicht besonders gut.
    Richard, genau wegen dem eigenen Protokoll möchte ich ja ein Standardpro.. verwenden um eben auch Standardsensoren einsetzen zu können. Ich will ja nicht dauernd das Fahrrad neu erfinden und die Fühler von Da.. drängen sich ja geradezu auf. Das größere Problem sehe ich ja eher in dem bidirektionalen Datenverkehr auf 2 Leitungen (4-2*Stromversorgung). Darauf zielte meine Frage eigendlich hauptsächlich ab.
    Markus, das mit Python hat sich wohl erledigt. Trotzdem danke für Deine Antwort. Ich glaube das mit dem Interpreter ist wohl der Hauptgrund für Deine Bedenken.
    Also weiter mit Bascom. Frage ist das Protokoll des '1wire-Bus' so weit veröffendlicht, das man Slaves (evt Tiny's) für Sensoren (Kontakte usw) und Aktoren (Schalter, Motoren usw) selbst programmieren kann. Mit dem Master gibt es ja genügend Programmbeispiele.
    Klaus.

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Kandel
    Alter
    29
    Beiträge
    1.220
    Hey Klaus,

    das 1-Wire-Protokoll ist veröffentlicht und hilfreiche Informationen gibt es u.A. in der Wikipedia.
    Bascom selbst bietet sogar schon 1-Wire funktionalität an (ob als kostenpflichtige Extra-Lib oder schon im Lieferumfang weiß ich nicht genau), für C gibt es mit an Sicherheit grenzender Wahrscheinlichkeit ebenfalls Bibliotheken.

    mfG
    Markus

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    16.02.2010
    Beiträge
    5
    Hallo Markus und Andere,
    1-wire hab ich alles durch auch Wiki. Ich habe einen 'Master' Mega8 gebaut/programmiert und der funzt auch mit zwei Temparatursensoren "DS18.. von Dallas". Mein Anliegen geht aber noch viel weiter, wie man oben sehen kann.
    Ich möchte gern wissen ob und wie man weitere Sensoren und auch Aktoren für den 1-Draht-Bus bauen/programmieren kann. Letzendlich möchte ich ja alles was es im einem Haus zu messen/auswerten/steuern gibt mit einer "Zentrale", vielen "industriellen/Eigenbau"-Sensoren/Aktoren und einem Bussystem realisieren. Eigendlich ist mir die Art des Busses ziemlich "wurscht" aber er muß für einige zig Slaves über gut 200 Meter geeignet und einigemaßen störsicher sein. Außerdem habe ich nur max. 2 Drähte (4-2*Stromversorgung) frei. Dabei wäre es mir sehr lieb wenn ich noch einen Draht für evt. spätere Änder-Störungen zur Sicherheit frei hätte, und da drängt sich ja der 1-Draht-Bus geradezu auf.
    Bitte schreibt mir Eure Meinungen.
    Danke Klaus

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Schau mal hier.....
    http://www.mikrocontroller.net/topic/44100

    etwas weiter lesen....

    Gruß Richard

  10. #10
    Neuer Benutzer Öfters hier
    Registriert seit
    16.02.2010
    Beiträge
    5
    Danke Richard,
    ich habe mir die Nacht um die Uhren gehauen, alles durchgearbeitet und sehe das es schon vor längerer Zeit Interesse in dieser Richtung gegeben hat. Nur sehe ich auch, das es nur einen wirklichen Beitrag in Form von, ich nehme an, Assemblerprogramm gegeben hat. Damit stellt sich mir die Frage der "richtigen" Programmiersprache zum wiederholten Male. Genauso ist man sich in der Frage des geeigneten Busses nicht sehr einig.
    Genaugenommen stehe ich jetzt nicht besser da wie vorher. Und so geht es sicher vielen anderen "Anfängern".
    Bitte redet so damit man auch was versteht. Trotzdem allen vielen Dank für Eure Beiträge. Ich werde mich weiterhin mit Eurer Hilfe mit Programmierung befassen und "irgendwann" mal einen nützlichen Betrag dazu leisten können.
    Gruß Klaus

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •