Unterschied zwischen bei Compiler MPLAB® C und MPLAB® XC

[David (Gast)]

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

[Pandur S. (jetztnicht)]

Welchen der beiden hast du denn probiert ? Ging's nicht ?

[Volker S. (vloki)]

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.

[David (Gast)]

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. (vloki)]

MPLABX ist eine IDE, kein Compiler und keine Bibliothek!
Das muss man dann extra installieren. Welche USB Library genau?

[E-Bastler (Gast)]

David schrieb:
> Unter die Virtuelle Maschine zu debuggen ist echt sehr schwierig

Warum?

[David (Gast)]

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.

[David (Gast)]

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.

[Gerhard M. (ggcode)]

MPLAB X mit XC8

[David (Gast)]

Gerhard M. schrieb:
> MPLAB X mit XC8

Ist eine grosse unterschied zwischen beide Compiler XC8 und die C18?

[Volker S. (vloki)]

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)

[Axel S. (a-za-z0-9)]

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.

[David (Gast)]

dafür entschuldige ich mich
Sorry

[David (Gast)]

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:

[Header]
MagicCookie={0b13fe8c-dfe0-40eb-8900-6712719559a7}
Version=1.0

[Volker S. (vloki)]

Einige Zeilen weiter unten...

[HEADER]
magic_cookie={66E99B07-E706-4689-9E80-9B2582898A13}
file_version=1.0
device=PIC18F2550
[PATH_INFO]
BuildDirPolicy=BuildDirIsProjectDir
dir_src=
dir_bin=_output
dir_tmp=_output
dir_sin=
dir_inc=..
dir_lib=c:/eda/Microchip/mcc18/lib
dir_lkr=c:/eda/microchip/mcc18/lkr

Also hier mcc18 /lib >>> C18 compiler

[David (Gast)]

Guten Morgen,

so mir steht auch so :

[HEADER]
magic_cookie={66E99B07-E706-4689-9E80-9B2582898A13}
file_version=1.0
device=PIC18F4550
[PATH_INFO]
BuildDirPolicy=BuildDirIsProjectDir
dir_src=
dir_bin=.\Output
dir_tmp=.\Objects
dir_sin=
dir_inc=C:\Microchip Solutions\Microchip\Include;C:\MCC18\h
dir_lib=C:\mcc18\lib

Die Frage ist: Um dieses Projekt in MPLAB X IDE zu integrien, worauf 
muss ich achten?

[Volker S. (vloki)]

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.

[Volker S. (vloki)]

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.

[David (Gast)]

@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?

[Volker S. (vloki)]

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

[Volker S. (vloki)]

Versuch am besten zuerst das da:
http://microchipdeveloper.com/mplabx:convert-an-mplab-8-project-to-mplab-x

Wenn es dann irgendwo klemmt, kannst du immer noch manuell nachhelfen...

Nach dem ersten geglückten Compilieren archivierst du das am besten 
damit:
http://microchipdeveloper.com/mplabx:projects-package

oder gleich mit einem Version Control System.
http://microchipdeveloper.com/mplabx:version-control-working-with

[Saheb (Gast)]

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

[Volker S. (vloki)]

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 ;-)

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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!

[Rufus Τ. F. (rufus)]

Saheb/David: Entscheide Dich bitte ein für alle Mal, wer Du sein willst.

Die https://www.mikrocontroller.net/user/conditions verbieten den 
Gebrauch mehrerer "Identitäten" in einem Thread.

[Volker S. (vloki)]

Rufus Τ. F. schrieb:
> Saheb/David: Entscheide Dich bitte ein für alle Mal, wer Du sein willst.

...oder melde dich einfach an, dann passiert das nicht!

[Saheb (Gast)]

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:

#define Current_Measure             0x10
int main()
{
    ....
    case Current_Measure:
    {
       ....
    }
}

[Volker S. (vloki)]

Saheb schrieb:
> 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.

DA wäre ich ja nie drauf gekommen ;-)

Es ist so was ähnliches, wie dieses einfache Beispiel:
http://picforum.ric323.com/viewtopic.php?f=46&t=103#p745
http://www.hs-ulm.de/nocache/wir/Personal/PersonalSaSchr/vschilli/Mikrocontroller/USBProjekte/USBHID/

Die Frage war aber eher in Richtung "Erhalten die Controller bei 
individuelle Seriennummern?"

[Saheb (Gast)]

Beim mir das Build und Programmer funktioniert einwandfrei.
Was nicht funktioniert, ist das Debuggen

[Volker S. (vloki)]

Build im debug mode funktioniert nicht!
(oder inzwischen doch)

[Saheb (Gast)]

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?

[Volker S. (vloki)]

http://microchipdeveloper.com/mplabx:main-toolbar

Bei
- Make and Program Target Project
- Debug Project
ist jedes mal Build im richtigen Modus im Hintergrund mit dabei

Bei
- Build Project
- Clean and Build Project
kann man den Mode über die DropDown Auswhl festlegen


Den Unterschied kann man hier gut erkennen:
http://microchipdeveloper.com/icd3:debug-executive
http://www.microchip.com/developmenttools/getting_started/gs_mplab4.aspx

[Volker S. (vloki)]

Volker S. schrieb:
> Den Unterschied kann man hier gut erkennen:
> http://microchipdeveloper.com/icd3:debug-executive

Für den 4550 sieht das übrigens so aus:
Fällt dir was auf?

[Saheb (Gast)]

Volker S. schrieb:
> Fällt dir was auf?

Wo sehe ich das?

Sorry

[Saheb (Gast)]

anbei das MPLAB X IDE beim starten

[Saheb (Gast)]

wenn ich so mache: seh bitte Anhang

dann lauft alles Okay

[Volker S. (vloki)]

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...

[Saheb (Gast)]

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

[Volker S. (vloki)]

Die Debug Executive benötigt den Speicherbereich 0x7DC0-0x7FFF *1.
Im Linker Script wird aber eine SEKTION namens SERIAL reserviert.

CODEPAGE   NAME=serial    START=0x7FC0    END=0x7FFF   PROTECTED
...
SECTION    NAME=SERIAL     ROM=serial

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

Error - section 'dbgP0' can not fit the absolute section. Section 'dbgP0' start=0x00007dc0, length=0x00000240

 *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

[Saheb (Gast)]

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

[Volker S. (vloki)]

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 ...

[Saheb (Gast)]

danke nochmal

 
/*********************************************************************
 * Descriptor specific type definitions are defined in:
 * usb_device.h
 *
 * Configuration options are defined in:
 * usb_config.h
 ********************************************************************/
#ifndef __USB_DESCRIPTORS_C
#define __USB_DESCRIPTORS_C

/** INCLUDES *******************************************************/
#include "./USB/usb.h"
#include "./USB/usb_function_hid.h"

/** CONSTANTS ******************************************************/
#if defined(__18CXX)
//#pragma romdata
#endif

/* Device Descriptor */
ROM USB_DEVICE_DESCRIPTOR device_dsc=
{
    0x12,    // Size of this descriptor in bytes
    USB_DESCRIPTOR_DEVICE,                // DEVICE descriptor type
    0x0200,                 // USB Spec Release Number in BCD format
    0x00,                   // Class Code
    0x00,                   // Subclass code
    0x00,                   // Protocol code
    USB_EP0_BUFF_SIZE,          // Max packet size for EP0, see usb_config.h
    0x04D8,                 // Vendor ID
    0x003F,                 // Product ID: Mouse in a circle fw demo
    0x0002,                 // Device release number in BCD format
    0x01,                   // Manufacturer string index
    0x02,                   // Product string index
    0x03,                   // Device serial number string index
    0x01                    // Number of possible configurations
};

