SDCC e Eclipse su W64 bit.Non vuole saperne di andare

Che cos'è P1? Non sarà una costante?...

--

Domanda per chi ci è già passato. Causa crisi dei semiconduttori devo valutare l'utilizzo di piccolo microcontrollori a 8 bit di altre marche(per es Nuvoton),evoluzione di 8051. L'unico modo per programmarli senza spendere migliaia di euro in licenze , improponibile per me in fase di valutazione,è usare SDCC (compilatore per piccoli dispositivi ). Utilizzato con un Notepad compila e genera il file per il programmatore,sarebbe però meglio usare un IDE con debugger integrato, come ad esempio Eclipse. Anche se i tutorial inerenti all'integrazione di SDCC e EClipse non mancano non sono riuscito a farli funzionare. Nell'installazione con l'Eclipse più recente ci sono grossi problemi con preprocessore e include files:i files vengono visti ma il loro contenuto rimane sconosciuto al compilatore

Con Eclipse 64 bit più vecchi combinati con SDCC nuovo o vecchi ho sempre un errore Cannot invoke "java.net.URL.getFile()" che impedisce la creazione di progetti con SDCC,mentre altri progetti che usano altri microcontrollori e compilatori partono senza problemi.

Qualcuno in rete dice che con Eclipse 64bit non c'è niente d fare,ma le versioni a 32bit vogliono altra versione di Java,non vorrei sconvolgere il mio PC installando un Java che non piace ad altre applicazioni

Qualcuno è riuscito a mettere assieme qualche versione di Eclipse e SDCC? Grazie

Mai provato con Eclipse, invece ho usato molto e uso ancora SDCC con la IDE Silabs per i processori C8051F120 e altri della famiglia, ma dubito si riesca a farlo andare in debug con una interfaccia HW diversa da quella Silabs. Mi verrebbe da provare con Visual Studio Code: l'ho usato per ESP32, ma senza fare debug. Tieni presente che per la famiglia 8051 dovrebbe essere libero il compilatore Keil, almeno mi pare si possa scaricare dal sito Silabs. Personalmente non ho provato, perche' ha delle leggere differenze nelle keyword e nelle macro rispetto a SDCC, ma dovrebbe funzionare meglio. SDCC qualche bachetto ce l'ha.

Ciao,

Grazie prima di tutto Purtroppo l'IC che dovrò usare io non è Silabs ma Nuvoton, ha 32KB di Flash,il compilatore della Keil ,nella versione gratuita permanente, è limitato a 2K,la licenza costa ,se nn ho capito male,qualche Keuro,e così dovrebbe essere per IAR,

con Eclipse ho provato per molte ore ma ho concluso poco: Riassumendo:

Con l'ultimo Eclipse 64 bit 2022 e SDCC 4.xx non mi vedeva le definizioni negli #include files,pur vedendo gli #include files, credevo fosse un problema di versioni troppo nuove,perchè a un certo punto ho letto in rete che l'unica era passre agli Eclipse a 32 bit...per poi scoprire che c'era l'identico problema Ho provato diverse versioni a 32 bit ,per cui serve anche Java a 32 bit Nei 2 casi alle cartelle eclipse.>plugins e eclipse->features vanno aggiunte internamente le cartelle di SDCC come ben indicato in vari tutorial,e così ho fatto

Ora,senza nemmeno considerare i micro Nuvoton mi ritrovo con la versione a 32 bit pronta per compilare, ma c'è ancora il problema degli #include xxxx.h,nonostante il path sia da me stato indicato nelle proprietà del progetto, quindi i files vengono visti,controprova ne è che se metto il nome di un file.h non esistente ho già una segnalazione a livello di editor. Il contenuto dei files non viene visto..allora provo ad aggirare il problema copiando i files .h nella stessa cartella del main,e almeno qui il loro contenuto viene visto(ci aggiungo qualche definizione io per verifica es #define MY_DUMMY 0x34)

il codice minimale che viene correttamente compilato è

#include "lint.h"//necessario per i tipi particolari degli 8051 #include "8051.h" #include "8052.h"

//************************************** void main(void) { volatile unsigned char var1=0,var2=3,result;

