Datum:
Ich würde gerne eine 1-Wire Slave Application auf einem Atmel Avr realisieren. Der uC soll dabei als Slave im Bus zur verfügung stehen. Das ganze sollte mit dem 1-Wire Protokoll von Dallas kompatibel sein da noch andere 1-Wire Devices am Bus hängen. Leider gibts von Atmel nur eine Application Note für die Implementierung des Masters. Ich würde ungern das Rad neu erfinden. Das hat sicher schonmal jemand gemacht. Hat jemand erfahrung damit und weiss wo ich entsprechenden SOurce COde finden kann?
Datum:
hallo martin, du willst dir also soweit ich das verstehe mit einem mc ein 1-wire-device erstellen. im prinzip ist das doch nicht schwerer, als den mc als master zu programmieren. brauchst doch die selben routinen nur das du halt den portpin nun abtasten musst, ob ein reset ansteht und das ganze zeug. selbermachen ist doch am schönsten!
Datum:
Es ist fast hoffnungslos. Wenn es nur ein Slave waere, dann koennte man das realisieren, aber wenn da andere Slaves dran haengen, dann hat man mit AVR kaum eine Chance. Timing ist sehr wichtig fuer 1-wire, AVR schafft es nicht. Und es gibt keine vernuenftige Beschreibung, weil es von DS lizensiert ist. Alles was man finden kann ist nur ein Paar Tests.
Datum:
Geht m.E. nur mit etwas Nachilfe in Form externer Hardware, die ggf. den 1µs-Impuls vom Master latched. Ansonsten müsste der AVR garantiert binnen 1µs reagieren können, was sich schwer garantieren lässt, wenn der noch was anderes tun soll.
Datum:
Hmm. Vielleicht mit Hilfe vom USI, so vorhanden. Der start condition detector könnte sich missbrauchen lassen um den Impuls zu latchen, und ein timer mit input capture kriegt raus, wie lange das schon her ist. Damit könnte es gehen. Trotzdem haarig.
Datum:
Wäre denn der ordinäre externe Interrupt nicht für den 1µs-Impuls geeignet?
Datum:
Beim Lesen zieht der Master für 1µs auf 0. Der Slave muss dann binnen dieser 1µs den Pin selber auf 0 ziehen, wenn er eine 0 zurückgeben will, oder er lässt den Pin in Ruhe bei einer 1. In Software ist diese Reaktionszeit schlecht zu gewährleisten.
Datum:
hallo, wo habt ihr die 1us her. schau ich mir die timmingbeschreibung von maxim an, finde ich diese bedingung nicht. ich gehe davon aus, das man die devices nicht im overdrive modus betreibt. z.b. um auf den presence puls zu reagieren, hat man genügent zeit. Die erst phase ist ca. 600us und detektiert wird bei 610us. avr kenn ich perönlich nicht. aber der takt wird doch sicher auch bei 20mhz liegen. schwirig ist eher, das das timing zwischen min und max werten läuft. hier würde ich auf masterseite den ds2482-100 empfehlen, der sich ums timing kümmert und nicht die onewire schnittstelle sleber realisieren.
Datum:
Habe das seit ein paar Wochen am laufen für einen Tiny13 und Mega8. Hat allerdings noch einen kleinen Bug (gelegentlich antwortet der nur mit FFs, gibt dann aber CRC Error, kann aber auch am Netzwerk liegen), aber funktioniert prinzipiell in einem Netzwerk mit mehreren DS1820. Kann ich heute abend mal reinstellen. Ist aber noch Alpha status. Gruss Axel
Datum:
"wo habt ihr die 1us her." Die stehen doch im Datenblatt. Der Master muß für mindestens 1µs Low anlegen, um dem Slave zu sagen, daß er ein Bit lesen will. Und der Slave muß dann dieses Low für min 15µs strecken, wenn er ein 0-Bit ausgeben will. Der Master gibt also für 1µs low und irgendwann innerhalb 14µs liest er den Pin zurück. Nur mit dem USI der ATTinys kann man das realisieren. Ist kein Original-Slave mit dran, könnte man sich darauf einigen, daß der Slave innerhalb von 10µs auf low ziehen muß und der Master erst nach 10µs ausliest. Dadurch reduziert sich natürlich auch die maximal mögliche Leitungslänge. Peter
Datum:
hallo peter, das timing lässt sich gut aus dem datenblatt zum DS2482-100 ablesen. dort steht, das der master nach ca. 14us (typischer wert), den zustand auswertet. also muss ich nach feststellen der negativen flanke bis dahin meinen zustand stabil haben. bei den devices, z.b. dem ds2433 wird das fenster für die detektierung mit trvd - tlowr angeben. wie man daraus sieht, stellt der ds2482-100 den zustand zimlich am ende erst fest. so schlägt maxim das ja auch vor, wenn man sich den master mit einem portpin selber schustert. Man muss sich also nicht einigen, da ja das von maxim geklärt ist und wann dein mc das zurück liest, kannst ja du selber festlegen. ich nutzte den ds2482-100 und hab damit keine probleme.
Datum:
Das One-Wire Timing laesst sich prima mit einem UART erzeugen. Bei Maxim oder Atmel gab eine Applikationsnote dazu.
Datum:
Die Frage ist doch, was ich für einen Master verwende. Digiterm z. B. verwendet den PC UART, das Timing dort kann ich beeinflussen. Das Gleiche gilt, wenn man einen AVR als Master nimmt. Somit sind die 1 us zwar in der Theorie vorhanden, kommen aber praktisch kaum vor. Eigentlich muss man nur die Flanke detektieren und dann das Signal auf den Pin bekommen. Das kann man aber schon vorbereiten, d. h. der Flankeninterrupt kann das direkt nach Aufruf machen. Entscheidend ist, dass man rechtzeitig aktiv wird, bevor der Master das Signal abtastet. Gruss Axel
Datum:
Bei den Dallas-Bausteinen ist das Protokoll in Hardware realisiert. Bei einem Read-Data-Time-Slot zieht der Slave das Signal so nach spätestens einer us auf Masse. Ein integrierter Master (z.B. DS2480) hält das Signal dagegen zu Beginn des Time-Slots 8 us auf Masse. Bei der Masterschnittstelle mittels UART nutzt Dallas für den Read-Data-Time-Slot das Startbit eines 115200 bd Signals, das ungefähr 8,6 us dauert. Da es nicht erforderlich ist, den 1-wire-Bus gleichzeitig vom Master und vom Slave auf Masse legen zu lassen, sollte man für das mit dem "1us-Signal" ohne übertriebene Eile handhaben. Bei einer Dauer von 7 us entsteht auch keine Lücke, in der der Pullup die Leitung auf 1 ziehen könnte. Gruß Joachim
Datum:
@martin Es gibt zum one-wire-slave einige Quellen im Netz: http://lcd.strony.pl/d-109v2.htm http://embeddeddatasystems.com/page/EDS/PROD/IO/DSP7X4 http://www.louisswart.co.za/1-Wire_Overview.html http://home.hetnet.nl/~thomas_7/1Wire/1-WireIOPort.html http://www.alpov.net/elektronika/owslave.html evtl. kannst Du davon etwas brauchen. @axel Du hattest angeboten, deinen Quelltext zu veröffentlichen. Ich bin daran interessiert. Gruß Joachim
Datum:
zitat http://www.mikrocontroller.net/articles/Hausbus : "in Software realisierte Peripherie verstößt gegen US-Patente" Also nicht verklagen lassen bei Veroeffentlichung... gruss, bjoern.
Datum:
@ Joachim, hmm, das mit den Patenten könnte tatsächlich ein Problem sein, wenn ich das hier veröffentliche. Ist vielleicht auch schlicht der Grund, warum ich nirgends ein Programm für so einen Slave finden konnte. Hast Du eine E-Mail Adresse, wo ich das hinschicken kann ? Gruss Axel
Datum:
Hallo Axel, meine email-Adresse ist: joachim.boerke(at)gmx.de Gruß Joachim
Datum:
Hallo Joachim, ich schicke es Dir heute abend, will den Code erst noch ein bischen aufräumen. Gruss Axel
Datum:
Hallo Axel, ich hätte auch interesse an dem Code. Wäre super wenn du ihn mir auch schicken könntest. Email: einer.meiner@lycos.de Danke und Grüße, Joachim
Datum:
Hallo Axel, ich hätte auch interesse an Deinem Code. Könntest Du ihm mir bitte auf diese Adresse schicken: stephan_bauer@gmx.de Danke Grüße Stephan
Datum:
Nun Das mit den Patenten geht so: US-Patente gelten nur in USA! Wenn Du kein Geld damit machst, kannst Du das benutzen. Patente sind keine Geheimnisse... eher das Gegenteil! Was nicht geht: Patent nutzen für eine Sache die verkauft oder vermietet wird.
Datum:
Hallo Axel, so einen Code suche ich doch schon seit Ewigkeiten... Wenn es geht, bitte auch an mich: xtsi@gmx.de Gruss, Henning
Datum:
Ok, ich schieb ihn heute Abend hoch. Ist aber, wie bereits geschrieben, noch Alpha Stadium (funktioniert aber). Gruss Axel
Datum:
Angehängte Dateien:Hier also der Code. Läuft auf einem Tiny13 und einem Mega8. Das kann im Makefile eingestellt werden.Im Tiny13 wird es aber schon sehr knapp und es ist der Timer und der externe interrupt belegt. Ich habe im Haus einen 1-Wire Bus hängen, an dem viele 18B20 hängen, die Tiny13 Variante nutze ich um z. B. Reedkontakte abzufragen. Der Baustein verhält sich im Prinzip wie ein 1820 Temperatur Sensor wobei natürlich keine Temperaturen, sondern die 8 Datenbytes ausgegeben werden, die in "transdata" stehen. Dazu gibt es noch eine adaptierte Digitemp 3.3.2 Source, die zusätzliche Aufrufparameter zum Schreiben der zwei EEPROM Zellen bietet. Gruss Axel
Datum:
dann sind patente nur schutz dieser speziellen sache. die idee selbst ist nicht geschützt. wenn du nicht unbedingt die genauen zeiten brauchst dann fahr das ding auf einer anderen (nicht in den datenblättern spezifizierten) taktrate und schon ist das nicht mehr 1wire konform - aber kompatibel. wenn die z.b. nur zwischen zwei µC aus layout-gründen nur eine leitung ziehen kannst, dann bist du doch nicht an 1wire gebunden. abgesehen davon sind 1µS bei 8MHz takt eines avrs immer noch 8 takte... assembler lässt grüssen.
Datum:
Hallo Axel Wie hast du den Tiny13 beschaltet? Data I/O auf welchem Port, mit externem Transistor? Interner RC-Oszi oder extern? Gruss Mike
Datum:
Hallo Mike, lies doch einmal in "onewire.c" nach. Data I/O liegt an INT0. Die Taktfrequenz sollte 9,6 MHz sein. Ein Transistor ist sicher nicht erforderlich. Bei einem bidirektonalen Anschluß wüsste ich nicht wie das Schaltungstechnisch aussehen sollte? Gruß Joachim
Datum:
Hallo Christian, Du hast recht. Ich hatte mich auf diesen Teil der Datei bezogen:
#define ONEWIREPIN 1 // Pin, an dem der 1-Wire angeschlossen ist, MUSS INT0 sein #define PRESENCEZEIT 15 // Timingdeclarationen für 9,6 MHz #define PRESENCEWAITZEIT 2 #define ABTASTZEIT 3 // Abtastzeitpunkt beim empfangen #define SENDEZEIT 5 // Dauer des 0-Sendeimpulses |
Die 17% Abweichung sind dann offensichtlich nicht kritisch. Gruß Joachim
Datum:
Hallo zusammen, hab mir eine ATTiny13 besorgt, scheint aber nicht zu funktionieren. Kann es sein das "SKIP_ROM" nicht richtig unterstütz wird ?
Autor:
Christian H.
(netzwanze)
Datum:
Nicht ganz richtig. Korrekt ist es wenn man das Wort "richtig" streicht. Es werden nur folgende Kommandos unterstützt: MATCHROM READ SCRATCHPAD WRITE SCRATCHPAD
Datum:
wenn ich per SKIP_ROM alle DS18B20 abfrage, reagiert der ATiny aber und verstümmelt die Daten bzw. der Bus bricht ab. Der 1-Wire Master schickt auch noch ein "SEARCH ROM [F0h]" Kommando beim einlesen der DS18B20, evtl. reagiert der ATiny darauf. Im Code ist "SEARCHROM" ist zwar definiert, aber nicht benutzt.
Datum:
erwind schrieb: > wenn ich per SKIP_ROM alle DS18B20 abfrage, reagiert der ATiny aber und > verstümmelt die Daten bzw. der Bus bricht ab. Mit SKIP-ROM darf man nur einen Dallas-Baustein am Bus haben. Dieser fühlt sich dann ohne Seriennummern-Check angesprochen.
Datum:
hab im Master nachgeschaut - CONVERT T [44h] wird mit SKIP ROM [CCh] angefordert. Nach etwa 1s wird mit SEARCH ROM [F0h] nach den IDs der DS18(S,B)20 Sensoren gesucht, diese werden dann gezielt mit READ SCRATCHPAD [BEh] + ID aus dem vorhergehenden SEARCH ROM [F0h] Commando ausgelesen. Das Tut alles seit Jahren, ich brauche aber ein paar Eingänge, so bin ich auf die ATiny Geschichte hier gestossen. Läuft das tatsächlich bei jemandem am Bus zusammnen mit anderen Dallas Bausteinen ? Welche Komando-Reihenfolge führt zum Ziel ?
Datum:
Wow, so viel Aktivität bei einem 4 Jahre alten Beitrag :-) Ich hatte SKIP ROM nie verwendet, allerdings sollte es trotzdem keine Störungen machen. Allerdings hatte ich mal Probleme mit dem RESET nach Übertragsungsfehlern, die aber nur alle paar Wochen bei mir Probleme gemacht hatten. Ich könnte mir aber vorstellen, dass das genau diese Symptome zeigt, weil Übertragunsfehler und unbekannte Opcodes aus Sicht der Software ja im Prinzip das Gleiche sind. Ich werde das die Tage mal raussuchen, vorher schaffe ich es leider nicht. Gruss Axel
Datum:
Hier mal ide aktuelle Variante. Habe da einiges angepasst, um die
Störungen wegzukriegen, bin aber nicht sicher, ob das auf einem ATTINY
noch läuft, da ich das nur noch auf einem ATMEGA laufen lasse.
So läuft das aber seit drei Jahren ohne Fehler.
// Timer interrupt routine
#ifdef _AVR_ATtiny13_
ISR (TIM0_OVF_vect)
#elif defined (_AVR_ATmega8_)
ISR (TIMER0_OVF_vect)
#endif // Port als Ausgang
{
unsigned char tim0_i, status;
signed int temperaturwert, temperaturwert_bruch;
TIMSK0 &= ~(1 << TOIE0); // Timer Interrupt aus
status = status_global;
#ifdef _AVR_ATtiny13_
DDRB &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
DDRD &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#endif
if (status == RESET){
#ifdef _AVR_ATtiny13_
DDRB |= (1 << ONEWIREPIN); // Pin auf Ausgang
#elif defined (_AVR_ATmega8_)
DDRD |= (1 << ONEWIREPIN); // Pin auf Ausgang
#endif
status = PRESENCEPULSE;
bitcount = 0;
TCNT0 = ~PRESENCEZEIT; // Neu Starten zum bestimmen der
Presencepulselaenge
TIFR0 |= (1 << TOV0);
TIMSK0 |= (1 << TOIE0); // Timer Interrupt an
}
else if (status == PRESENCEPULSE){ // Presence Puls zu ende,
Timer INT aus, Pin auf Eingang, warten auf Opcode
status = RECEIVE_OPCODE;
bitcount = 0; // TINT wird oben ausgeschaltet
}
else if (status & (RECEIVE_OPCODE | MATCHROM | WRITEMEM)){
bitcount++;
if (bitcount == 1) {
transbyte = 0;
}
transbyte = transbyte >> 1;
if (PIND & (1 << ONEWIREPIN)){
transbyte |= 0x080;
}
if (bitcount == 8){
if (status == RECEIVE_OPCODE) {
if (transbyte == 0x55){ // 0x55 -> Matchrom
status = MATCHROM;
transbyte = 0; // New
}
else if (transbyte == 0x4E){
status = WRITEMEM;
transbyte = 0;
}
else if (transbyte == 0x48){ // Write data to
EEPROM
status = WRITEMEM;
transbyte = 0;
}
else if (transbyte == 0x48){ // Write data to
EEPROM
for (tim0_i = 2; tim0_i < 4; tim0_i++){
while(EECR & (1<<EEPE)) ;
/* Set Programming mode */
//EECR = (0<<EEPM1)|(0>>EEPM0);
/* Set up address and data registers */
EEARL = tim0_i; // EEPROM
Address
EEDR = transdata[tim0_i];
/* Write logical one to EEMPE */
EECR |= (1<<EEMPE);
/* Start eeprom write by setting EEPE */
EECR |= (1<<EEPE);
}
status = IDLE;
transbyte = 0;
}
else if (transbyte == 0xBE){ // Daten lesen
status = READMEM;
shift_reg = 0; // Schiebergister für
CRC loeschen
transbyte = transdata[0];
}
else {
status = IDLE;
}
bitcount = 0;
bytecount = 0;
}
else if (status == MATCHROM){
if (bytecount == 0){
if (transbyte == FAMILYCODE);
else status = IDLE;
}
else if (bytecount < 7){
if (transbyte == DEVICEID) ;
else status = IDLE;
}
else { // Byte 8
status = RECEIVE_OPCODE; // Eigentlich
CRC checken, aber wozu ?
}
if (status == IDLE){
bytecount = 0;
}
bytecount++;
bitcount = 0;
}
else if (status == WRITEMEM){
if (bytecount == 0){
onewire_cmd1 = transbyte;
transdata[2] = transbyte;
}
else {
onewire_cmd2 = transbyte;
transdata[3] = transbyte;
status = RECEIVE_OPCODE;
bytecount = 0;
}
bytecount++;
bitcount = 0;
}
}
}
else { // status == READMEM oder rest
#ifdef _AVR_ATtiny13_
DDRB &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
DDRD &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#endif
}
status_global = status;
}
// Flankenerkennung am 1-Wire pin, entsprechend wird dann dei Aktion
ausgewählt
ISR (INT0_vect)
{
unsigned char tim0_i, status;
status = status_global;
#ifdef _AVR_ATtiny13_
DDRB &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
DDRD &= ~(1 << ONEWIREPIN); // Pin auf Eingang
#endif
#ifdef _AVR_ATtiny13_
if (PINB & (1 << ONEWIREPIN)){ // Steigende Flanke am One Wire
#elif defined (_AVR_ATmega8_)
if (PIND & (1 << ONEWIREPIN)){ // Steigende Flanke am One Wire
#endif
if ((TCNT0 < 0xE0) && (TCNT0 > 35)) { // Reset pulse wenn
Puls >30 und < F0 geaendert auf 35
TIFR0 |= (1 << TOV0); // Timer
Overflow loeschen
TCNT0 = ~PRESENCEWAITZEIT; // Timer
Neu Starten Fuer Presencepulse
TIMSK0 |= (1 << TOIE0); // Timer Interrupt an
status = RESET;
}
}
else { // Fallende Flanke am
One Wire
if (status == READMEM){
if ((transbyte & 0x01) == 0){
#ifdef _AVR_ATtiny13_
DDRB |= (1 << ONEWIREPIN); // Pin auf Ausgang
#elif defined (_AVR_ATmega8_)
DDRD |= (1 << ONEWIREPIN); // Pin auf Ausgang
#endif
}
TIFR0 |= (1 << TOV0); // TimerOverflow loeschen
TCNT0 = ~SENDEZEIT;
TIMSK0 |= (1 << TOIE0); // Timer Interrupt an
fb_bit = (transbyte ^ shift_reg) & 0x01; // CRC
berechnen
shift_reg = shift_reg >> 1;
if (fb_bit)
shift_reg = shift_reg ^ 0x8c;
bitcount++;
transbyte = transbyte >> 1;
if (bitcount == 8){
bitcount = 0;
bytecount++;
if (bytecount == 8){
transbyte = shift_reg; // CRC senden
}
else if (bytecount == 9) status = IDLE; // CRC
senden
else transbyte = transdata[bytecount];
}
}
else if (status == IDLE) { // Erste fallende Flanke
TIFR0 |= (1 << TOV0); // TimerOverflow loeschen
TIMSK0 &= ~(1 << TOIE0); // Timer Interrupt aus
TCNT0 = 0;
// status = RESET; // Erste fallende Flanke
nach Idle, Timer nutzen um Länge des Pulses zu messen
}
else if (status & (RECEIVE_OPCODE | MATCHROM | WRITEMEM)){
TCNT0 = ~ABTASTZEIT; // Zeichen abtasten in
ABTASTZEIT
TIFR0 |= (1 << TOV0); // TimerOverflow loeschen
TIMSK0 |= (1 << TOIE0); // Timer Interrupt an
}
else if (status == RESET) { // Da hat ein anderer
einen Presence Pulse gesendet, da haengen wir uns dran
// DDRD |= (1 << ONEWIREPIN); // Pin auf Ausgang
status = PRESENCEPULSE;
bitcount = 0;
TCNT0 = ~PRESENCEZEIT; // Neu Starten zum bestimmen
der Presencepulselaenge
TIFR0 |= (1 << TOV0); // Timer OVF loeschen
TIMSK0 |= (1 << TOIE0); // Timer Interrupt an
}
else if (status == PRESENCEPULSE); // Gar nichts tun,
Pegeländerung kommt vom eigenen Timer beim Senden oder anderen
else {
status = IDLE;
TCNT0 = 0;
TIFR0 |= (1 << TOV0); // TimerOverflow loeschen
TIMSK0 &= ~(1 << TOIE0); // Timer Interrupt aus
}
}
status_global = status;
}
Datum:
Angehängte Dateien:hab das mal in den Ur-Code eingepflegt, komme aber erst Morgen zum testen. Danke schon mal AVR Memory Usage ---------------- Device: attiny13 Program: 958 bytes (93.6% Full) (.text + .data + .bootloader) Data: 15 bytes (23.4% Full) (.data + .bss + .noinit) Build succeeded with 6 Warnings...
Datum:
Ich habe mich an dem Code mal ausgelassen. Jetzt läuft er bei mir (Boarduino, d.h. atmega168) stabil, kann SEARCH_ROM, lässt sich debuggen (via interruptgesteuertem UART-Output), passt dafür aber nicht mehr in den attiny13 rein (nichtmal wenn man die neuen Features weglässt). Dagegen werde ich noch was tun müssen. :-/ Bei Interesse: Mail an mich. Sobald einigermaßen fertig, veröffentliche ich's auf github, damit Andere sich auch daran auslassen können. Ach ja: Axel: Ich hoffe, du hast nichts dagegen; dein Code hatte kein Copyright und stand nicht unter GPL oder Ähnlichem ...
Datum:
>Ach ja: Axel: Ich hoffe, du hast nichts dagegen; dein Code hatte kein >Copyright und stand nicht unter GPL oder Ähnlichem .. Is scho recht :-) Gruss Axel
Datum:
Code ist hier: http://github.com/smurfix/owslave SEARCH_ROM funktioniert, die Grundfunktion eines DS2408 und eines DS2423 sind als Proof-of-concept implementiert, wenn auch noch ohne externe Anschlüsse. Passt momentan leider nur in AVRs ab 4k Flash; den Code wieder auf 2k runterzubringen dürfte möglich sein, 1k ist nicht besonders realistisch (u.A. wegen der CRC-Berechnung). Ich freue mich auf Mitarbeit.
Datum:
Bjoern M. schrieb: >> http://www.mikrocontroller.net/articles/Hausbus : >> "in Software realisierte Peripherie verstößt gegen US-Patente" > > Also nicht verklagen lassen bei Veroeffentlichung... > > gruss, bjoern. Hallo, kann diesen Abschnitt jemand mit einer Quelle belegen? Gruß, Alexander
Datum:
Hallo, wenn ich versuche den Code von smurfix im AVR Studion für einen ATmega8 zu kompilieren, bekomme ich folgende Fehlermeldung(en): Build started 22.7.2010 at 11:14:02 avr-gcc -mmcu=atmega8 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT onewire.o -MF dep/onewire.o.d -c ../onewire.c ../onewire.c: In function 'setup': ../onewire.c:170: error: 'EIFR' undeclared (first use in this function) ../onewire.c:170: error: (Each undeclared identifier is reported only once ../onewire.c:170: error: for each function it appears in.) ../onewire.c: In function 'set_idle': ../onewire.c:428: error: 'EIFR' undeclared (first use in this function) ../onewire.c: In function '__vector_9': ../onewire.c:455: error: 'EIFR' undeclared (first use in this function) ../onewire.c: In function '__vector_1': ../onewire.c:677: warning: overflow in implicit constant conversion make: *** [onewire.o] Error 1 Build failed with 5 errors and 1 warnings... Leider kann ich damit nichts anfangen, da in den betreffenden Zeilen immer nur IFR |= (1 << INTF0); steht. Für jede Art von Hilfe bin ich dankbar. Gruß, Dieter
Datum:
Alexander schrieb: > Hallo, kann diesen Abschnitt jemand mit einer Quelle belegen? Irgendwo hier wirst du bestimmt fündig, auch wenn sich das eher als Belegungsplan eines Krankenhauses liest: http://www.1wire.org/Files/Patents/Dallas.htm
Datum:
Mit WinAVR ist das EIFR Problem gelöst. Ja das ist aber jetzt nicht so super. Ich habe einen ziemlich langen Beitrag über die Verwendung der Arbeit von smurf geschrieben und vor dem Abschicken noch auf das Lesen der Nutzungsbedingungen geklickt, womit mein Beitrag weg war. Klar, ich bin schon ein ..., wenn ich Nutzungsbedingungen lese, aber das weiss ich. Mein Beitrag zusammengefasst: Smurfs Arbeit, aufbauend auf der Arbeit von Axel, erachte ich als professionelle Basis für weitere Arbeiten.
Datum:
Hallo, > Smurfs Arbeit, aufbauend auf der Arbeit von Axel, erachte ich als > professionelle Basis für weitere Arbeiten. Danke für die Blumen. Ich muss dringend die Änderungen von taliesin in meine Version einpflegen (siehe github, http://github.com/smurfix/owslave/network). Hoffentlich komme ich demnächst dazu. :-/
Datum:
( ... in den Raum ruf ... ) Ist dieser Fred noch aktuell resp. wird an dem Projekt noch gewerkelt? Egal ob oder ob nicht: http://www.brain4home.eu scheint mit Dallas keine Probleme zu haben / zu befürchten. Denn was die da cooles machen, ist ja im Grunde vergleichbar, nur halt fertig (zumindest der BAE0910). Sowas wie die derzeit als BAE0911 stricken auf einem AVR gepackt wäre echt eine supercoole Sache und sicherlich ein lohnendes Projekt; oder gibts das schon? Dann ist es mir entgangen...
Datum:
Scheint dieser oder ein PIN kompatibler FreeScale "MC9S08SH32" zu sein, der da verwendet wird (großes Board).
Datum:
stimmt sogar, ich hatte PINs verglichen um den Typ zu finden ... Ich habs eben gerade in der Doku gefunden: MC9S08SH8 im SOIC-8 für das kleine Modul. MC9S08SH16/MC9S08SH32 im SOIC and TSSOP 28 für das große Modul. Na dann kann das Reverse Engineering ja losgehen ... (ich hab von FreeScale Null Ahnung)
Datum:
Das scheint ein 1-Wire Master zu sein. Da gibt es keine Probleme mit. Dallas verfolgt meines Wissens nur Slave Implementierungen. Wobei Patente sowieso nur die kommerzielle Verwertung verbieten, so dass einem Einsatz im eigenen Haus wohl nichts entgegensteht. Gruss Axel
Datum:
... hmmm? Definitionssache? ;) Ich halte das für einen Slave. So ist es ja auch konzipiert. Ok, wenn ich das richtig verstanden habe, könnte der auch als Master tätig werden, da ja auch eigene Routinen im System abgelegt werden können (wohl in Zukunft in einer Art Basic), aber das ist ja nicht der Zustand "out of the box" ... Aber ist ja eh alles Banane, da hier ja niemand sowas für kommerzielle Zwecke einsetzen wird ;)
Datum:
Stimmt, man muss ja nur das Datenblatt öffnen, da steht auf der ersten Seite, dass das ein Slave ist. Gruss Axel
Datum:
Hi, > > Ist dieser Fred noch aktuell resp. wird an dem Projekt noch gewerkelt? > Aktuell werkle ich an diesem Projekt nicht, weil keine Zeit dafür. Irgendwann ändert sich das aber wieder … Hauptproblem ist übrigens, dass der aktuelle Code stark CPU- und taktabhängige Timingparameter hat, die man ohne gutes Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann. :-/ NB, dieses BAE0910-Projekt klingt interessant, aber wenn die nackte CPU 15€ kostet, fängt es schon wieder an schwierig zu werden. Da kriege ich fünf Atmel für, zumal es die auch im DIL-Gehäuse gibt -- zum Basteln doch etwas einfacher als SOIC und Konsorten.
Datum:
Matthias Urlichs schrieb: > die man ohne gutes Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann. ... hmmm, so teuer sind die nicht mehr, je nach dem, was du unter "gut" verstehst; wo kommst du denn weg? BTW: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=... > aber wenn die nackte CPU 15€ kostet Ebend, nicht nackend. Daher ja meine Idee, sowas oder sowas ähnliches in einen AVR zu packen; was braucht man denn meisst? Einen Knecht, der schalten und Sensorik erkennen kann, der autark ein oder mehrere PWM generiert, wobei der Master ihm halt z.B. sagt "mach ma 25%DC" und ggf. autark noch nebenher kleinen Code ausführen kann. Dann das ganze in einen Tiny45, einen Tiny44 und ggf. in einen "Dicken" und feddich ist ein universelles Werkzeugs für uns Frickler ;)
Datum:
Michael Buchholz schrieb: > Matthias Urlichs schrieb: >> die man ohne gutes Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann. > > ... hmmm, so teuer sind die nicht mehr, je nach dem, was du unter "gut" > verstehst; wo kommst du denn weg? Das Problem sind nicht die 300€ (nebenbei bemerkt gibt es vernünftige schnelle USB-Messwandler mit brauchbarer Oszilloskop-Software für die Hälfte, und die können mehr. PS: das Zeug, was Conrad als PC-Oszi anbietet, ist alles Andere als brauchbar.) Das Problem ist, dass ich mich als Bastler bei diesen Teilen auf was Anderes konzentrieren mag als darauf, das 1wire-Bustiming hinzufrickeln -- zumal ich zum Prüfen sämtlicher Funktionen, die das Teil eigentlich übernehmen können muss, keinen Oszi brauche, sondern mit einem simplen Multimeter auskomme. Ich gebe gerne zu, dass meine Lösung genau das noch nicht leistet. Andererseits: wenn's erstmal läuft, ist das Anbinden von eigenem Code (Funktion X => empfange Y und sende Z, und so) ziemlich einfach. Um Einiges einfacher, als dem OWFS-Code dessen Ansteuerung beizubringen ...
Datum:
Angehängte Dateien:-
mikrocontroller.jpg
58,1 KB, 236 Downloads -
schaltplan.pdf | anzeigen
33,9 KB, 99 Downloads
Bin vor ein paar Wochen zufällig auf diesen Thread gestossen. Eigentlich suchte ich ja Beiträge zum DS 2423. Herausgekommen ist folgende Platine mit einem Attiny44. Als Software Basis wurden die Versionen von smurfix und taliesin verwendet. Hinzugefügt wurde der ATtiny44 und einige Änderungen im SourceCode. Auslesen mit Digitemp .. total easy (1Wire Adapter USB9097) win2000@AMDX2:~/digitemp-3.6.0$ ./digitemp_DS9097U -i -s /dev/ttyUSB0 DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Turning off all DS2409 Couplers . Searching the 1-Wire LAN 1D89E1C34CBE42B7 : DS2423 4Kbit RAM + Counter ROM #0 : 1D89E1C34CBE42B7 Wrote .digitemprc win2000@AMDX2:~/digitemp-3.6.0$ ./digitemp_DS9097U -a -s /dev/ttyUSB0 DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Oct 10 08:27:10 Sensor 0 #0 31 Oct 10 08:27:10 Sensor 0 #1 51 win2000@AMDX2:~/digitemp-3.6.0$
Datum:
Das freut mich. Kannst du mir deine Änderungen schicken? (Direkt auf github wäre noch besser. ;-)
Datum:
Angehängte Dateien:Matthias Urlichs schrieb: > Das freut mich. Kannst du mir deine Änderungen schicken? > (Direkt auf github wäre noch besser. ;-) Natürlich, kein Problem. als Diff Vergleich zur taliesin-Basis (Datei aenderungen) und als kompl. Directory (tiny44.zip) Folgende Datein wurden geändert: - avr.h - ds2423.c - features.h - Makefile - onewire.c - onewire.h Falls Interesse besteht. Die Platine wurde unter Kicad entwickelt. Kann auch diesen Teil hier noch posten.
Datum:
kicad ist super, das verwende ich auch, immer nur her damit. freu Ich hoffe, ich komme dieses Jahr noch dazu, die ganzen Änderungen diverser Leute in das öffentliche Archiv einzupflegen. :-/ NB: Ich finde es faszinierend, dass das Timing offenbar auf Anhieb passt; da hatten Andere schon schlechtere Erfahrungen.
Datum:
Timing war kein Problem. Habe es mit mehreren 1 Wire Adaptern mit 8 und 16 MHz ausprobiert. Keine Probleme aufgetreten.
Datum:
Hallo, wer kann mir helfen damit ich die Dateien auf einem WinXP mit WinAVR und AVRStudio zu kompilieren. Es kommt z.B diese Fehlermeldung: ../ow_slave.c:170: error: 'EIFR' undeclared (first use in this function) Wie muss ich das Makefile umschreiben damit es auf WinAVR läuft? Wie funzt das mit dem gen_eeprom Danke und Gruß Mario
Datum:
Mario schrieb: > Hallo, > > wer kann mir helfen damit ich die Dateien auf einem WinXP mit WinAVR und > AVRStudio zu kompiliere Deine Frage ist eher eine fürs GCC-Forum.Bitte mach dort einen neuen Thread auf und beziehe dich dann auf diesen Code hier. Sonst wird dieser Thread zugemüllt mit Dingen die hier keiner sucht und wissen möchte.
Datum:
Angehängte Dateien:hier mal die Dateien für den Tiny44 Flash: ds2423.hex eeprom: ds2423.eeprom Fuse-Bytes: Highbyte = 0xDD, Lowbyte = 0XE2, Extended = 0xFF
Datum:
Hallo Günter, vielen Dank, hast du mir auch Hex-Files und EEProm für einen atmega8, den hab grad zur Hand und will eigentlich nur mal das ganze one-wire ausprobieren. Danke und Gruß Mario
Datum:
Mario schrieb: > Hallo Günter, > > vielen Dank, hast du mir auch Hex-Files und EEProm für einen atmega8, > den hab grad zur Hand und will eigentlich nur mal das ganze one-wire > ausprobieren. > > Danke und Gruß > Mario Hallo Mario, nein für den atmega8 nicht. Pin-Interrupt geht so mit dem atmega8 nicht. Da dürften weitere Änderungen im Source-Code notwendig werden. Besser würde da ein atmega88 passen.
Autor:
Jörg Wunsch
(dl8dtl)
(Moderator)
Datum:
Mario schrieb: > ich hab mal beim C geschaut, den Attiny44 und atmega88 gibts nicht im > DIL. Dann kauf woanders. Selbstverfreilich gibt's beide ICs im DIL-Gehäuse.
Datum:
Mario schrieb: > Hallo Günter, > > ich hab mal beim C geschaut, den Attiny44 und atmega88 gibts nicht im > DIL. > Im File avr.h sind doch viele Typen definiert unter anderem auch der > Atmega 8. > > Gruß > Mario bei CSD gibt es den attiny44 für 2,39 Euro im DIL Gehäuse
Datum:
Habe noch ein paar leere Platinen. Bitte Boardmail an mich falls Interesse besteht. Gehen zum Selbstkostenpreis von 5 Euro + Versand raus.
Datum:
Hallo, nun muss ich diesen Beitrag doch noch einmal rauskramen :-) Ich habe obigen Code von Axel auf meinem ATtiny85 erfolgreich zum Laufen gebracht und gebe derzeit (Dummy)-Messwerte an meinen Haupt-Controller aus. Wenn ich nun zusätzlich den Timer1 starte und den entsprechenden Timer-Overflow aktiviere, so treten Aussetzer in der One-Wire Kommunikation auf. Je kleiner der Prescaler (also je öfter ein solcher Overflow) desto frequentierter diese Aussetzer. Das Problem tritt auch dann auf, wenn die Interruptroutine nur ein ";" enthält, also vernachläsigbar kurz sein sollte. Mein derzeitiges Hauptprogramm besteht derzeit nur aus einer leeren Schleife, macht also nichts. Mit dem Timer1 möchte ich später eine kleine LED für eine gewisse Zeit nach einer erfolgreichen Übertragung leuchten lassen. Ich bin mit meinem Latein wirklich am Ende und habe keine Ahnung, wo ich den Fehler suchen soll... Für einen kleinen Denkanstoß wäre ich sehr dankbar :-) Hier noch die Initialisierung:
int main(void) { TCCR0B |= (1<<CS00)|(1<<CS01); TCCR1 |= (1<<CS10)|(1<<CS11); GTCCR = 0; TIMSK |= (1<<TOIE0)|(1<<TOIE1); GIMSK |= (1<<PCIE); DDRB |= (1<<PB3)|(1<<PB4); // LED's status_global = IDLE; // USI_TWI_Master_Initialise(); sei(); while(1) {} } |
Vielen Dank schonmal !! Gruß Christoph
Datum:
Hi Christoph, ich habe zufälligerweise genau das selbe letzte Woche gemacht. Bin aber leider noch nicht zum testen gekommen. Wo sind deine Interrupt Routinen? Verwendest du ISR_NOBLOCK?
Datum:
Das Problem: der Interrupt-Wrapper (also der Maschinencode vor- und nachher) ist ziemlich lang; er sicher so gut wie alle Register, egal ob sie gebraucht werden oder nicht. Das bringt das Timing im Zweifelsfall zu sehr durcheinander. (1wire ist diesbezüglich leider ziemlich kritisch.) Evtl. reicht es, gleich am Anfang der Routine Interrupts wieder zu ermöglichen (entsprechendes Bit setzen …), anstatt darauf zu warten, dass das der Maschinencode am Ende der ISR tut. Wenn das auch nicht reicht, muss wohl ein wenig Assemblerprogrammierung her, zusammen mit anderen Compiler-Optionen (-mcallee-saves und Konsorten). Die darf man aber nur für die ISR verwenden, für sonst nix.
Autor:
Jörg Wunsch
(dl8dtl)
(Moderator)
Datum:
Matthias Urlichs schrieb: > Das Problem: der Interrupt-Wrapper (also der Maschinencode vor- und > nachher) ist ziemlich lang; er sicher so gut wie alle Register, egal ob > sie gebraucht werden oder nicht. Bei einer leeren ISR tut er das nicht. Das von dir beschriebene Verhalten tritt nur auf, wenn man eine Funktion aus der ISR heraus aufruft (die der Compiler nicht inlinen kann), weil er dann davon ausgehen muss, dass die Funktion alle ihr nach ABI zustehenden Register auch modifizieren könnte. Bei ISR_NOBLOCK wäre dieser Vorgang übrigens bereits wieder unterbrechbar (muss man aber mit Vorsicht genießen, bei manchen Interrupts kann das tödlich sein).
Datum:
Zunächst mal vielen Dank für Eure Antworten / Tips! Die "ISR_NOBLOCK"-Option war mir bis dato völlig unbekannt... (man lernt eben nie aus!). Das Ganze scheint tatsächlich mein "Problem" zu lösen. Seit ich die timer1-OVF Routine auf diese Weise unterbrechbar gemacht habe, treten die Übermittlungs-Aussetzer nicht mehr aus. Ich werde mich jetzt mal mit Hilfe der Forensuche näher in die Problematik einlesen, um meinen Horizont diesbezüglich zu erweitern. Wenn ich das richtig verstanden habe, dann kann ich durch die "ISR_NOBLOCK"-Option die Priorität bestimmter ISR-Routinen herabstufen... Vielen Dank auf jeden Fall für Eure Hilfe, da wär ich wohl selber nicht drauf gekommen !!!
Autor:
Jörg Wunsch
(dl8dtl)
(Moderator)
Datum:
Christoph schrieb: > Ich werde mich jetzt mal mit Hilfe der Forensuche näher in die > Problematik einlesen, um meinen Horizont diesbezüglich zu erweitern. Lies doch lieber gleich das Original. ;-) http://www.nongnu.org/avr-libc/user-manual/group__... (Könnte sich gut und gern sogar auf deiner Festplatte befinden.) > Wenn ich das richtig verstanden habe, dann kann ich durch die > "ISR_NOBLOCK"-Option die Priorität bestimmter ISR-Routinen > herabstufen... Nein, es gibt keine echten Interruptprioritäten beim Standard-AVR. Stattdessen werden normalerweise beim Eintritt in die ISR die Interrupts geblockt und mit RETI wieder freigegeben. Die Option ISR_NOBLOCK veranlasst (über ein attribute) den Compiler, ein sei() in die Präambel der ISR einzubauen, sodass die Interrupts sofort wieder (global!) freigeben werden.
Datum:
Hallo Ein Beispiel eines SLAVES, allerdings in ASSEMBLER: Beitrag "1-WIRE SLAVE DEVICE BEISPIELE AVR ASSEMBLER ATmega8" Bernhard
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten