Hallo Ich gehöre noch zur Gemeinde von Microchip, bin aber zur Zeit gefrustet, weil der Support von Microchip USA sprich Forum, einfach nur Grotten schlecht ist. Ich habe ein I2C Problem Ich kann Strings lesen aber keine einzelnen Chars, egal nur zur Info. Beispiele wie man etwas machen könnte, total veraltetet. Meine Frage an Atmel, meint ihr es lohnt sich von MC umzusteigen. Gibt es eine Programmier - Oberfläche wie MPLab X bei MC. Wie es mit debuggen, wie teuer ist so was. Meine Kenntnisse würde ich als ! Ich verstehe mich ganz gut in "C" keine Ahnung von C++ (Objekte) Ich habe 6 Monate nur MC Assembler programmiert, eine UHR um die Philosophie des ganzen zu verstehen. MPLab X "C" ist schon toll und das umsonst.
Was hindert dich denn daran mal die Seite von Atmel zu besuchen? Ich glaube, den Support den du benötigst gibt es nicht. Du schaffst es ja nicht mal dich über die aller einfachsten Sachen selbst zu informieren.
Es gibt AVR Studio, das erfüllt in etwa den gleichen Zweck wie MPLAB, und die Atmel Toolchain, das ist der C-Compiler dazu. Kostenlos zum Download. Für I2C nimmt der geneigte AVR-User gern die Bibliothek von Peter Fleury, findet man im Netz. Programmer (AVRISP MKII) und Debugger (JTAGICE o.ä.) gibt es in ähnlichen Preisregionen wie von Microchip.
Martin Michael schrieb: > Ich kann Strings lesen aber keine einzelnen Chars, egal nur zur Info. "Ich kann ein Raumschiff bauen aber für n Papierflieger reicht es nicht..."
Ich verstehe auch nicht, warum ein Controllerhersteller in der Pflicht stehen sollte, Support für ein C Problem zu leisten. So eine Einstellung sollte man mal überdenken.
Martin Michael schrieb: > Ich kann Strings lesen aber keine einzelnen Chars Sebastian schrieb: > Übrigens, ist ein String der Länge 1 nicht ein char? Nein, ein String der Länge 1 hat mindestens 2 Byte, nämlich das Datenbyte und eine abschliessende 0. Und genau da wird sich auch das Problem des To befinden. @Martin Michael: Womit liest du "Strings" von der I2C Schnittstelle? Die liefert erst mal Bytes ohne die Information ob das jetzt Teil eines Strings ist, wann der angefangen haben könnte und wann der String zu Ende ist. Ich tippe jetzt mal, dass du eine irgendwo aus dem Internet kopierte (Bibliotheks)funktion hast die dir einen String zurückliefert, der aus I2C gelesen wurde. Dabei macht die Funktion aber Annahmen, wie dieser String gesendet wurde, die deinen tatsächlich gesendeten Bytes nicht entsprechen. Man müsste also mal den Code sehen, den du geschrieben hast und was an Bytes von wem gesendet wurde um dein Problem einzugrenzen.
>Ich kann Strings lesen aber keine einzelnen Chars, egal nur zur Info. >Beispiele wie man etwas machen könnte, total veraltetet. Klingt nach Problemen mit der Programmiersprache und nicht mit der Schnittstelle. Außer der Anzahl und dem normalerweise folgenden '\0', gibt es keinen Unterschied zwischen einem String und seinen Zeichen.
Martin Michael schrieb: > Hallo > > Ich gehöre noch zur Gemeinde von Microchip, bin aber zur Zeit gefrustet, > weil der Support von Microchip USA sprich Forum, einfach nur Grotten > schlecht ist. Ich habe ein I2C Problem > Ich kann Strings lesen aber keine einzelnen Chars, egal nur zur Info. > Beispiele wie man etwas machen könnte, total veraltetet. > > Ähhm na ja....deine im Nachbarforum geäußerten Vermutungen bezüglich "Bugs" des Kontrollers - darüber habe ich dort schon geschrieben. Der Hinweis, wenn man bei einer EEPROM-Pagesize von 16 Byte mehr als 16 Byte mit einer "PageWrite" Funktion überträgt (und die Lib-Funktion das nicht selbst umsetzt und ggf. aufteilt), man beim Zurücklesen Probleme bekommt, kam dort auch schon....
Martin Michael schrieb: > Meine Frage an Atmel, meint ihr es lohnt sich von MC umzusteigen. Klar lohnt es sich für die Anbieter, wenn du dir Brenner, µC und Co. neu anschaffst. Ob es dein Problem löst, möchte ich an der Stelle arg bezweifeln. Ich vermute nämlich einfach mal, dass du irgendeine Lib verwendest ohne die Funktionsweise von I2C verstanden zu haben. Bei der kleinsten Änderung hast du damit natürlich ein Problem. Schaue dir doch einfach mal die Seite sprut.de an. Dort wird der I2C recht detailiert beschrieben. Zwar für ASM, aber das sollte kein Problem sein. Die Abläufe sind die gleichen. PS: Wenn du deine Programme so schreibst wie deine Posts wundert es mich noch weniger. Sorry.
Dann schreib dem Support. Der wäre dein offizieller Ansprechpartner von Microchip. Die Microchip Foren sind "User helfen Usern" wie hier. Ich bezweifle, dass Microchip- Offizielle da drin aktiv sind. Ich habe schon von der Arbeit aus dort einige Fragen reingeschrieben, und auch selten wirklich Hilfe erhalten. Der offizielle Support von Microchip dafür nicht schlecht. Inwieweit das für Privatleute zutrifft, kann ich dir aber nicht sagen. Bei den Libs hast du aber allerdings nicht unrecht. Andererseits ist das woanders auch nicht besser. Es ist eben gerade schick, den Kunden indische Billigprodukte aus den Slums von Kalkutta andzudrehen. Beispiele: CUBE (ST), Harmony (Microchip). PS: Du könntest du deine Frage übrigens auch hier stellen.
Martin Michael schrieb: > Ich gehöre noch zur Gemeinde von Microchip, bin aber zur Zeit gefrustet, > weil der Support von Microchip USA sprich Forum, einfach nur Grotten > schlecht ist. Ich habe ein I2C Problem > Ich kann Strings lesen aber keine einzelnen Chars, egal nur zur Info. > Beispiele wie man etwas machen könnte, total veraltetet. > > Meine Frage an Atmel, meint ihr es lohnt sich von MC umzusteigen. Nein. Nicht für Dich. Du würdest die gleichen Probleme mit JEDEM Controller haben, so wie ich Dich einschätze. Microchip ist einer der besseren Hersteller, was Support angeht. Atmel macht aktiv recht wenig, sondern überlässt es fast komplett der Community, eine Infrastruktur aufzubauen. Das kann man natürlich so machen, aber damit kommt auch viel GPL-Code, der im kommerziellen Projekten nicht verwendet werden kann. Die Microchip-Bibliotheken sind zwar keine Freie Software (gemäß GNU oder BSD oder sonstiger Definition), aber Du kannst sie kostenlos benutzen, egal ob privat oder kommerziell. Die Peripherie ist bei den PICs deutlich besser als bei AVR - Du hast eine größere Auswahl, und die einzelnen Peripherieeinheiten sind auch leistungsfähiger. Und wer über die 8-Bit Architektur mosert, möge einfach den Mund halten und einen 16- oder 32-Bit PIC verwenden. Zu Deinem I2C-Problem: Schreibe Deine eigene I2C-Bibliothek. Das ist bei PIC im Gegensatz zu AVR sehr einfach, weil die I2C-Einheit reicht gut ist. AVR-I2C-Routinen sind deutlich komplizierter. > Gibt es eine Programmier - Oberfläche wie MPLab X bei MC. ja. > Wie es mit debuggen, wie teuer ist so was. Debuggen geht nur bei den größeren AVRs, die JTAG haben. Über ISP kannst nur nur Programmieren, nicht debuggen, und debugWire ist ein Krampf. Du siehst, ich kenne beides, habe auf beiden Architekturen größere Projekte gemacht, und kann daher vergleichen. fchk
Martin Michael schrieb: > Ich habe ein I2C Problem > Ich kann Strings lesen aber keine einzelnen Chars I2C kennt nur 4 Grundfunktionen: Start, schreibe Byte, lese Byte und Stop. Wie man diese verwenden muß, hängt vom Slave ab, was der versteht. Ein generelles String oder Char lesen gibt es nicht. Dein Problem ist also nicht das I2C oder der MC, sondern das Protokoll, was Deine Funktionen auf dem I2C übertragen. Oder einfach nur ein C-Problem beim Aufruf dieser Funktionen.
Danke an alle netten Beiträgen WehOhWeh das habe ich http://www.microchip.com/forums/m852585.aspx und Du bekommst da so wenig Feedback. An dem I2C Bus kann es nicht liegen, wie gesagt ich kann mit EESequentialRead mehre Bytes ohne Probleme lesen nur wenn ich mit EERandomRead bekomme ich einen Collision Error, was mit Collision nix absolut nix zu tun hat, dafür ist das PIR2bits.BCLIF Flag nur zu SSPCON1bits.WCOL kann niemand mir was sagen. Mals sehen, was ich mache. Ist nur ein Hobby, was solls.
Hier kann man sehr schön sehen da hatte einer das gleiche Problem http://www.microchip.com/forums/m323549.aspx und es endet ohne Antwort. Toll
Martin Michael schrieb: > > und Du bekommst da so wenig Feedback. Wenn Du eine helfende Hand suchst ... Du findest sie am Ende Deines rechten Arms. > nur zu SSPCON1bits.WCOL > kann niemand mir was sagen. Steht ja auch im Datenblatt. Lesen bildet. "17.4.10.2 WCOL Status Flag If the user writes the SSPBUF when a transmit is already in progress (i.e., SSPSR is still shifting out a data byte), the WCOL is set and the contents of the buffer are unchanged (the write doesn’t occur). WCOL must be cleared by software." Wenn Du wirklich wissen willst, was abgeht, schreibe Dir Deine eigenen Routinen und schau mit einem Logic Analyzer auf den Bus. So teuer sind die Teile inzwischen auch nicht mehr. fchk
Hier ein Code welcher funktioniert, uint8_t ee_read(uint16_t address) { uint8_t data; while(!ee_ready()); i2c_start(); write((0xa0|(uint8_t)(address>>7))&0xfe); i2c_write(address); i2c_start(); i2c_write((0xa0|(uint8_t)(address>>7))|1); data=i2c_read(0); i2c_stop(); return(data); } Den kannst du mit deinem Vergleichen und siehst dann was nicht funktioniert.
Es geht, es geht Ich hatte Gott sei dank 3 von den Dingern PIC18F46K20 gekauft und beim dritten geht es. Was ein Frust über 30 Stunden für fast nicht., immerhin verstehe ich I2C ein wenig.
Sebastian schrieb: > Übrigens, ist ein String der Länge 1 nicht ein char? Ein String der Länge 1 besteht aus zwei Zeichen - zumindest in C oder Pascal. Wie soll der in ein char passen?
Mike schrieb: > Wie soll der in ein char passen? Und in diesem Zusammenhang noch interessanter: was kommt hinter dem Char im Speicher?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.