Presentation d'un programme source MikroC

[paulfjujo]

bonsoir,


Je pense que nous avons tous des efforts à faire lorsque nous presentons un programme source MikroC
(à commencer par moi-meme d'ailleurs, car je ne m'en exclue pas)

En particulier pour l'environnement du programme et Hardware
le source MikroC ne montre pas , ni le type de MCU, ni la valeur de FOSC, ni les bits de configuration !
Je pense que le fichier source à lui seul, grace aux renseignements inclus et à un code dûment documenté,
doit pouvoir rendre état de ce qui doit etre réalisé en final.
je propose que l'on adopte un canevas d'entete ..
à critiquer, ameliorer , modifier ..

Code : Tout sélectionner



#define Version "14-08-2015"
 // MikroC version 6.50
 // Test UART Hardware 19200bds at Q=8MHz
// Directory :  C:\_MikroC\_MesProjets_MikroC\
 // Project  : 18F2550_test_RBx_IT_w_UART.mcppi1
 // Source : 18F2550_RB4-7_IT_RB0-2_IT_test_w_UART_150814.c
 // hardware:
 // platine StartUSB 18F2550 de MikroE
 //  RA0 analog input <- Potar 0 à 5V
 //  0V --  Led --- RA1
 // UART1   Tx-RC6 -> rx   et  Rx-RC7  <--  tx 
 //documents :
 //ac:StartUSB_schema
// rajout fonction    unsigned long HexacarToLong( unsigned char *P)

#define PROCESSOR 18F2550
#define POWER_SUPPLY_5V
#define FOSC_Interne
#define FOSC 8.0         // MHz
#define BAUD 19200     // UART1

#define CLS 12
#define CR 13
#define LF 10
#define TAB 9
#define BACK 8
#define Separator 0x20   // space
#define NBCycles_Timer1   4  // 4x 125mS at 8MHz

/*  voir P18F2550_Fosc_Interne_8MHz_19200bds.cfgsch
avec FOSC externe avec Q=8MHZ
CONFIG1L : $300000 : 0x0001
CONFIG1H : $300001 : 0x0000
CONFIG2L : $300002 : 0x001F
CONFIG2H : $300003 : 0x001E
CONFIG3H : $300005 : 0x0083
CONFIG4L : $300006 : 0x0081
CONFIG5L : $300008 : 0x000F
CONFIG5H : $300009 : 0x00C0
CONFIG6L : $30000A : 0x000F
CONFIG6H : $30000B : 0x00E0
CONFIG7L : $30000C : 0x000F
CONFIG7H : $30000D : 0x0040
*/
//=== compilation conditionnelle  =====
#define With_UART    // enlever le commentaire pour avoir le resultat ADC sur la sortie UART
 

les #define dans un code peuvent servir de substitution bien plus parlant
ex: CR (Carriage Return ou Touche ENTER) au lieu de 13 ou 0x0D

La compilation conditionelle permettant plusieurs cas de figure
ex: usage de FOSC interne ou QUARTZ
.. à developper

à noter aussi la possibilité d'inclure des documents dans le source (images, pdf ..)
mais dommage que les liens soient perdus des que le source est transferé ailleurs.
.... à developper

Pour transmettre un projet :
il n'y a pas vraiment d'outil probant pour recuperer un projet
hormis la fonction export.. il me semble qu'il manque un outil dans MikroC
semblable à celui qui était dans MLPAB C18 . Zip du projet

ou creer manuellement un Zip regroupant au minimum :
les fichiers suivant
*.mcppi le fichie rprojet mikroC
*.c sources C
*.h includes
*.cfg (bits de config)
*.log (liste les alarmes, erreurs et aussi les librairies usitées)
*.xml (la partie documents + les *jpg et *. pdf)

[Jérémy]

Je trouve l'idée très bonne, Maî avait préparé un canevas dans ce style, pour le langage ASM.

Personnellement je suis pour tout du moins pour les généralités. Tant que l'on ai en comité restreint, cela peut être effectivement vraiment bien.

Pour la partie Hard , je suis plus friand, des schémas en bon et due forme . C'est sur qu'a la limite pour branché un potar on peut s'en passer à priori. Je vais essayer moi aussi de faire un effort la dessus .

Je pense qu'il sera dur de démocratiser ceci aux personnes de passage. Mais pourquoi pas ! A la limite on pourrait rajouter ceci dans les règles de "bonne conduite" comme le lien de la DS etc ..... . Mais il faudra faire attention à ne pas non plus faire fuir les membres en devenant trop restrictifs sur certains points.
Même si je sais que vous allez me dire, autant prendre les bonnes habitudes tout de suite, mais pour avoir des habitudes il faut des membres.

A appliquer sur les programmes conséquents je pense !

La parole est à vous

[HULK28]

Bonjour,

je partage à 100% l'intention de paulfjujo que je salue.
Cela ne coûte rien de le faire systématiquement et les gens de passage, en général des jeunes, doivent apprendre les bonnes manières de codage.
Un bon code se doit d'être documenté et commenté.
Une fonction doit avoir dans son entête la description des arguments d'entrée et également du paramètre de sortie, une explication claire de son rôle pour le reste du programme et de sa portée.
Quand on reprend un code qui a été fait 2 ans avant ça rend bien des services sinon attendez vous à des déboires.

Coder autrement revient à démontrer un manque de rigueur, en général je ne lis pas au delà de 5 lignes si ces choses ne sont pas mises en place.
Pour ceux qui coderont un jour dans le milieu professionnel je vous conseille vivement de vous y faire, c'est la norme.