/* Configuration 1 Descriptor */
ROM BYTE configDescriptor1[]={
    /* Configuration Descriptor */
    0x09,//sizeof(USB_CFG_DSC),    // Size of this descriptor in bytes
    USB_DESCRIPTOR_CONFIGURATION,                // CONFIGURATION descriptor type
    0x29,0x00,            // Total length of data for this cfg
    1,                      // Number of interfaces in this cfg
    1,                      // Index value of this configuration
    0,                      // Configuration string index
    _DEFAULT | _SELF,               // Attributes, see usb_device.h
    50,                     // Max power consumption (2X mA)
              
    /* Interface Descriptor */
    0x09,//sizeof(USB_INTF_DSC),   // Size of this descriptor in bytes
    USB_DESCRIPTOR_INTERFACE,               // INTERFACE descriptor type
    0,                      // Interface Number
    0,                      // Alternate Setting Number
    2,                      // Number of endpoints in this intf
    HID_INTF,               // Class code
    0,     // Subclass code
    0,     // Protocol code
    0,                      // Interface string index

    /* HID Class-Specific Descriptor */
    0x09,//sizeof(USB_HID_DSC)+3,    // Size of this descriptor in bytes
    DSC_HID,                // HID descriptor type
    0x11,0x01,                 // HID Spec Release Number in BCD format (1.11)
    0x00,                   // Country Code (0x00 for Not supported)
    HID_NUM_OF_DSC,         // Number of class descriptors, see usbcfg.h
    DSC_RPT,                // Report descriptor type
    HID_RPT01_SIZE,0x00,//sizeof(hid_rpt01),      // Size of the report descriptor
    
    /* Endpoint Descriptor */
    0x07,/*sizeof(USB_EP_DSC)*/
    USB_DESCRIPTOR_ENDPOINT,    //Endpoint Descriptor
    HID_EP | _EP_IN,                   //EndpointAddress
    _INTERRUPT,                       //Attributes
    0x40,0x00,                  //size
    0x01,                        //Interval

    /* Endpoint Descriptor */
    0x07,/*sizeof(USB_EP_DSC)*/
    USB_DESCRIPTOR_ENDPOINT,    //Endpoint Descriptor
    HID_EP | _EP_OUT,                   //EndpointAddress
    _INTERRUPT,                       //Attributes
    0x40,0x00,                  //size
    0x01                        //Interval
};


//Language code string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[1];}sd000={
sizeof(sd000),USB_DESCRIPTOR_STRING,{0x0409
}};

//Manufacturer string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[11];}sd001={
sizeof(sd001),USB_DESCRIPTOR_STRING,
{
'G','m','b','H'
}};

//Product string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[31];}sd002={
sizeof(sd002),USB_DESCRIPTOR_STRING,
{
'D',
}};

#pragma romdata SERIAL
ROM struct{BYTE bLength;BYTE bDscType;WORD string[8];}sd003={
sizeof(sd003),USB_DESCRIPTOR_STRING,{'6','9','0','0','0','0','0','1'}
};
#pragma romdata

//Class specific descriptor - HID 
ROM struct{BYTE report[HID_RPT01_SIZE];}hid_rpt01={
{
    0x06, 0x00, 0xFF,       // Usage Page = 0xFF00 (Vendor Defined Page 1)
    0x09, 0x01,             // Usage (Vendor Usage 1)
    0xA1, 0x01,             // Collection (Application)
    0x19, 0x01,             //      Usage Minimum 
    0x29, 0x40,             //      Usage Maximum   //64 input usages total (0x01 to 0x40)
    0x15, 0x00,             //      Logical Minimum (data bytes in the report may have minimum value = 0x00)
    0x26, 0xFF, 0x00,       //      Logical Maximum (data bytes in the report may have maximum value = 0x00FF = unsigned 255)
    0x75, 0x08,             //      Report Size: 8-bit field size
    0x95, 0x40,             //      Report Count: Make sixty-four 8-bit fields (the next time the parser hits an "Input", "Output", or "Feature" item)
    0x81, 0x00,             //      Input (Data, Array, Abs): Instantiates input packet fields based on the above report size, count, logical min/max, and usage.
    0x19, 0x01,             //      Usage Minimum 
    0x29, 0x40,             //      Usage Maximum   //64 output usages total (0x01 to 0x40)
    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.
    0xC0}                   // End Collection
};                  


//Array of configuration descriptors
ROM BYTE *ROM USB_CD_Ptr[]=
{
    (ROM BYTE *ROM)&configDescriptor1
};

//Array of string descriptors
ROM BYTE *ROM USB_SD_Ptr[]=
{
    (ROM BYTE *ROM)&sd000,
    (ROM BYTE *ROM)&sd001,
    (ROM BYTE *ROM)&sd002,
  (ROM BYTE *ROM)&sd003
};

/** EOF usb_descriptors.c ***************************************************/

#endif

[Volker S. (vloki)]

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

[Saheb (Gast)]

Hallo,

Compilieren einwandfrei
das Debuggen leider nicht
Error:

Error - section 'dbgP0' can not fit the absolute section. Section 'dbgP0' start=0x00007d30, length=0x000002d0

[Volker S. (vloki)]

Quatsch, das ist eine Meldung des Compilers/Linkers.
Bis zum Debuggen kommt das doch gar nicht!

[Saheb (Gast)]

Sorry Tipp Fehler
Ich bekomme folgende Errors:

make[2]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed


make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 1s)

[Volker S. (vloki)]

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 (Gast)]

Ich habe die beide Zeilen in Linker gelöscht aber ich bekomme immer die 
gleiche Fehlermeldung.

make[2]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 1s)

[Volker S. (vloki)]

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!

[Saheb (Gast)]

Ich habe es gepasst aber trotzdem immer die gleiche Fehlermeldung

[Saheb (Gast)]

Das habe ich auch so immer gemacht CLEAN AND BUILD

[Saheb (Gast)]

CLEAN SUCCESSFUL (total time: 102ms)
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
make  -f nbproject/Makefile-default.mk dist/default/production/EFI_Firmware_HID.X.production.hex
make[2]: Entering directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1494620250/usb_function_hid.o   "C:/Microchip Solutions/Microchip/USB/HID Device Driver/usb_function_hid.c" 
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1472/usb_descriptors.o   ../usb_descriptors.c 
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1472/main.o   ../main.c 
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1472/i2c_func.o   ../i2c_func.c 
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1472/asic_func_mo.o   ../asic_func_mo.c 
"C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe"  -p18F4550 -I".." -I"C:/MCC18/h" -I"C:/Microchip Solutions/Microchip/Include" -I"." -ms -oa-  -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h  -fo build/default/production/_ext/1302440332/usb_device.o   "C:/Microchip Solutions/Microchip/USB/usb_device.c" 
MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

D:\Projekte\HID-Firmware-HR\i2c_func.c:88:Warning [2054] suspicious pointer conversion
D:\Projekte\HID-Firmware-HR\i2c_func.c:259:Warning [2058] call of function without prototype
D:\Projekte\HID-Firmware-HR\i2c_func.c:261:Warning [2058] call of function without prototype
D:\Projekte\HID-Firmware-HR\i2c_func.c:280:Warning [2054] suspicious pointer conversion
D:\Projekte\HID-Firmware-HR\i2c_func.c:309:Warning [2054] suspicious pointer conversion
D:\Projekte\HID-Firmware-HR\i2c_func.c:401:Warning [2054] suspicious pointer conversion
D:\Projekte\HID-Firmware-HR\i2c_func.c:452:Warning [2054] suspicious pointer conversion
D:\Projekte\HID-Firmware-HR\usb_descriptors.c:161:Error [1030] identifier expected in #ifdef
MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

make[2]: *** [build/default/production/_ext/1472/usb_descriptors.o] Error 3
make[2]: *** Waiting for unfinished jobs....
nbproject/Makefile-default.mk:162: recipe for target 'build/default/production/_ext/1472/usb_descriptors.o' failed
MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2242:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2242:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2246:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2246:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2258:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2258:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2296:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2296:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2300:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2300:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2312:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\asic_func_mo.c:2312:Warning [2060] shift expression has no effect
MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

D:\Projekte\HID-Firmware-HR\main.c:427:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\main.c:427:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\main.c:439:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\main.c:439:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\main.c:446:Warning [2060] shift expression has no effect
D:\Projekte\HID-Firmware-HR\main.c:446:Warning [2060] shift expression has no effect
MPLAB C18 3.47 (evaluation)
Copyright 2000-2011 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  54