while(1) { var1+=var2; //MY_DUMMY è definita da me in lint.h,e viene vista result=var1 +MY_DUMMY; //P1=0xFF; delay(); //P1=0x00; delay(); } }

se decommento P1 non viene visto:Symbol 'P1' could not be resolved inoltre 8051.h si riempie di errori: Type '__sbit' could not be resolved nonostante il tipi __sbit sia definito in lint.h come #define __sbit volatile bool invece il tipo __sfr,che dovrebbe avere gli stessi problemi e sempre definito in lint.h viene visto!

insomma per ora sono fermo qui...

Grazie prima di tutto Purtroppo l'IC che dovrò usare io non è Silabs ma Nuvoton, ha 32KB di Flash,il compilatore della Keil ,nella versione gratuita permanente, è limitato a 2K,la licenza costa ,se nn ho capito male,qualche Keuro,e così dovrebbe essere per IAR,

con Eclipse ho provato per molte ore ma ho concluso poco: Riassumendo:

Con l'ultimo Eclipse 64 bit 2022 e SDCC 4.xx non mi vedeva le definizioni negli #include files,pur vedendo gli #include files, credevo fosse un problema di versioni troppo nuove,perchè a un certo punto ho letto in rete che l'unica era passre agli Eclipse a 32 bit...per poi scoprire che c'era l'identico problema Ho provato diverse versioni a 32 bit ,per cui serve anche Java a 32 bit Nei 2 casi alle cartelle eclipse.>plugins e eclipse->features vanno aggiunte internamente le cartelle di SDCC come ben indicato in vari tutorial,e così ho fatto

Ora,senza nemmeno considerare i micro Nuvoton mi ritrovo con la versione a 32 bit pronta per compilare, ma c'è ancora il problema degli #include xxxx.h,nonostante il path sia da me stato indicato nelle proprietà del progetto, quindi i files vengono visti,controprova ne è che se metto il nome di un file.h non esistente ho già una segnalazione a livello di editor. Il contenuto dei files non viene visto..allora provo ad aggirare il problema copiando i files .h nella stessa cartella del main,e almeno qui il loro contenuto viene visto(ci aggiungo qualche definizione io per verifica es #define MY_DUMMY 0x34)

il codice minimale che viene correttamente compilato è

#include "lint.h"//necessario per i tipi particolari degli 8051 #include "8051.h" #include "8052.h"

//************************************** void main(void) { volatile unsigned char var1=0,var2=3,result;

while(1) { var1+=var2; //MY_DUMMY è definita da me in lint.h,e viene vista result=var1 +MY_DUMMY; //P1=0xFF; delay(); //P1=0x00; delay(); } }

se decommento P1 non viene visto:Symbol 'P1' could not be resolved inoltre 8051.h si riempie di errori: Type '__sbit' could not be resolved nonostante il tipi __sbit sia definito in lint.h come #define __sbit volatile bool invece il tipo __sfr,che dovrebbe avere gli stessi problemi e sempre definito in lint.h viene visto!

insomma per ora sono fermo qui...

Il 12/10/2022 09:54, LAB ha scritto:

Dov'è definita P1?

Il 12/10/2022 09:54, LAB ha scritto:

Dov'è definita P1?

Il 12/10/2022 09:54, LAB ha scritto:

Dov'è definita P1?

Il 12/10/2022 09:54, LAB ha scritto: > Che cos'è P1? Non sarà una costante?...Dov'è definita P1?

Il 12/10/2022 09:54, LAB ha scritto:

Ciao,è uno Special Function Register, un __sfr che ,se non mi esprimo male,è un tipo particolare degli 8051, e ogni __sfr viene dichiarato ad un indirizzo specifico

#ifndef REG8051_H #define REG8051_H

/* BYTE Register */ __sfr __at (0x80) P0 ; __sfr __at (0x81) SP ; __sfr __at (0x82) DPL ; __sfr __at (0x83) DPH ; __sfr __at (0x87) PCON ; __sfr __at (0x88) TCON ; __sfr __at (0x89) TMOD ; __sfr __at (0x8A) TL0 ; __sfr __at (0x8B) TL1 ; __sfr __at (0x8C) TH0 ; __sfr __at (0x8D) TH1 ; __sfr __at (0x90) P1 ;//<<<<-------------

__sfr viene definito in lint.h #define __sfr volatile unsigned char (e così pure __sbit #define __sbit volatile bool)

grazie

Il 12/10/2022 09:21, blisca ha scritto:

se non vengono viste delle macro, forse perchè sono inclusi nelle direttive @ifdef, devi per forza definire prima i nomi per poter accedere a quelle macro. Questo si fa o tramite parametro o "#define" e servirà per l'abilitazione al tipo di micro che vuoi usare. Anche il solo posizionamento degli #include può servire a prendere le definizioni dagli altri file (#include)

Il 12/10/2022 11:23, Franco Af ha scritto:

salve non mi pare che sia per quello,le macro sembrano attive, infatti devo trasformare gli #ifdef in #ifndef per vedere lo sfondo del file.h colorarsi indicando che il codice non viene considerato nella compilazione,quindi,al momento sembra che le righe interessate siano considerate dal preprocessore e compilatore

Il 12/10/2022 11:23, Franco Af ha scritto:

salve non mi pare che sia per quello,le macro sembrano attive, infatti devo trasformare gli #ifdef in #ifndef per vedere lo sfondo del file.h colorarsi indicando che il codice non viene considerato nella compilazione,quindi,al momento sembra che le righe interessate siano considerate dal preprocessore e compilatore

Un bel giorno blisca digitò:

Se proprio non ci salti fuori, potresti sempre installare un Windows a 32 bit in una macchina virtuale. Almeno per fare una prova.

Sono stato qualche giorno in ferie... Ti allego un frammento di codice di main() che uso con SDCC e funziona:

#include <c8051F120.h> // SFR declarations for the specific processor #include <stdio.h> // printf used for test mode (board connected to an ASCII terminal) #include "main.h" #include "serial.h" // .... other includes

// IRQ declarations: mandatory in the module containing main() for SDCC void com_isr0(void) __interrupt(INT_UART0) __using(1); void Timer3_ISR(void) __interrupt(INT_TIMER3) __using(1);

//***************************** // Initialization functions ** //***************************** void init(void); // main initialization void init_sysclk(__bit); // clock initialization void init_xbar_ports(void); // crossbar and ports initialization

//************** // Variables ** //************** volatile __xdata char board_failure; // allows to stop the watchdog auto-reset __xdata long sysClock; // system clock frequency in Hz __xdata unsigned char sw_ID; // board ID for RS-485 __xdata unsigned char is_xclock; // actual clock mode

//********************************* // program entry point ** //********************************* void main(void) { // disable watchdog timer SFRPAGE = ACTIVE_PAGE;

// initiation of the whole system init();

// infinite loop while (1) { // ... }

} // end main

//**************************************** // Initialize Board ** //**************************************** void init(void) __reentrant { long baudrate; __bit sw_xclock;

// Save Current SFR page char SFRPAGE_SAVE = SFRPAGE; // read DIP switches settings in order to set the right values // config_page has address 0x0f and it is used to set uart and system settings SFRPAGE = CONFIG_PAGE;

// initialize crossbar and port I/O init_xbar_ports();

// initialize system clk init_sysclk(sw_xclock);

// initialize uart, interrupt init_uart0(baudrate);

// other initializations // ...

// Restore SFR page SFRPAGE = SFRPAGE_SAVE; }

--------------------------

La "#include <c8051F120.h>" e' parte della distribuzione SDCC e definisce gli SFR per il particolare processore. A volte manca il file giusto (es. mi e' successo per il c8051F580) e bisogna farselo con tanta pazienza.

Opzioni del compilatore ad esempio "-mmcs51 --model-small", opzioni del linker non le trovo in questo momento.

Ciao,

Guarda qui:

Scrivono: "The Keil PK51 Developer’s Kit includes an industry-leading

8051 C compiler, linker and assembler for use with Silicon Labs’ 8-bit microcontrollers and Studio. This toolchain package provides the build support for 8051 projects, while the IDE provides editing and debugging support. This free toolchain comes without time or code size limit!".

Come gia' scrivevo, non ho provato.

Ciao,

Il 15/10/2022 12:03, dalai lamah ha scritto:

Salve,grazie anche a dalai e Rov riassumendo ho visto che java a 32 e 64 possono coesistere,alla fine anche la versione di Eclipse a 32 bit,dà più o meno gli stessi problemi..non vede quella definizione pur non vedendo il file..vede gli sfr ma non gli sbit che dovrebbero essere definiti nello steeso file...insomma ce n'è sempre una.E non sono ancora arrivato a vedere cosa succede col debugger Dopo una ventina di ore (non pagate) di prove ho rinunciato,se la verdrà qualcun altro