Datum: 11.03.2006 00:34
Hallo, ist es möglich mittels des Hardware TWI einen einfachen I2C Monitor mit dem Mega8 zu realisieren? Er sollte mir alle Daten die auf dem Bus laufen inklusive Adresse zB über die serielle Schnittstelle ausgeben. Habe im Datenblatt leider nix dazu gefunden, wie ich den Mega8 so konfigurieren kann das er auf alle Adressen reagiert. Hat das mal jemand gemacht oder hat sonst eine Idee wie ich einen einfachen I2C Monitor realisieren könnte? Vielen Dank Gruß Philipp
Datum: 11.03.2006 10:40
Nein, das geht nur mit HW-I2C ohne Adreßerkennung, z.B. wie im ATTiny2313. Peter
Datum: 11.03.2006 14:45
Ich habe mir mal sowas auf einem Mega8 gecodet(weil ich diesen noch rumliegen hatte) Benutzt jedoch dir nicht das HW-TWI modul Erkennt start, stop, Ackn und nAckn bedingungen und gibt die zusammen mit den Adressen/Daten über eine 115kBaud RS232 raus. Hab aber schon ewig nicht mehr damit gearbeitet. Meld dich einfach falls du das gebrauchen kannst. cu Hauke
Datum: 11.03.2006 16:17
meld :) Das wäre super wenn dur mir das zukommen lassen könntest. Vielen Dank schonmal Gruß Philipp
Datum: 11.03.2006 16:19
Achso. schafft dein Mega8 damit auch 200KHz? so schnell scheint der Bus hier zu laufen. Bin schon gespannt :) Schönes Wochenende Gruß Philipp
Datum: 11.03.2006 17:22
200 khz geht leider in der vorliegenden Version nicht, weil der rs232 mit 115kBaud zu langsam wäre. Ich hatte mal mit einer version mit einem ft245 usb wandlerchip (bis zu 8Mbaud) angefangen. Hab die aber nicht fertig gemacht. Hatte andere Projekte. cu Hauke
Datum: 11.03.2006 17:54
Ist das Programm in C oder ASM? es kommen ja nicht viele Nachrichten. eiegntlich nur 2-3 und dann ist wieder ruhe. also wenn man das buffert sollte es gehen. Kannst du mir deine Ergebnisse mal zur Verfügung stellen? Gruß Philipp
Datum: 11.03.2006 18:56
Das programm ist in asm, und noch recht krude programmiert (war eines meiner sehr frühen programme) Ich müßte mal durchtesten ob das auch mit 200kHz fubbt cu Hauke
Datum: 11.03.2006 19:09
könntest du es mir zum testen mal zur verfügung stellen? wenn du nicht den source hergeben möchtest würde ja auch das hex file reichen. Vielen Dank Gruß Philipp
Datum: 11.03.2006 19:11
Hätte ich auch gerne !!! Kannste das nicht in die codesammlung stellen ? Gruss Michael
Datum: 11.03.2006 23:48
Angehängte Dateien:Ok Ich habe mich nochmal an den Code drangesetzt und die größten Sünden ausgebügelt. Habe noch den FIFO verbessert. Das Ding läuft jetzt auf nem Mega8 @ 14.7456MHz. So wie es aussieht sind 200 kHz SCL jetzt kein Problem mehr. Früher ware lediglich 50kHz drin (wegen dem UART). Anschlüsse wären: PD2 = SCL PD3 = SDA PD7 = INT RS232 Parameter: 115.200 Baud 8 Datenbit keine Parität 1 Stoppbit Beispiel der Datenausgabe: Start s41aE0aC1np s = Start condition 41 = Adresse ($40 im lesemodus) a = Acknowledged E0 = übertragene Daten a = Acknowledged C1 = übertragene Daten n = not Acknowledged p = Stop condition cu Hauke
Datum: 11.03.2006 23:51
P.S. INT ist nur eine Interuptleitung welche mitüberwacht wurde. i = Interrupt auf low gesprungen I = Interrupt auf high gesprungen cu Hauke
Datum: 12.03.2006 15:08
Super. FIFO klingt für mich nach einem Buffer oder sehe ich das Falsch? Obwohl eigentlich würden sonst die 200KHz ja auch nicht gehen. Kann es leider noch nicht testen, weil ich nur einen 11,059 MHz quarz da hab für korrekte 115K2 Vielen Dank schonmal, da müsste genau das sein was ich gesucht habe. Schönes Wochenende Gruß Philipp
Datum: 12.03.2006 18:22
Angehängte Dateien:Ich habe mal auf 11.0592MHz gepatcht. Funktion ohne Gewähr. cu Hauke
Datum: 13.03.2006 08:11
Hat funktioniert mit 11,0592 war genau das was ich gesucht hatte und hat mir sehr geholfen. Vielen Dank Gruß Philipp
Datum: 21.03.2007 12:32
Mal herauskramen dieser sniffer wäre genau das was ch zur zeit suchen würde nur hab ich ein problem bei mir kommen wilde ausgaben und keine klaren i²c daten auf der rs232 an. problem könnte sein das mein atmega 8 mit 5v läuft und der I2c bus mit 0/3,3v weis jemand hier rat? mfg sven
Datum: 21.03.2007 13:22
:) gerade gestern habe ich diesen Thread auch rausgekramt um mal wieder am Bus zu horchen. Habe es zuhause gerade aufgebaut und es funktioniert. Allerdings ein 5V Bus. Der Sniffer ist echt super hilfreich. Wenn du möchtest kann ich ja mal die Spannung etwas runterteilen und schauen ob es mit rund 3V auch noch funktioniert. Gruß Philipp
Datum: 21.03.2007 14:33
wäre klasse hab aber schon das problem das mein atmega8 sendet ohne das überhaupt ein iic bus vorhanden ist und dort solte er doch gar nix machen oder? evtl pullup down nötig? betreibe ihn auf eienm stk500 board danke sven
Datum: 22.03.2007 01:49
Ja auf einen definierten Pegel musst du die Pins schon bringen. Was genau geht denn nicht bei dir? Teste doch sonst einfach erstmal ob du mit den 3,3V aus deinem System da diese Interrupt Leitung ansprechen kannst. Gruß Philipp
Datum: 22.03.2007 09:51
Problem bei mir ist schon das ich wilde ausgaben auf der rs232 seite bekomme selbst wenn gar kein i²c bus angeschlossen ist. un dich die eingänge auf gnd via 1kohm lege. evtl fuses im spiel? aber die werden doch bei der hex datei mit gesetzt wenn ich micht recht entsinne. sven
Datum: 22.03.2007 12:54
Moin Nun schalte ich mich mal wieder ein. Immer wenn ich den Sniffer einsetze, habe habe ich 2MOhm Pullups am M8 dranhängen. So zum reinen testen der UART verbindung kannst du ja mal den I²C Bus abklemmen. Und dann PD2 PD3 und PD7 an VCC hängen (über je einen 1kOhm Widerstand) Nach dem Reset sollte der M8 das Wort "Start <CR>" an das Terminal Prtogramm senden. Wenn dies schon nicht funtioniert, dann stimmt was an der UART übertragung nicht. Entweder falscher Quarz oder UART-Teiler Einstellung. Oder Falsche parameter im Terminalprogramm (Parity,Stopbit Baudrate) Wenn das "Start" nach dem Reset immer sauber rauskommt, dann schaun wir mal weiter. cu Hauke
Datum: 22.03.2007 14:23
ok alles vergessen das war abolute dummheit von mir!!!! hab jetzt zwar kein gerät da zum sniffen aber es solte gehen.... mein fehler hatten nen atmega32 parallel mit im stk das konnte nicht gehen!!! melde mich sobald das sniffen geklappt hat. auf alle fälle erst mal danke!!! sven
Datum: 26.03.2007 11:23
So nochmal eine kleine rückmeldung der i²c sniffer geht 1a und hat schon viel geholfen danke nochmal an euch für die nette und gute unterstützung nochmal passiert mir sowas nicht g mfg sven
Datum: 26.03.2007 23:15
Hallo, würde mit dem Sniffer auch gerne mal lauschen. Habe aber leider nur folgende Quarze hier 4 MHz, 8 MHz, 16 MHz und einen ausgelöteten 14,318 MHz quarz hier. Lässt sich da was machen ? mit dem 14,318 bekomme ich zwar das Start, aber dann nur noch pppp und sssssss gruß Mario
Datum: 27.03.2007 00:13
Hi Mario Zuerst einmal wodrin läßt du den Mega8 laufen? evt. STK500? Wenn ja dann kannst du den 3.68 MHz Software Takt (software-generated clock) vom STK500 nehmen. Die entsprechenden UART Parameter wären dann:
;RS232 init clr work out UBRRH,work ldi work,0x01 ;für 115.2kBaud ; ldi work,0x02 ;für 76.8kBaud ; ldi work,0x03 ;für 57.6kBaud ; ldi work,0x05 ;für 38.4kBaud out UBRRL,work ldi work,(1<<TXC) out UCSRA,work ldi work,(1<<TXEN) out UCSRB,work ldi work,0x86 out UCSRC,work |
Du brauchst aber nicht unbedingt ein STK500 oder einen Quarz. Der Quarz ist sogar für das Sniffen relativ unerheblich. Das Problem ist, daß pro übertragenem Byte auf dem I²C-Bus mehrere Byte über den UART gesendet werden müssen. Das bedeutet der Sniffer braucht eine hohe UART Geschwindigkeit. Und diese geht nur mit diesen "Ungeraden" Taktgeschwindigkeiten. Ich habe zwar einen FIFO eingebaut, aber bei einem zu hohen Missverhältniss zwischen Eingabe und Ausgabe läuft jeder FIFO voll. Es gibt jedoch einen Trick einem Mega8 mit dem internen Oscilator auf 115kBaud zu bringen. Dazu stellt man den Oscilator auf 8MHz. Danach wird mithilfe des OCCAL-Registers der AVR auf 7,3728MHz untertaktet. Am besten liest man das Oscillator Calibration Register aus, multipliziert diesen Wert mit 0,9216. Das Ergebniss wird dann in den Code eingebracht. Danach muß dann noch die UART Initialisierung so eingestellt werden als wenn man einen 7,3728MHz Quarz dranhängen hat.
;OSCCAL init ldi work,*** ;***=ist das oben angesprochene Ergebnis out OSCCAL,work ;RS232 init clr work out UBRRH,work ldi work,0x03 ;für 115.2kBaud ; ldi work,0x05 ;für 76.8kBaud ; ldi work,0x07 ;für 57.6kBaud ; ldi work,0x11 ;für 38.4kBaud out UBRRL,work ldi work,(1<<TXC) out UCSRA,work ldi work,(1<<TXEN) out UCSRB,work ldi work,0x86 out UCSRC,work |
Danach sollte es auch mit dem Calibrated Internal RC Oscillator gehen. Eine Funktionsgarantie kann ich natürlich nicht geben. Also Anwendung auf eigende Gefahr. Einen Max232 o.Ä. brauchst du aber so oder so für die RS232 Verbindung Ich hoffe geholfen zu haben cu Hauke
Datum: 27.03.2007 07:48
Hallo Hauke, vielen Dank für die Antwort, ja ich lasse einen Mega32 im STK500 laufen. Wie soll ich nun deinen Beispielcode einbauen, ich habe ja nur die HEX Datei von dir. Ich habe zwar die HEX Datei im AVR Studio geladen, aber das ist dann schon etwas gruslig alles zu analysieren. Dann ist die Quarzfrequenz nur für RS232 relevant ? Das Start bekomme ich ja, aber wieso dann nur pppppppp und ssss. viele Grüße Mario
Datum: 27.03.2007 11:02
Ähem Räusper Der Code ist für einen Atmel ATMega8 geschrieben, und zwar in Assembler. Das kann man nicht einfach in einen anderen, nicht pinkompatiblen, Controler packen. Der Mega32 hat ganz andere Pins für die Interrupts usw. Vermutlich gibt es auch eine Kollision zwischen dem FIFO und den IO-Registern. Ich müßte erstmal schauen wie man den Code auf den Mega32 umpatchen müßte. cu Hauke P.S. Ich habe nur die Hexdatei raus gegeben, weil der Source Code ziemlich krude, unübersichtlich und undokumentiert war. Er war mir schlichtweg peinlich. Mittlerweile habe ich ihn aber etwas aufgeräumt. Wenn die Leute vom mikrocontroller.net interressiert sind, dann kann man den Code vieleicht in einem Tutorial veröffentlichen. Die sollen sich einfach bei Interresse melden
Datum: 27.03.2007 19:38
Hallo, ja ok, bisher hat das immer ohne große probleme geklappt, ist aber der warscheinlichste Fehler. Hab mir Heute den Mega 8 bestellt mit passenden quarzen. Bitte Code Veröffentlichen :-) wäre Super. viele Grüße Mario
Datum: 28.03.2007 09:37
hi fände es auch klasse wenn der code veröffentlicht würde! Deien arbeit ist echt spitze! und die einzige die ich bis jetzt gesehen hab die bis gut 200khz geht und noch bezahlbar für hobbyanwender ist! sven
Datum: 28.03.2007 11:33
Hi Prinzipiel habe ich jetzt nichts mehr gegen eine Veröffentlichung. Ich bin den Code nochmal durchgegangen, dokumentiert und einige Umwege beseitigt. Er ist jetzt auch für AVRs mit größerem RAM einsetzbar (d.H. hat dann einen größerem FIFO) Wogegen ich etwas habe ist, das sich irgend so ein Heini sich den Code runter lädt, in einen Chip brennt und diesen dann für teuer Geld an Noobs vertickt. Sowas ist schonmal so bei C64 und Amiga Demos geschehen. Die Firma hat sich einfach den Code abgegriffen und dann für Geld angeboten. Ohne daß die eigendlichen Entwickler gennannt wurden, oder eine müde Mark bekommen hätten. Wenn man mit Copyrights nicht aufpasst dann könnten die dem Coder am Ende noch selbst die Verbreitung untersagen. Ich hab halt keinen Bock das Leute mit meiner Arbeit Geld verdienen ohne selbst einen müden Handschlag dafür gemacht zu haben. (Ich habe aber nichts dagegen wenn mein Tool beim Debuggen eines Hobbyprojektes hilft welches hinterher plötzlich Geld abwirft.) Ich kenne mich halt nicht so gut mit Copyright Bestimmungen aus, und wäre froh wenn die Leute von mikrocontroller.net das Projekt unter irgend eine GPL ähnliche Lizenz stellen könnten. Wäre nett wenn irgend jemand von euch einen der Admins kennen würde. cu Hauke
Datum: 28.03.2007 12:09
Da hste recht kenn ich auch zu gut! im zenega forum haben wir die arbeit gemacht und irgendeiner vertickt die kostenlos verfügbaren artikel bei ebay für 9€. geb dir recht ist ärgerlich werd mal mit unserem forumsinhaber reden der solte in gpl und co sehr fit sein. mlg sven
Datum: 28.03.2007 12:28
Ich kann Hauke nur zu gut verstehen ! Du könntest höchstens ein paar Codeschnipsel der wichtigsten Routinen rausgeben. Ich denke darum geht es den meisten. Um ein lauffähiges Programm zu schreiben bedarf es halt dann doch noch ein bischen Arbeit (und Wissen). Letztlich ist aber deine HEX-Datei völlig ausreichend. Lies doch noch einen DIP-Switch mit aus, um unterschiedliche Baudraten einzustellen, oder pack die Werte ins EEROM. Diesen könnte man dann editieren. Wie bereits gesagt: Ein schönes PROJEKT !!!! LG EC
Datum: 28.03.2007 13:23
Das mit dem EEPROM wäre schon eine gute Idee, nur habe ich noch nicht viel mit dem EEPROM gemacht. Und zum zweiten ist das EEPROM empfindlich gegenüber solchen Tricks mit dem OSCCAL Register. Ich muß mal schauen cu Hauke
Datum: 28.03.2007 13:51
Wenn Du die Lösung mit dem EEPROM wählst, brauchst Du am OSCCAL-Register ja nicht mehr rumfummeln !
Datum: 28.03.2007 13:57
Doch schon. Es gibt immer noch solche Leute die weder einen Baudratenquarz noch STK500 übrig haben. Und dann braucht man für die hohen Baudraten den Trick mit dem untertakteten, internem 8MHz Oszilator. Dann braucht man außer einem Mega8, einem Max232 und ein wenig R und C Gestrüpp nicht für den Sniffer. cu Hauke
Datum: 28.03.2007 14:36
slbst den max232 kann men meist weglasen da die meisten rs232 schnittstellen zumintest auf der rx seite durchaus 0/5v Pegel kompatiebel sind. mein snffer ist nur noch ein atmega 2* 1MOhm 2*22pF un ddier 14,x quarz geht super. eine idea hätte ich ncoh nachdem der atmega ja genug i/o eingänge noch frei hätte könnte man eine adress vorauswahl noch mit einbauen z.b. dip schalter oder auch eeprom sven
Datum: 28.03.2007 14:54
@ Sven F.: "slbst den max232 kann men meist weglasen".... Mhhh.. Wenn schon, sollte man(n) das Ganze doch vernünftig machen. Ich "optimiere" doch auch nicht meine Abblockkondensatoren, Filter oder Sicherungen weg..... Mir dieser Einstellung kannst Du auch Deine beiden 22pF-Kondensatoren streichen. @Hauke: Nungut, aber wenn jemand schon einen Sniffer braucht, gehe ich davon aus, das er sich mit Elektronik beschäftigt. Und ein paar Quarze mit entsprechender Baudratenfrequenz in der Schublade sprengen sicherlich kein Budget, auch wenn`s noch so knapp ist. Zum Thema OSCCAL-Register: Was nützt mir ein Sniffer an dem ich frequenzmässig rumbiegen muss, wenn ich mich doch halbwegs auf die "gesnifften" Daten verlassen will. Mit dem internen Oszillator ist das sowieso so eine Sache. Bei Anwendungen, wo das Timing nicht relevant ist kann man ihn gut benutzen. Aber Anwendngen mit RS232 fallen bei mir unter "Timingrelevant". Lg EC
Datum: 28.03.2007 15:23
@ecslowhand Dem eingendlichen Sniffer ist es egal mit welcher Frequenz er läuft. (Hauptsache Sie ist um einen gewissen Faktor höher als die I²C Frequenz). Es ist nur die UART übertragung die gestört sein könnte. Der Oszilator muß ja nur zu dem jeweiligem Zielcomputer passen. Es muß ja nicht universal sein. Sprich man kann bei Übertragungsfehlern noch trimmen. Ein zweites Stopbit hilft auch sehr gut. Zum Thema Buget und Quarz in der Schublade: Das Design soll ja auch für die Anfänger da sein. Ihr wisst, die Leute die sich mit einem solchen Post melden: "Mein I²C Programm funktioniert nicht" (Post ende) Die haben nicht immer eine Schublade voller Kleinkram. Als ich die erste Version des Sniffers geprogt habe, ging es mir genauso. Ich hatte keinen Baudratequarz da. Und auch kein zweites STK500. Ich werde aber mal mit einer EEPROM Version für Mega8, Mega16 und Mega 32 probieren. cu Hauke
Datum: 28.03.2007 15:54
@Hauke: "Das Design soll ja auch für die Anfänger da sein." Genau, deshalb weniger mit ISP-Einstellungen rumspielen (hier: OSCCAL) sondern eine Hardware die läuft (vorausgesetzt man kann löten ;) ). Ein Anfänger hat kaum (keine) Möglichkeiten, eine nichtfunktionierende Hardware zum laufen zu bekommen. Daher ist eine handvoll STANDARD-Bauteile der einfachste Weg. Lg EC
Datum: 28.03.2007 17:00
Finde deine Arbeit auch echt klasse Hauke. Vielen Dank nochmal dafür hat mir schon sehr viel geholfen. Ich kann deine Bedenken auch voll nachvollziehen, du hast es mir ja damals einfach angepasst für meinen Quarz und seitdem bin ich super damit zufrieden. Ich denke den meisten würde es auch langen, wenn man einfach ein HEX File für ein paar gebräuchliche Quarze erstellt. Was das Nachbauen betrifft, so hatte ich auch schon vor das ganze nicht nur auf meinem Steckbrett immer kurz aufzubauen, sondern eine kleine Platine zu ätzen und das so zu benutzen. (Mit HEX File wäre ein ebay oder sonstwas verkauft natürlich auch denkbar, vielleicht wäre es sinnvoll nicht nur Start sondern noch einen Text auszugeben mit deinem Namen oder so, um das zumindest ein wenig zu erschweren.) Eine Sache gibt es allerdings noch. Deine Software scheint nur ein CR auszugeben und kein CR+LF. Ich muss es immer in meinem Terminal Programm umstellen, wenn ich die Nachrichten alle untereinander sehen möchte. Gruß Philipp
Datum: 28.03.2007 17:22
schau mal hier http://creativecommons.org/license/ kannst du z.b. die passende creative-commons license raussuchen die zu deinen ansprüchen passt und unter der du deinen code verbreiten würdest. auf der webseite gibts auch gute infos zur gpl oder lgpl. gruß fabian
Datum: 28.03.2007 20:15
@Phillip Für mein Terminal Programm hat einfach nur <CR> gereicht (Ich benutze Bray) Der Stop Befehl ist eh der einzige Befehl welcher direkt mehr als 1 Byte über den UART senden muß. Könnte ich evt. erweitern. Muß mal schauen. Zum Thema ätzen, Ich habe mir seit Ewigkeiten vorgeneommen eine USB Version mit FT245R Basis zu entwickeln. Dann kann man die Quarze ganz weglassen, hat einen höheren Durchsatz, und braucht keine RS232 Schittstellen mehr. cu Hauke P.S. mir ist grade noch eine Möglichkeit der "Veröffentlichung" eingefallen.
Datum: 28.03.2007 23:26
So Hier eine hab ihr eine Version wo ihr die UART einstellungen selbst vornehmen könnt. cu Hauke
; ****************************************************** ; Sniffer.ASM ; ****************************************************** .include "C:\PROGRA~1\VMLAB\include\m8def.inc" ; variables ; .def work =r16 ; interrupt vectors ; rjmp RESET ; Reset Handler rjmp EXT_INT0 ; IRQ0 Handler rjmp EXT_INT1 ; IRQ1 Handler reti ;TIM2_COMP ; Timer2 Compare Handler reti ;TIM2_OVF ; Timer2 Overflow Handler reti ;TIM1_CAPT ; Timer1 Capture Handler reti ;TIM1_COMPA ; Timer1 CompareA Handler reti ;TIM1_COMPB ; Timer1 CompareB Handler reti ;TIM1_OVF ; Timer1 Overflow Handler reti ;TIM0_OVF ; Timer0 Overflow Handler reti ;SPI_STC ; SPI Transfer Complete Handler reti ;USART_RXC ; USART RX Complete Handler reti ;USART_UDRE ; UDR Empty Handler reti ;USART_TXC ; USART TX Complete Handler reti ;ADC ; ADC Conversion Complete Handler reti ;EE_RDY ; EEPROM Ready Handler rjmp ANA_COMP ; Analog Comparator Handler reti ;TWSI ; Two-wire Serial Interface Handler reti ;SPM_RDY ; Store Program Memory Ready Handler .org 0x18 RESET: .dw 0xE004,0xBF0E,0xE50F,0xBF0D,0x2400,0xE003,0x2E10,0xE004 .dw 0x2E20,0xE004,0x2E30,0xE008,0x2E40,0xE009,0x2E50,0xE200 .dw 0x2E60,0xE703,0x2E80,0xE700,0x2E90,0xE601,0x2EA0,0xE60E .dw 0x2EB0,0xE00A,0x2E70,0xE0D1,0xE0C0,0xE0B1,0xE0A0,0xE090 .dw 0xE080,0x2711,0xE007,0xBF05,0xEC00,0xBF0B,0xE108,0x95A8 .dw 0xBD01,0xE100,0xBD01,0x940E,0x00D0,0xE004,0xBF00,0xE408 .dw 0xB908,0xE503,0x930D,0xE704,0x930D,0xE601,0x930D,0xE702 .dw 0x930D,0xE704,0x930D,0xE00D,0x930D,0x9606,0x9478,0x9B5D .dw 0xCFFE,0x1180,0xC003,0x1190,0x1000,0xCFF9,0x9109,0x9701 .dw 0xB90C,0x11D2,0x1000,0xE0D1,0xCFF2 .org 0x68 ANA_COMP: .dw 0x1191,0x1000,0x9518,0xE619,0x9B45,0x5210,0x931D,0x9601 .dw 0x11B2,0x1000,0xE0B1,0x9518 .org 0x78 EXT_INT0: .dw 0x0F11,0x9983,0x9513,0x9523,0x1125,0x1000,0xC019,0x1123 .dw 0x1000,0xC002,0x1124,0x9518,0x1591,0xF428,0x301A,0xF040 .dw 0x5C19,0x931D,0x9601,0x2711,0x11B2,0x1000,0xE0B1,0x9518 .dw 0x5D10,0x931D,0x9601,0x2711,0x11B2,0x1000,0xE0B1,0x9518 .dw 0x1591,0xF428,0xFF10,0x92AD,0xFD10,0x92BD,0x9601,0x2722 .dw 0x2711,0x11B2,0x1000,0xE0B1,0x9518 .org 0xA8 EXT_INT1: .dw 0x9B82,0x9518,0x9983,0xC00B,0x2722,0x2711,0x1191,0x1000 .dw 0x9518,0x928D,0x9601,0x11B2,0x1000,0xE0B1,0x9518,0x2722 .dw 0x2711,0x1191,0x1000,0x9518,0x929D,0x9601,0x11B2,0x1000 .dw 0xE0B1,0x1191,0x1000,0x9518,0x927D,0x9601,0x11B2,0x1000 .dw 0xE0B1,0x9518 .org 0xD0 ;Trimmen des internen Oscillators ; ldi work,0x81 ; out osccal,work ;RS232 init clr work out UBRRH,work ldi work,7 ;diese Konstante muß für die jeweilige Taktrate auf die gewünschte Baudrate eingestellt werden out UBRRL,work ldi work,(0<<RXC)|(1<<TXC)|(0<<UDRE)|(0<<FE)|(0<<DOR)|(0<<PE)|(0<<U2X)|(0<<MPCM) out UCSRA,work ldi work,(0<<RXCIE)|(0<<TXCIE)|(0<<UDRIE)|(0<<RXEN)|(1<<TXEN)|(0<<UCSZ2)|(0<<RXB8)|(0<<TXB8) out UCSRB,work ldi work,(1<<URSEL)|(0<<UMSEL)|(0<<UPM1)|(0<<UPM0)|(0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0)|(0<<UCPOL) out UCSRC,work reti |
Datum: 28.03.2007 23:28
Ich habe jetzt grad keine I²C Hardware hier, deshalb sagt bescheid ob es funktioniert. cu Hauke P.S Ich habe <CR> gegen <LF> ausgetauscht.
Datum: 29.03.2007 10:13
Nette Lösung :) Die INCLUDE-Zeile wird aber unter AVRStudio eine Fehlermeldung auslösen. ".include "C:\PROGRA~1\VMLAB\include\m8def.inc"" Einfach in ".include "m8def.inc" ändern. Danke für den "Code" ! Lg EC
Datum: 14.11.2007 01:51
Hallo, super Programm, aufgespielt ldi work angepasst und hat auf anhieb funktioniert
Datum: 13.07.2009 16:58
Hallo, das ist ein sehr interessanter Beitrag. Werde mir ebenfalls einen I2C Monitor mal stricken. Ist womöglich etwas viel verlangt aber wäre es möglich dieses Projekt ebenfalls für einen M168 zu kompilieren. Der ist ja soweit Pinkompatibel. Habe ein kleines fertiges Modul von embedit mit MAX202 hier. Leider mit M168 drauf. Beim Takt bin ich recht flexibel. Wäre super, wenn das klappt. Gruß RePi
Datum: 13.07.2009 19:36
Muss ich mal schauen. Ich bin noch bis Mitte August im Ausland und habe meinen Elektronik Krempel nicht mit dabei. Der M168 hat meines wissens die neue IO Register Anordnung. Müsste mal schauen ob das passt. Ich melde mich dann wieder. cu Hauke
Datum: 13.07.2009 21:20
RePi! schrieb: > Ist womöglich etwas viel verlangt aber wäre es möglich dieses Projekt > ebenfalls für einen M168 zu kompilieren. Der ist ja soweit > Pinkompatibel. Der ist ja so groß. Mit nem ATtiny85 kriegst Du alles in den D-Sub9 Stecker mit rein. Und dann sind auch 400kHz kein Problem. Beitrag "I2C (TWI) Sniffer mit AVR" Peter
Datum: 14.07.2009 02:36
Hi Peter Klar ist deine Version kleiner und schneller. Als ich die erste Versuch von meinem Sniffer gecodet habe, gab es den AT90S4433 noch (für diesen war der Code erst gedacht). Die ersten funktionsfähigen Codeversionen waren aber dann schon für den Mega8. Als ich den dann 2006 gepostet hatte war der Code aber schon "uralt" Ich habe schon lange nichts mehr dran gemacht, weil ich irgendwann mit eine Version mit FTDI245R (o.ä.) stricken wollte. RS232 stirbt ja so langsam aber sicher aus. Was die Datenausgabe angeht, hast du ja mein Format verwendet (oder hattest die gleiche Idee) Was ich auf jeden Fall vermeiden wollte, war das der Sniffer irgendwie in den Bus eingreift. Weiterhin habe ich noch eine Erkennung für Interruptsignal eingebaut (für z.B. PCF8574 "IO" oder PCF85x3 "RTC") Ich werde wenn ich wieder in Deutschland bin, mal meinen Sourecode reinstellen. cu bis dann
E-Mail-Benachrichtigung aktivieren