WARNING:  Running the compiler in extended mode will not be supported when the evaluation becomes feature limited.

WARNING: The procedural abstraction optimization will not be supported when the evaluation becomes feature limited.

make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
make[2]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Projekte/HID-Firmware-HR/EFI Firmware HID.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed

BUILD FAILED (exit value 2, total time: 1s)

[Saheb (Gast)]

Sorry sorry wieder eine tipp Fehler von mir
Das Build geht
Das Debuggen aber nicht.
Error :

Error - section '.stack' has a memory 'gpr3' which can not fit the section. Section '.stack' length=0x00000100.
Errors    : 1

[Volker S. (vloki)]

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

[Saheb (Gast)]

Guten Morgen,


Der Linker script sieht jetzt so aus:

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4550.lib

CODEPAGE   NAME=bootloader START=0x0               END=0x002F         PROTECTED
CODEPAGE   NAME=vectors    START=0x0030            END=0x0059        PROTECTED
CODEPAGE   NAME=page       START=0x0060            END=0x7FFF
CODEPAGE   NAME=idlocs     START=0x200000          END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000          END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000          END=0xF000FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x5F
DATABANK   NAME=gpr0       START=0x60           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x2FF
DATABANK   NAME=gpr3       START=0x300          END=0x3FF
DATABANK   NAME=usb4       START=0x400          END=0x4FF          PROTECTED
DATABANK   NAME=usb5       START=0x500          END=0x5FF          PROTECTED
DATABANK   NAME=usb6       START=0x600          END=0x6FF          PROTECTED
DATABANK   NAME=usb7       START=0x700          END=0x7FF          PROTECTED
ACCESSBANK NAME=accesssfr  START=0xF60          END=0xFFF          PROTECTED

SECTION    NAME=CONFIG     ROM=config

STACK SIZE=0x100 RAM=gpr2

SECTION     NAME=USB_VARS   RAM=usb4

[Saheb (Gast)]

Mit dieses Linker kann ich das projekt compilieren.
Problem ist beim debuggen.
Ich bekomme immer diese Fehlermeldung:

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x7d3f
configuration memory
Debug Executive
Address: 7d30 Expected Value: 14 Received Value: 0
Failed to program device

[Volker S. (vloki)]

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

[Saheb (Gast)]

Hi,
wenn ich die das Projekt so einstelle (Seh bitte Anhang), dann bekomme 
ich folgende Error beim Debuggen:

Failed to program device
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.

[Volker S. (vloki)]

Stell's halt auf Automatic oder auf 0-0x7D2F ;-)

[Saheb (Gast)]

Ich habe es jetzt so eingestellt("seh Anhang").

Ich bekomme aber diese Fehlermeldung:

program memory: start address = 0x0, end address = 0x7d3f
configuration memory
Debug Executive
Address: 7d30 Expected Value: 14 Received Value: 0
Failed to program device

[Volker S. (vloki)]

Was passiert bei manuell 0-7d2f?

[Saheb (Gast)]

program memory: start address = 0x0, end address = 0x7d3f
configuration memory
Debug Executive
Address: 7d30 Expected Value: 14 Received Value: 0
Failed to program device

[Saheb (Gast)]

So sieht es aus meine Änderung

[Volker S. (vloki)]

So langsam glaub ich, du willst mich verarschen. Das ist nicht manuell!
Wie blind kann man eigentlich sein?

[Saheb (Gast)]

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.

Failed to program device
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.

[Volker S. (vloki)]

Jetzt lies nochmal die Fehlermeldung und denk ein klitze kleines 
bisschen mit. Wie lautet die nächst kleinere Adresse die passt?

[Saheb (Gast)]

Das hier:

0x7d3f

[Volker S. (vloki)]

Falsch!

[Saheb (Gast)]

Nächste Zahl nach 7D2F ist 7D30

[Volker S. (vloki)]

Welche Bedeutung hat das Adjektiv "kleiner"?

[Saheb (Gast)]

kleiner als (7D2F) halt:
7D2E

[Saheb (Gast)]

Ich weiss es nicht wie du auf diese Adresse "7D2F" gekommen bist.
richtig wäre aber diese Adresse "7D3F", die du eigentlich meinst.

[Volker S. (vloki)]

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?

[Saheb (Gast)]

@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

[Volker S. (vloki)]

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.

[Saheb (Gast)]

@ Volker SK (vloki)


Vielen vielen dank für deine Geduld und einfach alles.
Jetzt geht

Ich kann schon debuggen.

Super

[Volker S. (vloki)]

Vergiss das Problem mit der Seriennummer nicht.
Am Ende muss die möglicherweise wieder genau da stehen , wo sie war...

[Saheb (Gast)]

noch eine letze Frage.
das heisst, dass es bei der Linker:

CODEPAGE   NAME=serial     START=0x7FC0         END=0x7FFF  PROTECTED

dieses gar nicht zu gebrauchen ist.

Der Linker in der zwischen habe ich so angepasst:

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4550.lib

CODEPAGE   NAME=bootloader START=0x0               END=0x002F         PROTECTED
CODEPAGE   NAME=vectors    START=0x0030            END=0x0059        PROTECTED
CODEPAGE   NAME=page       START=0x0060            END=0x7FFF
CODEPAGE   NAME=idlocs     START=0x200000          END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000          END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000          END=0xF000FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x5F
DATABANK   NAME=gpr0       START=0x60           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x2FF
DATABANK   NAME=gpr3       START=0x300          END=0x3FF
DATABANK   NAME=usb4       START=0x400          END=0x4FF          PROTECTED
DATABANK   NAME=usb5       START=0x500          END=0x5FF          PROTECTED
DATABANK   NAME=usb6       START=0x600          END=0x6FF          PROTECTED
DATABANK   NAME=usb7       START=0x700          END=0x7FF          PROTECTED
ACCESSBANK NAME=accesssfr  START=0xF60          END=0xFFF          PROTECTED

#IFDEF _CRUNTIME
SECTION    NAME=CONFIG     ROM=config

//STACK SIZE=0x100 RAM=gpr3
    #IFDEF _DEBUGSTACK
    STACK SIZE=0x100 RAM=gpr2
    #ELSE
    STACK SIZE=0x0F4 RAM=gpr3
    #FI
#FI
SECTION     NAME=USB_VARS   RAM=usb4

[Volker S. (vloki)]

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:

//#pragma romdata SERIAL
#ifndef __DEBUG
    #pragma romdata serilanumber = 0x7FC0
#endif
const struct{uint8_t bLength;uint8_t bDscType;uint16_t string[8];}sd003={
sizeof(sd003),USB_DESCRIPTOR_STRING,{'6','9','0','0','0','0','0','1'}
};
#pragma romdata

Siehe User Guide vom Compiler -> 2.9.1 #pragma sectiontype

[Saheb (Gast)]

vielen dank nochmal
Ich habe noch einen Frage wofür die serialnummer?

   #pragma romdata serialanumber = 0x7FC0

[Volker S. (vloki)]

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...

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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!

[Patrick B. (p51d)]

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...

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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.

[Saheb (Gast)]

@Volker

Wie kann ich dich danken?

[Saheb (Gast)]

@Volker

Codeabschnitt Review bzw. Feadback

/********************************************************************
 FileName:     main.c
 Dependencies: See INCLUDES section
 Processor:    PIC18F4550
 Complier:    Microchip C18 (for PIC18)
********************************************************************/

#ifndef MAIN_C
#define MAIN_C

/** INCLUDES *******************************************************/

#include <EEP.h>
#include <delays.h>

#include <timers.h>


/** VERSION INFO ****************************************************/
#define MAJOR_VERSION 9
#define MINOR_VERSION 15
#define DELAY10MS  Delay10KTCYx(10);

/** CONFIGURATION **************************************************/
        #pragma config PLLDIV   = 3         // (20 MHz crystal on PICDEM FS USB board)
        #pragma config CPUDIV   = OSC1_PLL2 
        #pragma config USBDIV   = 2         // Clock source from 96MHz PLL/2
        #pragma config FOSC     = HSPLL_HS
        #pragma config FCMEN    = OFF
        #pragma config IESO     = OFF
        #pragma config PWRT     = OFF
        #pragma config BOR      = ON
        #pragma config BORV     = 3
        #pragma config VREGEN   = ON      //USB Voltage Regulator
        #pragma config WDT      = ON  
        #pragma config WDTPS    = 512  
        #pragma config MCLRE    = ON
        #pragma config LPT1OSC  = OFF
        #pragma config PBADEN   = OFF
//      #pragma config CCP2MX   = ON
        #pragma config STVREN   = ON
        #pragma config LVP      = OFF
//      #pragma config ICPRT    = OFF       // Dedicated In-Circuit Debug/Programming
        #pragma config XINST    = OFF       // Extended Instruction Set
        #pragma config CP0      = OFF
        #pragma config CP1      = OFF
//      #pragma config CP2      = OFF
//      #pragma config CP3      = OFF
        #pragma config CPB      = OFF
//      #pragma config CPD      = OFF
        #pragma config WRT0     = OFF
        #pragma config WRT1     = OFF
//      #pragma config WRT2     = OFF
//      #pragma config WRT3     = OFF
        #pragma config WRTB     = OFF       // Boot Block Write Protection
        #pragma config WRTC     = OFF
//      #pragma config WRTD     = OFF
        #pragma config EBTR0    = OFF
        #pragma config EBTR1    = OFF
//      #pragma config EBTR2    = OFF
//      #pragma config EBTR3    = OFF
        #pragma config EBTRB    = OFF




/** VARIABLES ******************************************************/
#pragma udata

#if defined(__18F14K50) || defined(__18F13K50) || defined(__18LF14K50) || defined(__18LF13K50) 
    #pragma udata usbram2
#elif defined(__18F2455) || defined(__18F2550) || defined(__18F4455) || defined(__18F4550)\
    || defined(__18F2458) || defined(__18F2453) || defined(__18F4558) || defined(__18F4553)
    #pragma udata USB_VARIABLES=0x500
#elif defined(__18F4450) || defined(__18F2450)
    #pragma udata USB_VARIABLES=0x480
#else
    #pragma udata
#endif
unsigned char ReceivedDataBuffer[64];
unsigned char ToSendDataBuffer[64];
#pragma udata


USB_HANDLE USBOutHandle = 0;
USB_HANDLE USBInHandle = 0;
BOOL blinkStatusValid = TRUE;

unsigned char ResetSignaturRAM[9];
const unsigned char ResetSignaturROM[9] = {0x55,0xAA,0x00,0xFF,0xA5,0x5A,0xF0,0x0F,0x00};



/** PRIVATE PROTOTYPES *********************************************/
void BlinkUSBStatus(void);
BOOL Switch2IsPressed(void);
BOOL Switch3IsPressed(void);
static void InitializeSystem(void);
void ProcessIO(void);
void UserInit(void);
void YourHighPriorityISRCode();
void YourLowPriorityISRCode();
WORD_VAL ReadPOT(void);

void vfuTestWatchdog(void);

/** VECTOR REMAPPING ***********************************************/
    #define PROGRAMMABLE_WHIT_USB_HID_BOOTLOADER
    
    #define REMAPPED_RESET_VECTOR_ADDRESS      0x0030
    #define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS  0x0038
    #define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS  0x0048
    
    
    extern void _startup (void);        // See c018i.c in your C18 compiler dir
    #pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
    void _reset (void)
    {
        _asm goto _startup _endasm
    }

    #pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
    void Remapped_High_ISR (void)
    {
         _asm goto YourHighPriorityISRCode _endasm
    }
    #pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
    void Remapped_Low_ISR (void)
    {
         _asm goto YourLowPriorityISRCode _endasm
    }
    
    #pragma code HIGH_INTERRUPT_VECTOR = 0x08
    void High_ISR (void)
    {
         _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
    }
    #pragma code LOW_INTERRUPT_VECTOR = 0x18
    void Low_ISR (void)
    {
         _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
    }

    #pragma code
    
    #pragma interrupt YourHighPriorityISRCode
    void YourHighPriorityISRCode()
    {
        int           i;
        #if defined(USB_INTERRUPT)
            USBDeviceTasks();
        #endif
//        if (INTCONbits.TMR0IF) //check for TMR0 overflow
//        {                                   
//          UCONbits.SUSPND = 0;    
//          UCON = 0x00;        
//          for(i = 0; i < 0xFF; i++) {
//            WREG = 0xFF;
//            while(WREG) {
//              WREG--;
//              _asm
//              bra  0  
//              bra  0  
//              _endasm  
//            }
//          }
//          Reset();
//        }
    }
    
    #pragma interruptlow YourLowPriorityISRCode
    void YourLowPriorityISRCode()
    {
    
    } 

/** DECLARATIONS ***************************************************/
#pragma code

/** Define function ***********************************************/
....

#define FIRMWARE_VERSION       0x08
#define RESET_DEVICE           0xFE
#define TEST_WATCHDOG          0xFF

#define TEST_MODE              0x30
/********************************************************************
 * Function:        void main(void)
 * PreCondition:    None
 * Input:           None
 * Output:          None
 * Side Effects:    None
 * Overview:        Main program entry point.
 * Note:            None
 *******************************************************************/
#if defined(__18CXX)
void main(void)
#else
int main(void)
#endif
{   

    // postscaler = 512, damit 4ms*512 = 2.048s timeout
    ClrWdt();  

    InitializeSystem();

    ClrWdt();

    #if defined(USB_INTERRUPT)
        USBDeviceAttach();
    #endif

    ClrWdt();

  //vfuTestWatchdog();

    while(1)
    {
       ClrWdt();

        #if defined(USB_POLLING)
        // Check bus status and service USB interrupts.
        USBDeviceTasks(); // Interrupt or polling method.  If using polling, must call
                          // this function periodically.  This function will take care
                          // of processing and responding to SETUP transactions 
                          // (such as during the enumeration process when you first
                          // plug in).  USB hosts require that USB devices should accept
                          // and process SETUP packets in a timely fashion.  Therefore,
                          // when using polling, this function should be called 
                          // frequently (such as once about every 100 microseconds) at any
                          // time that a SETUP packet might reasonably be expected to
                          // be sent by the host to your device.  In most cases, the
                          // USBDeviceTasks() function does not take very long to
                          // execute (~50 instruction cycles) before it returns.
        #endif
                      

        // Application-specific tasks.
        // Application related code may be added here, or in the ProcessIO() function.
        ProcessIO();   
     
    }//end while
}//end main 
 
#if 0
unsigned char ucfuLrcChecksum(unsigned char *pucBuff_p, int iBufflen_p)
{
  int i;
  unsigned char ucLrc_l=0;
  for (i=0; i<iBufflen_p; i++)
  {
    ucLrc_l = ucLrc_l ^ pucBuff_p[i];
  }
  
  return ucLrc_l;
}


void vfuTestWatchdog(void)
{
  unsigned char i;

  ResetSignaturRAM[8] = 1;

  for (i=0; i<8; i++)
  {
    if (ResetSignaturRAM[i] != ResetSignaturROM[i])
    {
      ResetSignaturRAM[8] = 0;
    }
  }
    
  if (ResetSignaturRAM[8] == 0)
  {
    for (i=0; i<8; i++)
    {
      ResetSignaturRAM[i] = ResetSignaturROM[i];
    }
  }
}
#endif


static void InitializeSystem(void)
{
   char Data[3]; 
    #if (defined(__18CXX) & !defined(PIC18F87J50_PIM))
        ADCON1 |= 0x0F;                 // Default all pins to digital
    #elif defined(__C30__)
        #if defined(__PIC24FJ256DA210__) || defined(__PIC24FJ256GB210__)
            ANSA = 0x0000;
            ANSB = 0x0000;
            ANSC = 0x0000;
            ANSD = 0x0000;
            ANSE = 0x0000;
            ANSF = 0x0000;
            ANSG = 0x0000;
        #else
            AD1PCFGL = 0xFFFF;
        #endif        
    #elif defined(__C32__)
        AD1PCFG = 0xFFFF;
    #endif



//  The USB specifications require that USB peripheral devices must never source
//  current onto the Vbus pin.  Additionally, USB peripherals should not source
//  current on D+ or D- when the host/hub is not actively powering the Vbus line.
//  When designing a self powered (as opposed to bus powered) USB peripheral
//  device, the firmware should make sure not to turn on the USB module and D+
//  or D- pull up resistor unless Vbus is actively powered.  Therefore, the
//  firmware needs some means to detect when Vbus is being powered by the host.
//  A 5V tolerant I/O pin can be connected to Vbus (through a resistor), and
//   can be used to detect when Vbus is high (host actively powering), or low
//  (host is shut down or otherwise not supplying power).  The USB firmware
//   can then periodically poll this I/O pin to know when it is okay to turn on
//  the USB module/D+/D- pull up resistor.  When designing a purely bus powered
//  peripheral device, it is not possible to source current on D+ or D- when the
//  host is not actively providing power on Vbus. Therefore, implementing this
//  bus sense feature is optional.  This firmware can be made to use this bus
//  sense feature by making sure "USE_USB_BUS_SENSE_IO" has been defined in the
//  HardwareProfile.h file.    
    #if defined(USE_USB_BUS_SENSE_IO)
    tris_usb_bus_sense = INPUT_PIN; // See HardwareProfile.h
    #endif
    
//  If the host PC sends a GetStatus (device) request, the firmware must respond
//  and let the host know if the USB peripheral device is currently bus powered
//  or self powered.  See chapter 9 in the official USB specifications for details
//  regarding this request.  If the peripheral device is capable of being both
//  self and bus powered, it should not return a hard coded value for this request.
//  Instead, firmware should check if it is currently self or bus powered, and
//  respond accordingly.  If the hardware has been configured like demonstrated
//  on the PICDEM FS USB Demo Board, an I/O pin can be polled to determine the
//  currently selected power source.  On the PICDEM FS USB Demo Board, "RA2" 
//  is used for  this purpose.  If using this feature, make sure "USE_SELF_POWER_SENSE_IO"
//  has been defined in HardwareProfile.h, and that an appropriate I/O pin has been mapped
//  to it in HardwareProfile.h.
    #if defined(USE_SELF_POWER_SENSE_IO)
    tris_self_power = INPUT_PIN;  // See HardwareProfile.h
    #endif

    UserInit();
    USBDeviceInit();  //usb_device.c.  Initializes USB module SFRs and firmware
                                //variables to known states.
    InitPort();
      i2c_init();
      i2c_confChips();
} //end InitializeSystem



void UserInit(void)
{
    unsigned char timerConfig = 0x00;

    //Initialize all of the LED pins
    mInitAllLEDs();
    
    USBOutHandle = 0;
    USBInHandle = 0;

    blinkStatusValid = TRUE;


    timerConfig = T0_16BIT & T0_SOURCE_INT & T0_PS_1_1 & TIMER_INT_OFF;
    WriteTimer0(0x0000);
    OpenTimer0(timerConfig);


}//end UserInit


