| |
| Autore |
Messaggio |
opzioni |
  e.ferriani
postato il:
23.09.2018, alle ore 10:58 |
Sì, l'avevo visto e più o meno avevo capito cosa fa intervenire il suo intervento.
Quello che mi manca, oltre alle basi, è capire cosa c'è scritto in quella riga.
L'ho cercato sul Kernighan e Ritchie (II ed.) ma non sapendo come cercarlo forse non ho cercato la cosa giusta, perchè non ho trovato quel tipo di scrittura.
Sai indicarmi come trovare qualche spiegazione sul suo funzionamento?
Enea Ferriani |
|
picmicro675
postato il:
23.09.2018, alle ore 13:59 |
La definizione nome(punto)nome si indica un elemento di una struct o union.
Se ci sono più di uno allora è da considerare come una ramificazione.
Per tanto si haextern union i2c_error_events {
unsigned char status;
struct error_events { // structure with 16 bits
unsigned int slave_override :1; // flag indicating
unsigned int retry_attempt :1; // flag indicating to retry I2C comm
unsigned int :1; //
unsigned int :1; //
unsigned int :1; //
unsigned int overlimit :1; // flag indicating byte is out-of-range
unsigned int ack_error :1; // flag indicating acknowledge error
unsigned int bus_coll_error :1; // flag indicating bus collision error
} i2c;
} eflag;
che definisce un gruppo di dati. Una struct non fa tanta differenza da una union, la prima comunque assegna tutta la RAM subito, mentre la seconda è piuttosto dinamica. Però non ho ancora capito bene la differenza.
Vedi questo
https://www.geeksforgeeks.org/difference-structure-union-c/
Ad ogni modo, questa union di nome eflag contiene una unsigned char (un byte) di nome status ed un altro byte, suddiviso in bits, che vengono usati singolarmente, con il proprio nome.
Se voglio usare un bit di nome bus_coll_err devo indirizzarlo tramite il nome della union, poi il nome della struct ed infine il nome del bit. Questi usano il separatore punto.
Per cui sarà eflag.i2c.bus_coll_err (notare i due punti tra le tre parole).
Se voglio usare status, allora sarà indirizzato come eflag.status.
In quella AN le union sono già nominate al momento della creazione. Però si potrebbe fare che sia anonima. Per cui alla fine della parentesi graffa non c'è il nome. Si potrà quindi assegnare diverse con il segno di uguale.
Per esempio
myflags = i2c_error_events;
altra_union = i2c_error_events;
Ovvero entrambe usano lo stesso stampo di dati ed ad ognuna verrà allocata una certa quantità di memoria. Eventualmente si può anche fare una matrice di union
uni_array = { i2c_error_events, i2c_error_events. i2c_error_events};
Che servono a contenere delle "tabelle" di informazioni, come fosse uno schedario.
Questo, sarebbe un discorso a parte che andrebbe nella sezione Informatica ed Elettronica.
Rientrando del caso di farne un utilizzo, è giusto capire come funzionano queste implementazioni del C.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
picmicro675
postato il:
23.09.2018, alle ore 14:10 |
Beh!
Volendo ampliare le conoscenze col C:
http://www.html.it/guide/guida-c/
https://www.cprogramming.com/tutorial/c-tutorial.html
https://www.learn-c.org/
Senza contare quello migliaia di risposte con una ricerca "c tutorial"
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
e.ferriani
postato il:
23.09.2018, alle ore 15:30 |
Scusami, sarà anche che non sono esperto, ma io queste 4 definizioni non le ho trovate nei files, nemmeno nelle AN 35 e 36.
Non credo, ma potrebbero essere, come per le union e le struct di prima, cose che non conosco, quindi sbaglio a cercare?
//---------------------------------------------------------------------
// STATE 1: If this is a WRITE operation and last byte was an ADDRESS
//---------------------------------------------------------------------
if(!STAT_DA && !STAT_RW && STAT_BF && STAT_S)
Le trovo solo dentro a degli if.
Found 5 matches of STAT_DA in 1 file.
ISRhandler-s.c
if(!STAT_DA && !STAT_RW && STAT_BF && STAT_S) [position 34:9]
else if(STAT_DA && !STAT_RW && STAT_BF) [position 80:13]
else if(!STAT_DA && STAT_RW && !STAT_BF && STAT_S) [position 240:14]
else if(STAT_DA && STAT_RW && !STAT_BF) [position 253:13]
else if(STAT_DA && !STAT_RW && !STAT_BF) [position 300:17]
Enea Ferriani |
|
picmicro675
postato il:
23.09.2018, alle ore 18:14 |
Forse non mancano, sono i bit della locazione 0x94 (SSPSTAT), che probabilmente erano inclusi nelle definizioni del vecchio compilatore (PICC).
Se XC non ne fa più uso, bisogna scrivere dei #define per renderli esistenti.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
picmicro675
postato il:
23.09.2018, alle ore 18:15 |
Visto che il sorgente è stato scritto originale con PICC.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
e.ferriani
postato il:
25.09.2018, alle ore 07:35 |
Quindi mi confermi quanto di seguito?
- STAT è l'abbreviazione di SSPSTAT, registro in 94h
- STAT_DA è equivalente a scrivere SSPSTATbits.D_nA
- STAT_RW corrisponde a SSPSTATbits.R_nW,
- STAT_BF corrisponde a SSPSTATbits.BF
- STAT_S corrisponde a SSPSTATbits.S
e così via per le altre posizioni.
Enea Ferriani |
|
picmicro675
postato il:
25.09.2018, alle ore 10:49 |
Scusa che non ho provato.
La conversione è così. Solo che alla prova con MPLABX 3.45 ci sono altri difetti, da limare.
Quindi ci sono altri problemi per usare le routines. C'è un ulteriore lavoro di conversione dal PICC a XC8. Proverò a capire da che parte tira il fumo.
In particolare come sono state definite le union. Al momento non ho capito.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
picmicro675
postato il:
25.09.2018, alle ore 11:59 |
Ho verificato il file slavnode.c che aveva degli errori di conversione, alcune sviste.
Qui faccio ammenda del pacchetto con delle correzioni. Se ce ne fossero altre, allora provvedo a revisionare gli errori.
http://www.grix.it/UserFiles/picmicro675/File/TransitFiles/A…
Quindi non posso garantire che sia compilabile, rimane base di studio.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
e.ferriani
postato il:
25.09.2018, alle ore 16:53 |
 picmicro675: Scusa che non ho provato.
La conversione è così. Solo che alla prova con MPLABX 3.45 ci sono altri difetti, da limare.
Quindi ci sono altri problemi per usare le routines. C'è un ulteriore lavoro di conversione dal PICC a XC8. Proverò a capire da che parte tira il fumo.
In particolare come sono state definite le union. Al momento non ho capito.
Sì, ci sono altre cose, e per quanto riguarda struct o union non ci ho proprio guardato, ma in questo periodo ho delle cose più serie a cui pensare, credimi. Però a piccoli passi sto provando a pensare a come strutturare il nuovo controllo degli eventi.
Almeno quando riesco a pensare magari me lo scrivo su un pezzo di carta.
Resta poi da capire se funzionerà .
Enea Ferriani |
|
| |
