Hallo Zusammen,
ich habe eine PIC18F4550, die wurde unter MPLAB IDE 8.9.2 programmiert.
Jetzt bin dabei einen neue Entwicklungsumgebung (MPLAB® X IDE v3.65) zu
runterladden.Die Frage ist was für einen kompiler muss ich noch
installieren
die MPLAB® C Compiler oder die MPLAB® XC Compilers?
Danke
David schrieb:> Die Frage ist was für einen kompiler muss ich noch installieren> die MPLAB® C Compiler oder die MPLAB® XC Compilers?
Wenn du es dir einfach machen willst, dann den, den das "alte" Projekt
verwendet hat.
Hi,
der alten project war unter MPLAB IDE V8.9.2 und unter XP.
Wir haben dann diese in eine Virtuelle Maschine gesiedelt(vor 4 jahre).
Unter die Virtuelle Maschine zu debuggen ist echt sehr schwierig,
deswegen bin ich dabei das Projeckt in MPLAB X IDE (V3.65) zu
integrieren.
Was mir aufgefallen ist, dass die Library von MPLAB X anders im
vergleich zu MPLAB 8.9.2.
z.B:
Ich brauche die USB Library aber ich finde die nicht unter MPLAB X.
Soll ich die extra runterladen?
Wenn ja Woher?
Danke
Volker S. schrieb:> Welche USB Library genau?
Damals als der MPLAB IDE V8.9.2 installiert wurde gaben Librarys dabei.
Ob es diese extra installiert sind, weiss ich nicht.
Da diese Librarys in Code auch includiert sein müssen "Seh bitte
Anhang", muss ich die installieren.
E-Bastler schrieb:> Warum?
Es ist einfach mühsam aber das problem lag nicht an der Virtuelle
maschine selber sondern an der Entwicklungsumgebeung " MPLAB IDE
V8.9.2".
Es macht ehrlich gesagt kein spass damit zu arbeiten.
David schrieb:> Damals als der MPLAB IDE V8.9.2 installiert wurde gaben Librarys dabei.> Ob es diese extra installiert sind, weiss ich nicht
Die sind extra installiert und es gibt zudem noch eine Menge
unterschiedlicher Versionen, die nicht unbedingt kompatibel sind.
-> Version heraus finden...
David schrieb:> Ist eine grosse unterschied zwischen beide Compiler XC8 und die C18?
Ja, wenn du das alte Projekt nicht komplett neu aufsetzen willst, dann
solltest du den da verwendeten Compiler benutzen. (müsste im *.mcp File
stehen)
David schrieb:> der alten project war unter MPLAB IDE V8.9.2 und unter XP.> Wir haben dann diese in eine Virtuelle Maschine gesiedelt(vor 4 jahre).
Aha. Dann bist du also nicht nur "David", sondern auch "Saheb" vom
Beitrag "Von Mpalb IDE Version 8.9.2 zu MPLAB X IDE"
Das gleichzeitige Eröffnen mehrerer Threads zum gleichen Thema empfinde
ich als grob unhöflich. Die gleichzeitige Verwendung mehrerer
verschiedener Nicks ist nicht nur unhöflich, sondern auch ein Verstoß
gegen die Nutzungsbedingungen.
Was deine Frage angeht: MPLAB X ist nur die IDE. Die kann mit beiden
Compilern. Auch Libraries sind nicht Bestandteil der IDE, sondern müssen
(natürlich) extra installiert werden, sofern sie nicht bereits mit dem
Compiler kommen.
Volker S. schrieb:> Ja, wenn du das alte Projekt nicht komplett neu aufsetzen willst, dann> solltest du den da verwendeten Compiler benutzen. (müsste im *.mcp File> stehen)
Bei der .mcp steht folgende:
Du kannst versuchen das Projekt in MPLABX zu importieren, oder einfach
mit den vorhandenen Dateien neu zu erstsellen.
Da das Projekt eine sehr frühe Version der USB Lib verwendet, würde ich
dazu raten, weiterhin den C18 Compiler zu verwenden und auch die
entsprechende Version der Bibliothek zu installieren, bzw. die alte
Bibliothek einfach an den entsprechenden Ort zu kopieren.
Falls du entgegen meiner Vermutung ein erfahrener Programmierer sein
solltest, wäre es auch möglich auf die neueste Version der Library um zu
stellen und den User-Teil aus dem alten Projetk in das passende Beispiel
für MPLABX und XC8 zu intergrieren.
David schrieb:> E-Bastler schrieb:>> Warum?>> Es ist einfach mühsam aber das problem lag nicht an der Virtuelle> maschine selber sondern an der Entwicklungsumgebeung " MPLAB IDE> V8.9.2".>> Es macht ehrlich gesagt kein spass damit zu arbeiten.
Viele Umsteiger behaupten übrigens, dass das Debuggen mit der alten IDE
viel besser funktioniert hat ;-)
USB-Devices zu debuggen ist im allgemeinen etwas mühsam, weil das
Betriebssytem (windoof X) das Device meist disconnected, wenn man es
(beim debuggen) anhält.
@Volker SK
Was PIC betrifft bin ich wirklich neu.
Mir ist nur wichtig die Projekt unter die neue Entwcklungsumgebung im
laufen zu bringen, ob es nachher auf XC8 integriert werden muss ist
einen andere Frage.
Wie sieht es aus mit der Licence brauche ich eine oder?
David schrieb:> Mir ist nur wichtig die Projekt unter die neue Entwicklungsumgebung im> laufen zu bringen,
Sollte kein Problem sein ;-)
Lizenz brauchst du erst mal keine. Mit den Free/Light Versionen der
Compiler kann man schon arbeiten. Professionell mit XC8 wär's
längerfristig aber sinnvoll.
Beim alten MCHP C18 Compiler bestand meiner Meinung nach die
Notwendigkeit die PRO Version zu haben eigentlich nicht. Die ersten Free
XC8 Versionen waren allerdings sehr übel. Hat sich inzwischen aber etwas
gebessert.
http://www.microchip.com/forums/FindPost/668751
Es gibt Lizenz-Modelle, welche die XC8 PRO Version monatlich frei
schalten.
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=SW006021-SUB
in diesem HID Bootload.lkr weiss es nicht wofür ist die da ist und was
macht man damit.
Wie soll ich diese umschreiben?
worauf muss ich achten?
was Pic betrifft bin wirklich neu und auf deine Hilfe freue ich mich.
10000 Danke und Sorry für die Umstände
Kommt von; http://www.microchip.com/forums/FindPost/1005969
Also generell beschreibt das Linker Skript bei den 8bit PICs für
Assembler und den alten MCHP C18 Compiler die Aufteilung des Speichers
(ROM und RAM).
Dazu kommt beim C18 noch die Einbindung des Startup Codes, der
Prozessorbibliothek und die Angabe, wie groß der Stack sein soll.
Zusätzlich kann man noch "Sektions" für bestimmte Sachen in bestimmten
Speicherbereichen anlegen und reservieren. Schau dir einfach mal das
unverpfuschte Script ..\Microchip\mplabc18\v3.47\bin\LKR\18f4550_g.lkr
zusammen mit dem Datasheet des 4550 an...
In "deinem" Fall wurde anscheinend ein Linker Script, welches
ursprünglich für die Verwendung mit einem Bootloder gedacht war,
umgeschrieben, so dass ein bestimmter Teil des Programmcodes (die
Seriennummer des USB Gerätes?) an einer bestimmten Adresse zu liegen
kommt um dann möglichst einfach beim Programmieren der Controller mit
einer fortlaufenden Nummer ersetzt werden zu können.
Frag doch am besten den, der das verbockt hat nach der Dokumentation ;-)
Volker S. schrieb:> Frag doch am besten den, der das verbockt hat nach der Dokumentation ;-)
Wenn er hier ist.Er ist schon seit lange weg und dazu gibt es gar keine
Documentation.
Na ja so ist halt.
Jetzt habe ich die Suppe und muss zu recht kommen.
Es wäre ganz nett, wenn du mich noch einbisschen helfen kannst.
Du hast mich ehrlich gesagt sehr viel geholfen dafür danke ich dir noch
mal.
Saheb schrieb:> Wenn er hier ist.Er ist schon seit lange weg und dazu gibt es gar keine> Documentation.
Schon klar ;-)
Auf jeden Fall musst du herausfinden, was es mit dieser "serial" Sektion
auf sich hat!
Volker S. schrieb:> Auf jeden Fall musst du herausfinden, was es mit dieser "serial" Sektion> auf sich hat!
Was ich weiss, dass es mit diesem Board USB Kommunikationen gibt.
zb: Commando werden von einen GUI ausgeführt, die wiederum zu den Board
weitergeleitet werden.
Dieses Commandos werden auf die Firmware seite verschlüsselt in so einen
Art z.B:
Von der GUI wird einen Commando z.B StromMessen:
Auf die Firmwareseite, sind dieses Commandos auch definiert:
Volker S. schrieb:> Build im debug mode funktioniert nicht!> (oder inzwischen doch)
Sorry wenn ich noch blöd frage: wo sehe ich das, dass es sich im einen
Debug version handelt?
Lies dir doch bitte mal die Links durch, die ich gepostet habe bevor du
die nächste Frage stellst und versuche die Zusammenhänge zu verstehen.
(Frag von mir aus gezielt nach, wenn du etwas aus den Links überhaupt
nicht verstehst)
Dabei sollte dir eigentlich klar werden, dass in deinem Projekt keine
Sektion definiert sein darf, die sich mit den Debug Resourcen
überschneidet, wenn debuggen möglich sein soll!
Da das Problem ja nur beim debuggen auftritt, könntest du das VERMUTLICH
recht einfach mit einer bedingten Compileranweisung umgehen.
Dazu müsstest du natürlich wissen was das ist und wo du die einsetzen
musst...
Volker S. schrieb:> Dabei sollte dir eigentlich klar werden, dass in deinem Projekt keine> Sektion definiert sein darf, die sich mit den Debug Resourcen> überschneidet, wenn debuggen möglich sein soll
Was meinst du bitte hier genau?
Danke
Der Speicherbereich kann ja vom Linker nicht zweimal verwendet werden.
Er ist von deinem Programm belegt von 0x7FC0...0x7FD1 *2 und der
Debugger braucht ihn von 0x7DC0...0x7FFF. Das heißt, dein Programm liegt
teilweise im verbotenen Bereich.
Deshalb bekommst du beim Debug-Build den Fehler
*3
Sorry, ich habe das Gefühl du bist mit dem Projekt hoffnungslos
überfordert und nicht bereit zu akzeptieren, das es jede Menge
Grundlagen gibt, die du erst noch lernen musst um damit zurecht zu
kommen.
Wenn der Rest dann auch so ein Chaos ist wie das verpfuschte Linker
Skript kommst du damit nirgendwo hin ;-)
------------------------------------------------------------------
*1 Volker S. schrieb:> Für den 4550 sieht das übrigens so aus:
*2 http://www.microchip.com/forums/FindPost/1005961
*3 http://www.microchip.com/forums/FindPost/1005440
Volker S. schrieb:
--> Für deine Erklärung vielen Dank.
Das habe ich verstanden.
Die Frage ist: Nach welchen Muster kann ich die speicher aufteilen,
damit ich solche Problem mit der Linker in verbindung mit der Debugger
vermeiden kann.
> Sorry, ich habe das Gefühl du bist mit dem Projekt hoffnungslos> überfordert.
Ehrlich gesagt ja aber ich gebe mein besten...
> Wenn der Rest dann auch so ein Chaos ist wie das verpfuschte Linker> Skript kommst du damit nirgendwo hin ;-)
Ja ist es, aber erst mal nicht priorität eins
Saheb schrieb:> Die Frage ist: Nach welchen Muster kann ich die speicher aufteilen,
Du kannst die Speicher gar nicht aufteilen. Das ist eine Beschreibung
der unveränderlichen Realität!
Die Frage, die sich schon seit geraumer Zeit stellt und die ich gebeten
habe zu klären, ist: "Wofür ist diese SERIAL Sektion?"
Poste doch mal die Datei mit den usb Descriptoren. Da sollte nicht
alzuviel geheimnisvolles drin stehen.
Saheb schrieb:> Ja ist es, aber erst mal nicht priorität eins
Auch wenn es Priorität eins wäre das Dach zu decken.
Das ist einfach unmöglich solange noch nicht mal die Fundamente
betoniert wurden ...
0x29, 0x40, // Usage Maximum //64 input usages total (0x01 to 0x40)
123
0x15, 0x00, // Logical Minimum (data bytes in the report may have minimum value = 0x00)
124
0x26, 0xFF, 0x00, // Logical Maximum (data bytes in the report may have maximum value = 0x00FF = unsigned 255)
125
0x75, 0x08, // Report Size: 8-bit field size
126
0x95, 0x40, // Report Count: Make sixty-four 8-bit fields (the next time the parser hits an "Input", "Output", or "Feature" item)
127
0x81, 0x00, // Input (Data, Array, Abs): Instantiates input packet fields based on the above report size, count, logical min/max, and usage.
128
0x19, 0x01, // Usage Minimum
129
0x29, 0x40, // Usage Maximum //64 output usages total (0x01 to 0x40)
130
0x91, 0x00, // Output (Data, Array, Abs): Instantiates output packet fields. Uses same report size and count as "Input" fields, since nothing new/different was specified to the parser since the "Input" item.
Ok, da ist so ein #pragma romdata SERIAL
Das sorgt dafür, dass der String sd003 genau an der Adresse 0xFDC0 im
ROM steht. (0x03, // Device serial number string index)
Ändere das mal auf:
#ifndef __DEBUG
#pragma romdata SERIAL
#endif
Vielleicht taucht das sonst noch wo auf.
Kommentiere doch die zwei Seciton Zeilen im Linker Script aus, dann wird
man schon sehen...
DIE PAGE ZEILE MUSS DANN NATÜRLICH bis 0x7FFF...
Saheb schrieb:> Ich bekomme folgende Errors:
Poste doch bitte den gesamten Build Output. Mit dem obigen kann man gar
nichts anfangen. Unbedingt CLEAN AND BUILD!
Kommt auch vom vermurksten Linker Skript.
Die Debug Executive belegt Speicher in BANK3 von 0x3F4...0x3FF,
Dann sind da natürlich keine 0x100 Bytes mehr übrig.
(siehe screenshot93 weiter oben ;-)
>> Stack verkleinern oder auf andere BANK
- STACK SIZE=0x0F4 RAM=gpr3
- STACK SIZE=0x100 RAM=gpr2
Es kam noch nie zum Debuggen!
Bisher waren die Probleme immer beim Build,
jetzt beim Programmieren!
Was mich etwas wundert, ist warum anfangs die Debug Executive den
Speicher ab 0x7DC0 beansprucht hat und jetzt ab 0x7D30.
Beim Programmieren passiert ja folgendes:
- der Programmspeicher wird gelöscht
-> alle Bits werden zu 1, alles ist 0xFFFF
- dann wird der Programmspeicher programmiert
-> manche Bits werden zu 0
Bei dir wird aus irgendwelchen Gründen der Programmspeicher zuerst bis
0x7D3F beschrieben und dann folgt die Debug Executive ab 0x7D30.
Dummer Weise wurde der Speicher an 0x7D30 mit 0 beschreiben und beim
Programmieren können keine Bits gesetzt werden...
Ist in den Einstellungen für das Programmier/Debug Tool etwas
eingetragen?
-> http://microchipdeveloper.com/icd3:select-memory-to-program
Hi,
wenn ich die das Projekt so einstelle (Seh bitte Anhang), dann bekomme
ich folgende Error beim Debuggen:
1
Failed to program device
2
The selected program range, 0-7fff, does not fall within the proper range for the memory area selected. Please check the manual program ranges on the debug tool's, "Memories to Program" property page.
Nein
warum soll ich dich verarschen.Ich habe deine vorschlag "Stell's halt
auf Automatic oder auf 0-0x7D2F" falsch interpretiert. Sorry
Ich bekomme dann diese Fehlermeldung beim program und das gleiche auch
beim debuggen.
1
Failed to program device
2
Invalid program range received: end address 7D2F is not aligned on a proper 0x3f address boundary. Please check the manual program ranges on the debug tool's, "Memories to Program" property page.
Saheb schrieb:> Ich weiss es nicht wie du auf diese Adresse "7D2F"
Die Adresse muss kleiner sein als der Start der Debg Exekutive.
Saheb schrieb:> Invalid program range received: end address 7D2F is not aligned on a> proper 0x3f address boundary.
Da wusste ich noch nicht, das die Adresse auf 3F, 7F, usw...
enden muss ;-)
Also letzter Versuch: Wie lautet die größte passende Adresse, die
kleiner ist als die Startadresse der Debug-Exekutive?
@Volker S
danke für deine Hilfe.
Volker S. schrieb:> Also letzter Versuch: Wie lautet die größte passende Adresse, die> kleiner ist als die Startadresse der Debug-Exekutive?
Als Antwort auf deine Frage:
Ich kann dich leider nicht verfolgen: Wo sehe ich die Start Adresse der
"Debug-Excekutive":?
Danke dir und Sorry sorry für die Umstände.
Ich will deine zeit nicht vergolden aber ich weiss es einfach nicht
z.B da ->
Saheb schrieb:> Debug Executive> Address: 7d30 Expected Value: 14 Received Value: 0> Failed to program device
und gleich nochmal:
Saheb schrieb:> Debug Executive> Address: 7d30 ...
und dann nochmal von mir:
Volker S. schrieb:> und dann folgt die Debug Executive ab 0x7D30.
Den ganzen Bootloader und Vectors Blödsinn solltest du auch entfernen.
Ach was, entferne am besten die Linker Script Datei aus dem Projekt,
dann wird das Standard-Script genommen ;-)
Im Descriptor-File kannst du das mal so probieren:
Die Seriennummer ist das da -> 6','9','0','0','0','0','0','1
Was das andere ist solltest du inzwischen eigentlich wissen.
Wenn nicht lies einfach mal im User Guide nach...
Hi,
beim Integrieren von einem alten Projekt Mplab 8.92 in MPLAB X bekomme
ich folgende Error "Seh bitte Anhang" und damit kann ich nicht das
Import zu ende führen.
Ja das "other has a different root" kannst du vermutlich nicht
überwinden.
Das bedeutet, dass die Projektdateien von verschiedenen Laufwerken
kommen.
Dann musst du das Projekt eben manuell aus den alten Dateien und
Einstellungen zusammen stöpseln...
PS: keine Leer- und sonstige Zeichen in Projektdateien und Pfaden!
Saheb schrieb:> bekomme ich folgende Error
Also ich sehe keinen Fehler... ev. solltest du den kompletten Auszug der
Summary hier rein kopieren.
Ich habe den Thread ja nur überflogen, aber mal ernsthaft: Bedienst du
zum ersten mal einen Computer? Und da fragen sich die Leute wieso ein
Support von einem Drucker fragt, ob er eingeschaltet ist...
Hallo,
danke für den Hinweis.
Man kann das Projekt trotzdem integrieren in dem die abhängige
Projektordner vorübergehen umbenennen.
Das Project wird dann importiert.
Saheb schrieb:> Man kann das Projekt trotzdem integrieren in dem die abhängige> Projektordner vorübergehen umbenennen.
Also die Dateien auf ein gemeinsames Laufwerk bringen und die *.mcp
entsprechend editieren? Das ist natürlich auch eine Möglichkeit.
Mir geht Hauptsächlich um die USB Funktionen, ob die überhaupt wichtig
sind.
In diesem Code sind bestimmt sehr viele Leichen.
Wenn es nach mir geht werde ich alle neu schreiben und allermal von
diesem USB Geschichte weg aber es lag nicht in meine Hand für so was zu
entscheiden bzw. ich wurde immer gebremmst.....
Wenn das ein USB Gerät sein soll, dann lass den USB Teil einfach so wie
er ist. Sicher kann man da einiges entfernen, aber ohne sehr genaues
Wissen was man tut, wird das schnell im Desaster enden!
Was man unbedenklich entfernen kann wäre z.B.
BlinkUSBStatus() und die ganzen #if defined(PIC24FJ2... Sachen, die
definitiv nicht zu deinem Controller passen.
Den ganzen Bootloader Stuff kann man natürlich auch weg lassen, wenn
nicht die Absicht besteht die Firmware im Feld mittels eines Bootlaoders
updatebar zu machen. Die Ganze Arbeit das alles zu entfernen lohnt aber
meiner Meinung nach die Mühe nicht!
Der Code, der sich auf dein Projekt bezieht, ist eigentlich komplett in
den Funktionen
- void UserInit(void)
- void ProcessIO(void)
enthalten.
- InitPort(); i2c_init(); i2c_confChips();
gehören wohl auch in UserInit()
ucfuLrcChecksum() und das Watchdog Zeug stammt wohl auch nicht aus dem
Original Demo-Projekt
Wenn du das ganze neu schreiben willst (vermutlich die beste Idee), dann
nimm als Grundlage die neueste Version des HID Demo Projektes aus den
MAL (Microchip Libraries for Applications). Dann musst du aber den XC8
Compiler verwenden!
Das am besten passende Projekt für einen 18Fx550 ist aktuell dieses:
.../mla/v2017_03_06\apps\usb\device\hid_custom\firmware\picdem_fs_usb.x
Alternativ könntest du auch meine Version benutzen, in der ich schon
einiges weg gekürzt habe und die mit C18 und XC8 kompilierbar sein
sollte.
Ich habe das mal gemacht, weil die früheren Versionen der Demo Projekte
extrem unübersichtlich waren, weil es nur ein Projekt mit sehr vielen
verschiedenen Konfigurationen für alle möglichen PICs (8..32bit) und
Demo- Boards gab.
Inzwischen wurde das aber geändert und es gibt in jedem Projekt nur noch
eine Konfiguration. Jetzt sind die MCHP Demos für Anfänger eigentlich
noch einfacher zu verwenden als meine Version ;-)
PS: solch umfangreichen Code würde ich als Anhang...
Volker S. schrieb:> Das am besten passende Projekt für einen 18Fx550 ist aktuell dieses:> .../mla/v2017_03_06\apps\usb\device\hid_custom\firmware\picdem_fs_usb.x
Wo finde ich das bitte?
Um mit der PIC18F4550 zu kommunizieren, wird einen HID class.DLL
gebraucht.
Dieses HID class.DLL weiss ich immer noch nicht woher?
Es wird immer benutzt und keine mensch weiss woher?
Mittlerweile weiss ich. Es stammt von Microship aber als Demozweck.
Meine Frage an dich, weiss du bitte vielleicht wo kann ich die Source
Code bekommen damit ich die neue erstellen und zwar mit der richtige
"aktuell" Framework.
Problem ist:
Dieses HID Class.DLL wurde in C# geschrieben und mit der 2.0 Framework
erstellt.
Unter Visual Studio 2008 C++ war ein Problem (Es passiert, dass die USB
Kommunikation abgebrochen wird)aber nicht so instabil wie in Visual
studio 2015 ist.
Um das überhaupt unter Visual studio 2015 zum laufen zu bekommen, muss
es extra eine .conf datei geschrieben um die ganze Application mit einem
bestimmten Framework z.B 4.6 zu zwingen.
SW extra zu flicken und warten, dass es alles gut geht ist sehr
gefährlich.
Hallo Volker,
beim ausprobieren deinen Beispiel in Qt Creator zu starten haben ich
folgende Link Problem(Seh bitte Anhang).
Was muss ich machen, damit ich dieses Linksproblem umgehe?
danke
Keine Ahnung warum ich das da hin kopiert haeb. Ist zu lange her ;-)
Die Datei solle im Qt Installationsordner zu finden sein. Bei mir:
...\Qt5.4.1\Tools\mingw491_32\i686-w64-mingw32\lib
Kann sein, dass man die Bibliothek bei früheren Qt Versionen noch
gebraucht hat und ich gar nicht gemerkt habe, dass sie jetzt überflüssig
ist.
Hatte auf jeden Fall mit den Aufrufen der SetupDiGet...() Funktionen in
den HID.c zu tun.
Hallo Volker,
ich versuche gerade mithilfe deinen "LPC_FSUSB-HID-X-r4a.zip" in meinen
Projekt anzupassen.
Ich nehme einen Beispiel"Firmware":
Bei dir in der Main Funktion:
1
MAIN_RETURN main(void)
2
{
3
.....
4
// Application-specific tasks.
5
APP_CustomHIDTasks();
6
}
wird die Funktion APP_CustomHIDTasks() aufgerufen, die wiederum in der
"app_custom_hid.c" implementiert und die wiederum in
1
APP_usbOUT(); // Data USB(pc) -> PIC
oder
1
APP_usbIN();
Mich interessiert, die beide Zeilen:
1
USBInHandle = HIDTxPacket(HID_EP,(uint8_t *)ToSendDataBuffer, 64);// bei APP_usbIN();
In dem Projekt, der ich habe ist so vorgegangen worden.
In der main Datei:
#define LED_ON 0x20
#define Firmware_version 0x28
#define MAJOR_VERSION 5
#define MINOR_VERSION 9
...
Jede Commando ist mit diesem Makro "#define" definiert
dann in der main Funktion:
Saheb schrieb:> In dem Projekt, der ich habe ist so vorgegangen worden...
Dein Projekt basiert lediglich auf einer älteren Version des HID custom
demo Projektes.
z.B.
Saheb schrieb:> Jede Commando ist mit diesem Makro "#define" definiert
In neueren Version sind die Kommandos als enum angelegt. Das mach hier
praktisch keinen Unterschied.
Die zusätzliche Trennung in Funktionen für APP_usbOUT() und APP_usbIN()
habe ich implementiert, weil bei meinen Projekten auch usbIn Transfers
vorkommen die KEINE Antwort auf einen vorhergehenden usbOUT Transfer
sind, sondern z.B Datenpakete vom kontinuierlich messenden ADC. Also
einmal ein Kommando zum Starten der Messung (usbOUT) und eben immer dann
Daten (usbIN), wenn ein Paket voll ist.
Soll ich vielleicht eine Änderung vornehmen deine Meinung nach?
Eine andere Frage: Lohnt es sich eine PIC32 zu nehmen, die die gleiche
Eingenschaften hat wie eine Pic18F?
Saheb schrieb:> Soll ich vielleicht eine Änderung vornehmen deine Meinung nach?
Falls das Projekt längerfristig weiter entwickelt wird, dann sollte man
auf die neueste Version des Frameworks umsteigen. Wenn nur ein kleiner
Zusatz programmiert werden soll, dann eher nicht. (ausser ihr habt sonst
nichts zu tun ;-)
Saheb schrieb:> Eine andere Frage: Lohnt es sich eine PIC32 zu nehmen, die die gleiche> Eingenschaften hat wie eine Pic18F?
Woher soll das irgend jemand wissen, der keine Ahnung von den
Anforderungen des Projektes hat?
Ohne grosse Änderungen könnte man vermutlich einen 18F45K50 nehmen. Der
sollte billiger sein.
Wie kommst du auf die Idee mit dem PIC32?
Auch schon daran gedacht einen 16F1459 zu nehmen?
Volker S. schrieb:> Wie kommst du auf die Idee mit dem PIC32?
Einfach um mehr Leistung zu schaffen.
Die Abtastrate ist auch eine wichtige Kriterium für uns und aus diesem
grund habe ich an PIC32 bzw. die Überlegung auch an eine STM32.
> Auch schon daran gedacht einen 16F1459 zu nehmen?
Nein wenn einen neues Mikrocontroller sein muss, dann muss mindesten
eine 32Bit sein.
1. Braucht ihr die Leistung wirklich?
2. Die Bandbreite zur Übermittlung von Daten über HID ist nicht sehr
hoch.
(Die kann auch ein 8bit Controller locker auslasten ;-)
Volker S. schrieb:> 1. Braucht ihr die Leistung wirklich?> 2. Die Bandbreite zur Übermittlung von Daten über HID ist nicht sehr> hoch.
Wir sind seit 10 Jahre mit diesem Pic und ich denke der Zeitpunkt ist
schon gekommen davon zu verabschieden.
Die SW ist auf drei schichten aufgebaut:
1)FW
2)DLL (Algorithmen)
3) View Schicht
Wir wollen auch gerne der 1 und der zweite Schicht in einem schicht
haben.
IstStand:
Die SW ist aus Mischmaschi gebaut also eine durchgehende Änderung ist
ein Muss.
Es ist eine Entwicklung, die es nicht von heute auf morgen geht aber
wenn es langfristig gedacht dann muss die SW genau wie die HW von vorne
an überlegt werden.
was mir auch in diesem Projekt stört, dass es zwischen die Hardware (FW)
und die DLL(Algorithem) einen HID Class.dll benutzt wird was wirklich
mit sich sehr viele Probleme mitbringt.
Ich kann mir als Außenstehender leider nicht recht vorstellen was diese
Schicht DLL(Algorithmen) so macht ;-)
Ich habe auf meinem Rechner 8 Versionen der MLA von 2013..2017 und die
einzige welche diese HID class.dll enthält, ist die älteste v2013_06_15.
Da mich grundsätzlich nur Cross-Platfform taugliche Beispiele
interessieren
...mla\v2017_03_06\apps\usb\device\hid_custom\utilities\plug_and_play_ex
ample\cross_platform...
habe ich bisher aber auch nur die HID-API von Alan Ott verwendet.
wenn ich auf die die HID Class.dll verzichte und stadessen mich um deine
Demo mich orientiere, muss ich auch was ändern auf die FW Seite?
In der FW seite sind die Commandos so dekalariert:
Da musst du erst mal gar nichts ändern. Die PC Software funktioniert auf
dem TAB Terminal auch wie ein solches.
Die Nummer deines USB Gerätes auswählen und Connect klicken.
Wenn es funktioniert hat, schreibst du dein Kommando (z.B. 08) in eine
der vier Zeilen links neben den HEX OUT Buttons und klickst den Button
oder drückst die entsprechende Funktionstaste.
Die Antwort deines Gerätes wird dann in den zwei Fenstern darunter
angezeigt.
Saheb schrieb:> Ich frage mich wie bekommt man der Value dieses Array?
? Vermutlich verstehe ich die Frage nicht ;-)
Saheb schrieb:> USBOutHandle = HIDRxPacket(HID_EP,(uint8_t*)&ReceivedDataBuffer,64);Volker S. schrieb:> Das sind Macros aus dem MCHP USB Framework> -> irgendeine_installierte_MLA_Version -> .../doc/help_mla_usb.xxx
...
Saheb schrieb:> switch(ReceivedDataBuffer[0])
aber das wird erst später aufgerufen
Volker S. schrieb:> USBOutHandle = HIDRxPacket(HID_EP,(uint8_t*)&ReceivedDataBuffer,64);
z.B in deinem Projekt bei der Funktion:
1
void APP_cmd(void)
2
{
3
...
4
switch (ReceivedDataBuffer[1]) {
5
.. case CID_DEVICE: // send device identification string
6
ToSendDataBuffer[1] = CID_DEVICE | ID_MESSAGE;
7
ToSendDataBuffer[0] = sizeof (strDevice) + 1;
8
.....
9
10
}
Wo deklarierst, dass die Daten, die von der USB verbindung kommen
ReceivedDataBuffer heissen?
Danke
Saheb schrieb:> aber du muss irgendwie sagen die Daten, die von der USB bekomme heissen> "ReceivedDataBuffer"
Sieh es mal so:
Es wird irgendwo ein Array angelegt das ReceivedDataBuffer[] heißt und
dem USB Modul wird über das Makro mitgeteilt, dass die an einem
speziellen Endpunkt ankommenden Daten genau da rein geschrieben werden
sollen.
Das Makro gibt ein Handle zurück, mit dessen Hilfe überprüft werden
kann, ob ein Paket angekommen ist und verarbeitet werden kann
1
if(!HIDRxHandleBusy(USBOutHandle))
Wenn ein Paket empfangen und gegebenenfalls verarbeitet wurde, muss dem
USB Modul wieder mitgeteilt werden, dass der Speicherbereich wieder für
ein zukünftig ankommendes Paket benutzt werden kann/soll.
Darum steht am Ende der Verarbeitung wieder das Makro...
Das FIXED_ADDRESS_MEMORY Zeug ist nochmal eine andere Geschichte und
kommt daher, dass bei den älteren PICs das USB-Modul nur auf bestimmte
Bereiche des RAMs Zugriff hat. -> Datasheet
Hallo Volker,
Ich habe es mit deinem HID-Demo rumgespielt.
Was ich gemerkt habe ist: Bei bestimmten Commandos bleibt die HID-Demo
SW hängen.
Technisch: Die
liefert keine Antwort zurück.
Und wenn ich das Programm beende und neue starten, wird trotzdem die USB
Verbindung nicht gefunden.
In diesem Fall hilft nur die USB Kabel kurz auszustecken und wieder
einzustecken, dann wird die USB Verbindung gefunden.
Was meinst du jetzt genau?
PC Software, Firmware oder beides?
Welche bestimmten Kommandos?
Wenn du das alles gleich geschrieben hättest,
wüsste ich jetzt vermutlich schon die Antwort auf das Problem ;-)
Volker S. schrieb:> Was meinst du jetzt genau?> PC Software, Firmware oder beides?
Pc SW
>> Welche bestimmten Kommandos?>
z.B in meine Firmware das Kommando:23 heisst Messung Signalperiode.
Eigentlich nicht.
Dieses Effekt tritt, wenn ich z.B das Kommandos 23 drei mal wiederhole.
Bei ersten mal ist gut
beim zweiten mal ist auch gut
Und beim dritten mal bekomme ich keine Antwort und die SW(PC SW)bleibt
hängen.
Saheb schrieb:> Und beim dritten mal bekomme ich keine Antwort und die SW(PC SW)bleibt> hängen.
Soll heißen das Programm bleibt in der Funktion hid_write() hängen oder
was?
Saheb schrieb:> Technisch: Diehid_write(hid_device *dev, const unsigned char *data,> size_t length)> liefert keine Antwort zurück.
Immer beim dritten mal?
Dann wurde das Gerät vielleicht mit dem zweiten Kommando abgeschossen.
Volker S. schrieb:> Soll heißen das Programm bleibt in der Funktion hid_write() hängen oder> was?
Ja die FKT hid_write()wird ne beendet aber sobald die USB Verbindung
kurs aus/eingestekt dann wird beendet.
Volker S. schrieb:> Immer beim dritten mal?
Ja
> Dann wurde das Gerät vielleicht mit dem zweiten Kommando abgeschossen
Die ist schon beim zweiten Kommando abgeschossen aber beim zweiten
Kommandos kann es die FKT "hid_write()" mindesten aufgereufen aber beim
dritten bleibt es hängen.
Saheb schrieb:> Die ist schon beim zweiten Kommando abgeschossen aber beim zweiten> Kommandos kann es die FKT "hid_write()" mindesten aufgereufen aber beim> dritten bleibt es hängen.
Das heißt, beim dritten mal kannst du auch ein anderes Kommando ( nicht
mehr ;-) schicken?
Oder wenn einmal 23 geschickt wurde, dann kann man noch ein einziges
weiteres/anderes Kommando abschicken und bei jedem weiteren Versuch ist
Ende?
Tja, da solltest du wohl mal die Firmware deines Gerätes mit dem
Debugger untersuchen...
Volker S. schrieb:> Das heißt, beim dritten mal kannst du auch ein anderes Kommando ( nicht> mehr ;-) schicken?
Ja
Volker S. schrieb:> Oder wenn einmal 23 geschickt wurde, dann kann man noch ein einziges> weiteres/anderes Kommando abschicken und bei jedem weiteren Versuch ist> Ende?
Warum?
Aber es muss doch möglich sein, dieses Kommandos beliebig abzufragen und
es spricht nicht dagegen
Saheb schrieb:> und es spricht nicht dagegen
Deine Firmware?
BTW: Beantworte bitte noch die Frage:
Volker S. schrieb:> Oder wenn einmal 23 geschickt wurde, dann kann man noch ein einziges> weiteres/anderes Kommando abschicken und bei jedem weiteren Versuch ist> Ende?
Volker S. schrieb:> Deine Firmware?
Ja
Volker S. schrieb:>> Oder wenn einmal 23 geschickt wurde, dann kann man noch ein einziges>> weiteres/anderes Kommando abschicken und bei jedem weiteren Versuch ist>> Ende?
Das Kommando 23 muss belibig oft abgeschcikt werden ohne Begrenzung
Saheb schrieb:> Das Kommando 23 muss belibig oft abgeschcikt werden ohne Begrenzung
Das ist keine Antwort auf meine Frage!
Ich habe danach gefragt, wie es ist und nicht wie es sein soll!
Kommt überhaupt eine Antwort auf das Kommando 23?
Volker S. schrieb:> Saheb schrieb:>> und es spricht nicht dagegen>> Deine Firmware?
Soll heißen: "deine/eure Firmware spricht dagegen" ;-)
Na, oben hast du behauptet, die Software bleibt beim dritten Kommando
hängen. Jetzt schon beim zweiten. Was denn nun GENAU?
-------------------------------------------------------------------
PS:
Die Länge der Antwort ist vermutlich viel kürzer.
Das kommt wohl davon, dass ich in meinem Beispiel das erste Byte
inBuffer[0] für eine Info benutze, wie viele gültige Daten-Bytes
kommen. (es kommt immer ein komplettes Paket mit 64, die aber nicht alle
etwas vernünftiges enthalten)
Antwort 0x23 wird von der SW interpretiert als 35 gültige Daten und so
viele werden angezeigt.
Volker S. schrieb:> Was denn nun GENAU?
z.B:
folgende vorgehen:
1)Beim Kommando: 8
überhaupt kein Problem. Kommandos kann öfter wiederholt werden
Antwort ist immer korrekt.
2)Beim Kommando: 23
Nur Kommando 23
Beim ersten mal Durchführung --> richtig ausgeführt
Beim zweiten mal auch --> richtig ausgeführt
Beim dritten mal --> SW bleibt hängen
3) Kommando: 8
@ richtig ausgeführt
Kommando: 23
@ richtig ausgeführt
Kommando: 8
SW (PC SW) bleibt hängen
Saheb schrieb:> Beim Kommando 23 und 8 sieht der inBuffer wie folgende aus (Seh bitte> Anhang).
Es ist egal, wie der Buffer aussieht. Wichtig ist nur die Information,
dass im Buffer nicht unbedingt was sinnvolles drin steht!
DU musst irgendwie wissen, wie die Antwort aussieht, bzw. wie lang sie
wirklich ist.
Zum Thema hängen bleiben:
Ich nehme an das Kommando 23 schießt den uC ab und er reagiert nicht
mehr.
Das kannst du sehr einfach überprüfen.
Kommando 23 schicken und dann disconect. Wenn das Gerät dann nicht
wieder oben in der Liste auftaucht, ist es tot! (wurde es vom Kommando
23 gekillt)
Zweite Möglichkeit:
In der Firmware einen Breakpoint auf die Verarbeitung von Kommando 8.
Zuerst Kommando 23 schicken und dann 8. Wird der Breakpoint nicht
erreicht...
Volker S. schrieb:> Das kannst du sehr einfach überprüfen.> Kommando 23 schicken und dann disconect. Wenn das Gerät dann nicht> wieder oben in der Liste auftaucht, ist es tot! (wurde es vom Kommando> 23 gekillt)
Ja das stimmt Kommando 23 ist gekillt.
Das Kommando 23 hat die USB Verbindung gekillt, weil es von der (PC SW)
Inhalte fehlen.
Um das Kommando 23 korrekt auszuführen muss man noch 2 DatenValue
"ReceivedDataBuffer[2] und ReceivedDataBuffer[3] " mitschicken (mein
Fehler).
Volker das kannst du nicht wissen.
Jetzt, wenn ich die beiden Values der ReceivedDataBuffer[2] bzw. der
ReceivedDataBuffer[3] korrekt mitschicke, dann läuft alles wie es sein
muss.
(HID-Demo "PC SW") wird nicht mehr hängen bleiben.
@Saheb: bitte, registriere dich endlich mal, dann kannst du eine private
Unterhaltung mit Volker weiter per PN führen. Er hat zwar (wieder mal)
eine auserordentliche Geduld und Hilfsbereitschaft gezeigt, aber es gibt
noch zig tausend andere Forumnutzer. Einige von denen können und wollen
dir bei konkreten Fragen zu STM32 oder FPGA helfen, aber bitte in
separaten, neuen Threads ggf. im entspr. Unterforum.
Ich nehme jetzt mal an, die Variablen sind lokal und der Stack ist im
C18 Linker Skript wie groß definiert?
Stellt sich die Frage: Sollen die Variablen lokal sein?
PS: DAS wäre im XC8 Compiler anders/besser gelöst...
PPS: Hat mit der IDE natürlich genau gar nichts zu tun ;-)
Volker S. schrieb:> Ich nehme jetzt mal an, die Variablen sind lokal und der Stack ist im> C18 Linker Skript wie groß definiert?
Ja
Es handelt sich um lokale Variablen."Seh bitte Anhang"
> Stellt sich die Frage: Sollen die Variablen lokal sein?
Wenn die Variable nur in eine Funktion gebraucht ist, dann muss es
lokale definiert sein oder muss ich die jetzt globale definieren um
diese Error umzugehen?
> PS: DAS wäre im XC8 Compiler anders/besser gelöst...
Das muss ich sowiso tun. Das ganze in XC8 integrieren.
Danke in voraus
Wenn das Ganze nach XC8 transferiert werden soll, dann würde ich
vorschlagen, du machst das zuerst und erweiterst das Programm danach.
Das würde die Geschichte mit Variablen in einem Modul, die in der Summe
mehr als eine BANK beanspruchen, erleichtern bzw. unnötige Arbeit
vermeiden...
ODER du liest im User Guide des C18 Compilers nach ;-)