void ProcessIO(void) 
{
    static unsigned char ucTestMode_m = 0;
  static unsigned char ucSendResetString_m = 0;
    
    int i,j;
    unsigned char counter = 2;
    long int     Result;

    unsigned char ucModeFlag =1;



    //Blink the LEDs according to the USB device status
    if (blinkStatusValid) 
    {
        BlinkUSBStatus();
    }

    // User Application USB task1 
    if ((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) 
        return;
    

    if (!HIDRxHandleBusy(USBOutHandle)) 
    {  

    //Check if data was received from the host.
        switch(ReceivedDataBuffer[0]) 
        { //Look at the data the host sent, to see what kind of application specific command it sent.

            /**********************************************************************************/
            /*                                                                                */
            /**********************************************************************************/
      ....
            case TEST_MODE:
                ucTestMode_m = 1;
            break;  

            case INDEX_CHECK:
                if (ucTestMode_m == 0)
                {
                    //                                    +--------- n values must be true
                    //                                    |  
                    ToSendDataBuffer[2] = index_check_new(8);
                }
                else
                {
                    ToSendDataBuffer[2] = 0x1;
                }

                counter += 1;
            break;
        
            /**********************************************************************************/
            /*                                                                                */
            /**********************************************************************************/
            case FIRMWARE_VERSION:
                ToSendDataBuffer[2] = MAJOR_VERSION;
                ToSendDataBuffer[3] = MINOR_VERSION;

                counter += 2;
            break;
      
      case HW_DELAY1MS:
        hw_delay1ms(ReceivedDataBuffer[2]);
          
                ToSendDataBuffer[2] = 1; // true = OK

        counter += 1;      
      break;

            /**********************************************************************************/
            /*                                                                                */
            /**********************************************************************************/
      case EXTENDED_IO_WRTIE:
        extended_io_write(ReceivedDataBuffer[2], ReceivedDataBuffer[3]);
      break;

            /**********************************************************************************/
            /*                                                                                */
            /**********************************************************************************/
      case EXTENDED_IO_READ:
                ToSendDataBuffer[2] = extended_io_read(ReceivedDataBuffer[2]);
                counter += 1;
      break;


        //******************************
            case TEST_WATCHDOG:
        //******************************
                while(1);
            break;


            default:
        ReceivedDataBuffer[0] = 0;
            counter = 0;
            break;



        } //End switch


       
    ToSendDataBuffer[0] = ReceivedDataBuffer[0];
    ToSendDataBuffer[1] = counter;
    USBInHandle = HIDTxPacket(HID_EP,(BYTE*)&ToSendDataBuffer[0],64);
    //Re-arm the OUT endpoint for the next packet
    USBOutHandle = HIDRxPacket(HID_EP,(BYTE*)&ReceivedDataBuffer,64);
 }

}//end ProcessIO


void BlinkUSBStatus(void) {
  #if defined(PIC24FJ256DA210_DEV_BOARD)
     // No need to clear UIRbits.SOFIF to 0 here.
     // Callback caller is already doing that.
     #define BLINK_INTERVAL 20000
     #define BLANK_INTERVAL 200000

     static WORD blink_count=0;
     static DWORD loop_count = 0;
    
    if(loop_count == 0) {
      if(blink_count != 0) {
        loop_count = BLINK_INTERVAL;
        if(mGetLED_1()) {
          mLED_1_Off();
          blink_count--;
        }
        else {
          mLED_1_On();
        }
      }
      else {
        loop_count = BLANK_INTERVAL;
        switch (USBDeviceState) {
          case ATTACHED_STATE:
            blink_count = 1;
            break;
          case POWERED_STATE:
            blink_count = 2;
            break;
          case DEFAULT_STATE:
            blink_count = 3;
            break;
          case ADR_PENDING_STATE:
            blink_count = 4;
            break;
          case ADDRESS_STATE:
            blink_count = 5;
            break;
          case CONFIGURED_STATE:
            blink_count = 6;
            break;
          case DETACHED_STATE:
            //fall through
            default:
            blink_count = 0;
            break;
        }
      }
    }
    else {
      loop_count--;
    }

#else
    // No need to clear UIRbits.SOFIF to 0 here.
    // Callback caller is already doing that.
    static WORD led_count=0;
    
    if(led_count == 0)led_count = 10000000U;
    led_count--;

    #define mLED_Both_Off()         {mLED_1_green_Off();mLED_1_red_Off();}
    #define mLED_Both_On()          {mLED_1_green_On();mLED_1_red_On();}
    #define mLED_Only_1_On()        {mLED_1_green_On();mLED_1_red_Off();}
    #define mLED_Only_2_On()        {mLED_1_green_Off();mLED_1_red_On();}
    if(USBSuspendControl == 1) {
      if(led_count==0) {
        mLED_1_green_Toggle();
        if(mGetLED_1_green()) {
          mLED_1_red_On();
        }
        else {
          mLED_1_red_Off();
        }
      }//end if
    }
    else {
      if (USBDeviceState == DETACHED_STATE) {
        mLED_Both_Off();
      }
      else if (USBDeviceState == ATTACHED_STATE) {
        mLED_Both_On();
      }
      else if (USBDeviceState == POWERED_STATE) {
        mLED_Only_1_On();
      }
      else if (USBDeviceState == DEFAULT_STATE) {
        mLED_Only_2_On();
      }      else if (USBDeviceState == ADDRESS_STATE) {
        if (led_count == 0) {
          mLED_1_green_Toggle();
          mLED_1_red_Off();
        }//end if
      }
      else if (USBDeviceState == CONFIGURED_STATE) {
        if (led_count==0) {
          mLED_1_green_Toggle();
          if (mGetLED_1_green()) {
            mLED_1_red_Off();
          }
          else {
            mLED_1_red_On();
          }
        }//end if
      }
    }
#endif
}//end BlinkUSBStatus

void USBCBSuspend(void)
{
    //Example power saving code.  Insert appropriate code here for the desired
    //application behavior.  If the microcontroller will be put to sleep, a
    //process similar to that shown below may be used:
    
    //ConfigureIOPinsForLowPower();
    //SaveStateOfAllInterruptEnableBits();
    //DisableAllInterruptEnableBits();
    //EnableOnlyTheInterruptsWhichWillBeUsedToWakeTheMicro();  //should enable at least USBActivityIF as a wake source
    //Sleep();
    //RestoreStateOfAllPreviouslySavedInterruptEnableBits();  //Preferrably, this should be done in the USBCBWakeFromSuspend() function instead.
    //RestoreIOPinsToNormal();                  //Preferrably, this should be done in the USBCBWakeFromSuspend() function instead.

    //IMPORTANT NOTE: Do not clear the USBActivityIF (ACTVIF) bit here.  This bit is 
    //cleared inside the usb_device.c file.  Clearing USBActivityIF here will cause 
    //things to not work as intended.  
    

    #if defined(__C30__)
    #if 0
        U1EIR = 0xFFFF;
        U1IR = 0xFFFF;
        U1OTGIR = 0xFFFF;
        IFS5bits.USB1IF = 0;
        IEC5bits.USB1IE = 1;
        U1OTGIEbits.ACTVIE = 1;
        U1OTGIRbits.ACTVIF = 1;
        Sleep();
    #endif
    #endif
}

#if 0
void __attribute__ ((interrupt)) _USB1Interrupt(void) {
  #if !defined(self_powered)
     if (U1OTGIRbits.ACTVIF) {
       IEC5bits.USB1IE = 0;
       U1OTGIEbits.ACTVIE = 0;
       IFS5bits.USB1IF = 0;
        
       //USBClearInterruptFlag(USBActivityIFReg,USBActivityIFBitNum);
         USBClearInterruptFlag(USBIdleIFReg,USBIdleIFBitNum);
       //USBSuspendControl = 0;
     }
  #endif
}
#endif


void USBCBWakeFromSuspend(void)
{
    // If clock switching or other power savings measures were taken when
    // executing the USBCBSuspend() function, now would be a good time to
    // switch back to normal full power run mode conditions.  The host allows
    // a few milliseconds of wakeup time, after which the device must be 
    // fully back to normal, and capable of receiving and processing USB
    // packets.  In order to do this, the USB module must receive proper
    // clocking (IE: 48MHz clock must be available to SIE for full speed USB
    // operation).
}

void USBCB_SOF_Handler(void) {
  // No need to clear UIRbits.SOFIF to 0 here.
  // Callback caller is already doing that.
}

void USBCBErrorHandler(void) {
  // No need to clear UEIR to 0 here.
  // Callback caller is already doing that.

    // Typically, user firmware does not need to do anything special
    // if a USB error occurs.  For example, if the host sends an OUT
    // packet to your device, but the packet gets corrupted (ex:
    // because of a bad connection, or the user unplugs the
    // USB cable during the transmission) this will typically set
    // one or more USB error interrupt flags.  Nothing specific
    // needs to be done however, since the SIE will automatically
    // send a "NAK" packet to the host.  In response to this, the
    // host will normally retry to send the packet again, and no
    // data loss occurs.  The system will typically recover
    // automatically, without the need for application firmware
    // intervention.
    
    // Nevertheless, this callback function is provided, such as
    // for debugging purposes.
}

void USBCBCheckOtherReq(void) {
  USBCheckHIDRequest();
}//end


void USBCBStdSetDscHandler(void) {
  // Must claim session ownership if supporting this request
}//end


void USBCBInitEP(void) {
  //enable the HID endpoint
  USBEnableEndpoint(HID_EP,USB_IN_ENABLED|USB_OUT_ENABLED|USB_HANDSHAKE_ENABLED|USB_DISALLOW_SETUP);
  //Re-arm the OUT endpoint for the next packet
  USBOutHandle = HIDRxPacket(HID_EP,(BYTE*)&ReceivedDataBuffer,64);
}


 *******************************************************************/
void USBCBSendResume(void) {
  static WORD delay_count;
    
  USBResumeControl = 1;                // Start RESUME signaling
    
  delay_count = 1800U;                // Set RESUME line for 1-13 ms
  do {
    delay_count--;
  } while(delay_count);
  USBResumeControl = 0;
}

BOOL USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void *pdata, WORD size) {
  switch(event) {
    case EVENT_CONFIGURED: 
      USBCBInitEP();
      break;
    case EVENT_SET_DESCRIPTOR:
      USBCBStdSetDscHandler();
      break;
    case EVENT_EP0_REQUEST:
      USBCBCheckOtherReq();
      break;
    case EVENT_SOF:
      USBCB_SOF_Handler();
      break;
    case EVENT_SUSPEND:
      USBCBSuspend();
      break;
    case EVENT_RESUME:
      USBCBWakeFromSuspend();
      break;
    case EVENT_BUS_ERROR:
      USBCBErrorHandler();
      break;
    case EVENT_TRANSFER:
      Nop();
      break;
      default:
      break;
  }      
  return TRUE; 
}

/** EOF main.c *************************************************/
#endif

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.....

[Volker S. (vloki)]

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...

[Saheb (Gast)]

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?

[Volker S. (vloki)]

MLA installieren?
(wenn du es nicht suchst, dann findest du es überhaupt nicht ;-)

[Saheb (Gast)]

jetzt schon
Danke :-)

[Saheb (Gast)]

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.

[Volker S. (vloki)]

Da brauch man nicht unbedingt eine dll dafür.

Ich habe meine Qt Anwendung mit der HID-API von Alan Ott realisiert
http://www.hs-ulm.de/nocache/wir/Personal/PersonalSaSchr/vschilli/QtProjekte/

ältere Screenshots:
http://picforum.ric323.com/viewtopic.php?f=46&t=103#p745

Die HID-API kann man natürlich auch in VS C++ verwenden.

[Saheb (Gast)]

Ich wollte deine Qt5-HID_20141103.zip testen.
Ich benutze der Qt Creator Version 4.0.2.

Fehlermeldung:
App.rc does not exist (seh bitte Anhang)

[Volker S. (vloki)]

Kommentiere das einfach im Projektfile aus...
(Braucht man nicht, ist nur für das Icon der exe)

Blöde Frage: Warum nicht Source_HID_20150806?

[Saheb (Gast)]

ja Okay Danke
In deinem qcustomplot.h bzw. qcustomplot.cpp muss ich auch was 
includieren und dazu was einrichten oder?

[Volker S. (vloki)]

Yo, steht ja in den Dateien drin ;-)

[Saheb (Gast)]

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

[Volker S. (vloki)]

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

[Saheb (Gast)]

Was für Datei: "libsetupapi.a"?

[Volker S. (vloki)]

Nein die Datei: "bloedefrage.txt" ;-)

[Saheb (Gast)]

Ich habe Qt 5.7 und finde diese Datei nicht?

[Saheb (Gast)]

aber was ist für einen Datei "libsetupapi"?

[Volker S. (vloki)]

