Mikro(Makro)controller :)
Stephan Zehrer
ich weiß schon, allein schon bei den
Begriff hier steht der eine oder der ander Kopf.
Darum hab ich auch brav die FAQ gelesen und alle
Beiträge die dazu in den letzten Wochen drin waren.
Allerdings mit ich mit der Hoffung da ran gegangen das ich
was geniales finde.
Ich bin gerade dabei eine Steuerung zu bauen für Dachfenster.
Die erste Ausbaustufe besteht aus einem C-Control (no comment)
und einer I2C Relai Platine.
Naja nun ist dieses System doch nicht so das ware was Leistung,
Preis und Ausstattung angeht, und für die 2 Ausbaustufe bin ich dann
eben auf die Suche gegangen.
Der CC2 Naja gefällt mir eigentlich nicht mehr, und da dachte ich
als gelernter Kommuniktationselektroniker (und jetzt Informatiker)
bau ich mir was eigenes.
Da kommt man dann eben nicht an den Atmel AVR vorbei was wohl
im Augenblick sehr gebräuchlich ist.
Allerdings fehl mir zu dem noch ein paar Sachen:
-Erst mal weiß jemand wo man den ATmega 161 bekommet
ich hätte ja schon mal geren 2 UARTS.
-Vernetzung von mehreren MCU's
Schön wäre über CAN, oder RS485
Allerdings sind hab ich dazu nicht so viel gefunden
vorallem zum letzten. CAN ist auch nicht so gut untersützt
Hat jemand was dazu gemacht ?
Zu vielen Andere Sachen wie z.B. I2C, DCF, Dallas 1-Wire-Bus,IR
usw. Hab ich ja schon mal was gefunden. Allerdings gehen dann
recht schnell die Int. Leitung aus von dem Teil (leider)
Darum hab ich mir eben schon eine verteilte Architektur überlegt.
Mein Absoluter Spitzenreiter wäre noch ein MB90F590 von Fujitsu,
der läßt wohl an Anschlüsse keine Wünsche offen.
(http://www.fme.gsdc.de/series/mb905901.htm)
Allerdings ist er im QFP Gehäuse für Hobby Zwecke nicht so einfach
zu Handhaben.
Kennt noch jemand eine Controller der eher in diese Richtung geht ?
Ok .. freue mich über jeden Kommentar ..
bye Steve
--
Please remove "nospam" to get my email address
Sorin Dean
"Stephan Zehrer" <st...@stevez.de> schrieb im Newsbeitrag
news:3A7AB922...@nospam.stevez.de...
> Hi,
>
> Allerdings fehl mir zu dem noch ein paar Sachen:
> -Erst mal weiß jemand wo man den ATmega 161 bekommet
> ich hätte ja schon mal geren 2 UARTS.
Laut Distributor zur zeit nicht verfügbar.....erst ende des Jahres...:(
> -Vernetzung von mehreren MCU's
Fast jeder AVR hat auch eine SPI.....oder läst sich über Soft die zweite
UART schafen.
> Mein Absoluter Spitzenreiter wäre noch ein MB90F590 von Fujitsu,
> der läßt wohl an Anschlüsse keine Wünsche offen.
> (http://www.fme.gsdc.de/series/mb905901.htm)
> Allerdings ist er im QFP Gehäuse für Hobby Zwecke nicht so einfach
> zu Handhaben.
...und was kostet so eine Entwicklungsumgebung bei Fujitsu???
Für AVR-s bekommst du alles kostenlos, und läst sich mit sehr kleines
aufwand "In System" programmieren !!!
Thomas Rudolph
>Schön wäre über CAN, oder RS485
schau mal auf www.lancos.com.CAN hat aber einen ganz schönen
Overhead.
>Zu vielen Andere Sachen wie z.B. I2C, DCF, Dallas 1-Wire-Bus,IR
>usw. Hab ich ja schon mal was gefunden. Allerdings gehen dann
>recht schnell die Int. Leitung aus von dem Teil (leider)
>Darum hab ich mir eben schon eine verteilte Architektur überlegt.
Ich bau auch grad sowas, eine Art UNI-AVR-Platine. Die 32 I/O-Pins
wollen aber erstmal alle sinnvoll belegt sein, da kommt man schon eine
Weile mit hin.
Dessenungeachtet will ich auch mit Steckmodulen arbeiten , die über
SPI angebunden sind .
Auf den ATmega161 warte ich auch sehnsüchtig, weil ich eine echte
zweite UART brauche, ansonsten muß man ja jede Bitflanke persönlich in
einer ISR begrüßen ;-)
Sehr interessant finde ich in diesem Zusammenhang auch das
SIMMStick-Project, da werden kleine MCU-Module (AVR,PIC,8051) in der
Form eines SIMM-Moduls gebaut, die dann über eine Art Motherboard und
halt die normalen SIMM-Stecker aus der PC-Welt miteinander
kommunizieren können.
Für die AVR-Prozessoren gibts übrigens auch freie
Debug-Monitorsoftware und mehrere kleine Betriebssysteme.
Viele Grüße
Thomas Rudolph
email: dk3...@dk3dua.de
Matthias Weingart
<3A7AB922...@nospam.stevez.de>:
>Hi,
>Allerdings fehl mir zu dem noch ein paar Sachen:
>-Erst mal weiß jemand wo man den ATmega 161 bekommet
>ich hätte ja schon mal geren 2 UARTS.
Falls Du die beiden seriellen nicht gleichzeitig brauchst, kannst Du die ja
auch multiplexen (mit nem 74HC... - der Typ faellt mir grad nicht ein).
>-Vernetzung von mehreren MCU's
>Schön wäre über CAN, oder RS485
>Allerdings sind hab ich dazu nicht so viel gefunden
>vorallem zum letzten. CAN ist auch nicht so gut untersützt
Bei RS485 ist im wesentlichen nur die Hardware definiert (also die
Signalpegel: diffentiell usw). Die seriellen der uC's sind per
75176 (oder aehnliche) verbunden. Das Softwareprotokoll musst Du selbst
definieren. (funktioniert aber mit jedem uC und an jedem UART)
CAN ist aufwendiger - da ist auch das Protokoll definiert und wenn es
schneller gehen soll, brauchts es schon nen CAN-Controller (entweder
integriert oder separat). Ich finde RS485 besser geeignet fuer "Mal schnell
ein paar uC's koppeln" - weil einfacher.
>Zu vielen Andere Sachen wie z.B. I2C, DCF, Dallas 1-Wire-Bus,IR
>usw. Hab ich ja schon mal was gefunden. Allerdings gehen dann
>recht schnell die Int. Leitung aus von dem Teil (leider)
>Darum hab ich mir eben schon eine verteilte Architektur überlegt.
Interrupt? Da der uC bei diesen Bussen Master ist, brauchst Du da
eigentlich keine Interrupts.
Matthias
Oliver Hanka
> Sehr interessant finde ich in diesem Zusammenhang auch das
> SIMMStick-Project, da werden kleine MCU-Module (AVR,PIC,8051) in der
> Form eines SIMM-Moduls gebaut, die dann über eine Art Motherboard und
> halt die normalen SIMM-Stecker aus der PC-Welt miteinander
> kommunizieren können.
Hast du da auch einen Link zu dem Thema ?
Gruß Oliver
Andreas Schwarz
computers.de>:
Hmm, vielleicht http://www.simmstick.com ?
MfG
Andreas
--
Forum und Code-Bibliothek für Mikrocontroller:
www.mikrocontroller.net
Gerald Oppen
Thomas Rudolph schrieb:
> Auf den ATmega161 warte ich auch sehnsüchtig, weil ich eine echte
> zweite UART brauche, ansonsten muß man ja jede Bitflanke persönlich in
> einer ISR begrüßen ;-)
Von Philips gibt es dazu ein PDF-Dokoment (AN6) für die 8051 Serie,
lässt sich auch für andere Controller anpassen.
Erste Flanke eines Bytes wird per Interrupt erfasst und die
nachfolgenden Bits mit einem Timerinterrupt abgefragt.
Gerald
Robert Hoffmann
wrote:
Aber Aufpassen Leute. Das funktioniert nur dann vernünftig, wenn ihre
ausreichend Signal zur Verfügung habt und keine Impulstörer in der
Nähe sind (industrielles Umfeld), da ihr sonst mit einem
flankensensitiven Algorithmus beim ersten Glitch rausfliegt.
Besser (und prozesseorbelastender) sind Algorithmen bei denen eine
Hardware-UART wirklich nachgebildet wird, also mit Überabtastung und
Korrelation.
Robert
Dipl.Ing. Robert Hoffmann
robert_...@utanet.at
Gerald Oppen
Robert Hoffmann schrieb:
> Aber Aufpassen Leute. Das funktioniert nur dann vernünftig, wenn ihre
> ausreichend Signal zur Verfügung habt und keine Impulstörer in der
> Nähe sind (industrielles Umfeld), da ihr sonst mit einem
> flankensensitiven Algorithmus beim ersten Glitch rausfliegt.
>
> Besser (und prozesseorbelastender) sind Algorithmen bei denen eine
> Hardware-UART wirklich nachgebildet wird, also mit Überabtastung und
> Korrelation.
Die Philips-Lösung funktioniert schon recht gut, einzelne Glitche z.B.
durch einschalten eines Verbrauches werden in der Regel erkannt und
herausgefiltert.
Gerald
Thomas Rudolph
InterruptServiceRoutine begrüßen . Ich möchte erst einen RX-Interrupt
bekommen wenn das Byte fertig empfangen ist.
Die Software-UART gibts für jeden Prozessor, auch Atmel hat solche
Software auf seinen Webseiten .
On Sat, 03 Feb 2001 17:52:44 +0100, Gerald Oppen <Gerald...@web.de>
wrote:
>
>
Stephan Zehrer
> >Allerdings fehl mir zu dem noch ein paar Sachen:
> >-Erst mal weiß jemand wo man den ATmega 161 bekommet
> >ich hätte ja schon mal geren 2 UARTS.
> Falls Du die beiden seriellen nicht gleichzeitig brauchst, kannst Du die
ja
> auch multiplexen (mit nem 74HC... - der Typ faellt mir grad nicht ein).
Naja kommt eben darauf an welche Topologie man benutzt.
Wenn es geht alle über eine Bus zu vernetzen dann reicht auch gut ein
UART.
> >-Vernetzung von mehreren MCU's
> >Schön wäre über CAN, oder RS485
> >Allerdings sind hab ich dazu nicht so viel gefunden
> >vorallem zum letzten. CAN ist auch nicht so gut untersützt
> Bei RS485 ist im wesentlichen nur die Hardware definiert (also die
> Signalpegel: diffentiell usw). Die seriellen der uC's sind per
> 75176 (oder aehnliche) verbunden. Das Softwareprotokoll musst Du selbst
> definieren. (funktioniert aber mit jedem uC und an jedem UART)
So weiß ich das. Allerdings fehlt mir dazu die Praxiserfahrung. Also gibt
es Bsp. für ein Master/Slave Protokoll ? Evtl mit einer Implementierung. ?
> CAN ist aufwendiger - da ist auch das Protokoll definiert und wenn es
> schneller gehen soll, brauchts es schon nen CAN-Controller (entweder
> integriert oder separat). Ich finde RS485 besser geeignet fuer "Mal
schnell
> ein paar uC's koppeln" - weil einfacher.
Wenn ich das richtig kapiert habe ist im Controller die ganze Protokoll
sache
mit integriert. Dann ist das doch fast einfacher oder hab ich was falsch
verstanden.
Ok die Verbindung zur Hardware ist komplizierter. Aber dafür muß man sich
dann eben bei der Software nicht so viel gedanken machen oder ?
> >Zu vielen Andere Sachen wie z.B. I2C, DCF, Dallas 1-Wire-Bus,IR
> >usw. Hab ich ja schon mal was gefunden. Allerdings gehen dann
> >recht schnell die Int. Leitung aus von dem Teil (leider)
> >Darum hab ich mir eben schon eine verteilte Architektur überlegt.
> Interrupt? Da der uC bei diesen Bussen Master ist, brauchst Du da
> eigentlich keine Interrupts.
Mmm .
Also I2C ist eine M/S Bus für den brauch man schon mal einen Int.
Zumindest sieh auch so die Bsp. Impementierung von Atmel aus
oder hab ich das falsch gesehen.
DCF .. um nicht immer Pollen zu müssen wäre es um einiges einfacher
das signal per Int zu verarbeiten oder ?
1- Wire ok dafür braucht man nichts.
IR .. kommt darauf an wie man es realisiert. Direkt .. dann würd man
an eine Int nicht rum kommen oder eben per I2C was mir besser gefällt.
Dann hab ich noch andere Sensoren für die Fenstersteuerung.
Temp -> geht über den Dallas
Windgeschwindigkeit --> da brauch ich eine Frequenzmessung wird wohl auch
über
eine Int am besten gehen ..
Freuchtigkeit .. das kann man immer wieder abfragen denke ich ..
naja
also sind genugt Interuper die man verbrauchen kann :=
oder ?
> Matthias
bye Steve
Stephan Zehrer
> > Allerdings fehl mir zu dem noch ein paar Sachen:
> > -Erst mal weiß jemand wo man den ATmega 161 bekommet
> > ich hätte ja schon mal geren 2 UARTS.
> Laut Distributor zur zeit nicht verfügbar.....erst ende des Jahres...:(
Schade....
> > -Vernetzung von mehreren MCU's
> Fast jeder AVR hat auch eine SPI.....oder läst sich über Soft die zweite
> UART schafen.
Zum Thema SPI .. gibt es eine Referenz im Netz wo man man schauen kann
was es auf der Basis zu SPI gibt ? .. darüber hab ich mich noch nicht schlau
gemacht.
> > Mein Absoluter Spitzenreiter wäre noch ein MB90F590 von Fujitsu,
> > der läßt wohl an Anschlüsse keine Wünsche offen.
> > (http://www.fme.gsdc.de/series/mb905901.htm)
> > Allerdings ist er im QFP Gehäuse für Hobby Zwecke nicht so einfach
> > zu Handhaben.
>
> ...und was kostet so eine Entwicklungsumgebung bei Fujitsu???
Sorry kann ich Dir nicht sagen.
ich hab noch eine Link dazu.. aber leider nicht hier, ich reche ihn am
Monath nach.
> Für AVR-s bekommst du alles kostenlos, und läst sich mit sehr kleines
> aufwand "In System" programmieren !!!
Der Fujitsu hat Bootstrap und läßt sich über die Serielle schnitstelle prog.
Die C entwicklungsumgebung stellen die scheints auch kostenlos zu verfügung.
bye Steve
Sorin Dean
> Hi,
>
> Zum Thema SPI .. gibt es eine Referenz im Netz wo man man schauen kann
> was es auf der Basis zu SPI gibt ? .. darüber hab ich mich noch nicht
schlau
> gemacht.
>
In jeder MC Datenblatt von Motorola und auch z.B. bei der AT90S8535 (
Atmel).
Gibt auch SPI-EEPROM.
> > Für AVR-s bekommst du alles kostenlos, und läst sich mit sehr kleines
> > aufwand "In System" programmieren !!!
> Der Fujitsu hat Bootstrap und läßt sich über die Serielle schnitstelle
prog.
> Die C entwicklungsumgebung stellen die scheints auch kostenlos zu
verfügung.
Kommt drauf an wieviel "POWER" brauchst.....:)
>
> bye Steve
>
>
Sorin Dean
>
> > >Allerdings fehl mir zu dem noch ein paar Sachen:
> > >-Erst mal weiß jemand wo man den ATmega 161 bekommet
> > >ich hätte ja schon mal geren 2 UARTS.
> > Falls Du die beiden seriellen nicht gleichzeitig brauchst, kannst Du die
> ja
> > auch multiplexen (mit nem 74HC... - der Typ faellt mir grad nicht ein).
> Naja kommt eben darauf an welche Topologie man benutzt.
> Wenn es geht alle über eine Bus zu vernetzen dann reicht auch gut ein
> UART.
>
> > >-Vernetzung von mehreren MCU's
> > >Schön wäre über CAN, oder RS485
> > >Allerdings sind hab ich dazu nicht so viel gefunden
> > >vorallem zum letzten. CAN ist auch nicht so gut untersützt
> > Bei RS485 ist im wesentlichen nur die Hardware definiert (also die
> > Signalpegel: diffentiell usw). Die seriellen der uC's sind per
> > 75176 (oder aehnliche) verbunden. Das Softwareprotokoll musst Du selbst
> > definieren. (funktioniert aber mit jedem uC und an jedem UART)
> So weiß ich das. Allerdings fehlt mir dazu die Praxiserfahrung. Also gibt
> es Bsp. für ein Master/Slave Protokoll ? Evtl mit einer Implementierung. ?
ja....L.O.A.A. ( www.hth.com/loaa/ )
und wenn du alle Messwerte in Analog umwandelst.....ein 8 Kanal ADC reicht
dann ( bei Atmel 8535, 10 Bit), da reicht auch die Auflösung.
>
> > Matthias
>
> bye Steve
>
>
Gruß
Sorin
Stephan Zehrer
> > > Bei RS485 ist im wesentlichen nur die Hardware definiert (also die...
> > So weiß ich das. Allerdings fehlt mir dazu die Praxiserfahrung. Also gibt
> > es Bsp. für ein Master/Slave Protokoll ? Evtl mit einer Implementierung. ?
> ja....L.O.A.A. ( www.hth.com/loaa/ )
Mmm naja auf der Seite bin ich nicht fündig geworden.
loaa steht doch für "List of AVR Applications" und es war keine App in
dieser Richtung dabei.
Die haben wohl zwar diese PLM-24 das auch mit RS485 geht aber
leider nicht offen Dokumentiert so wie ich das sehen.
Da scheint mir bis jetzt CAN immer noch besser, wenn der Controller
mir alles abnimmt.
> und wenn du alle Messwerte in Analog umwandelst.....ein 8 Kanal ADC reicht
> dann ( bei Atmel 8535, 10 Bit), da reicht auch die Auflösung.
Das problem ist nicht das Sie analog oder digital sind. 32 I/O Eingänge
reichen da sehr gut, nur wenn am auf Hardware Int. verzichtet muß man
laufend den Port abfragen. Was bei manchen sicher geht, aber nicht bei
allem.
Was man machen könnte wäre eine analogen Windsensor kaufen. Das dürfte
es geben
die sind aber meistens um einiges teuer. Dit Teile sind schon für sich
schon
relativ teuer (leider) bzw. ich hab noch keine billigen gefunden.
Stephan Zehrer
Hi
> >Schön wäre über CAN, oder RS485
> schau mal auf www.lancos.com.CAN hat aber einen ganz schönen
> Overhead.
Hab ich gemacht, Overhead ? in wie fern ?
Ich finde dem seine Implementierung interessant. Er hat ja da
Protokoll in Software gegossen und direkt eine Transivera an
dem MCU betrieben, ich würde auf jedenfall eine Controller davor
schalten.
> Ich bau auch grad sowas, eine Art UNI-AVR-Platine. Die 32 I/O-Pins
> wollen aber erstmal alle sinnvoll belegt sein, da kommt man schon eine
> Weile mit hin.
Hört sich interessant an, hast Du dazu was Dokumentiert im Netz ?
Genau so was in der Art hab ich mir nämlich auch vorgestellt.
> Dessenungeachtet will ich auch mit Steckmodulen arbeiten , die über
> SPI angebunden sind .
Über spi muß ich mich noch schlau machen. Was willst Du auf diesen
Steckmodulen unterbringen ?
Welche andere Hardware (außer MCU und EEPROMS) unterstützen
denn noch SPI ?
> Auf den ATmega161 warte ich auch sehnsüchtig, weil ich eine echte
> zweite UART brauche, ansonsten muß man ja jede Bitflanke persönlich in
> einer ISR begrüßen ;-)
> Sehr interessant finde ich in diesem Zusammenhang auch das
> SIMMStick-Project, da werden kleine MCU-Module (AVR,PIC,8051) in der
> Form eines SIMM-Moduls gebaut, die dann über eine Art Motherboard und
> halt die normalen SIMM-Stecker aus der PC-Welt miteinander
> kommunizieren können.
Naja bevor ich eine Software UART benutze denke ich lieber
über eine Vernetzung nach, dafür war die 2 UART gedacht.
> Für die AVR-Prozessoren gibts übrigens auch freie
> Debug-Monitorsoftware und mehrere kleine Betriebssysteme.
Jup die hab ich schon zum Teil gesehen, das könnte die
Programmierung von manchen Aufgaben doch um einiges erleichtern.
Ist ja dann fast schon schön wie am PC :)
Erik Hermann
> Mein Absoluter Spitzenreiter wäre noch ein MB90F590 von Fujitsu,
> der läßt wohl an Anschlüsse keine Wünsche offen.
Allerdings.
Mittlerweile bin ich von Atmel ziemlich abgerückt, denn sie sind
schlecht verfügbar und zu teuer. Wen man sich anschaut, was man
für das Geld bei Fujitsu oder Mitsubishi bekommt...
Ich habe hier ein paar MB90F598, allerdings aus Zeitgründen
noch nichts damit gemacht.
Momentan arbeite ich an einem Projekt mit dem MB90F497.
Auch ein nettes Teil. 64kByte Flash, 2k RAM, 16Bit, Full CAN
2 UART (RS232 oder SPI), 8 Kanal 10Bit A/D, Timer, Counter,
PWM, etc., 16 Bit Hardwaremultiplikation, 32kHz subclock, usw.
C-Compiler mit Workbench gibt's kostenlos, ebenso die
Software zum Download über RS232.
Und: Das Teil kostet beim Distributor ca. 12 DM!
> Allerdings ist er im QFP Gehäuse für Hobby Zwecke nicht so einfach
> zu Handhaben.
Geht noch. Den 497 gibts auch im QFP64 mit etwas grösserem
Beinabstand.
Ich werde vielleicht eine Experimentierplatine für den 497 oder
den 598 machen. Wenn, dann lege ich sie ins Web.
Sorin Dean
"Stephan Zehrer" <st...@nospam.stevez.de> schrieb im Newsbeitrag
news:3A7E5EC2...@nospam.stevez.de...
> Hi,
>
> > > > Bei RS485 ist im wesentlichen nur die Hardware definiert (also
die...
> > > So weiß ich das. Allerdings fehlt mir dazu die Praxiserfahrung. Also
gibt
> > > es Bsp. für ein Master/Slave Protokoll ? Evtl mit einer
Implementierung. ?
> > ja....L.O.A.A. ( www.hth.com/loaa/ )
> Mmm naja auf der Seite bin ich nicht fündig geworden.
> loaa steht doch für "List of AVR Applications" und es war keine App in
> dieser Richtung dabei.
> Die haben wohl zwar diese PLM-24 das auch mit RS485 geht aber
> leider nicht offen Dokumentiert so wie ich das sehen.
>
http://www.hth.com/snap/
Gruß
Sorin
Stephan Zehrer
> Allerdings.
> Mittlerweile bin ich von Atmel ziemlich abgerückt, denn sie sind
> schlecht verfügbar und zu teuer. Wen man sich anschaut, was man
> für das Geld bei Fujitsu oder Mitsubishi bekommt...
> Ich habe hier ein paar MB90F598, allerdings aus Zeitgründen
> noch nichts damit gemacht.
> Momentan arbeite ich an einem Projekt mit dem MB90F497.
> Auch ein nettes Teil. 64kByte Flash, 2k RAM, 16Bit, Full CAN
> 2 UART (RS232 oder SPI), 8 Kanal 10Bit A/D, Timer, Counter,
> PWM, etc., 16 Bit Hardwaremultiplikation, 32kHz subclock, usw.
> C-Compiler mit Workbench gibt's kostenlos, ebenso die
> Software zum Download über RS232.
> Und: Das Teil kostet beim Distributor ca. 12 DM!
Mmm ich glaub ich muß mal genauer schauen, hört
sich für mich nicht schlecht an. Genau umgefähr die größe
die ich bräuchte.
> > Allerdings ist er im QFP Gehäuse für Hobby Zwecke nicht so einfach
> > zu Handhaben.
> Geht noch. Den 497 gibts auch im QFP64 mit etwas grösserem
> Beinabstand.
> Ich werde vielleicht eine Experimentierplatine für den 497 oder
> den 598 machen. Wenn, dann lege ich sie ins Web.
Ich bin auf Fujitsu gekommen durch folgende Seite :
http://www.thomas-wedemeyer.de/
Er hat auch eine Kleinserie von dem großen, für ca. 320 (weiß nicht
mehr genau). Hat auch eine beschreibung auf seiner HP.
Und noch eine Praxis Tip von Ihm (hab ich per Mail bekommen) :
>Wenn Du Dir etwas selberbasteln willst, hier noch ein Tip: Der
>Controller reagiert äußerst mürrisch, wenn man I/O-Pins
>unbeschaltet lässt. Dann hat man häufiger mal Probleme den Chip
>zu programmieren. Deshalb am Besten alle Pins mit Pull-Up's
>beschalten oder direkt auf GND legen, wenn sie nicht benötigt
>werden.
Ist zwar normal das man das macht, aber zum testen läßt
man das gerne mal weg :)
Stephan Zehrer
> Momentan arbeite ich an einem Projekt mit dem MB90F497.
> Auch ein nettes Teil. 64kByte Flash, 2k RAM, 16Bit, Full CAN
> 2 UART (RS232 oder SPI), 8 Kanal 10Bit A/D, Timer, Counter,
> PWM, etc., 16 Bit Hardwaremultiplikation, 32kHz subclock, usw.
> C-Compiler mit Workbench gibt's kostenlos, ebenso die
> Software zum Download über RS232.
> Und: Das Teil kostet beim Distributor ca. 12 DM!
Mmm
ich hab jetzt mal etwas geschaut im Netz, naja das Teil hört
sich immer noch für mich Klasse an, allerdings findet man leider
nicht so viel im Netz dazu an freien Seiten.
Wohl nicht gerade sehr verbreiten (unter Hobby bastlern)
Oder hab ich da nur falsch gesucht. Hast Du dazu ein paar
Links und noch eine Frage.
Wo kann man das Teil hier denn kaufen in kleine Stückzahlen ?
thx
Matthias Weingart
>> >Zu vielen Andere Sachen wie z.B. I2C, DCF, Dallas 1-Wire-Bus,IR
>> >usw. Hab ich ja schon mal was gefunden. Allerdings gehen dann
>> >recht schnell die Int. Leitung aus von dem Teil (leider)
>> >Darum hab ich mir eben schon eine verteilte Architektur überlegt.
>> Interrupt? Da der uC bei diesen Bussen Master ist, brauchst Du da
>> eigentlich keine Interrupts.
>Mmm .
>Also I2C ist eine M/S Bus für den brauch man schon mal einen Int.
>Zumindest sieh auch so die Bsp. Impementierung von Atmel aus
>oder hab ich das falsch gesehen.
Da der uc der Master ist, beginnt er auch einfach (irgendwann) die I2C-
Kommunikation - also erstmal kein Interrupt noetig. Dann schiebt er den
Takt raus und gibt gleichzeitig Startbit,Daten aus oder liesst die ein -
immernoch kein Interrupt noetig. Ack lesen und stopbit - schliesst dann ab.
Also ich wuesste nicht, wo man bei einem I2C-Master nen Interrupt
braeuchte. (Es sei denn der uC is superflink, das er nach jedem Takt ewig
Daeumchen drehen muesste - naja 10us sind aber nicht viel - je nach
Prozessor 10-50 Befehle, es ist wohl einfacher da mit ein paar nop's zu
warten, als ne komplizierte timersteuerung zu bauen.)
Fuer ne I2C-Slaveroutine (oder Multimaster) ist ein Interrupt allerdings
noetig.
Matthias
Matthias Weingart
>> >-Vernetzung von mehreren MCU's
>> >Schön wäre über CAN, oder RS485
>> >Allerdings sind hab ich dazu nicht so viel gefunden
>> >vorallem zum letzten. CAN ist auch nicht so gut untersützt
>> Bei RS485 ist im wesentlichen nur die Hardware definiert (also die
>> Signalpegel: diffentiell usw). Die seriellen der uC's sind per
>> 75176 (oder aehnliche) verbunden. Das Softwareprotokoll musst Du selbst
>> definieren. (funktioniert aber mit jedem uC und an jedem UART)
>So weiß ich das. Allerdings fehlt mir dazu die Praxiserfahrung. Also gibt
>es Bsp. für ein Master/Slave Protokoll ? Evtl mit einer Implementierung. ?
(mhh, die Seite gibs nicht mehr?) Da waren mal Atmel'2051 Softwarequellen
fuer nen RS485-Homeautomationbus drauf. Die Kommunikation ist eigentlich
simpel. Master sendet nen paar Bytes und Slave empfaengt die. Die Slave
Routine hat nur 25 Zeilen C-Code. Slave kann auch ein paar bytes
zurueckschicken. Man kann es also ziemlich einfach machen. Ich glaub ich
hab die Quellen irgendwo noch ...
Matthias
Stephan Zehrer
Hi,
> Dessenungeachtet will ich auch mit Steckmodulen arbeiten , die über
> SPI angebunden sind .
> Auf den ATmega161 warte ich auch sehnsüchtig, weil ich eine echte
> zweite UART brauche, ansonsten muß man ja jede Bitflanke persönlich in
> einer ISR begrüßen ;-)
Die alternative dazu wäre dann wohl ein UART vom Maxim für SPI.
(MAX3100,3110,3111)
Das ist schon mal das was ich zu SPI gefunden habe, aber viel
mehr bisher nicht.
Abgesehen von Speicher und anderen MCU's.
Ein CAN Controller zu SPI würde mir gefallen :)
(gibt es glaub auch .. von Microchip)
Bin immer noch auf der suche nach eine vernünftigen Aufstellung von
SPI Komponenten ..
Stephan Zehrer
Matthias Weingart schrieb:
> Da der uc der Master ist, beginnt er auch einfach (irgendwann) die I2C-
> Kommunikation - also erstmal kein Interrupt noetig. Dann schiebt er den
> Takt raus und gibt gleichzeitig Startbit,Daten aus oder liesst die ein -
> immernoch kein Interrupt noetig. Ack lesen und stopbit - schliesst dann ab.
> Also ich wuesste nicht, wo man bei einem I2C-Master nen Interrupt
> braeuchte. (Es sei denn der uC is superflink, das er nach jedem Takt ewig
> Daeumchen drehen muesste - naja 10us sind aber nicht viel - je nach
> Prozessor 10-50 Befehle, es ist wohl einfacher da mit ein paar nop's zu
> warten, als ne komplizierte timersteuerung zu bauen.)
> Fuer ne I2C-Slaveroutine (oder Multimaster) ist ein Interrupt allerdings
> noetig.
Ja genau das gab ich gemeint. Zudem sollte man doch noch überprüfen
ob Slave mit dem Timing zurecht kommt, laut Protokoll kann ein Slave
das Takt herauszögern wenn es ihm zu schnell geht.
Thomas Wedemeyer
> Ein CAN Controller zu SPI würde mir gefallen :)
> (gibt es glaub auch .. von Microchip)
Den SAE81C90 von Siemens/Infineon kann man über ein SPI oder paralleles
Interface ansteuern. (Allerdings gab es beim SPI-Interface in der
Chipmaske, die ich mal benutzt habe, irgendeinen Bug den man kennen
sollte...)
--
Love, Peace and Happiness
Thomas
Thomas Wedemeyer | Je planmaessiger die Menschen
EMail: ma...@thomas-wedemeyer.de | vorgehen, desto wirksamer
vermag
WWW: http://www.thomas-wedemeyer.de/ | sie der Zufall zu treffen.
| (F. Duerrenmatt)
Stephan Zehrer
Thomas Wedemeyer schrieb:
> > Ein CAN Controller zu SPI würde mir gefallen :)
> > (gibt es glaub auch .. von Microchip)
> Den SAE81C90 von Siemens/Infineon kann man über ein SPI oder paralleles
> Interface ansteuern. (Allerdings gab es beim SPI-Interface in der
> Chipmaske, die ich mal benutzt habe, irgendeinen Bug den man kennen
> sollte...)
Ja von Bosch gibt es noch den CC750 und von Microchip den MCP2510.
Den von Infi .. hab kannte ich noch nicht.
Sag mal um wieder auf den Fujitsu Chip zu kommen.
Wo kann man den hier so kaufen ?
Thomas Wedemeyer
> Sag mal um wieder auf den Fujitsu Chip zu kommen.
> Wo kann man den hier so kaufen ?
Soweit ich weiss nur bei EBV oder bei Glyn. Wir beziehen unsere
Controller bei Glyn, nachdem wir bei EBV auf wenig interesse gestossen
sind uns welche zu verkaufen.
Thomas Rudolph
>> >Schön wäre über CAN, oder RS485
>> schau mal auf www.lancos.com.CAN hat aber einen ganz schönen
>> Overhead.
>Hab ich gemacht, Overhead ? in wie fern ?
>Ich finde dem seine Implementierung interessant. Er hat ja da
>Protokoll in Software gegossen und direkt eine Transivera an
>dem MCU betrieben, ich würde auf jedenfall eine Controller davor
>schalten.
also dann schau Dir das CAN-Protokoll mal genau an , das ist m.E. nach
doch recht umfangreich für kleine Projekte.Ist aber alles relativ, das
ist halt meine Persönliche Meinung, ich hab auch schon Software mit
CAN-Protokollen geschrieben.
>
>> Ich bau auch grad sowas, eine Art UNI-AVR-Platine. Die 32 I/O-Pins
>> wollen aber erstmal alle sinnvoll belegt sein, da kommt man schon eine
>> Weile mit hin.
>Hört sich interessant an, hast Du dazu was Dokumentiert im Netz ?
>Genau so was in der Art hab ich mir nämlich auch vorgestellt.
Also solche Projekte gibts etliche im Netzt, meines hab ich noch nicht
dokumentiert, aber die Grundideen hab ich auch nur von anderen
Projekten abgeschaut, da ist nichts besonderes dran.
>
>> Dessenungeachtet will ich auch mit Steckmodulen arbeiten , die über
>> SPI angebunden sind .
>Über spi muß ich mich noch schlau machen. Was willst Du auf diesen
>Steckmodulen unterbringen ?
>Welche andere Hardware (außer MCU und EEPROMS) unterstützen
>denn noch SPI ?
Mit SPI kann man erst mal zwischen verschiedenen CPUs Daten
austauschen,insbesondere wenn die CPUs das SPI Hardwaremäßig
mit TX-Ready Interrupts und SlaveSelect unterstützen, wie es die
AVRs machen.
Ich hab z.B. ein Modul mit Wettersensoren , Höhen/Luftdruckmessung,
eins für GPS-Daten,Funkschnittstelle etc. Die Schaltungen/Projekte
gibs alle schon etliche male im Netz. Meine Hauptanwendung ist ja der
Amateurfunk. Gibt da interessante Projekte u.a. auf www.tapr.org .
Es ist nur kein Projekt genau so wie ich es haben will , also rühr ich
mir aus allen Zutaten eine eigene Suppe zusammen ;-)
Es gibt die Ramtron-FRAMS mit SPI (www.ramtron.com) , dann auch noch
etliche A/D-Wandler (Maxim,Analog Devices,LinearTechnologies) . Etc.
etc. , es gibt viele Webseiten mit Aufstellungen aller SPI-ICs. Ich
kann da immer wieder nur den Gebrauch der Suchmaschinen empfehlen, die
URLs wechseln ja auch mal, und ich merk mir das nicht immer alles.
Viele Grüße
Thomas