Go Down

Topic: [OT] PIC, 8051, MCU e CPU varie (Read 100 times) previous topic - next topic

lesto

forse ho fatto casino io, si tratta di stlink Versione 2, poi non so se la stlink versione 1 sia compatibile al 100% come protocollo con la j-link..
anzi a quento vedo ogni scatolina parla (lato PC) a modo suo, è lato micro che seguino lo standard
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

BaBBuino

Si, lato MCU è uno standard, ma anche versus PC si tratta di driver USB che dialogano con un software in maniera abbastanza simile, anzi, spesso il driver è un semplice emulatore di COMx.

nid69ita

#1472
Jun 04, 2014, 08:30 pm Last Edit: Jun 04, 2014, 09:41 pm by nid69ita Reason: 1
Domandina PIC:
Questo codice su poverissimo PIC16F505 con cristallo esterno da 4Mhz:
Code: [Select]
/* Main Program */
#ifndef _XTAL_FREQ
#define _XTAL_FREQ 4000000 //4Mhz FRC internal osc
#define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
#endif

void main(void)
{ ConfigureOscillator();
 InitApp();
 TRISB=0b111111;   // all input
 TRISC=0b111000;   // 0,1,2 as output 3,4,5 as input
 while(1)
 { if(PORTBbits.RB2==0)
   { PORTCbits.RC0=0;
     PORTCbits.RC1=0;
     PORTCbits.RC2=0;
   }
   else
   {
       PORTCbits.RC0=1;    // verde
       PORTCbits.RC1=0;    
       PORTCbits.RC2=0;
       __delay_ms(1000);
       PORTCbits.RC0=0;
       PORTCbits.RC1=1;    // rosso
       PORTCbits.RC2=0;
       __delay_ms(1000);
       PORTCbits.RC0=0;
       PORTCbits.RC1=0;
       PORTCbits.RC2=1;    // blu
       __delay_ms(1000);
   }
 }      
}

Se ho un interruttore acceso, ogni secondo dovrebbe accendere un led tra 3 led.
Però, acceso il terzo, passa al 1° a occhio in meno di un secondo.
Ho scritto qualche ca...volata ?   :D
my name is IGOR, not AIGOR

lesto

sembra ok, mi sa che bisgna analizzare l'assembly :/
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Testato

Il codice è semplicissimo, non è che le altre funzioni che non hai postato mettono mano ai registri ?
Altra idea che mi viene, vedo che usi le funzioni delay standard della LibC, hai tenuto conto dei limiti ? Se ti leggi i sorgenti sono specificati nei commenti, sia per la ms che per la us

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

nid69ita

#1475
Jun 05, 2014, 09:50 am Last Edit: Jun 05, 2014, 09:53 am by nid69ita Reason: 1
@Testato, no, proverò a controllare.
Le due funzioni ConfigureOscillator() e InitApp() sono quelle standard che mette MPLABX.
O pensato però che se la _delay() ha dei limiti dovrebbe averli in tutti e tre i punti in cui li ho inseriti !?!
Cioè se anche non è preciso 1 sec ma 0,8 sec dovrebbe esserlo in tutti e tre i punti.

P.S. ma le sigle dei PIC hanno qualche regola?   Ad esmpio ci sono PIC16  con poche features tipo questo 16F505 (baseline) mentre un 16F877 (midrange) ha molte cose in più. Non ho capito le numerazioni. (O sono a caxxo ?  :smiley-mr-green:  )
my name is IGOR, not AIGOR

Testato

come dice lesto anche per me il programma e' scritto bene, ma visto che non funziona facevo ipotesi.
Non mi riferisco a limiti di precisione (che pure ci sono) ma anche ad eventuali overflow che hanno le due funzioni standard ms-us, a memoria mi sembra siano bassi (sui 600 ms ?). Resta il fatto che cmq gli overflow eventuali si presenterebbero anche sui pimi due led.
Ripeto sono solo primi approcci approfonditivi
Sulla sigla non so aiutarti perche' non uso PIC, solo mamma Atmel  :)
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

leo72

I PIC sono divisi in famiglie, come gli Atmel. I PIC12 sono diversi dai PIC16 che differiscono dai PIC18 ecc.. Sul sito Microchip vedi le caratteristiche comuni. Comunque la famiglia PIC16 mi disse tempo fa AStrobeed che era obsoleta, quindi se puoi sostituiscila con i modelli PIC18.

Detto questo, ocio con l'oscillatore interno dei PIC, ha un casino di cose a cui prestare attenzione per il setup, anch'io ci sbattei la testa all'inizio. Perché poi c'è da considerare il prescaler che usi a seconda della fonte di clock usata.
Per quanto riguarda il delay, non usare quella integrata di funzione, che mi pare sia una semplice funzione basata sull'esecuzione di una istruzione predefinita. Io mi sono rifatto la millis in stile Arduino, per evitare problemi. Nel thread ci dovrebbero essere tra le prime pagine dei codici che misi.

lesto

prova a copilare con -00 o con -O1, magari il compilatore erroneamente ottimizza via il delay
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

leo72

Meglio non usare proprio la _delay integrata nel compilatore. Non è affidabile.

Testato

ma parlate della _delay_ms e della _delay_us ?
funzioni cosi' importanti universalmente usate in tutti i programmi C hanno problemi ?
Non mi sono mai messo a vedere con un oscilloscopio se sono precise, ma le uso normalmente, si deve solo gestire correttamente la F_CPU perche' su quella si basa, ed essendoci una F_CPU di default nella LibC che puo' essere diversa dalla frequenza del quarzo usato, si possono sbagliare i tempi.

La millis e' altro discorso come ben sai, non e' bloccante, quindi a che pro metterla in campo se di delay bloccante si sta parlando ?
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

leo72

La delay_ms/us non si basa su un timer del micro ma è una funzione che dovrebbe (dico "dovrebbe") usare dei cicli che a tot ms/us eseguono una serie di centinaia/migliaia di semplici istruzioni macchina, che hanno un tempo fisso di numeri di clock per essere eseguite. Ovviamente si spera che il compilatore non ottimizzi il codice, per cui tutto sta, come ti ha detto Lesto, anche a come l'utente chiede di ottimizzare il codice, sperando che l'IDE informi il compilatore di non ottimizzare mai quei cicli, altrimenti saltano le tempistiche. Se io programmo un timer, non c'è compilatore che tenga: se chiedo di mettere un byte in un registro, lui me lo farà sempre, a qualunque livello di ottimizzazione.

insomma, tutto questo per dire che sei libero di usare _delay_ms/us ma io mi ci perderei un attimino a fare una cosina più pulita lo stesso.

lesto

in teoria esiste proprioper questo l'istruzione "nop()" che non fa nulla ma perde uno ciclo macchina, e non viene ottimizzata..

AVR dice di  non usare NOP() ma delle librerie ad hoc, per i pic non so..
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

leo72

Nel core di Arduino la delayMicroseconds è basata su nop(), e così è anche la delay presente nel core Avr.
Ora non sono a casa e non ho l'ambiente Microchip sotto mano, per cui non so dirti ma credo comunque che anche la delay_ms dei PIC usi lo stesso meccanismo.

ma per tempi così brevi va benissimo. il problema sorge quando si ragiona in ms invece che in us.

Testato

#1484
Jun 10, 2014, 08:30 am Last Edit: Jun 10, 2014, 08:32 am by Testato Reason: 1
Ma esiste una tabella da poter consultare per sapere cosa il compilatore ottimizza e cosa no ? In base ai rispettivi livelli di ottimizzazione.
Perché dovrebbe ottimizzare NOP ? È talmente chiara, l utente la mette per perdere tempo, non per perdere tempo  :DD

Io ho provato sia su arduino che su altri ide e la NOP perde il giusto tempo, l'ide arduinica usa un livello alto di ottimizzazione giusto ?
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Go Up