Kann mich nicht mehr erinnern, wozu man die überhaupt braucht.
Kommentiere das mal im Projektfile aus. Scheint trotzdem zu laufen...

[Saheb (Gast)]

ja es funktioniert

[Volker S. (vloki)]

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.

[Saheb (Gast)]

Hast du versucht das Projekt "Pro Datei" mit Visual Studio 2015  zu 
Öffnen?

[Volker S. (vloki)]

Nein, ich benutze kein VS.

[Saheb (Gast)]

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:

MAIN_RETURN main(void)
{
.....
        // Application-specific tasks.
        APP_CustomHIDTasks();
}

wird die Funktion APP_CustomHIDTasks() aufgerufen, die wiederum in der 
"app_custom_hid.c" implementiert und die wiederum in

APP_usbOUT(); // Data USB(pc) -> PIC

oder

 APP_usbIN();

Mich interessiert, die beide Zeilen:

 USBInHandle = HIDTxPacket(HID_EP,(uint8_t *)ToSendDataBuffer, 64);// bei APP_usbIN();
//und
USBOutHandle = HIDRxPacket(HID_EP,(uint8_t*)&ReceivedDataBuffer,64);

Was machst du hier ?

[Saheb (Gast)]

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:

#if defined(__18CXX)
void main(void)
#else
int main(void)
#endif
{   

    InitializeSystem();



    #if defined(USB_INTERRUPT)
        USBDeviceAttach();
    #endif


  //vfuTestWatchdog();

    while(1)
    {

        #if defined(USB_POLLING)
         APP_CustomHIDTasks();
}
}

die  APP_CustomHIDTasks() ist so implementiert:

 void APP_CustomHIDTasks()
{
    ....
     if (!HIDRxHandleBusy(USBOutHandle)) 
    {
         switch(ReceivedDataBuffer[0]) 
        {
          case LED_ON:
           ToSendDataBuffer[2] = 1;
           ReceivedDataBuffer[2] = 1;
           break;
           case Firmware_version:
           ToSendDataBuffer[2] = MAJOR_VERSION;
           ToSendDataBuffer[3] = MINOR_VERSION;
           break;
           ......
         }
         }
    USBInHandle = HIDTxPacket(HID_EP,(BYTE*)&ToSendDataBuffer[0],64);
    USBOutHandle = HIDRxPacket(HID_EP,(BYTE*)&ReceivedDataBuffer,64);
            

}

[Volker S. (vloki)]

Das sind Macros aus dem MCHP USB Framework
-> irgendeine_installierte_MLA_Version -> .../doc/help_mla_usb.xxx

[Volker S. (vloki)]

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.

[Saheb (Gast)]

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?

[Volker S. (vloki)]

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?

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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 ;-)

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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.

[Saheb (Gast)]

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:

......
#define FIRMWARE_VERSION       0x08
#define RESET_DEVICE           0xFE
#define MODE_CHANGE            0xFD
#define TEST_WATCHDOG          0xFF
#define TEST_MODE              0x30
...

Danke in voraus

[Volker S. (vloki)]

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 (Gast)]

Hi,

danke es funktioniert.

In der Firmware (deine bzw in meine Projekt) sehe ich stets

ReceivedDataBuffer

Ich frage mich wie bekommt man der Value dieses Array?

[Volker S. (vloki)]

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])

[Saheb (Gast)]

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:

void APP_cmd(void) 
{
...
switch (ReceivedDataBuffer[1]) {
..        case CID_DEVICE: // send device identification string
            ToSendDataBuffer[1] = CID_DEVICE | ID_MESSAGE;
            ToSendDataBuffer[0] = sizeof (strDevice) + 1;
            .....

}

Wo deklarierst, dass die Daten, die von der USB verbindung kommen 
ReceivedDataBuffer heissen?


Danke

[Volker S. (vloki)]

Was genau in der Doku verstehst du nicht?

[Saheb (Gast)]

Es hat sich geklärt.


Das machst du hier:

#if defined(FIXED_ADDRESS_MEMORY)
  #if defined(__XC8)
    unsigned char ReceivedDataBuffer[64] @ HID_CUSTOM_OUT_DATA_BUFFER_ADDRESS;
    unsigned char ToSendDataBuffer[64] @ HID_CUSTOM_IN_DATA_BUFFER_ADDRESS;
  #elif defined(COMPILER_MPLAB_C18)
    #pragma udata HID_CUSTOM_OUT_DATA_BUFFER = HID_CUSTOM_OUT_DATA_BUFFER_ADDRESS
    unsigned char ReceivedDataBuffer[64];
    #pragma udata HID_CUSTOM_IN_DATA_BUFFER = HID_CUSTOM_IN_DATA_BUFFER_ADDRESS
    unsigned char ToSendDataBuffer[64];
    #pragma udata
  #endif
#else
  unsigned char ReceivedDataBuffer[64];
  unsigned char ToSendDataBuffer[64];
#endif

Danke

[Volker S. (vloki)]

Saheb schrieb:
> Es hat sich geklärt.

Nein, das ist was anderes ;-)

[Saheb (Gast)]

Das verstehe ich schon aber ich glaube wir reden an einander vorbei.
Es hat sich aber geklärt.

[Saheb (Gast)]

aber du muss irgendwie sagen die Daten, die von der USB bekomme heissen 
"ReceivedDataBuffer"

[Saheb (Gast)]

Sorry Sorry
du hast vollkommen recht:

was ich meine ist das:

void APP_CustomHIDInitialize()
{
....
USBOutHandle = (volatile USB_HANDLE)HIDRxPacket(HID_EP,(uint8_t*)&ReceivedDataBuffer,64);

}

[Volker S. (vloki)]

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

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...

/*******************************************************************************
 * Function:        usbOUT(void)
...
 *
 * Overview:        Data USB(pc) -> PIC
...
******************************************************************************/

void APP_usbOUT(void) {

    APP_cmd();

    //Re-arm the OUT endpoint for the next packet
    USBOutHandle = HIDRxPacket(HID_EP,(uint8_t*)&ReceivedDataBuffer,64);
}

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

[Saheb (Gast)]

Herzlichen dank für die ausführliche Antwort

[Saheb (Gast)]

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

hid_write(hid_device *dev, const unsigned char *data, size_t length)

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.

[Volker S. (vloki)]

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 ;-)

[Saheb (Gast)]

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.

[Volker S. (vloki)]

Vielleicht misst dein Gerät einfach nur seeeehr lange bis es eine 
Antwort schickt ;-)

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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.

[Saheb (Gast)]

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.

[Volker S. (vloki)]

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...

[Saheb (Gast)]

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

[Volker S. (vloki)]

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?

[Saheb (Gast)]

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

[Volker S. (vloki)]

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" ;-)

[Saheb (Gast)]

Volker S. schrieb:
> Kommt überhaupt eine Antwort auf das Kommando 23?

ja

[Volker S. (vloki)]

Das ist aber eine lange Antwort für eine Signalperiode.

Auf das nächste Kommando (egal welches) kommt dann keine Antwort mehr?

[Saheb (Gast)]

Volker S. schrieb:
> Auf das nächste Kommando (egal welches) kommt dann keine Antwort mehr?

Nein
SW(PC SW) bleibt hängen

[Volker S. (vloki)]

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.

io_result = hid_read(connected_device, inBuffer, 65);

    if (io_result == 64){
...
        for (int i = 0; i<= inBuffer[0];i++){
            s += QString("%1").arg(inBuffer[i],3,16);
        }
        ui->teInHEX->append(s);

[Saheb (Gast)]

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 (Gast)]

In Debug Modus:
Beim folgende Codeabschnitt:

 for (int i = 0; i<= inBuffer[0];i++){
   s += QString("%1").arg(inBuffer[i],3,16);
  }

Beim Kommando 23 und 8 sieht der inBuffer wie folgende aus (Seh bitte 
Anhang).

[Volker S. (vloki)]

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...

[Saheb (Gast)]

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.

[Saheb (Gast)]

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.

[Volker S. (vloki)]

Das darf nie passieren! In einem solchen Fall muss das Gerät mit einer 
Fehlermeldung antworten und natürlich weiter funktionieren!

[Saheb (Gast)]

Hallo Volker,


kennst du dich mit STM32 aus?

[Volker S. (vloki)]

Nö ;-)

[Saheb (Gast)]

Schade

Das hatte sein können

[Saheb (Gast)]

Kennst du dich aus mit FPGA ?

[Witkatz :. (wit)]

@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.

[Saif K. (saif_k58)]

Hallo Volker,


Darf ich in MPLAB X IDE so was schreiben?

  int ADR_DATA[64][4];
  int ROM[8][4];

Wenn ich so schreibe und meine Prog kompiliere da bekomme ich stets eine 
Fehlermeldung:
Error [1300] Stack frame too large


Danke

[Volker S. (vloki)]

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 ;-)

[Saif K. (saif_k58)]

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

[Saif K. (saif_k58)]

Ich habe es jetzt die beiden Variablen

int ADR_DATA[64][4];
int ROM[8][4];

 globale definiert dann bekomme jetzt eine andere Fehlermeldung:

Error [1131] type mismatch in assignment

Meine Funktion sieht so aus:

void Get_ROM_Content(unsigned char *paucRomContent_p) 
{
  char chAdr_l;
  unsigned char ucRomVal;
  unsigned char ucMsk_l;
  unsigned char ucRomRead_l;

  int Data[4];
//  int ADR_DATA[64][4];
//  int ROM[8][4];
    int i= 0;

  for (i = 0; i < 64; i++)
    {
    if (i % 9 == 0)
        {
      Data[0] = 8 ;
      Data[1] = 4;
      Data[2] = 2;
      Data[3] = 1;
    }
    else 
        {
      Data[0] = 0;
      Data[1] = 0;
      Data[2] = 0;
      Data[3] = 0;
    }
    ADR_DATA[i][0] = (i << 4) | Data[0];
    ADR_DATA[i][1] = (i << 4) | Data[1];
    ADR_DATA[i][2] = (i << 4) | Data[2];
    ADR_DATA[i][3] = (i << 4) | Data[3];
  }
  UNLOCK = 1;
  /////////////////////////////////////////////////////////////////  
  for (i = 0; i < 64; i++) 
    {
    if (i % 9 == 0) {
        // RAM loeschen Power On Reset
        ON_OFF = 0;
        DELAY100MS
        ON_OFF = 1;
        DELAY100MS
      
      // RAM gelöscht, D1 aud "1" bei ADR = i
      ucRomVal = Write_Value(0x7, ADR_DATA[i][0]);
      if (ucRomVal == 1) {
        ROM[i][0] = ucRomVal;
      }

        // RAM loeschen Power On Reset
        ON_OFF = 0;
        DELAY100MS
        ON_OFF = 1;
        DELAY100MS
      
      // RAM gelöscht, D2 aud "1" bei ADR = i
      ucRomVal = Write_Value(0x7, ADR_DATA[i][1]);
      if (ucRomVal == 1) {
        ROM[i][1] = ucRomVal;
      }

        // RAM loeschen Power On Reset
        ON_OFF = 0;
        DELAY100MS
        ON_OFF = 1;
        DELAY100MS
      
      // RAM gelöscht, D3 aud "1" bei ADR = i
      ucRomVal = Write_Value(0x7, ADR_DATA[i][2]);
      if (ucRomVal == 1) {
        ROM[i][2] = ucRomVal;
      }

        // RAM loeschen Power On Reset
        ON_OFF = 0;
        DELAY100MS
        ON_OFF = 1;
        DELAY100MS
      
      // RAM gelöscht, D4 aud "1" bei ADR = i
      ucRomVal = Write_Value(0x7, ADR_DATA[i][3]);
      if (ucRomVal == 1) {
        ROM[i][3] = ucRomVal;
      }
    }
  }
  UNLOCK = 0;
    //return 0;
}
void Write_Value(char daten1, char daten2) {  
    int x;                          // Clock count
    char Data[10];                  // Array holds the bits
  unsigned char ucRet_l = 0;
    unsigned char IntConf = INTCON; // Holds the interrupt status
   
  INTCON = 0;
    // Define RA2, RA3, RB4, RD7 and RE1 as outputs
  // These three bits are the mode bits
    Data[0] = ((daten1 & 0x04) ==  4) ? 1 : 0;
    Data[1] = ((daten1 & 0x02) ==  2) ? 1 : 0;
    Data[2] = ((daten1 & 0x01) ==  1) ? 1 : 0;

  // These three bits are the address bits
    Data[3] = ((daten2 & 0x40) == 64) ? 1 : 0;
    Data[4] = ((daten2 & 0x20) == 32) ? 1 : 0;
    Data[5] = ((daten2 & 0x10) == 16) ? 1 : 0;

  // These four bits are the data bits D1 - D4
    Data[6] = ((daten2 & 0x08) ==  8) ? 1 : 0;
    Data[7] = ((daten2 & 0x04) ==  4) ? 1 : 0;
    Data[8] = ((daten2 & 0x02) ==  2) ? 1 : 0;
    Data[9] = ((daten2 & 0x01) ==  1) ? 1 : 0;
  
  V35 = 1; // Programming Voltage is 5V
  V10 = 0; // No over voltage for changing the outputs to inputs
  V15 = 0; // No 15V needed
               // Introducing the programming of the RAM, high voltage pulse
    START = 1; // generate rising high voltage pulse, means V10 = 1
    DELAY1MS;  // 1 ms - Wait until the START Signal has reached its maximum value of > 10.5V

  A2_OUT();  // CLOCK, Make LATAbits.LATA2 of PIC to output, to write to AISC
    A3_OUT();  // DATA,  Make LATAbits.LATA3 of PIC to output, to write to AISC

    DATA = 0;  // set data  0, at the beginning msut be zero
    CLK = 0;   // set clock 0, at the beginning msut be zero

    START = 0; // generate falling edge high voltage pulse, V10 = 0, ASIC Voltage is 5V again
    DELAY1K;   // 84.4 us - short delay

    // Output 10 bits content of the Array into seriell DATA line
  for(x = 0; x < 10; x++) { 
    if (Data[x] == 1) {DATA = 1;}
    else {DATA = 0;}
        // Falling edge of the clock must be in middle of the DATA
    CLK = 1;        DELAY100; // 8.55 us
        CLK = 0;        DELAY100; // 8.55 us, The period of  clk is 17.1 us
  }    
  DATA = 0;
    // RAM_LOAD, 11th pulse
    CLK = 1;    DELAY100; // 8.55 us
  CLK = 0;    DELAY100; // 8.55 us

    // END, 12th pulse
    CLK = 1;    DELAY100; // 8.55 us
    CLK = 0;   DELAY100; // 8.55 us

    // End of ASIC programming, Changing the outputs to inputs
  A3_IN(); 
    A2_IN();

  DELAY10K;
  ucRet_l = ROM_READ;

  V35 = 1; // Programming Voltage is 5V
  V10 = 0;
  V15 = 0;
  INTCON = IntConf; // interrupts status loading
  //return ucRet_l;
}

[Volker S. (vloki)]

Saif K. schrieb:
> dann bekomme jetzt eine andere Fehlermeldung:Error [1131] type mismatch
> in assignment

bisschen was drumrum?

[Saif K. (saif_k58)]

Hallo Volker,

Volker S. schrieb:
> bisschen was drumrum?

was mache ich dann falsch, wenn ich so was schreibe:

ucRomVal = Write_Value(0x7, ADR_DATA[i][1]);

Write_Value ist so deklariert:

void Write_Value(char daten1, int daten2);

Danke

[Volker S. (vloki)]

Saif K. schrieb:
> was mache ich dann falsch, wenn ich so was schreibe:
>
>

> ucRomVal = void

?

[Saif K. (saif_k58)]

vielen dank
Das habe ich übersehen

jetzt habe ich angepasst und bekomme ich diese Fehlermeldung:

Error - section '.udata_func.o' can not fit the section. Section '.udata_func.o' length=0x00000242

[Volker S. (vloki)]

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 ;-)