Prove di comunicazione I2C SLAVE con 18F4431

[bobboteck]

Hi guys,

sto perdendo un po di tempo dietro l'I2C, come al solito la mia
configurazione è una RB2.1 con 18F4620 che funziona da Master, provato
con una 24LC16 e le routine di scrittura e lettura funzionano.
Poi ho una RB2.0 con 18F4431, le due schede hanno in comune
l'alimentazione e i collegamenti tra RC4 e RC5 per l'I2C.

Quello che volevo fare per verificare se funzionava era scrivere dal
master un byte (0b00000001 o 0b00000010 o 0b00000100) che poi andavo a
scrivere sulla PORTE per far accendere un singolo LED, ma altre prove
che ho fatto sembra che non entri nel controllo "if(SSPSTATbits.BF==1)"
come se non ricevesse niente.

Di seguito riporto il codice usato, magari c'è qualcuno che avuto
esperienze in merito e sa darmi qualche consiglio!

Bobbo

#include <p18f4431.h>
#include <delays.h>
#include <i2c.h>

#pragma config OSC=HSPLL // Oscillatore PLL 4x attivo
#pragma config WDTEN=OFF // Whatch dog disattivato
#pragma config PWRTEN=ON // Power UP timer abilitato
#pragma config LVP=OFF // Programmazione LVP disabilitata
#pragma config BOREN=OFF // Brown out Reset disabilitato
#pragma config BORV=42 // Tensione per Brown out Reset 4.2 Volt
#pragma config PWM4MX=RB5 // RB5 = PWM4
#pragma config SSPMX=RC7 // SOLO PER 40pin, imposta RC4 e RC5 per l'I2C
perchè sono multiplexati

#define LedRosso PORTEbits.RE2 // Led Rosso
#define LedGiallo PORTEbits.RE1 // Led Giallo
#define LedVerde PORTEbits.RE0 // Led Verde

void initRB(void);
void lampeggio(void);

void main(void)
{
unsigned char dato;
// PINs Initial State
PORTA=0x00;
PORTB=0x00;
PORTC=0x00;
PORTD=0x00;
PORTE=0x00;
// PINs Direction
TRISA=0b00000000; // NOT USED NOW
TRISB=0b00000000; // RB0,RB1,RB2,RB3 (OUT)
TRISC=0b00111000; // RC4,RC5 (IN), RC3 è configurato come (IN)
solo per sfruttare il connettore I2C della scheda,
// inquanto la piedinatura del 4431 non corrisponde con quella su
cui è basata la RB2.0. Per il
// funzionamento corretto creo un ponticello tra RC3 e RC5 per
questo è meglio che RC3 sia un (IN)
TRISD=0x00; // NOT USED NOW
TRISE=0xF0; // LED

INTCON=0; // Clear Interrupt
ANSEL0=0x00; // PORTA e PORTE settate come ingressi digitali.
ANSEL1=0x00;

SSPADD=0x80; // Indirizzo della periferica
SSPCON=0b00110110; // Abilita I2C, generazione del clock, in
modalità 7 bit SLAVE

lampeggio();

while(1)
{
if(SSPSTATbits.BF==1)
{
SSPCONbits.SSPOV=0;
//PORTE=0x00;
dato=SSPBUF;
if(SSPSTATbits.D_A==1)
{
PORTE=dato;
}
}
}
}

[Marco d'Ambrosio]

Post by bobboteck
Di seguito riporto il codice usato, magari c'è qualcuno che avuto
esperienze in merito e sa darmi qualche consiglio!

Come ti avevo promesso durante la cena ARRM eccoti il codice per il 18F4431,
o 2431, per usare l'I2C come slave.

Per l'init della porta :

void ConfI2C(void)
{
// SSPSTAT &= 0x3F; // power on state
SSPCON = 0;

SSPCONbits.SSPEN = 1; // Abilita MMSP
SSPCONbits.CKP=1;

SSPCONbits.SSPM3 = 0; // I2C Slave, 7 bit, Start/Stop interrupt
SSPCONbits.SSPM2 = 1;
SSPCONbits.SSPM1 = 1;
SSPCONbits.SSPM0 = 0;

SSPSTATbits.SMP=0;
SSPSTATbits.CKE=0; // I2C Input Levels

SSPADD = I2Cadd; // slave address

SSPCONbits.SSPOV = 0;
SSPSTATbits.BF = 0;
}

Con questa funzione configuri l'I2C come slave con indirizzo a 7 bit,
interrupt ad ogni blocco dati ricevuto, sia che sia un address che un data.
Come ti dicevo è obbligatorio usare l'interrupt, col polling ti ritrovi con
dei time out che mandano in tilt la porta, per inizializzare l'int :

// interrupt
INTCON = 0; // disattiva tutti gli interrupt
INTCONbits.GIE = 1; // attiva interrupt periferiche
INTCONbits.PEIE = 1;
PIE1bits.SSPIE = 1; // interrupt SSP

Per la ISR eccoti quella che uso io :

void ComRTxDat() // interrupt service routine
{
unsigned char data;
TP2 = 1;

if(!SSPSTATbits.R_W) // Write operation
{
data = SSPBUF; // lettura buffer, autoreset flag BF

if (SSPSTATbits.D_A) // dato valido
{
strcom[TXcount] = data;
TXcount++;
}
else TXcount=0; // indirizzo valido, azzero puntatore

if (SSPSTATbits.P) // stop bit, end ricezione
{
ParsFlag = 1; // flag parser
}
}

if(SSPSTATbits.R_W & !SSPSTATbits.BF) // Read operation
{
//TP2 = 1;
if (Sidx > 1) Sidx = 0;

SSPBUF = 0b01010101; //0xff;

if (Sidx == 0) SSPBUF = rpm >> 8;
if (Sidx == 1) SSPBUF = rpm;
Sidx++;

// Delay10TCYx(1);
SSPCONbits.CKP = 1;
}

SSPCONbits.SSPOV = 0;
PIR1bits.SSPIF=0;
TP2 = 0;

return;
}

In ricezione, operazione di write i byte vegono accumulati in buffer
(strcom[]) fino a che non si riceve uno stop, ovviamente il buffer deve
essere predimensionato in testa al programma, al verificarsi dello stop
viene settato un flag (ParsFlag) che serve per dire al main che il buffer
I2C è pronto per essere letto e trattato da un parser se necessario.
Ovviamente gli interrupt vegono generati solo se l'indirizzo ricevuto, dopo
lo start, collima con quello contenuto dentro SSPADD, il valore deve essere
dichiarato nella ConfI2C().
In trasmissione, read operation, devi predisporre opportunamente per inviare
tutti i byte richiesti dal master, attualmente la routine invia solo due
byte, sta a te modificarla come serve, ricordati che il master durante la
read deve generare un ACK ad ogni byte ricevuto dallo slave.

Per finire ti rammento che il modulo SSP del 18F4431 è diverso da quello
degli altri pic della serie 18, ha tutte le funzionalità per lo slave, meno
la general call, e gli mancano svariate cose per il Master, usa due registri
in meno degli altri modelli di pic 18 e le routine di libreria del C18, che
a me non piacciono, non vegono compilate, ritorna un errore di linker, con
questo modello proprio per le diversità hardware.

p.s.
La ISR è quella che usa sulla mia motion controller e funziona
perfettamente, normalmente scrivo quando serve un comando e ogni 10 ms leggo
i vari dati operativi dai due pid.

Ciao

Marco d'Ambrosio

[bobboteck]

Ciao Marco,

questo è il programma che ho provato sullo SLAVE integrando il codice
che mi hai mandato, puoi dirmi se ti risulta corretto o c'è qualcosa che
non va, perchè ontinua a non funzionare!

#include <p18f4431.h>
#include <delays.h>
#include <i2c.h>

#pragma config OSC=HSPLL // Oscillatore PLL 4x attivo
#pragma config WDTEN=OFF // Whatch dog disattivato
#pragma config PWRTEN=ON // Power UP timer abilitato
#pragma config LVP=OFF // Programmazione LVP disabilitata
#pragma config BOREN=OFF // Brown out Reset disabilitato
#pragma config BORV=42 // Tensione per Brown out Reset 4.2 Volt
#pragma config PWM4MX=RB5 // RB5 = PWM4
#pragma config SSPMX=RC7 // SOLO PER 40pin, imposta RC4 e RC5 per
l'I2C perchè sono multiplexati

#define LedRosso PORTEbits.RE2 // Led Rosso
#define LedGiallo PORTEbits.RE1 // Led Giallo
#define LedVerde PORTEbits.RE0 // Led Verde

void initRB(void);
void lampeggio(void);
void ConfI2C(void);
void InterruptVectorLow(void);
void InterruptHandlerLow(void);
void InterruptVectorHigh(void);
void InterruptHandlerHigh(void);

unsigned char TXcount;
unsigned char strcom[5];
unsigned char ParsFlag;

void main(void)
{
unsigned char dato;

// PINs Initial State
PORTA=0x00;
PORTB=0x00;
PORTC=0x00;
PORTD=0x00;
PORTE=0x00;
// PINs Direction
TRISA=0b00000000; // NOT USED NOW
TRISB=0b00000000; // RB0,RB1,RB2,RB3 (OUT)
TRISC=0b00111000; // RC4,RC5 (IN), RC3 è configurato come
(IN) solo per sfruttare il connettore I2C della scheda,
// inquanto la piedinatura del 4431 non
corrisponde con quella su cui è basata la RB2.0. Per il
// funzionamento corretto creo un ponticello
tra RC3 e RC5 per questo è meglio che RC3 sia un (IN)
TRISD=0x00; // NOT USED NOW
TRISE=0xF0; // LED

INTCON=0; // Clear Interrupt
ANSEL0=0x00; // PORTA e PORTE settate come ingressi digitali.
ANSEL1=0x00;

// SSPADD=0x80; // Indirizzo della periferica
// SSPCON=0b00110110; // Abilita I2C, generazione del clock,
in modalità 7 bit SLAVE

ConfI2C();

// interrupt
INTCON = 0; // disattiva tutti gli interrupt
INTCONbits.GIE = 1; // attiva interrupt periferiche
INTCONbits.PEIE = 1;
PIE1bits.SSPIE = 1; // interrupt SSP

lampeggio();

while(1)
{
if(ParsFlag==1)
{
dato=strcom[0];
dato=dato && 0b00000111;
PORTE=dato;
ParsFlag=0;
}
}
}

void ConfI2C(void)
{
// SSPSTAT &= 0x3F; // power on state
SSPCON = 0;

SSPCONbits.SSPEN = 1; // Abilita MMSP
SSPCONbits.CKP=1;

SSPCONbits.SSPM3 = 0; // I2C Slave, 7 bit, Start/Stop interrupt
SSPCONbits.SSPM2 = 1;
SSPCONbits.SSPM1 = 1;
SSPCONbits.SSPM0 = 0;

SSPSTATbits.SMP=0;
SSPSTATbits.CKE=0; // I2C Input Levels

//SSPADD = I2Cadd; // slave address
SSPADD=0x80;

SSPCONbits.SSPOV = 0;
SSPSTATbits.BF = 0;
}
void lampeggio(void)
{
Delay10KTCYx(200);
LedVerde=1;
Delay10KTCYx(200);
LedVerde=0;
LedGiallo=1;
Delay10KTCYx(200);
LedGiallo=0;

Delay10KTCYx(200);
LedRosso=0;
}
/*===================================================*/
// Low priority interrupt vector
#pragma code LowVector = 0x18
void InterruptVectorLow (void)
{
_asm
goto InterruptHandlerLow //jump to interrupt routine
_endasm
}
//----------------------------------------------------
// Low priority interrupt routine
#pragma code
#pragma interruptlow InterruptHandlerLow
/*===================================================*
/*IntServiceRoutine**********************************/
void InterruptHandlerLow (void)
{
unsigned char data;
//TP2 = 1;

if(!SSPSTATbits.R_W) // Write operation
{
data = SSPBUF; // lettura buffer, autoreset flag BF

if (SSPSTATbits.D_A) // dato valido
{
strcom[TXcount] = data;
TXcount++;
}
else TXcount=0; // indirizzo valido, azzero puntatore

if (SSPSTATbits.P) // stop bit, end ricezione
{
ParsFlag = 1; // flag parser
}
}

if(SSPSTATbits.R_W & !SSPSTATbits.BF) // Read operation
{
//TP2 = 1;
// if (Sidx > 1) Sidx = 0;

SSPBUF = 0b01010101; //0xff;

// if (Sidx == 0) SSPBUF = rpm >> 8;
// if (Sidx == 1) SSPBUF = rpm;
// Sidx++;

// Delay10TCYx(1);
SSPCONbits.CKP = 1;
}

SSPCONbits.SSPOV = 0;
PIR1bits.SSPIF=0;
//TP2 = 0;

return;
} // Low Priority IntServiceRoutine
/*************************************************/
/*===============================================*/
// High priority interrupt vector
#pragma code HighVector = 0x08
void
InterruptVectorHigh (void)
{
_asm
goto InterruptHandlerHigh //jump to interrupt routine
_endasm
}
//------------------------------------------------
// High priority interrupt routine
#pragma code
#pragma interrupt InterruptHandlerHigh
/*===============================================*/
/*IntServiceRoutine*******************************/
void InterruptHandlerHigh (void)
{

}
/*===============================================*/

L'ACK lo SLAVE lo manda in automatico?

Ciao e grazie Bobbo

[Marco d'Ambrosio]

www.roboteck.org\FirstTest.wmv

Finalmente sono riuscito a fare un po di cablaggi quasi definitivi e tutta
la parte di locomozione di Gino è pronta, nel breve filmato, 20 secondi e
meno di 2 mega, potete vedere il primissimo test di movimento autonomo.
Il test prevede di avanzare 30 cm, ruotare di 180° in senso orario,
riavanzare di 30 cm, ruotare di 180° in senso antiorario, tutte le manovre
con una velocità di 20 cm/s, nulla di particolarmente complicato ma è quanto
basta per verificare che la motion controller risponda in modo corretto ai
comandi.
Devo ancora trovare i giusti valori di conversione tra conteggi encoder e
spazio reale percorso, che dipende dal diametro delle ruote e dal loro
interasse durante le curve/rotazioni, per questo primo test ho inserito dei
valori puramente teorici, ma andranno corretti con una serie di test pratici
perchè il diametro delle ruote, che sono pneumatiche, sotto carico varia
leggermente e induce degli errori se si usano i valori dei conversione
puramente teorici, in tutti i casi, nel test, la precisione di movimento
risulta abbastanza buona, oltretutto il fondo del tavolo è tutto meno che
perfettamente liscio.
In questo test la motion controller riceve i comandi, uno ogni cinque
secondi, via RS485 dalla scheda Sensor1, una RBV2.0, che per il momento fa
le veci del cervello principale, i due cavi attorcigliati attorno alle
colonnine per il secondo piano sono il cavo che va all'ICD2 e quello per
collegarsi ad un convertitore 485<->232 per leggere la telemetria sul pc,
non appena finiti tutti i test e gli ultimi ritocchi ovviamente questi cavi
verrano tolti.

Ciao

Marco d'Ambrosio m.dambrosio-***@public.gmane.org

[Vegekou]

Post by Marco d'Ambrosio
Devo ancora trovare i giusti valori di conversione tra conteggi encoder e
spazio reale percorso, che dipende dal diametro delle ruote e dal loro
interasse durante le curve/rotazioni, per questo primo test ho inserito dei
valori puramente teorici, ma andranno corretti con una serie di test
pratici perchè il diametro delle ruote, che sono pneumatiche, sotto carico
varia leggermente e induce degli errori se si usano i valori dei
conversione puramente teorici, in tutti i casi, nel test, la precisione di
movimento risulta abbastanza buona, oltretutto il fondo del tavolo è tutto
meno che perfettamente liscio.

Non ho trovato grandi errori nel video, il robot è PERFETTO! :)

Ma tutti quei LED che lampeggiano cosa stanno a significare?

CIAO!


Raffaello Bonghi
Webmaster www.minisumo.net
MSN rbonghi-***@public.gmane.org

-----Messaggio originale-----
Da: roboteck-***@public.gmane.org [mailto:roboteck-***@public.gmane.org] Per conto di
Marco d'Ambrosio
Inviato: domenica 12 agosto 2007 15.47
A: roboteck-***@public.gmane.org
Oggetto: [roboteck] Primi passi

www.roboteck.org\FirstTest.wmv

Finalmente sono riuscito a fare un po di cablaggi quasi definitivi e tutta
la parte di locomozione di Gino è pronta, nel breve filmato, 20 secondi e
meno di 2 mega, potete vedere il primissimo test di movimento autonomo.
Il test prevede di avanzare 30 cm, ruotare di 180° in senso orario,
riavanzare di 30 cm, ruotare di 180° in senso antiorario, tutte le manovre
con una velocità di 20 cm/s, nulla di particolarmente complicato ma è quanto

basta per verificare che la motion controller risponda in modo corretto ai
comandi.
Devo ancora trovare i giusti valori di conversione tra conteggi encoder e
spazio reale percorso, che dipende dal diametro delle ruote e dal loro
interasse durante le curve/rotazioni, per questo primo test ho inserito dei
valori puramente teorici, ma andranno corretti con una serie di test pratici

perchè il diametro delle ruote, che sono pneumatiche, sotto carico varia
leggermente e induce degli errori se si usano i valori dei conversione
puramente teorici, in tutti i casi, nel test, la precisione di movimento
risulta abbastanza buona, oltretutto il fondo del tavolo è tutto meno che
perfettamente liscio.
In questo test la motion controller riceve i comandi, uno ogni cinque
secondi, via RS485 dalla scheda Sensor1, una RBV2.0, che per il momento fa
le veci del cervello principale, i due cavi attorcigliati attorno alle
colonnine per il secondo piano sono il cavo che va all'ICD2 e quello per
collegarsi ad un convertitore 485<->232 per leggere la telemetria sul pc,
non appena finiti tutti i test e gli ultimi ritocchi ovviamente questi cavi
verrano tolti.

Ciao

Marco d'Ambrosio m.dambrosio-***@public.gmane.org



Sito ufficiale della mail list:
www.roboteck.org

Per consultare le F.A.Q. della ML:
http://www.roboteck.org/faq/faq.htm
Link utili di Yahoo! Gruppi




No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.13/947 - Release Date: 11/08/2007
14.29


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.13/947 - Release Date: 11/08/2007
14.29

[Marco d'Ambrosio]

Post by Vegekou
Ma tutti quei LED che lampeggiano cosa stanno a significare?

Niente sono solo coreografici :-)

Scherzi a parte hanno un ben preciso significato, i quattro sul ponte H, in
basso nel pianale del motore, indicano la percentuale PWM e il verso di
rotazione, dato che lavoro in LAP sono sempri accesi tutti, al 50% quando
sono fermo e variano fino al massimo uno e spento l'altro.
Sulle due schede montate sul pianale i tre led della RB indicano solo il
ciclo trasmissione dati via 485.
I sei led sulla motion controller sono abbinati a coppie ad ogni micro, per
il governor indicano il suo ciclo di lavoro e lo stato comunicazioni, per i
pid indicano il verso di rotazione imposto alle ruote, però possono anche
indicare se la ruota è sotto accelerarione oppure si trova in condizione di
velocità costante, oppure possono indicare se la velocità istantanea di
rotazione è al valore richiesto.
Se ci fai caso quando il robot si ferma le due coppie di led abbinati ai PID
lampeggiano rapidamente indicando che il pid è in condizione mantenimento
posizione.
Aspetta che metto gli altri due piani e vedrai che alberello di Natale viene
fuori.

Ciao

Marco d'Ambrosio

[domenico]

Ma se lo metti in .mpg o Divx o XviD così anche noi Linuxari lo possiamo
vedere?

Post by Marco d'Ambrosio
www.roboteck.org\FirstTest.wmv

[Guido Ottaviani]

Ma come? persino noi poveri utenti Mac riusciamo a vederlo?
Magari raddrizzando lo slash.

ciao
Guido

Post by domenico
Ma se lo metti in .mpg o Divx o XviD così anche noi Linuxari lo possiamo
vedere?

Post by Marco d'Ambrosio
www.roboteck.org\FirstTest.wmv

[domenico]

Voi applisti lo vedete perchè "qualcuno" si è calato le braghe davati
Minchiasoft...
Noi Linuxiani siamo ancora resistendo e quindi non usiamo standard
proprietari. :-)
tanto che invece di usare mp3 usiamo Vorbis (che è anche meglio).

ciao,
Domenico

Che il pinguino sia con te...

Post by Guido Ottaviani
Ma come? persino noi poveri utenti Mac riusciamo a vederlo?
Magari raddrizzando lo slash.
ciao
Guido

Post by domenico
Ma se lo metti in .mpg o Divx o XviD così anche noi Linuxari lo

possiamo

Post by domenico
vedere?

Post by Marco d'Ambrosio
www.roboteck.org\FirstTest.wmv

[Marco d'Ambrosio]

Post by domenico
Voi applisti lo vedete perchè "qualcuno" si è calato le braghe davati
Minchiasoft...

Ora non facciamo le guerre di religione, anche perchè vmw è un ottimo
formato video, offre buona qualità anche a forti compressioni e per noi
"poveri" utenuti Windows è facile creare un filmato in pochi secondi con le
utlità di serie di XP.

Post by domenico
tanto che invece di usare mp3 usiamo Vorbis (che è anche meglio).

Questo che cosa centra con windows, mp3 è un formato mpeg,.

Ciao

Marco d'Ambrosio

[domenico]

No, nessuna guerra di religione ma solo una lotta per la sopravvivenza.
Lo sai quanto costa winzoz vista?
E linux?

Se io sono un poveraccio che vuole imparare a configurare un server,
quanto mi costa da winzoz e quanto da linux?
Qui è solo un problema di accesso alla cultura (e non sto facendo il
noglobal). Se hai 400 euro impari e usi vista altrimenti no.
Se hai 2000 euro impari winzoz 2003 server altrimenti no.

Con linux che è gratis, client e server (a parte l'assistenza che quella
si paga) puoi imparare e metterti sul mondo del lavoro spendendo solo i
soldi per un PC, con windows no. Per fare un esempio io ho speso qualche
anno fa 180.000 lire per due manualetti sulle reti targati Minchiasoft e
quello che ne ho ricavato in sapere è solo la metà del primo volume CCNA
della Cisco (che pure si fa pagare). Il manuale Cisco costa la metà.
Questo tanto per dire.

Se l'utente è una azienda allora paga quello che vuole perchè lo
ammortizza, ma un padre di famiglia o uno studente viene automaticamente
tagliato fuori dal sapere.

E' un po come i prestiti, le banche li danno solo a chi ha già i soldi.

Se Minchiasoft tagliasse soltanto la metà i prezzi, allora si che
sarebbe competitiva, ma preferisce imporsi in altri modi.

Ciao,
Domenico

Post by Marco d'Ambrosio

Post by domenico
Voi applisti lo vedete perchè "qualcuno" si è calato le braghe davati
Minchiasoft...

Ora non facciamo le guerre di religione, anche perchè vmw è un ottimo
formato video, offre buona qualità anche a forti compressioni e per noi
"poveri" utenuti Windows è facile creare un filmato in pochi secondi con le
utlità di serie di XP.

Post by domenico
tanto che invece di usare mp3 usiamo Vorbis (che è anche meglio).

Questo che cosa centra con windows, mp3 è un formato mpeg,.
Ciao
Marco d'Ambrosio

[Marco d'Ambrosio]

Post by domenico
No, nessuna guerra di religione ma solo una lotta per la sopravvivenza.
Lo sai quanto costa winzoz vista?

Esattemente quanto costava XP quando è uscito, cioè tanto

Post by domenico
E linux?

Gratis, o al massimo il costo della distribuzione.

Post by domenico
Qui è solo un problema di accesso alla cultura (e non sto facendo il
noglobal). Se hai 400 euro impari e usi vista altrimenti no.
Se hai 2000 euro impari winzoz 2003 server altrimenti no.

Su questo punto posso anche essere d'accordo, ma un privato non ha bisogno
di Windows 2003 server, in casa mica hai una rete aziendale, Windows viene
dato in bundle con tutti i nuovi pc ad un costo molto ridotto, circa 35 Euro
per Vista Home basic e circa 50 Euro per Vista Home Premium, a suo tempo
anche XP in bundle aveva gli stessi costi.

Post by domenico
Con linux che è gratis, client e server (a parte l'assistenza che quella
si paga) puoi imparare e metterti sul mondo del lavoro spendendo solo i
soldi per un PC, con windows no.

Guarda che il costo per imparare a mettere su un server, parliamo di
applicazioni aziendali, non è certo il S.O., ma i vari corsi per imparare a
farlo e l'eventuale consulenza tecnica, nessuno nasce imparato e configurare
correttamente un server o costa molto tempo, ammesso che uno sia già
scafato, o costa molti soldi se uno non ha alcuna esperienza sull'argomento.

Post by domenico
Se l'utente è una azienda allora paga quello che vuole perchè lo
ammortizza, ma un padre di famiglia o uno studente viene automaticamente
tagliato fuori dal sapere.

Giusto diversifichiamo le due cose, mi spieghi perchè un padre di famiglia
deve sapere configurare una rete aziendale con Win 2003 Server ? se lo fa
solo per passione e sete di sapere in rete trovi tutti i manuali necessari,
ti rammento che MSDN è liberamente consultabile online, inoltre ci sono un
sacco di tutorial free che spiegano come fare.

Post by domenico
E' un po come i prestiti, le banche li danno solo a chi ha già i soldi.

Pura retorica, non è la stessa cosa.

Post by domenico
Se Minchiasoft tagliasse soltanto la metà i prezzi, allora si che
sarebbe competitiva, ma preferisce imporsi in altri modi.

Microsoft è una società a scopo di lucro che da lavoro a molte migliaia di
persone sparse nel mondo, Bill Gates e Microsoft ogni anno donano molte
decine di milioni di Dollari a scopo benifico, per non parlare delle borse
di studio, se tutte le grandi aziende e i grandi ricchi facessero la stessa
cosa sicuramente questo mondo andrebbe meglio.
Con questo non voglio prendere parte a favore di MS, però sono obbiettivo e
non mi schiero contro una persona o una società solo per partito preso,
inoltre Windows come S.O. è anni luce avanti a Linux, non c'è storia in un
confronto diretto, per non parlare delle applicazioni disponibili per
Windows e che non esistono per Linux o che devono girare, con svariati
problemi, tramite emulatori.
Riconosco che Linux è ottimo come server web e di rete, quindi usato senza
fronzoli e interfacce grafiche varie, ma come S.O. generico non regge il
confronto.

Ciao

Marco d'Ambrosio

[Simone Fabris]

Mi inserisco nella guerra di religione, stando dalla parte di Linux (che uso
in modo esclusivo, ma solo in ambiente domestico, da 10 anni)
perchè il filmato io ... lo vedo perfettamente in linux!!!
E senza calarsi le brage a nessuno!

Simone

Simone

Post by domenico
Voi applisti lo vedete perchè "qualcuno" si è calato le braghe davati
Minchiasoft...
Noi Linuxiani siamo ancora resistendo e quindi non usiamo standard
proprietari. :-)
tanto che invece di usare mp3 usiamo Vorbis (che è anche meglio).
ciao,
Domenico
Che il pinguino sia con te...

Post by Guido Ottaviani
Ma come? persino noi poveri utenti Mac riusciamo a vederlo?
Magari raddrizzando lo slash.
ciao
Guido

40yahoogroups.com>,

Post by Guido Ottaviani

Post by domenico
Ma se lo metti in .mpg o Divx o XviD così anche noi Linuxari lo

possiamo

Post by domenico
vedere?

Post by Marco d'Ambrosio
www.roboteck.org\FirstTest.wmv

[Sono state eliminare la parti non di testo del messaggio]

[Marco d'Ambrosio]

Post by Simone Fabris
perchè il filmato io ... lo vedo perfettamente in linux!!!
E senza calarsi le brage a nessuno!

Appunto, è solo una questione di player usato, esattamente come io in
windows vedo senza problemi i filmati in formato .mov senza dover per forza
di cose installare quick time e tutta la monnezza che si porta appresso e
che non voglio sul mio pc.

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Sul sito di Microchip sono disponibili vari aggiornamenti, sia per i
compilatori che per MPLAB, in particolare per quest'ultimo sono state
aggiunte alcune nuove funzionalità, un migliorato supporto per il Real Ice e
ICD2, pieno supporto anche per tutti i nuovi modelli di micro, più che altro
per le serie 24 e 33.
Da notare che con questa versione di MPLAB viene notevolmente esteso il
supporto diretto del PK2 (scaricare anche il nuovo firmware), esattamente
come avevo previsto qualche mese fa.
Ora potete usare il PK2 direttamente da MPLAB, sia come programmatore che
debugger, per moltissimi modelli di pic serie 16 e 18, in pratica tutti
quelli che normalmente usiamo, anche se per moltissimi il supporto è ancora
definito come beta, led giallo nella finestra di selezione mcu, non
dovrebbero essere particolari problemi come programmatore, ma potrebbero
essere delle restrizioni come debugger.
Attenzione che per usare come debugger i PK2 più vecchi, quelli col pulsante
nero quelli più recenti l'hanno rosso, è necessario aggiungere due
resistenze di pull down da 4.7k alle linee PGC e PGD, volendo è possibile
installarle direttamente dentro il PK2 se le trovate in formato da 1/8 di
watt o meglio SMD, trovate tutti i dettagli nel readme relativo al PK2 di
MPLAB.

Ciao

Marco d'Ambrosio

[bobboteck]

Mitica Microchip,

hanno fatto uscire la versione nuova esattamente il giorno dopo che
avevo installato la 7.60 sul computer pulito e da poco formattato.
Consigli sulla procedura migliore per installare la nuova versione?
Classico disinstalla poi installa o è cosigliabile fare in altri modi?

Bobbo

[Marco d'Ambrosio]

Post by bobboteck
hanno fatto uscire la versione nuova esattamente il giorno dopo che
avevo installato la 7.60 sul computer pulito e da poco formattato.
Consigli sulla procedura migliore per installare la nuova versione?
Classico disinstalla poi installa o è cosigliabile fare in altri modi?

Non serve disinstallare, l'install di MPLAB se trova una precedente versione
si comporta come un update aggiornando la precedente versione e mantenendo
tutti i setup impostati.

Ciao

Marco d'Ambrosio

[domenico]

Perfetto! Che lettore usi?

grey

Post by Simone Fabris
Mi inserisco nella guerra di religione, stando dalla parte di Linux (che uso
in modo esclusivo, ma solo in ambiente domestico, da 10 anni)
perchè il filmato io ... lo vedo perfettamente in linux!!!
E senza calarsi le brage a nessuno!
Simone
Simone

[Simone Fabris]

emerge -pv mplayer

[ebuild R ] media-video/mplayer-1.0.20070622-r1 USE="3dnow
3dnowext X alsa dvd esd gtk iconv live mmx mmxext mp2 mp3 opengl rar
rtc samba sse sse2 truetype unicode vidix vorbis win32codecs xv xvmc
-a52 -aac -aalib (-altivec) -amrnb -amrwb -arts -bidi -bindist -bl
-cddb -cdparanoia -cpudetection -custom-cflags -debug -dga -directfb
-doc -dts -dv -dvb -dvdnav -enca -encode -fbcon -ftp -ggi -gif -ipv6
-ivtv -jack -joystick -jpeg -libcaca -lirc -livecd -lzo -mad -md5sum
-musepack -nas -openal -oss -png -pnm -quicktime -radio -real -sdl
-speex -srt -ssse3 -svga -tga -theora -tivo -v4l -v4l2 -x264 -xanim
-xinerama -xvid -zoran" VIDEO_CARDS="vesa -mga -s3virge -tdfx" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

(il trucco sono i win32codecs)

Simone

Post by domenico
Perfetto! Che lettore usi?
grey

Post by Simone Fabris
Mi inserisco nella guerra di religione, stando dalla parte di Linux (che uso
in modo esclusivo, ma solo in ambiente domestico, da 10 anni)
perchè il filmato io ... lo vedo perfettamente in linux!!!
E senza calarsi le brage a nessuno!
Simone
Simone

www.roboteck.org
http://www.roboteck.org/faq/faq.htm
Link utili di Yahoo! Gruppi

[domenico]

Funzia! :)
Peccato però che la scheda video non ce la faccia e lo visualizza come
se fosse immerso in una bacinella d'acqua :D
Ho trasformato un explorer terrestre in uno sottomarino!!!

MARCO VOGLIO ESSERE REMUNERATO PER QUESTA TRASFORMAZIONE :D

Ciao,
grey

Post by Simone Fabris
emerge -pv mplayer
[ebuild R ] media-video/mplayer-1.0.20070622-r1 USE="3dnow
3dnowext X alsa dvd esd gtk iconv live mmx mmxext mp2 mp3 opengl rar
rtc samba sse sse2 truetype unicode vidix vorbis win32codecs xv xvmc
-a52 -aac -aalib (-altivec) -amrnb -amrwb -arts -bidi -bindist -bl
-cddb -cdparanoia -cpudetection -custom-cflags -debug -dga -directfb
-doc -dts -dv -dvb -dvdnav -enca -encode -fbcon -ftp -ggi -gif -ipv6
-ivtv -jack -joystick -jpeg -libcaca -lirc -livecd -lzo -mad -md5sum
-musepack -nas -openal -oss -png -pnm -quicktime -radio -real -sdl
-speex -srt -ssse3 -svga -tga -theora -tivo -v4l -v4l2 -x264 -xanim
-xinerama -xvid -zoran" VIDEO_CARDS="vesa -mga -s3virge -tdfx" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
(il trucco sono i win32codecs)
Simone

[Marco d'Ambrosio]

Post by domenico
Ma se lo metti in .mpg o Divx o XviD così anche noi Linuxari lo possiamo
vedere?

Ma da quando con Linux con si vedeno i filmati in formato wmv ?

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Post by Marco d'Ambrosio
Ma da quando con Linux con si vedeno i filmati in formato wmv ?

Ecco un ottimo esempio di quello che succede quando si scrive in fretta, si
modifica ancora più in fretta e non si rilegge.
Ovviamente la frase era :

***
Ma da quando con Linux non si vedono i file in formato wmv?
***

Ciao

Marco d'Ambrosio m.dambrosio-***@public.gmane.org

[domenico]

No, no, "vedeno" a Roma è corètto. Nun è sbajato. A morè, eh!

:-D ciao, Domenico

Post by Marco d'Ambrosio

Post by Marco d'Ambrosio
Ma da quando con Linux con si vedeno i filmati in formato wmv ?

Ecco un ottimo esempio di quello che succede quando si scrive in fretta, si
modifica ancora più in fretta e non si rilegge.
***
Ma da quando con Linux non si vedono i file in formato wmv?
***

[nonno_nino]

Una piccola domanda tecnica, con i motori, encoder e PID che usi nella
misurazione degli angoli quale è l'errore massimo che hai?

Ti chiedo questo perche dal video si evidenzia un certo errore nella
rotazione di 180° che fa Gino alla fine del tratto rettilineo.

Ciao Nonno

[Marco d'Ambrosio]

Post by nonno_nino
Una piccola domanda tecnica, con i motori, encoder e PID che usi nella
misurazione degli angoli quale è l'errore massimo che hai?

La risoluzione è quella permessa dagli encoder ed è altissima visto che sono
da 300 cpr e calettati direttamente sui motori, tenuto conto che il
motoriduttore è 30:1 e la decodifica è del tipo 4x abbiamo 1200*30 = 36000
impulsi per ogni giro della ruota, queste sono da 82 mm il che ci porta ad
avere 82 mm *3.14 = 250.7 mm di circonferenza e ben 36000/250.7 = 143.6
impulsi per ogni mm.
Però tutto questo è solo teorico in quanto che i copertoni sono pneumatici e
ovviamente variano, anche se di poco, il diametro in funzione del peso del
robot e delle manovre che esegue, a causa di ciò il reale numero di impulsi
per giro è leggermente minore e per giunta variabile.
Dal punto di vista software ho impostato la risoluzione minima per
l'avanzamento al singolo mm e per la rotazione al decimo di grado.

Post by nonno_nino
Ti chiedo questo perche dal video si evidenzia un certo errore nella
rotazione di 180° che fa Gino alla fine del tratto rettilineo.

Esatto, il piccolo errore di rotazione induce uno spostamento laterale di
circa 4-5 mm quando il robot torna alla posizione di avvio, si nota
benissimo facendo girare il filmato con ripetizione automatica, quando il
video riparte si vede che il robot si sposta di colpo di qualche mm verso
destra, invece l'avanzamento ha un errore di solo 2 mm.
Come ho già detto per questo primo test ho usato dei valori puramente
teorici, cioè calcolati dal diametro della ruota, per fare le conversioni
tra ppr e avanzamento/rotazione reale, quindi soggetti ad errori, per giunta
il fondo del tavolo è sconnesso e a sua volta induce errori aggiuntivi,
tutto sommato come risultato per il primo test reale di movimento non è
male, anche perchè c'è margine di miglioramento.
Il prossimo test, che farò oggi, è il famigerato quadrato, ovvero seguire il
perimetro di un quadrato con lato di 1 mt tornando al punto di partenza con
lo stesso orientamento, una volta messo a punto i parametri di conversione
il robot dovrebbe passarlo con un errore massimo di +/- 5 mm come posizione
e +/- 1° come rotazione, il che significa un errore massimo del 0.5% per la
navigazione puramente odometrica, il che non mi pare male.
Nella sua veste finale il robot ha anche una bussola che gli permette di
correggere l'errore di rotazione con una precisione di +/- 1°, questa
abbinata al radar 2D Ir gli permetterà di muoversi con sicurezza e
precisione all'interno di ogni ambiente, il piano con sopra il doppio GP2D02
ruotante, più altri cinque GP2D02 fissi, è già pronto e funzionante.
Qui puoi vedere un'immagine del secondo piano totalmente cablato, non ti
dico la faticaccia per mettere a posto tutti i fili :-)

Loading Image...


Ciao

Marco d'Ambrosio

[Roberto D'Amico]

Sempre sul solito problema in oggetto, ancora non funziona, questo
che segue è il codice usato sullo SLAVE, integrando quello che mi ha
consigliato Marco alcune cose prese da Guido, e le immancabili
Application Notes, sapete dirmi se è corretto o c'è qualcosa di
sbagliato? E' la prima volta che uso gli interrupt sui PIC, e se il
codice dovrebbe andare il problema potrebbe essere il master, anche
se provato con una 2416 funziona.

Bobbo

#include <p18f4431.h>
#include <delays.h>

#pragma config OSC=HSPLL // Oscillatore PLL 4x attivo
#pragma config WDTEN=OFF // Whatch dog disattivato
#pragma config PWRTEN=ON // Power UP timer abilitato
#pragma config LVP=OFF // Programmazione LVP disabilitata
#pragma config BOREN=OFF // Brown out Reset disabilitato
#pragma config BORV=42 // Tensione per Brown out Reset 4.2 Volt
#pragma config PWM4MX=RB5 // RB5 = PWM4
#pragma config SSPMX=RC7 // SOLO PER 40pin, imposta RC4 e RC5 per
l'I2C perchè sono multiplexati

#define LedRosso PORTEbits.RE2 // Led Rosso
#define LedGiallo PORTEbits.RE1 // Led Giallo
#define LedVerde PORTEbits.RE0 // Led Verde

void initRB(void);
void lampeggio(void);
void ConfI2C(void);
void InterruptVectorLow(void);
void InterruptHandlerLow(void);
void InterruptVectorHigh(void);
void InterruptHandlerHigh(void);

unsigned char TXcount=0;
unsigned char strcom[5];
unsigned char ParsFlag=0;

void main(void)
{
unsigned char dato;

// PINs Initial State
PORTA=0x00;
PORTB=0x00;
PORTC=0x00;
PORTD=0x00;
PORTE=0x00;
// PINs Direction
TRISA=0b00000000; // NOT USED NOW
TRISB=0b00000000; // RB0,RB1,RB2,RB3 (OUT)
TRISC=0b00110000; // RC4,RC5 (IN)
TRISD=0x00; // NOT USED NOW
TRISE=0xF0; // LED


ANSEL0=0x00; // PORTA e PORTE settate come ingressi digitali.
ANSEL1=0x00;

ConfI2C();

//-------Interrupts
RCONbits.IPEN=1; // Abilitata priorita' interrupt (non compatibile
con serie 16fxx)
INTCONbits.GIEH=0; // Disabilitati tutti gli interrupt high
INTCONbits.GIEL=0; // Disabilitati tutti gli interrupt low

PIE1bits.SSPIE=1; // Abilita gli interrupt per il modulo SSP
IPR1bits.SSPIP=0; // Imposta l'interrupt del modulo SSP a priorità
bassa
//-----------------

lampeggio();

while(1)
{
if(ParsFlag==1)
{
dato=strcom[0];
dato=dato && 0b00000111;
PORTE=dato;
ParsFlag=0;
}
}
}
//--------------------------------------------------------------------
---------
void ConfI2C(void)
{
// SSPSTAT &= 0x3F; // power on state
SSPCON = 0;

SSPCONbits.SSPEN = 1; // Abilita MMSP
SSPCONbits.CKP=1;

SSPCONbits.SSPM3 = 0; // I2C Slave, 7 bit, Start/Stop interrupt
SSPCONbits.SSPM2 = 1;
SSPCONbits.SSPM1 = 1;
SSPCONbits.SSPM0 = 0;

SSPSTATbits.SMP=0;
SSPSTATbits.CKE=0; // I2C Input Levels

//SSPADD = I2Cadd; // slave address
SSPADD=0x80;

SSPCONbits.SSPOV = 0;
SSPSTATbits.BF = 0;
}
//--------------------------------------------------------------------
---------
void lampeggio(void)
{
Delay10KTCYx(200);
LedVerde=1;
Delay10KTCYx(200);
LedVerde=0;
LedGiallo=1;
Delay10KTCYx(200);
LedGiallo=0;
LedRosso=1;
Delay10KTCYx(200);
LedRosso=0;
}
/*====================================================================
=======*/
// Low priority interrupt vector
#pragma code LowVector = 0x18
void InterruptVectorLow (void)
{
_asm
goto InterruptHandlerLow //jump to interrupt routine
_endasm
}
//--------------------------------------------------------------------
--------
// Low priority interrupt routine
#pragma code
#pragma interruptlow InterruptHandlerLow
/*====================================================================
=======*
/*IntServiceRoutine***************************************************
*****************/
void InterruptHandlerLow (void)
{
unsigned char data;
// Interrupt modulo SSP, ricezione o trasmissione completata
if(PIR1bits.SSPIF==1)
{
// Operazione di write sullo slave (che quindi riceve)
if(!SSPSTATbits.R_W)
{
data=SSPBUF;// lettura buffer, autoreset flag BF

if(SSPSTATbits.D_A) // dato valido
{
strcom[TXcount]=data;
TXcount++;
}
else
{
// indirizzo valido, azzero puntatore
TXcount=0;
}
// stop bit, end ricezione
if(SSPSTATbits.P)
{
ParsFlag=1; // flag parser
}
}
// Operaione di lettura sullo SLAVE (che quindi trasmette)
if(SSPSTATbits.R_W & !SSPSTATbits.BF)
{
SSPBUF=0b01010101;
SSPCONbits.CKP=1;
}

SSPCONbits.SSPOV=0; // Resetta il flag di OverFlow
// Resetta il flag di interrupt per il modulo SSP
PIR1bits.SSPIF=0;
}

return;
} // Low Priority IntServiceRoutine
/*********************************************************************
*****************/
/*====================================================================
=======*/
// High priority interrupt vector
#pragma code HighVector = 0x08
void
InterruptVectorHigh (void)
{
_asm
goto InterruptHandlerHigh //jump to interrupt routine
_endasm
}
//--------------------------------------------------------------------
--------
// High priority interrupt routine
#pragma code
#pragma interrupt InterruptHandlerHigh
/*====================================================================
=======*/
/*IntServiceRoutine***************************************************
*****************/
void InterruptHandlerHigh (void)
{
return;
} // High Priority IntServiceRoutine
/*********************************************************************
*****************/

[Marco d'Ambrosio]

Post by Roberto D'Amico
E' la prima volta che uso gli interrupt sui PIC, e se il
odice dovrebbe andare il problema potrebbe essere il master, anche
se provato con una 2416 funziona.

Il fatto che il MASTER vada con una EEPROM I2C non significa che è in grado
di colloquiare con il 18F4431.
Il codice che hai postato può essere sia giusto che sbagliato al tempo
stesso, dipende dal contesto generale e da come lavora il MASTER, detto in
altri termini "dati insufficienti per fornire una risposta significativa".
Se non ti serve usare gli interrupt low è inutile stare a definirlo, per
defualt i PIC18 lavorano con gli interrupt HIGH pertanto non serve
dichiarare nulla.

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Post by Roberto D'Amico
Sempre sul solito problema in oggetto, ancora non funziona, questo
che segue è il codice usato sullo SLAVE, integrando quello che mi ha
consigliato Marco alcune cose prese da Guido, e le immancabili

Ma perchè non provi a fare un pochino di verifiche con il firmware per il
Pickit2 serial analyzer che ho reso disponibile in versione modificata per
uso con la RoboBoard ?

Ciao

Marco d'Ambrosio

[Spad 05]

Devo dire che mi trovo d'accordo con astro.

Io uso entrambi ma sul desktop preferisco di gran lunga Windows.

Perche'? Perche' posso anche impegnare qualche decina di ore per configurare a dovere un server linux che poi resta li senza bisogno di tante attenzioni per settimane o mesi (e comunque non e' a costo zero, perche' se impieghi ore a cofigurarlo sonoore che paghi al dipendente), ma se devo aprire un file non posso entrare in una peripezia ciclopica alla ricerca di how to e cose varie che magari mi portano alla ricompilazione del kernel, io voglio solo aprire un file!!

Questo non vuol dire che ogni tanto non mi intrippo a smanettare su una distro desktop (uso fedora 7), solo che lo faccio quando ho un po' di tempo da buttar via.

Giusto per non voler apparire antipatico ;) : ma chi dice che l'accesso alla cultura debba essere gratis? NOn lo e' mai stato, perche' dovrebberlo esserlo a spese della MicroSoft che e' un'azienda? Inoltre ti contesto anche che l'accesso a linux sia gratis. Per sempio senza adsl oggi praticamente non riesci a fare un passo (se sei un niubbo) nell'uso di linux, se non conosci l'inglese idem...

Insomma, alla fine si tratta di vedere dove preferisci spendere i tuoi soldi e sopratutto del tempo che puoi permetterti di usare per raggiungere un obbiettivo.

No, nessuna guerra di religione ma solo una lotta per la sopravvivenza.> Lo sai quanto costa winzoz vista?Esattemente quanto costava XP quando è uscito, cioè tanto> E linux?Gratis, o al massimo il costo della distribuzione.> Qui è solo un problema di accesso alla cultura (e non sto facendo il> noglobal). Se hai 400 euro impari e usi vista altrimenti no.> Se hai 2000 euro impari winzoz 2003 server altrimenti no.Su questo punto posso anche essere d'accordo, ma un privato non ha bisognodi Windows 2003 server, in casa mica hai una rete aziendale, Windows vienedato in bundle con tutti i nuovi pc ad un costo molto ridotto, circa 35 Euro per Vista Home basic e circa 50 Euro per Vista Home Premium, a suo tempo anche XP in bundle aveva gli stessi costi.> Con linux che è gratis, client e server (a parte l'assistenza che quella> si paga) puoi imparare e metterti sul mondo del lavoro spendendo solo i> soldi per un PC, con windows no.Guarda che il costo per imparare a mettere su un server, parliamo di applicazioni aziendali, non è certo il S.O., ma i vari corsi per imparare a farlo e l'eventuale consulenza tecnica, nessuno nasce imparato e configurare correttamente un server o costa molto tempo, ammesso che uno sia già scafato, o costa molti soldi se uno non ha alcuna esperienza sull'argomento.> Se l'utente è una azienda allora paga quello che vuole perchè lo> ammortizza, ma un padre di famiglia o uno studente viene automaticamente> tagliato fuori dal sapere.Giusto diversifichiamo le due cose, mi spieghi perchè un padre di famiglia deve sapere configurare una rete aziendale con Win 2003 Server ? se lo fa solo per passione e sete di sapere in rete trovi tutti i manuali necessari, ti rammento che MSDN è liberamente consultabile online, inoltre ci sono un sacco di tutorial free che spiegano come fare.> E' un po come i prestiti, le banche li danno solo a chi ha già i soldi.Pura retorica, non è la stessa cosa.> Se Minchiasoft tagliasse soltanto la metà i prezzi, allora si che> sarebbe competitiva, ma preferisce imporsi in altri modi.Microsoft è una società a scopo di lucro che da lavoro a molte migliaia di persone sparse nel mondo, Bill Gates e Microsoft ogni anno donano molte decine di milioni di Dollari a scopo benifico, per non parlare delle borse di studio, se tutte le grandi aziende e i grandi ricchi facessero la stessa cosa sicuramente questo mondo andrebbe meglio.Con questo non voglio prendere parte a favore di MS, però sono obbiettivo e non mi schiero contro una persona o una società solo per partito preso, inoltre Windows come S.O. è anni luce avanti a Linux, non c'è storia in un confronto diretto, per non parlare delle applicazioni disponibili per Windows e che non esistono per Linux o che devono girare, con svariati problemi, tramite emulatori.Riconosco che Linux è ottimo come server web e di rete, quindi usato senza fronzoli e interfacce grafiche varie, ma come S.O. generico non regge il confronto.CiaoMarco d'Ambrosio

_________________________________________________________________
Sai cosa è successo oggi?
http://notizie.msn.it

[Sono state eliminare la parti non di testo del messaggio]

[Guido Ottaviani]

Post by Marco d'Ambrosio
inoltre Windows come S.O. è anni luce avanti a Linux, non c'è storia in un
confronto diretto, per non parlare delle applicazioni disponibili per
Windows e che non esistono per Linux o che devono girare, con svariati
problemi, tramite emulatori.
Riconosco che Linux è ottimo come server web e di rete, quindi usato senza
fronzoli e interfacce grafiche varie, ma come S.O. generico non regge il
confronto.

Su tutti gli altri discorsi sono abbastanza d'accordo o comunque disponibile ad un
confronto.
Sul fatto che Win sia il miglior sistema operativo invece, ho molto da obiettare.

Dipende ovviamente da cosa intendi, parlando di applicazioni disponibili hai sicuramente
ragione, lasciamo perdere il come e il perché zio Bill sia riuscito ad arrivare a questi
risultati, è così e basta, alla fine un Win (più o meno emulato) serve a tutti.

Non è assolutamente vero che Win sia più facile o che occorra meno tempo per gestirlo, è
solo che certe cose sono ormai date per scontate. Ormai è considerato normale perdere
una giornata ogni tanto per reinstallare tutto perché chissà quale applicazione ha rovinato
chissà quale registro e non funziona più niente. Oppure combattere ogni giorno con
montagne di virus, spyware e tutto quello che ci gira intorno, correndo appresso a tutti gli
aggiornamenti possibili.
Con Linux perdi sicuramente molto tempo per installarlo, ma poi te lo scordi, lo usi e
basta. C'è chi usa il computer in quanto tale, e quindi perde giornate su giornate ad
installare SW e pochissimo tempo a usare le applicazioni (e lo considera normale), e chi
invece non vuole problemi e vuole usare solo il suo programma di grafica o di office
automation.

Non è neanche vero che tutti sanno usare bene Win.
Nel mio ambiente di lavoro usiamo tutti gli OS, sia come client che come server (abbiamo
dismesso OS2 da poco). Più o meno tutti mettiamo le mani su tutto, ma abbiamo un solo
sistemista veramente esperto di Linux e un solo sistemista veramente esperto di Win, che
sanno mettere le mani su tutto e risolvere tutti i problemi, gli altri smanettano, anche
bene, ma davanti al vero problema o all'installazione complicata si fermano.

Fa parte del mio lavoro anche tenere conto delle risorse impegnate nei vari lavori, ti
assicuro che, pur essendo il numero dei client Mac superiore a quello dei client Win (e con
i Mac facciamo produzione), il reparto di assistenza perde molto più tempo a risolvere i
problemi Win.

Tutti considerano normale il fatto che le nostre macchine Win siano praticamente
inutilizzabili dalle 13 alle 14 perché parte l'antivirus centralizzato e impegna
completamente il PC, "ho una buona scusa per andare a pranzo".
Tutti considerano normale perdere ore per un defrag perché il disco non risponde più, o
meglio, comprare un disco più grande che si fa prima.
Sull'organizzazione del file system Linux non si batte, anche il Mac fa abbastanza schifo in
tal senso.

A tutti sembra più corta la strada che facciamo tutti i giorni per andare al lavoro mentre
una strada nuova sembra più lunga e difficile. E' comunque sempre questione di abitudine.
Però, volendo essere veramente obiettivi, e considerando tutto il tempo perso per
operazioni non strettamente legate all'utilizzo del computer, non credo proprio che Win
sia quello che fa perdere meno tempo.

E rispondo anche a Spad:

--- In roboteck-***@public.gmane.org, Spad 05 <***@...> ha scritto:
Per sempio senza adsl oggi praticamente non riesci a fare un passo (se sei un niubbo)
nell'uso di linux, se non conosci l'inglese idem...

Permettimi di sorridere alla tua affermazione: perché se non hai ADSL riesci a mantenere
aggiornato il tuo Win? Oppure Office? Oppure l'antivirus?

ciao
Guido

[Marco d'Ambrosio]

Post by Guido Ottaviani
Sul fatto che Win sia il miglior sistema operativo invece, ho molto da obiettare.

Io non ho detto che è il miglior sistema operativo, ho detto che rispetto a
Linux è migliore sia come affidabilità che prestazioni, salvo l'uso come
server dove Linux è ottimo, ma usato senza fronzoli vari.

Post by Guido Ottaviani
Dipende ovviamente da cosa intendi, parlando di applicazioni disponibili hai sicuramente
ragione, lasciamo perdere il come e il perché zio Bill sia riuscito ad arrivare a questi

Quando parlo di applicazioni non mi riferisco certo ai soli programmi
Microsoft, mi riferisco alla miriade di programmi realizzati da altre
società che esistono in ambiente windows.

Post by Guido Ottaviani
Non è assolutamente vero che Win sia più facile o che occorra meno tempo per gestirlo, è
solo che certe cose sono ormai date per scontate.

Verissimo, ma non è questo il punto, diciamo pure che i costi per imparare
ad usare Win o Linux sono equipollenti, però mettiamo pure nel calderone che
Windows viene dato in bundle con tutti i nuovi pc e incide sul costo meno di
50 Euro per Vista Premium, tutto sommato lo stesso costo di una buona distro
home per Linux.

Post by Guido Ottaviani
una giornata ogni tanto per reinstallare tutto perché chissà quale applicazione ha rovinato
chissà quale registro e non funziona più niente. Oppure combattere ogni giorno con
montagne di virus, spyware e tutto quello che ci gira intorno, correndo appresso a tutti gli
aggiornamenti possibili.

Pensi forse che anche Linux non ha gli stessi problemi ?
Li ha eccome, pure con lui se vengono fatti casini tocca reinstallarlo da 0,
pure lui ha i suoi virus e altre schifezze, unico vantaggio che sono in
numero notevolmente minore di quelli per Win ed è più difficile infettarsi,
ma la situazione è in evoluzione a sfavore di Linux.

Post by Guido Ottaviani
Con Linux perdi sicuramente molto tempo per installarlo, ma poi te lo scordi, lo usi e
basta. C'è chi usa il computer in quanto tale, e quindi perde giornate su giornate ad
installare SW e pochissimo tempo a usare le applicazioni (e lo considera normale), e chi
invece non vuole problemi e vuole usare solo il suo programma di grafica o di office
automation.

Anche con XP se usi solo i tuoi normali applicativi non succede nulla, io
non ho mai perso un dato o un file con XP a meno che non siano intervenuti
guasti dell'hard disk, adesso manco più quelli visto che lavoro in raid, o
supervirus con effetti devastanti, pure questi ormai sono quasi
completamente scomparsi, ora la tendenza è usare i pc infetti come server
per espandere l'infezione e creare supertraffico in rete con vari fini.

Post by Guido Ottaviani
Non è neanche vero che tutti sanno usare bene Win.

Assolutamente vero, infatti se ci fosse una maggiore conoscenza del S.O.
tanti problemi non esisterebbero, ma questo vale ancora di più per Linux
perchè è decisamente molto meno user friendly del suo antagonista.

Post by Guido Ottaviani
Fa parte del mio lavoro anche tenere conto delle risorse impegnate nei vari lavori, ti
assicuro che, pur essendo il numero dei client Mac superiore a quello dei client Win (e con
i Mac facciamo produzione), il reparto di assistenza perde molto più tempo a risolvere i
problemi Win.

Su questo non ho dubbi, sono il primo a dire che il S.O. della mela è
migliore di Windows.

Post by Guido Ottaviani
Tutti considerano normale il fatto che le nostre macchine Win siano praticamente
inutilizzabili dalle 13 alle 14 perché parte l'antivirus centralizzato e impegna
completamente il PC, "ho una buona scusa per andare a pranzo".

Questo non è certo un problema imputabile a Windows, purtroppo essendo
l'S.O. più diffuso al mondo è quello più bersagliato e dove si studia
maggiormente per trovare falle di sicurezza.

Post by Guido Ottaviani
Tutti considerano normale perdere ore per un defrag perché il disco non risponde più, o
meglio, comprare un disco più grande che si fa prima.

Questa sa tanto di leggenda metropolitana, un defrag fatto bene al massimo
porta via 15 minuti su un disco da 80 giga pieno zeppo, al massimo va fatto
una volta a settimana, io lo faccio una volta al mese e non noto nessuna
differenza tra prima e dopo, e sul mio pc di file che vanno e vengono ce ne
sono molti.

Post by Guido Ottaviani
Sull'organizzazione del file system Linux non si batte, anche il Mac fa abbastanza schifo in
tal senso.

Avrei qualcosina da ridire su questo punto, diciamo che sono alla pari che è
meglio.
.

Post by Guido Ottaviani
Però, volendo essere veramente obiettivi, e considerando tutto il tempo perso per
operazioni non strettamente legate all'utilizzo del computer, non credo proprio che Win
sia quello che fa perdere meno tempo.

Le cosidette operazioni che fanno perdere tempo sono molto soggetive e
comunque dipendono più da come si usa in modo corretto il S.O. che altro.
La verità è che normalmente l'utilizzatore di Linux è più evoluto di quello
Windows, ma in numero nettamente minore, questo porta a superare senza
grossi problemi le indubbie difficoltà di installazione e configurazione di
Linux e a farne un uso più oculato, il che porta a meno problemi, se lo
stesso utente usasse Windows si troverebbe ugualmente bene, a meno che non
ragioni per partito preso, ma questo è un altro paio di maniche.

Ciao

Marco d'Ambrosio

[domenico]

GRAZIE Guido!!! Io mi ficco sempre in queste discussioni idiote :-(

Qualcosa però vorrei ribattere, ma molto brevemente:

Window è dal punto di vista client più facile di Linux, ma vi ricordate
quando il S.O. a finestre era del Mac e e Minchiasoft aveva DOS 3.3 che
era considerato un S.O. serio mentre il Mac un giocattolo? Parlo degli
anni 80, poco dopo la sfida di IBM ad Apple. In quegli anni Bill fondò
il suo impero scrivendo DOS per IBM. Bill non era un idealista come Wozniak.

Bill regala un sacco di soldi tramite la sua fondazione e questo è
buono, ma è solo bontà ? Speriamo di si a parte il fatto che in un certo
periodo della nostra storia moderna c'è stato un "fiorire" di Fondazioni
nel mondo. Anche il nostro Ex ne ha una :)

Quanto riguarda il sapere, questo è come l'acqua, deve essere dato ad un
prezzo tale da essere accessibile a tutti (e ripeto, non sono un
noglobal, che mi stanno anche "lì sopra"). La conoscenza (tutta) serve
all'evoluzione dell'umanità, non serve a farsi fighetti di fronte agli
altri.
Tutti i miei ringraziamenti alle licenze GNU GPL e affini. Quanto alla
disponibilità di Linux non serve ADSL, basta un edicolante e 5 euro e
per configurarlo adesso fa tutto da solo. Se vuoi qualcosa in più allora
un po di sudore ce lo devi mettere ma lì puoi far uso di persone che ti
danno GRATIS la loro conoscenza per il piacere di farlo e di essere
utile (anche io lo faccio quando posso e la cosa mi appaga molto).

Quanto alla ricompilazione del kernel, al lavoro è la cosa che meno si
fa. Oggi come oggi devi proprio essere sfigato per avere la necessità di
farlo. Certo, non tutti i driver sono disponibili, ma è sempre questione
di tempo.

Perchè un padre di famiglia o uno studente deve avere accesso a basso
prezzo alla conoscenza? (linux, windows, ecc.)
Perchè ci sono padri di famiglia come me o neolaureati come alcuni miei
colleghi che devono tenere in piedi centinaia di server pieni di
centinaia di Terabyte di dati (e non sto esagerando) e quando
all'azienda gli chiedi un corso da qualche migliaia di euro neanche ti
rispondono. Peccato che se quel lavoro poi non lo sai fare ti
sostituiscono con un bel consulente da 300 euro al giorno... (rapporto
medio di costo 1:6).

Quanto a quale sia migliore come S.O. non discuto neanche. Basta
guardare le percentuali client/server per S.O. e la loro collocazione in
ambito industriale/office-casa. Quanto alla sicurezza quella fino alla
Fat32 non era certo appannaggio di Win. Adesso la cosa è un po
migliorata ma ciò non toglie che i buchi maggiori stanno ancora in casa
Micros... e non parlo di quantità di attacchi perchè quello dipende
anche dalle "guerre di religione".

Comunque, tanto per non dare impressioni sbagliate, sul mio PC c'è WinXp
e Linux Fedora5.

Con il primo (in bundle ma non per 35 euro) ci faccio girare qualche
programma free/GPL che gira solo sotto WIN e con il secondo ci faccio
tutto il resto (posta con un ottimo antispam/antiphishing,
programmazione PHP, bash, disegno tecnico, office di solaris, giochini,
ecc).

Il motivo di questo?
1) mi ero rotto gli zibidei di riformattare una volta l'anno.
2) perchè a volte anche gli aggiornamenti di Xp mi facevano crashare il
portatile!!!
3) perchè Linux desktop è diventato in tre anni molto più friendly di prima.
4) perchè se vuoi sviluppare applicazioni web devi avere una ottima
piattaforma e non emulatori tipo easyphp o simili. Con Linux lo spesso
PC è server e client e ripeto: GRATIS, cioè il prezzo del PC e 5 euro
della rivista con CD.
5) Poter acere accesso alla cultura mi permette di portare il pane a
casa facendo un lavoro abbastanza gradevole.

Mo' vado a famme er caffè e poi me aspetta fisica e matematica....

Ciao a tutti,
greybear <-- notare il nick!! :)

Post by Marco d'Ambrosio

Post by Marco d'Ambrosio
inoltre Windows come S.O. è anni luce avanti a Linux, non c'è storia

in un

Post by Marco d'Ambrosio
confronto diretto, per non parlare delle applicazioni disponibili per
Windows e che non esistono per Linux o che devono girare, con svariati
problemi, tramite emulatori.
Riconosco che Linux è ottimo come server web e di rete, quindi usato

senza

Post by Marco d'Ambrosio
fronzoli e interfacce grafiche varie, ma come S.O. generico non

regge il

Post by Marco d'Ambrosio
confronto.

Su tutti gli altri discorsi sono abbastanza d'accordo o comunque disponibile ad un
confronto.
Sul fatto che Win sia il miglior sistema operativo invece, ho molto da obiettare.
Dipende ovviamente da cosa intendi, parlando di applicazioni
disponibili hai sicuramente
ragione, lasciamo perdere il come e il perché zio Bill sia riuscito ad arrivare a questi
risultati, è così e basta, alla fine un Win (più o meno emulato) serve a tutti.
Non è assolutamente vero che Win sia più facile o che occorra meno tempo per gestirlo, è
solo che certe cose sono ormai date per scontate. Ormai è considerato normale perdere
una giornata ogni tanto per reinstallare tutto perché chissà quale
applicazione ha rovinato
chissà quale registro e non funziona più niente. Oppure combattere ogni giorno con
montagne di virus, spyware e tutto quello che ci gira intorno,
correndo appresso a tutti gli
aggiornamenti possibili.
Con Linux perdi sicuramente molto tempo per installarlo, ma poi te lo scordi, lo usi e
basta. C'è chi usa il computer in quanto tale, e quindi perde giornate su giornate ad
installare SW e pochissimo tempo a usare le applicazioni (e lo
considera normale), e chi
invece non vuole problemi e vuole usare solo il suo programma di grafica o di office
automation.
Non è neanche vero che tutti sanno usare bene Win.
Nel mio ambiente di lavoro usiamo tutti gli OS, sia come client che come server (abbiamo
dismesso OS2 da poco). Più o meno tutti mettiamo le mani su tutto, ma abbiamo un solo
sistemista veramente esperto di Linux e un solo sistemista veramente esperto di Win, che
sanno mettere le mani su tutto e risolvere tutti i problemi, gli altri smanettano, anche
bene, ma davanti al vero problema o all'installazione complicata si fermano.
Fa parte del mio lavoro anche tenere conto delle risorse impegnate nei vari lavori, ti
assicuro che, pur essendo il numero dei client Mac superiore a quello dei client Win (e con
i Mac facciamo produzione), il reparto di assistenza perde molto più tempo a risolvere i
problemi Win.
Tutti considerano normale il fatto che le nostre macchine Win siano praticamente
inutilizzabili dalle 13 alle 14 perché parte l'antivirus centralizzato e impegna
completamente il PC, "ho una buona scusa per andare a pranzo".
Tutti considerano normale perdere ore per un defrag perché il disco non risponde più, o
meglio, comprare un disco più grande che si fa prima.
Sull'organizzazione del file system Linux non si batte, anche il Mac
fa abbastanza schifo in
tal senso.
A tutti sembra più corta la strada che facciamo tutti i giorni per andare al lavoro mentre
una strada nuova sembra più lunga e difficile. E' comunque sempre questione di abitudine.
Però, volendo essere veramente obiettivi, e considerando tutto il tempo perso per
operazioni non strettamente legate all'utilizzo del computer, non credo proprio che Win
sia quello che fa perdere meno tempo.
Per sempio senza adsl oggi praticamente non riesci a fare un passo (se sei un niubbo)
nell'uso di linux, se non conosci l'inglese idem...
Permettimi di sorridere alla tua affermazione: perché se non hai ADSL riesci a mantenere
aggiornato il tuo Win? Oppure Office? Oppure l'antivirus?
ciao
Guido

[domenico]

Post by domenico
GRAZIE Guido!!! Io mi ficco sempre in queste discussioni idiote :-(

A scanso di equivoci, le ho catalogate in maniera molto forte
"discussioni idiote" per tre motivi:

1) perchè ognuno (io incluso) parla per la propria esperienza.
2) perchè alcuni la potrebbero far diventare una guerra di religione.
3) perchè altri potrebbero essere scambiati per crociati alla guerra pur
non essendolo.

La prossima volta questa discussione la facciamo "dal cinese" davanti a
una "flesca billa" :)

greybear

[Marco d'Ambrosio]

Post by domenico
A scanso di equivoci, le ho catalogate in maniera molto forte
1) perchè ognuno (io incluso) parla per la propria esperienza.

Verissimo

Post by domenico
2) perchè alcuni la potrebbero far diventare una guerra di religione.

Purtroppo si, non tutti sono "illuminati" come noi che alla fine anche se ci
"azzuffiamo" virtualmente per un banale S.O. poi ci vediamo al classico bar,
quello vero, e tutto finisce con i proverbiali "tarallucci e vino" più amici
di prima.

Post by domenico
3) perchè altri potrebbero essere scambiati per crociati alla guerra pur
non essendolo.

Questo è anche peggio

Post by domenico
La prossima volta questa discussione la facciamo "dal cinese" davanti a
una "flesca billa" :)

Ottimo, pure con una megaporzione di "liso alla cantonese" e le discussioni
sui rapporti tra asse z e y che tanto piacciono a Bobbo :-)

Ciao

Marco d'Ambrosio

[stefano664 - Roboteck]

Beh, direi che le persone evolute si vedono da un fatto... dieci
messaggi sui SO e la guerra di religione è chiusa in pace (ragazzi vengo
anche io per tarallucci e vino). In qualsiasi ML di informatica si
sarebbe aperto un flame di centinaia di utenti, con migliaia di messaggi
e quattro giorni... e senza neppure un cinese.
Credo che il significato di questo sia che troppo spesso il problema
viene affrontato sul campo sbagliato. Qui, per fortuna, si ha combattuto
su quello giusto. Perciò ringraziamo Win con i sui difetti, Linux con i
suoi pregi, Mac con la sua storia di "giocattolo", e a ciascuno il suo!
Ricordiamoci che Win ha tanti difetti perchè è stato il primo, e Lin ha
tanti pregi perchè è l'emergente...
Buon SO a tutti!


--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Logos Finanziaria SPA. Società di credito ad erogazione diretta. Fino a 30.000 euro in 24 ore! Clicca e scopri come
*
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2909&d=13-8

[domenico]

Non farti impressioni sbagliate, l'ultima volta a cena abbiamo tentato
di trafiggerci con i bastoncini ed avvelenarci con il sakè ma senza
risultato :D

grey

P.S. giusto una correzione.... Win non è stato il primo, prima di lui
c'era Lisa son il S.O a finestre della Xerox e costava quasi trenta anni
fa 12.000.000 di lire. Il secondo è stato il Mac (non contiamo Apple][ e
Apple/// ) ed il terzo Win, ma poi la prepotenza dei mercati
pubblicitari ha di fatto nascosto i pionieri. Quanto a Linux è emergente
perchè gratuitamente tutto il mondo sviluppa per lui e gratuitamente
viene distribuito. Chi ha bisogno della pappa pronta invece paga ma se
li rifà alla grande ;-)
Inoltre pensa al risparmio sulla spesa pubblica se lo stato usasse Linux
invece di "chi sai tu". C'è qualche comune del nordest che lo ha fatto e
documentato in TV ed ha risparmiato cifre da lotteria di capodanno.

Se questo succedesse, i deputati potrebbero aumentarsi lo stipendio del
100% senza gravare sul debito pubblico.
Meno male che non lo sanno :D

Post by stefano664 - Roboteck
Beh, direi che le persone evolute si vedono da un fatto... dieci
messaggi sui SO e la guerra di religione è chiusa in pace (ragazzi vengo
anche io per tarallucci e vino). In qualsiasi ML di informatica si
sarebbe aperto un flame di centinaia di utenti, con migliaia di messaggi
e quattro giorni... e senza neppure un cinese.
Credo che il significato di questo sia che troppo spesso il problema
viene affrontato sul campo sbagliato. Qui, per fortuna, si ha combattuto
su quello giusto. Perciò ringraziamo Win con i sui difetti, Linux con i
suoi pregi, Mac con la sua storia di "giocattolo", e a ciascuno il suo!
Ricordiamoci che Win ha tanti difetti perchè è stato il primo, e Lin ha
tanti pregi perchè è l'emergente...
Buon SO a tutti

[stefano664 - Roboteck]

Post by domenico
Se questo succedesse, i deputati potrebbero aumentarsi lo stipendio del
100% senza gravare sul debito pubblico.
Meno male che non lo sanno :D

Quoto, l'ha fatto anche il parlamento (camera o senato, non ricordo) risparmiando (ipotesi sul prossimo anno) un bel po' di soldi in licenze!!




--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Prestiti: con Prometeo fino a 30.000 Euro, senza spese e senza attese! Richiedi subito l’importo e la rata che desideri, basta un clic!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6914&d=13-8

[Marco d'Ambrosio]

Post by domenico
Non farti impressioni sbagliate, l'ultima volta a cena abbiamo tentato
di trafiggerci con i bastoncini ed avvelenarci con il sakè ma senza
risultato :D

Peccato che mancava il sushi fatto con il pesce palla :-)

Post by domenico
P.S. giusto una correzione.... Win non è stato il primo, prima di lui
c'era Lisa son il S.O a finestre della Xerox e costava quasi trenta anni
fa 12.000.000 di lire.

Non solo ma anche il mouse non è un'invenzione di Apple come molti pensano,
anche lui è nato in Xerox..
Io ho usato pure Lisa ed è un peccato che non abbia preso piede.

Post by domenico
Il secondo è stato il Mac (non contiamo Apple][ e
Apple/// ) ed il terzo Win, ma poi la prepotenza dei mercati

Sbagliato prima di Windows c'è stato pure. l'Amiga di Commodore che aveva un
S.O. grafico a icone, poi è arrivato OS2, però già c'era il primo Win 2.11
con intefaccia grafica, per ultimo il primo vero windows utilizzabile sul
serio, la versione 3.11 con supporto di rete che ho ancora buttata da
qualche parte sui cd di backup più vecchi, a dire il vero conservo ancora
anche il DOS 6.21, non si sa mai :-)

Post by domenico
Inoltre pensa al risparmio sulla spesa pubblica se lo stato usasse Linux
invece di "chi sai tu". C'è qualche comune del nordest che lo ha fatto e
documentato in TV ed ha risparmiato cifre da lotteria di capodanno.

Il costo maggiore è addestare il personale, se usi Win molto probabilmente i
tuoi dipendenti sanno già usarlo, quindi il costo si abbassa, se metti Linux
servono corsi e consulenti, non mi dire che non è vero perchè negli anni
passati ho guadagnato molti soldini facendo consulenze e
installazioni/assistenza per sistemi Linux.
Linux è un sistema operativo che conosco molto bene, del quale so
perfettamente pregi e difetti visto che lo uso come server di rete fin da
quando era solo un S.O. per gli addetti ai lavori, esclusivamente con
interfaccia a riga di comando e molto rognoso da installare e far
funzionare.
Morale della favola non è detto che risparmiare qualche migliaio di Euro per
le licenze Win sia sempre un buon affare, tocca valutare bene le cose, in
certe realtà può essere una cosa positiva passare a Linux in altre realtà
molto negativa e con costi indotti di gran lunga maggiori di quelli dovuti
alle licenze Windows.

Ciao

Marco d'Ambrosio

[Guido Ottaviani]

E no... avevo deciso di non intervenire più in questo thread ma qui viene ritirato in ballo un
discorso che conosco molto bene e che vivo tutti i giorni.

Hai presente quanti consulenti ci paghi con un centinaio di licenze Win + Office,
e un Win server con Active Directory (licenze) + licenze di antivirus?
Diciamo un valore molto vicino ai 100.000euro?

E questo solo per far scrivere qualche lettera ad un po' di impiegati.
Il 95% degli utenti amministrativi usa il PC solo per l'e-mail, il browsing di internet,
scrivere o leggere documenti, qualche foglio elettronico, qualche presentazione.

Non so quanto costi tu ma, anche non avendo in casa un sistemista, quanto vuoi che
costerebbe farsi configurare da qualcuno una installazione Linux con OpenOffice?

Senza fare troppi conti, vogliamo esagerare e diciamo 5.000 euro?
Parliamo di 95.000euro di risparmio.

Replicare l'iimmagine dell'istallazione su tutte la macchine sarebbe un'operazione alla
portata di un tecnico anche non particolarmente skillato.

Il corso per gli utenti (comunque sempre necessario quando introduci nuove tecnologie, se
non altro per ragioni sindacali) sarebbe solo quello di dirgli "fai doppio click su questa
icona per lanciare il programma", non devono conoscere il S.O. per andare a configurare i
driver di sistema.

Moltiplicato per tutti gli uffici italiani sarebbe un risparmio enorme.

ciao
Guido

P.S.
Tanto per aumentare le variabili, il S.O. negli iMac è compreso nel prezzo di acquisto e
comprende Apple Works (più che sufficiente per le operazioni di office automation).
Per avere un numero di licenze illimitate su un Mac server ci vogliono circa 1.000 euro e
comprende Open Directory (equivalente di Active Directory) mail server, web server, video
stream server ed un sacco di altri servizi gratuiti (vengono tutti da Unix).
Tenendo conto anche dei soldi risparmiati per l'antivirus e della facilità di installazione
paragonabile a quella di Win (se non maggiore), il risparmio totale è enorme.

ariciao

Post by Marco d'Ambrosio

Post by domenico
Inoltre pensa al risparmio sulla spesa pubblica se lo stato usasse Linux
invece di "chi sai tu". C'è qualche comune del nordest che lo ha fatto e
documentato in TV ed ha risparmiato cifre da lotteria di capodanno.

Il costo maggiore è addestare il personale, se usi Win molto probabilmente i
tuoi dipendenti sanno già usarlo, quindi il costo si abbassa, se metti Linux
servono corsi e consulenti, non mi dire che non è vero perchè negli anni
passati ho guadagnato molti soldini facendo consulenze e
installazioni/assistenza per sistemi Linux.
Linux è un sistema operativo che conosco molto bene, del quale so
perfettamente pregi e difetti visto che lo uso come server di rete fin da
quando era solo un S.O. per gli addetti ai lavori, esclusivamente con
interfaccia a riga di comando e molto rognoso da installare e far
funzionare.
Morale della favola non è detto che risparmiare qualche migliaio di Euro per
le licenze Win sia sempre un buon affare, tocca valutare bene le cose, in
certe realtà può essere una cosa positiva passare a Linux in altre realtà
molto negativa e con costi indotti di gran lunga maggiori di quelli dovuti
alle licenze Windows.
Ciao
Marco d'Ambrosio

[domenico]

Post by Guido Ottaviani
Senza fare troppi conti, vogliamo esagerare e diciamo 5.000 euro?

Eh? Qualcuno mi ha cercato? Sono qui.... Eccomi... Dove siete?

[Marco d'Ambrosio]

Post by Guido Ottaviani
Hai presente quanti consulenti ci paghi con un centinaio di licenze Win + Office,
e un Win server con Active Directory (licenze) + licenze di antivirus?
Diciamo un valore molto vicino ai 100.000euro?

Nulla ti vieta di usare open office anche con Windows, quando compri un
nuovo pc assieme hai la licenza di Windows in bundle per meno di 50 Euro, o
comunque è il costo medio per una licenza client per le versioni server di
Windows, più o meno la stessa cosa che succede con il MAC, sul quale paghi
la licenza d'uso del S.O. e paghi pure i programmi visto che di software
free in quel mondo non ne gira molto.

Post by Guido Ottaviani
Non so quanto costi tu ma, anche non avendo in casa un sistemista, quanto vuoi che
costerebbe farsi configurare da qualcuno una installazione Linux con OpenOffice?
enza fare troppi conti, vogliamo esagerare e diciamo 5.000 euro?

La prossima volta che devi configurare una postazione Linux chiamami subito,
per 5000 Euro ti offro pure il pranzo al meglio ristorante di Roma :-)


Ciao

Marco d'Ambrosio

[nonno_nino]

Posso fare il furbo?

Post by Guido Ottaviani
E no... avevo deciso di non intervenire più in questo thread ma qui

viene ritirato in ballo un

Post by Guido Ottaviani
discorso che conosco molto bene e che vivo tutti i giorni.
Hai presente quanti consulenti ci paghi con un centinaio di licenze Win + Office,
e un Win server con Active Directory (licenze) + licenze di antivirus?
Diciamo un valore molto vicino ai 100.000euro?

Questo è uno dei motivi perchè Win è migliore del Mac ..... non va a
capo quando decide lui ma quando lo decidiamo noi .....

Ciao ..... si scherza ovviamente ....

Nonno

[Guido Ottaviani]

E il bello è che io vedo tutto bene e non so poi quando va a capo.

ciao
Guido

Post by nonno_nino
Questo è uno dei motivi perchè Win è migliore del Mac ..... non va a
capo quando decide lui ma quando lo decidiamo noi .....
Ciao ..... si scherza ovviamente ....
Nonno

[nonno_nino]

Sono stato davvero un pò "bastardo" .... mi sono ricordato del tuo
treath in cui parlavi di questo problema e non ho saputo resistere
nel fare la battuta. Ovviamente sono cose che possono succedere a
tutti e con tutti i sistemi operativi.

Ciao Nonno

Post by Guido Ottaviani
E il bello è che io vedo tutto bene e non so poi quando va a capo.
ciao
Guido

Post by nonno_nino
Questo è uno dei motivi perchè Win è migliore del Mac ..... non va a
capo quando decide lui ma quando lo decidiamo noi .....
Ciao ..... si scherza ovviamente ....
Nonno

[domenico]

Se non erro va a capo quando passa per la mailing list :)
I sistemi operativi non c'entrano niente, a me lo fa sia con linux sia
con win...

Ciao,
grey

Post by Guido Ottaviani
E il bello è che io vedo tutto bene e non so poi quando va a capo.
ciao
Guido

Post by nonno_nino
Questo è uno dei motivi perchè Win è migliore del Mac ..... non va a
capo quando decide lui ma quando lo decidiamo noi .....
Ciao ..... si scherza ovviamente ....
Nonno

[domenico]

Questo pomeriggio hanno fatto vedere al telegiornale un nuovo mouse della logitech
che non ha bisogno di essere appoggiato per funzionare ma va mosso nello
spazio. Suppongo che possa avere degli accelerometri...



Adesso costa solo 149 euro ma nel prossimo futuro....



grey

[Marco d'Ambrosio]

Post by domenico
Questo pomeriggio hanno fatto vedere al telegiornale un nuovo mouse della logitech
che non ha bisogno di essere appoggiato per funzionare ma va mosso nello
spazio. Suppongo che possa avere degli accelerometri...

Sicuramente col tempo il suo prezzo calerà, ma non certo a cinque Euro,
comunque dalla presentazione non è molto chiaro come funziona quando è
sollevato.

Ciao

Marco d'Ambrosio

[Marco F.]

Post by Marco d'Ambrosio
Sicuramente col tempo il suo prezzo calerà, ma non certo a cinque Euro,
comunque dalla presentazione non è molto chiaro come funziona quando è
sollevato.

Tecnologia Wii? :)

[domenico]

Senza entrare in polemica, :) io ci spero.
Ti ricordi i mouse a pallina da 70.000 lire di una volta?

ciao,
grey

Post by Marco d'Ambrosio

Post by domenico
Questo pomeriggio hanno fatto vedere al telegiornale un nuovo mouse della logitech
che non ha bisogno di essere appoggiato per funzionare ma va mosso nello
spazio. Suppongo che possa avere degli accelerometri...

Sicuramente col tempo il suo prezzo calerà, ma non certo a cinque Euro,
comunque dalla presentazione non è molto chiaro come funziona quando è
sollevato.
Ciao
Marco d'Ambrosio

[Marco d'Ambrosio]

Post by domenico
Senza entrare in polemica, :) io ci spero.
Ti ricordi i mouse a pallina da 70.000 lire di una volta?

Certo che li ricordo, come mi ricordo pure i primissimi mouse ottici, quelli
con la tavoletta a metallica a griglia, che costavano 400000 lire, lire dei
fine anni 80.
Però il caso è diverso, la tecnologia usata nel Logitech MX Air è già
consolidata e costosa di suo, cercando in rete ho trovato qualche info, usa
un mix di giroscopio e accelerometro a tre assi, la precisione non è nemmeno
lontanamente paragonabile a quella del WII, lo surclassa alla grande, su you
tube ci sono diversi filmati che testimoniano la precisione nel detect dei
movimenti.
Comunque un accelerometro a tre assi con caratteristiche superiori a quello
del modello usato in quel Mouse è il LIS3LV02DQ di ST, disponibile da
Farnell a 15 Euro + iva, ho appena finito un lavoro dove li ho impiegati e
sono veramente eccezionali come caratteristiche tecniche, solo per citarne
una hanno una banda effettiva, già prefiltrata, di 2560 Hz, uscita dati su
interfaccia SPI e I2C, fino a 16 bit di risoluzione, fondo scala
selezionabile via software compreso tra +/- 2G e +/- 6G, unico neo è il case
che non è dei più simpatici da saldare, anzi è impossibile senza una
stazione ad aria, pasta saldante (si trova da RS) e un pcb con solder, come
alternativa saldatura in forno.

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

http://www.roboteck.org/Twister.wmv

Nuovo test sulla motion controller di Gino, ho corretto i valori di
conversione tra ppr e mm reali e sto facendo un po di prove per verificare
sia la precisione che le prestazioni.
Questo test è interessante perchè mette sotto stress il pid controller, il
robot viene fatto girare su se stesso per 720° alla velocità di 50 cm/s,
prima avantie poi indietro, in questo caso entrano in gioco anche la massa e
i problemi per l'arresto della stessa, da notare come alla fine del secondo
giro di ritorno l'anello di controllo posizione del pid interviene e
corregge di qualche mm la posizione di arresto per riportare il robot alla
posizione iniziale.

Marco d'Ambrosio

[Guido Ottaviani]

Se sai cosa ti serve e conosci pregi e difetti di ognuno sei a posto. Quello che bisognerebbe

evitare sono le prese di posizione ideologiche, e fortunatamente il mercato tutte entrambe le
possibilita' (mettiamoci dentro anche OSX)
Su questo mi trovi perfettamente d'accordo!

ciao
Guido

[Spad 05]

Certo che no.... ma avevamo gia' appurato che windows costa :)

Comunque a scanso di equivoci voglio ribadire che uso entrambi i sistemi, ma per cose diverse e al di la' dei pregi e dei difetti che hanno, entrambi costano (in modo diverso).

In genere windows deve fare ancora molta strada per avere l'affidabilita' e le prestazioni di linux in campo server (sopratutto web) e linux ne ha da fare molta per essere un desktop alla portata di tutti.

Se sai cosa ti serve e conosci pregi e difetti di ognuno sei a posto. Quello che bisognerebbe evitare sono le prese di posizione ideologiche, e fortunatamente il mercato tutte entrambe le possibilita' (mettiamoci dentro anche OSX)

Per sempio senza adsl oggi praticamente non riesci a fare un passo (se sei un niubbo) nell'uso di linux, se non conosci l'inglese idem... Permettimi di sorridere alla tua affermazione: perché se non hai ADSL riesci a mantenere aggiornato il tuo Win? Oppure Office? Oppure l'antivirus?ciaoGuido

Attività recenti


1
Nuovi iscritti

2
Nuovi FileVisita il tuo gruppo


Mio Yahoo!
Passa a Mio Yahoo!
Tutti i tuoi feed
in una sola pagina

Yahoo! Gruppi
Crea un gruppo
In sole tre mosse
E condividilo!

Y! Toolbar
Scaricala gratis
Accedi ai Gruppi
in una sola mossa
.


_________________________________________________________________
Crea il tuo gadget e vinci 10 Windows Vista e 30€ di musica!
http://concorsogadget.it.msn.com/

[Sono state eliminare la parti non di testo del messaggio]

[Spad 05]

Stai parlando di aziende grandi in cui la postazione di lavoro e' quasi sempre blindata e il lavoro fortemente specializzato. In quest situazioni non e' difficile trovare per esempio windows blindato dove l'utente non puo' fare niente.

In questi ambiti hai ragione, l'utente non usa tanto un pc quanto un appliance su cui gira il word processor (un po come fanno molti grafici col mac ;) ).
Nella stragrande maggioranza degli uffici, dove ci sono 10 max 15 persone e la flessibilita' richiesta e' piuttosto alta, il tuo ragionamento ha qualche crepa.







Hai presente quanti consulenti ci paghi con un centinaio di licenze Win + Office,e un Win server con Active Directory (licenze) + licenze di antivirus?Diciamo un valore molto vicino ai 100.000euro?


Attività recenti


2
Nuovi iscritti

3
Nuove foto

2
Nuovi FileVisita il tuo gruppo


Mio Yahoo!
Passa a Mio Yahoo!
Tutti i tuoi feed
in una sola pagina

Yahoo! Gruppi
Crea un gruppo
In sole tre mosse
E condividilo!

Y! Toolbar
Scaricala gratis
Accedi ai Gruppi
in una sola mossa
.


_________________________________________________________________
Crea il tuo gadget e vinci 10 Windows Vista e 30€ di musica!
http://concorsogadget.it.msn.com/

[Sono state eliminare la parti non di testo del messaggio]

[Marco d'Ambrosio]

Post by Spad 05
Stai parlando di aziende grandi in cui la postazione di lavoro e' quasi
sempre blindata e il lavoro fortemente specializzato. In quest >situazioni
non e' difficile trovare per esempio windows blindato dove l'utente non
puo' fare niente.

Vero, però Guido giustamente ragiona con la sua realtà ed esperienza
lavorativa, da lui i pc sono proprio tanti.
Io invece ragiono sulla base di piccola e media impresa, ma ho anche
esperienza con grandi enti dove si ragiona con le wan piuttosto che le lan,
in questi ambiti si mette un server Linux, se non addirittura Unix, e si
usano client Windows.

Post by Spad 05
Nella stragrande maggioranza degli uffici, dove ci sono 10 max 15 persone e
la flessibilita' richiesta e' piuttosto alta, il tuo ragionamento ha

Post by Spad 05
qualche crepa.

Infatti il grosso dei pc non è certo nei grandi enti/aziende, ma ben
distribuito nelle piccole imprese dove si hanno realtà di piccole reti,
pochi pc, e semplici server, dove si fa tutto senza problemi con le normali
versioni in bundle di XP, quindi un costo 0 di S.O. visto che sono già in
dotazione alle macchine, senza dover ricorrere a versioni server con il
relativo aggravio di costo.
Se poi occorre tirare su un server degno di questo nome allora si prende
Linux, se non hai una persona che è capace di configuralo chiami un
consulente esterno che in poche ore, al massimo un paio di giorni se la rete
è complessa, e con meno di 1000 Euro, nel peggiore dei casi, hai risolto il
problema.

Ciao

Marco d'Ambrosio

[Guido Ottaviani]

Post by Spad 05
Stai parlando di aziende grandi in cui la postazione di lavoro e' quasi sempre blindata e

il lavoro fortemente specializzato. In quest situazioni non e' difficile trovare per esempio
windows blindato dove l'utente non puo' fare niente.

Sbaglio o questo sottothread nel thread era partito dalla risposta di Domenico riguardante

Post by Spad 05
Inoltre pensa al risparmio sulla spesa pubblica se lo stato usasse Linux
invece di "chi sai tu". C'è qualche comune del nordest che lo ha fatto e
documentato in TV ed ha risparmiato cifre da lotteria di capodanno.

questi casi rientrano abbastanza bene nella mia ipotesi.

Non stiamo parlando di piccola impresa, per la media (se i costi sono quelli che dice
Marco) già c'è la convenienza.

Comunque, Marco, ho detto che esageravo, stai tranquillo, 5.000 euro non li diamo ne a te
ne a Domenico :-)

Comunque ora smetto sul serio, senza fare conti esatti in situazioni reali rischiamo di
rientrare proprio in quella guerra di religione che volevamo evitare.

ciao
Guido

P.S.
Per quanto riguarda il SW freeware o shareware su Mac, ti assicuro che ce n'è molto e poi,
essendo Unix, molti SW per Linux si trovano già ricompilati o da ricompilare.

[Marco d'Ambrosio]

Post by Guido Ottaviani
Comunque, Marco, ho detto che esageravo, stai tranquillo, 5.000 euro non li diamo ne a te

Te pareva, mi stavo già facendo i conti per comprarmi Luna rossa :-)

Post by Guido Ottaviani
Comunque ora smetto sul serio, senza fare conti esatti in situazioni reali rischiamo di
rientrare proprio in quella guerra di religione che volevamo evitare.

Vero, anche perchè siamo andati molto OT e stiamo parlando di un argomento
molto complesso che non può essere trattato con la dovuta profondità in una
mail list.

Post by Guido Ottaviani
P.S.
Per quanto riguarda il SW freeware o shareware su Mac, ti assicuro che ce n'è molto e poi,
essendo Unix, molti SW per Linux si trovano già ricompilati o da ricompilare.

Buono a sapersi.

Ciao

Marco d'Ambrosio

[Spad 05]

Queste sono le cose che mi fanno apprezzare l'aver speso i 35 euro per il PK2 :)

Sono pero' un po' confuso.... nella device debug list sono riportati alcuni modelli con l'*. Nella nota si rimanda ad un documento che e' specifico per l'ICD2 e non PK2.

Questi modelli continuano quindi a non essere supportati? In questo momento mi interesserebbe molto il 16F690, che guarda caso e' proprio tra questi.


To: roboteck-hHKSG33Tihig7M29m/***@public.gmane.org: m.dambrosio-***@public.gmane.org: Thu, 16 Aug 2007 10:23:57 +0200Subject: [roboteck] MPLAB 7.62




Sul sito di Microchip sono disponibili vari aggiornamenti, sia per i compilatori che per MPLAB, in particolare per quest'ultimo sono state aggiunte alcune nuove funzionalità, un migliorato supporto per il Real Ice e ICD2, pieno supporto anche per tutti i nuovi modelli di micro, più che altro per le serie 24 e 33.Da notare che con questa versione di MPLAB viene notevolmente esteso il supporto diretto del PK2 (scaricare anche il nuovo firmware), esattamente come avevo previsto qualche mese fa.Ora potete usare il PK2 direttamente da MPLAB, sia come programmatore che debugger, per moltissimi modelli di pic serie 16 e 18, in pratica tutti quelli che normalmente usiamo, anche se per moltissimi il supporto è ancora definito come beta, led giallo nella finestra di selezione mcu, non dovrebbero essere particolari problemi come programmatore, ma potrebbero essere delle restrizioni come debugger.Attenzione che per usare come debugger i PK2 più vecchi, quelli col pulsante nero quelli più recenti l'hanno rosso, è necessario aggiungere due resistenze di pull down da 4.7k alle linee PGC e PGD, volendo è possibile installarle direttamente dentro il PK2 se le trovate in formato da 1/8 di watt o meglio SMD, trovate tutti i dettagli nel readme relativo al PK2 di MPLAB.CiaoMarco d'Ambrosio


_________________________________________________________________
Sai cosa è successo oggi?
http://notizie.msn.it

[Sono state eliminare la parti non di testo del messaggio]

[Marco d'Ambrosio]

Post by Spad 05
Queste sono le cose che mi fanno apprezzare l'aver speso i 35 euro per il PK2 :)

Io l'ho comprato appena uscito, lo scopo primario era metterlo nella borsa
del notebook in modo da avere sempre con me un valido programmatore di pic.
Poi usandolo mi sono reso conto delle sue potenzialità, ora lo uso spesso in
simultanea con l'ICD2 o il REAL ICE (grandissimo tool) quando devo lavorare
su più micro conteporaneamente.

Post by Spad 05
Sono pero' un po' confuso.... nella device debug list sono riportati alcuni
modelli con l'*. Nella nota si rimanda ad un documento che e' >specifico
per l'ICD2 e non PK2.

I modelli con l'* sono quelli che per programmazione ICSP e il debug possono
richiedere uno speciale adattatore, ne avevamo già parlato in passato di
questa cosa, per alcumi modelli è obbligatorio l'uso dell'adattore per altri
dipende da come vengono usati.

Post by Spad 05
Questi modelli continuano quindi a non essere supportati? In questo momento
mi interesserebbe molto il 16F690, che guarda caso e' >proprio tra questi.

Sono supportati però può essere necessario usare l'adattore, personalmente
ti sconsiglio caldamente l'uso del 16F690, anzi di tutta la serie 16 in
generale, usa solo la serie 18 tanto hai modelli direttamente equivalenti
come periferiche e pin out a quelli della serie 16, questo solo se hai
progettato lo schema su uno specifico modello.
In particolare come general purpose ti conviene usare il 18F2520 a 28 pin o
il 18F4520 a 40 pin, facilmente reperibili e con un costo contenuto, per un
20 pin risulta ottimo il 18F1320.

Ciao

Marco d'Ambrosio

[Spad 05]

Nello specifico c'era il fattore cassetto e il fatto che mi faceva comodo un 20pin per via delle dimensioni. L'altro pic sulla scheda e' un 18F2520.

Col senno di poi..... avrei anche potuto usare un solo dsPIC30F4012 (anche quello nel cassetto) ma al tempo non avevo come programmarlo :)
In piu' mi sarei risparmiato I2C slave sul 16F ..... dal quale non so se ne cavo le gambe ;)







personalmente ti sconsiglio caldamente l'uso del 16F690, anzi di tutta la serie 16 in generale, usa solo la serie 18 tanto hai modelli direttamente equivalenti come periferiche e pin out a quelli della serie 16, questo solo se hai progettato lo schema su uno specifico modello.In particolare come general purpose ti conviene usare il 18F2520 a 28 pin o il 18F4520 a 40 pin, facilmente reperibili e con un costo contenuto, per un 20 pin risulta ottimo il 18F1320.


Attività recenti


2
Nuovi iscritti

3
Nuove foto

1
Nuovi FileVisita il tuo gruppo


Mio Yahoo!
Passa a Mio Yahoo!
Tutti i tuoi feed
in una sola pagina

Yahoo! Gruppi
Crea un gruppo
In sole tre mosse
E condividilo!

Y! Toolbar
Scaricala gratis
Accedi ai Gruppi
in una sola mossa
.


_________________________________________________________________
Sai cosa è successo oggi?
http://notizie.msn.it

[Sono state eliminare la parti non di testo del messaggio]

[nonno_nino]

Post by Spad 05
In piu' mi sarei risparmiato I2C slave sul 16F ..... dal quale non so se ne cavo le gambe ;)

Se non lo hai fatto scaricati i seguenti doc di Microchip:

00734a.pdf slave mode con SSP in assembler
00554c.pdf slave + master in software (usa pin rb0 per individuare
inizio rx) in assembler
00736a.pdf slave + master con SSP in C

Poi puoi anche scaricarti questi altri .... meno importanti per te ma
sempre utili in libreria.

00690a.pdf
00735a.pdf

I doc sono nominati come ANxxx non so se conviene cercarli così.

Ciao Nonno

Però alla prima occasione mi fai fare un giro sul ragno .....

[Marco d'Ambrosio]

Post by nonno_nino
00734a.pdf slave mode con SSP in assembler
00554c.pdf slave + master in software (usa pin rb0 per individuare
inizio rx) in assembler
00736a.pdf slave + master con SSP in C

Molto generiche e relativamente utili, sopratutto quando si lavora con la
modalità slave.
In tutti i casi il vero problema non è far funzionare le periferiche I2C dei
pic, che vanno benissimo, ma capire come funziona il protocollo I2C e
scrivere le necessarie funzioni per gestirlo.
Questo perchè le periferiche si limitano a ricevere/trasmettere un byte di
dati e fornire tutta una serie di informazioni relative allo stato della
linea e dei dati ricevuti, ma è compito del programma leggere i giusti flag
e gestire le possibili risposte agli eventi, i vari ACK, NACK etc.

Ciao

Marco d'Ambrosio

[nonno_nino]

Proprio per questa difficoltà proponevo di usare una seriale
software, in cui il protocollo se lo scrive lui (per eccesso ad ogni
carattere trasmesso una azione eseguita) per far dialogare due pic.

La gestione dell'i2c come giustamente dici tu implementa anche il
protocollo e non il solo invio di un byte. Al limite si può pensare
di usare il protocollo i2c come hardware ma implementando un sistema
più semplice per ilsolo dialogo fra i due pic.

Tutto questo solo per vedere muovere il ragno, poi con calma rifare
la parte i2c come previsto dallo stesso protocollo.

Spero di non aver deto stupidaggini.

Saluti Nonno

PS se poi non ricordo male Saverio ha decodificato e si è scritto le
relative routine del protocollo del pad della play station,
figuriamoci se non sa realizzare un protocollo propietario per
scambiare una decina di comandi fra i due pic senza scornarsi con
l'i2c.

Post by Marco d'Ambrosio

Post by nonno_nino
00734a.pdf slave mode con SSP in assembler
00554c.pdf slave + master in software (usa pin rb0 per individuare
inizio rx) in assembler
00736a.pdf slave + master con SSP in C

Molto generiche e relativamente utili, sopratutto quando si lavora con la
modalità slave.
In tutti i casi il vero problema non è far funzionare le

periferiche I2C dei

Post by Marco d'Ambrosio
pic, che vanno benissimo, ma capire come funziona il protocollo I2C e
scrivere le necessarie funzioni per gestirlo.
Questo perchè le periferiche si limitano a ricevere/trasmettere un byte di
dati e fornire tutta una serie di informazioni relative allo stato della
linea e dei dati ricevuti, ma è compito del programma leggere i giusti flag
e gestire le possibili risposte agli eventi, i vari ACK, NACK etc.
Ciao
Marco d'Ambrosio

[Marco d'Ambrosio]

Post by nonno_nino
Proprio per questa difficoltà proponevo di usare una seriale
software, in cui il protocollo se lo scrive lui (per eccesso ad ogni
carattere trasmesso una azione eseguita) per far dialogare due pic.

Non sempre è possibile usare la seriale, sopratutto quando ne hai solo una e
un conto è far dialogare tra loro diverse schede usando la RS485 e un conto
è far dialogare tra loro degli IC montati sulla stessa scheda.

Post by nonno_nino
Al limite si può pensare
di usare il protocollo i2c come hardware ma implementando un sistema
più semplice per ilsolo dialogo fra i due pic.

Non ci siamo capiti, le periferiche I2C, il modulo SSP, presenti sui PIC non
implementano il protocollo vero e proprio, quello è a carico del software,
si limitano a trasmettere fisicamente i singoli bit sul bis I2C e
controllare lo stato di questt'ultimo, p.e. eventuali collisioni, per
mandare via un carattere sull'I2C non basta scrivere TXREG = carattere come
si fa con la seriale TTL, occorre verificare tutta una serie di condizioni e
mandare via le giuste risposte quando serve.

Post by nonno_nino
Tutto questo solo per vedere muovere il ragno, poi con calma rifare
la parte i2c come previsto dallo stesso protocollo.

Non vedo nessun motivo valido per dover eliminare la parte I2C, è un sistema
di comunicaizione affidabile, stracollaudato, relativamente semplice da
gestire, però tocca capire come funziona.

Post by nonno_nino
figuriamoci se non sa realizzare un protocollo propietario per
scambiare una decina di comandi fra i due pic senza scornarsi con
l'i2c.

Il protocollo di comunicazione fisica del bus e quello di gestione dati,
sono due cose diverse, l'I2C per trasmettere dei byte ha un suo esatto e ben
defnito protocollo di gestione, poi come questi dati vengono interpretati è
un'altro paio di maniche e questo è il protocollo dati che non ha nulla a
che vedere con il funzionamento dell'I2C, esempio pratico se sul bus
trasmetto la stringa "@123456#" oppure la stringa "@SPOSTA 1000,50#" per
l'I2C non fa alcuna differenza, sono solo dei byte dal suo punto di vista,
però farà molta differenza per il software che riceve questi dati e li deve
interpretare

Ciao

Marco d'Ambrosio

[nonno_nino]

Post by Marco d'Ambrosio
Non sempre è possibile usare la seriale, sopratutto quando ne hai solo una e
un conto è far dialogare tra loro diverse schede usando la RS485 e un conto
è far dialogare tra loro degli IC montati sulla stessa scheda.

Parlavo di usare una seriale simulata in software .... io l'ho fatto
su un 16f628 (partendo dal an585) e non mi è sembrato così
scandaloso.

Post by Marco d'Ambrosio
Non ci siamo capiti, le periferiche I2C, il modulo SSP, presenti sui PIC non
implementano il protocollo vero e proprio, quello è a carico del software,
si limitano a trasmettere fisicamente i singoli bit sul bis I2C e
controllare lo stato di questt'ultimo, p.e. eventuali collisioni, per
mandare via un carattere sull'I2C non basta scrivere TXREG =

carattere come

Post by Marco d'Ambrosio
si fa con la seriale TTL, occorre verificare tutta una serie di condizioni e
mandare via le giuste risposte quando serve.

Diciamo la stessa cosa, per questo consigliavo a Saverio, almeno in
un primo momento di simulare in software una seriale e usarla per far
parlare i due pic.

Post by Marco d'Ambrosio
Non vedo nessun motivo valido per dover eliminare la parte I2C, è un sistema
di comunicaizione affidabile, stracollaudato, relativamente

semplice da

Post by Marco d'Ambrosio
gestire, però tocca capire come funziona.

Dipende dal tempo che uno vuole dedicarci, del resto da come parla
Saverio sembrava che il tempo per studiarsi e realizzare la i2c se lo
sarebbe risparmiato tutto.

Post by Marco d'Ambrosio
Il protocollo di comunicazione fisica del bus e quello di gestione dati,
sono due cose diverse, l'I2C per trasmettere dei byte ha un suo esatto e ben
defnito protocollo di gestione, poi come questi dati vengono

interpretati è

Post by Marco d'Ambrosio
un'altro paio di maniche e questo è il protocollo dati che non ha nulla a
che vedere con il funzionamento dell'I2C, esempio pratico se sul bus

1000,50#" per

Post by Marco d'Ambrosio
l'I2C non fa alcuna differenza, sono solo dei byte dal suo punto di vista,
però farà molta differenza per il software che riceve questi dati e li deve
interpretare

Perfettamente daccordo.

Ciao Nonno

[Marco d'Ambrosio]

Post by nonno_nino
Parlavo di usare una seriale simulata in software .... io l'ho fatto
su un 16f628 (partendo dal an585) e non mi è sembrato così
scandaloso.

La seriale software è poco efficiente, consuma molto tempo CPU, in tutti i
casi c'è sempre il problema che puoi dialogare solo con un altro IC e non
con più IC in parallelo come si fa con l'I2C.

Ciao

Marco d'Ambrosio

[Stefano M.]

Infatti! Saverio deve far dialogare solo due PIC.

Comunque è ovvio che hai ragione sia tu che Saverio, usare la i2c è
più affidabile e poi dopo aver fatto le routine si possono sempre
riusare per altri lavori. Io volevo dire che se era roso dalla voglia
di far correre "subito" il ragno dietro al bimbo ...... poteva
prendere in considerazione l'opzione seriale, tutto qui. Opzione
bocciata, non insisto, anzi ragionandoci bene magari in C con la
seriale software si incasinerebbe la vita più che l'i2c .....

Ciao Nonno

Post by Marco d'Ambrosio

Post by nonno_nino
Parlavo di usare una seriale simulata in software .... io l'ho fatto
su un 16f628 (partendo dal an585) e non mi è sembrato così
scandaloso.

La seriale software è poco efficiente, consuma molto tempo CPU, in tutti i
casi c'è sempre il problema che puoi dialogare solo con un altro IC e non
con più IC in parallelo come si fa con l'I2C.
Ciao
Marco d'Ambrosio

[max_xxv]

Installando in versione full il nuovo mplab mi chiede di installare il
PICC della hitech in versione lite... come mai la microchip lo ha
incluso? qualcuno ne sa niente? non è che avranno intenzione di
abbandonare il C18 per via di qualche accordo con la hitech?
--
Visita il mio sito
http://www.katodo.com e http://wiki.tuttoelettronica.org
oppure contattami in MSN, GTALK o ICQ N° 129440900
Radioamatore: IW3HZQ --- Gentoo user!!
"Tutto è impossibile fino a quando qualcuno non ci dimostra il contrario... "


Sito ufficiale della mail list:
www.roboteck.org

Per consultare le F.A.Q. della ML:
http://www.roboteck.org/faq/faq.htm
Link utili di Yahoo! Gruppi

<*> Per andare all'homepage del gruppo vai alla pagina:
http://it.groups.yahoo.com/group/roboteck/

<*> Le tue impostazioni email:
Email singoli|Tradizionali

<*> Per cambiare le impostazioni online visita il sito:
http://it.groups.yahoo.com/group/roboteck/join
(necessaria l'ID Yahoo!)

<*> Per cambiare le impostazioni tramite email:
mailto:roboteck-***@yahoogroups.com
mailto:roboteck-***@yahoogroups.com

<*> Per annullare l'iscrizione al gruppo scrivi a:
roboteck-***@yahoogroups.com

<*> L'utilizzo da parte tua di Yahoo! Gruppi è soggetto alle:
http://it.docs.yahoo

[Spad 05]

Grazie nonno.
Io mi ero scaricato solo AN734, piu' un posto di astro per i pic 18F.

Ormai mi manca solo questo...


To: roboteck-hHKSG33Tihig7M29m/***@public.gmane.org: nonno_62-***@public.gmane.org: Thu, 16 Aug 2007 10:39:35 +0000Subject: [roboteck] Ogg: MPLAB 7.62




--- In roboteck-***@public.gmane.org, Spad 05 <***@...> ha scritto:>> In piu' mi sarei risparmiato I2C slave sul 16F ..... dal quale non so se ne cavo le gambe ;)Se non lo hai fatto scaricati i seguenti doc di Microchip:00734a.pdf slave mode con SSP in assembler 00554c.pdf slave + master in software (usa pin rb0 per individuare inizio rx) in assembler00736a.pdf slave + master con SSP in CPoi puoi anche scaricarti questi altri .... meno importanti per te ma sempre utili in libreria.00690a.pdf00735a.pdfI doc sono nominati come ANxxx non so se conviene cercarli così.Ciao NonnoPerò alla prima occasione mi fai fare un giro sul ragno .....


_________________________________________________________________
Sai cosa è successo oggi?
http://notizie.msn.it

[Sono state eliminare la parti non di testo del messaggio]

[nonno_nino]

Ho trovato anche questo file nella mia libreria ..... nascosto dentro
una directory di quando si giocava con altro ....

sono le routine base software per il master (16f84), ma con queste ho
capito come funziona l'i2c ..... da qui potrebbe essere più facile
risalire allo slave piuttosto che con le routine microchip, questo
perchè spesso i soft microchip devono tenere conto di un ambiente
multi periferica e non di un collegamento tra soli du pic.

Non ricordo l'autore delle routine sottopubblicate .... ma era
sicuramente un amico.
Inoltre fai una visita sul sito di Guiot che se non ricordo male
sull'i2c a diversa roba pubblicata (qulacosa l'ho presa da lì).

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

Variabili da dichiarare

_N res 1 ; 20
I2C_BYTE res 1 ; 21
I2C_LOOP res 1 ; 22


Codice

;*****************************************************************
;* I2C
;*****************************************************************

I2C_IN_BYTE ; read byte on i2c bus
CLRF I2C_BYTE
MOVLW .8
MOVWF _N ; set index to 8
CALL I2C_HIGH_SDA ; be sure SDA is configured
as input
I2C_IN_BIT
CALL I2C_HIGH_SCL ; clock high
BTFSS PORTA, 4 ; test SDA bit
GOTO I2C_IN_ZERO
GOTO I2C_IN_ONE

I2C_IN_ZERO
BCF STATUS, C ; clear any carry
RLF I2C_BYTE, F ; I2C_BYTE = I2C_BYTE << 1 | 0
GOTO I2C_CONT_IN

I2C_IN_ONE
BCF STATUS, C ; clear any carry
RLF I2C_BYTE, F
INCF I2C_BYTE, F ; I2C_BYTE = (I2C_BYTE << 1)
| 1
GOTO I2C_CONT_IN

I2C_CONT_IN
CALL I2C_LOW_SCL ; bring clock low
DECFSZ _N, F ; decrement index
GOTO I2C_IN_BIT
RETURN

;;;;;;

I2C_OUT_BYTE: ; send I2C_BYTE on I2C bus
MOVLW .8
MOVWF _N
I2C_OUT_BIT:
BCF STATUS,C ; clear carry
RLF I2C_BYTE, F ; left shift, most sig bit is
now in carry
BTFSS STATUS, C ; if one, send a one
GOTO I2C_OUT_ZERO
GOTO I2C_OUT_ONE

I2C_OUT_ZERO:
CALL I2C_LOW_SDA ; SDA at zero
CALL I2C_CLOCK_PULSE
CALL I2C_HIGH_SDA
GOTO I2C_OUT_CONT

I2C_OUT_ONE:
CALL I2C_HIGH_SDA ; SDA at logic one
CALL I2C_CLOCK_PULSE
GOTO I2C_OUT_CONT

I2C_OUT_CONT:
DECFSZ _N, F ; decrement index
GOTO I2C_OUT_BIT
RETURN

;;;;;;

I2C_NACK: ; bring SDA high and clock
CALL I2C_HIGH_SDA
CALL I2C_CLOCK_PULSE
RETURN

I2C_ACK:
CALL I2C_LOW_SDA
CALL I2C_CLOCK_PULSE
RETURN

I2C_START:
CALL I2C_LOW_SCL
CALL I2C_HIGH_SDA
CALL I2C_HIGH_SCL
CALL I2C_LOW_SDA ; bring SDA low while SCL is
high
CALL I2C_LOW_SCL
RETURN

I2C_STOP:
CALL I2C_LOW_SCL
CALL I2C_LOW_SDA
CALL I2C_HIGH_SCL
CALL I2C_HIGH_SDA ; bring SDA high while SCL is
high
CALL I2C_LOW_SCL
RETURN

I2C_CLOCK_PULSE: ; SCL momentarily to logic one
CALL I2C_HIGH_SCL
CALL I2C_LOW_SCL
RETURN

I2C_HIGH_SDA: ; high impedance by making
SDA an input
BSF STATUS, RP0 ; bank 1
BSF TRISA, 4 ; make SDA pin an input
BCF STATUS, RP0 ; back to bank 0
CALL I2C_DELAY_SHORT
RETURN

I2C_LOW_SDA:
BCF PORTA, 4
BSF STATUS, RP0 ; bank 1
BCF TRISA, 4 ; make SDA pin an output
BCF STATUS, RP0 ; back to bank 0
CALL I2C_DELAY_SHORT
RETURN

I2C_HIGH_SCL:
BSF STATUS, RP0 ; bank 1
BSF TRISA, 3 ; make SCL pin an input
BCF STATUS, RP0 ; back to bank 0
CALL I2C_DELAY_SHORT
RETURN

I2C_LOW_SCL:
BCF PORTA, 3
BSF STATUS, RP0 ; bank 1
BCF TRISA, 3 ; make SCL pin an output
BCF STATUS, RP0 ; back to bank 0
CALL I2C_DELAY_SHORT
RETURN

I2C_DELAY_SHORT: ; provides nominal 25 usec
delay
MOVLW .5
MOVWF I2C_LOOP
I2C_DELAY_SHORT_1:
NOP
DECFSZ I2C_LOOP, F
GOTO I2C_DELAY_SHORT_1
RETURN

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

Stavo comunque pensando se non ti convenisse convertire il
collegamento con due seriali ttl simulate in software con quella
distanza non credo risentano di disturbi, sulle seriali software e
sui pic più in generale puoi visitare questo sito ....

http://stor.altervista.org/pic/pic.htm

molto semplice, ho imparato moltissimo da qui, la seriale poi è di
una semplicità stupefacente. inoltre ci sono una monagna di AN
sull'argomento, in particolare AN585 dove viene implementato un os
con una seriale a stati.

Ciao Nonno

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

Post by Spad 05
Grazie nonno.
Io mi ero scaricato solo AN734, piu' un posto di astro per i pic 18F.
Ormai mi manca solo questo...

+0000Subject: [roboteck] Ogg: MPLAB 7.62
piu' mi sarei risparmiato I2C slave sul 16F ..... dal quale non so se
ne cavo le gambe ;)Se non lo hai fatto scaricati i seguenti doc di
Microchip:00734a.pdf slave mode con SSP in assembler 00554c.pdf slave
+ master in software (usa pin rb0 per individuare inizio rx) in
assembler00736a.pdf slave + master con SSP in CPoi puoi anche
scaricarti questi altri .... meno importanti per te ma sempre utili
in libreria.00690a.pdf00735a.pdfI doc sono nominati come ANxxx non so
se conviene cercarli così.Ciao NonnoPerò alla prima occasione mi fai
fare un giro sul ragno .....

Post by Spad 05
_________________________________________________________________
Sai cosa è successo oggi?
http://notizie.msn.it
[Sono state eliminare la parti non di testo del messaggio]

[Spad 05]

Non posso usare la seriale perche' gia' occupata per parlare con il servo controller....

Non e' che mi spaventa tantissimo implementare i2c slave...(semmai e' il fatto di non avere debugger che mi allunghera' molto i tempi) ho letto i vari AN e il codice di astro e mi sembra tutto abbastanza chiaro.
Anche se non ho capito come mai, astro , usi la modalita' interrupt per start e stop. In genere (fonte AN) la si usa quando lo slave deve intercettare l'idle del bus e prenderne il controllo come master.
_________________________________________________________________
Crea il tuo gadget e vinci 10 Windows Vista e 30€ di musica!
http://concorsogadget.it.msn.com/

[Sono state eliminare la parti non di testo del messaggio]

[Marco d'Ambrosio]

Post by Spad 05
Anche se non ho capito come mai, astro , usi la modalita' interrupt per
start e stop. In genere (fonte AN) la si usa quando lo slave deve

Post by Spad 05
intercettare l'idle del bus e prenderne il controllo come master.

Le AN sono da prendere come esempi sicuramente funzionanti, ma sono
soluzioni assolute, spesso e volentieri riguardano casi molto particolari,
insomma sono utili ma non sono il "verbo".
Le righe di codice che ho postato sono relative all'uso come slave del
18F2431, che ha il modulo SSP leggermente diverso da quello degli altri pic,
e devono funzionare all'interno di un controllo PID, mi pare abbastanza
logico usare l'interrupt per gestire le richieste I2C da parte del master,
in tutti i casi non viene attivato sullo start e stop, ma solo quando c'è un
byte valido, sia dato che address, nel registro SSPBUF, poi l'ISR in base ai
vari flag decide cosa fare.

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Post by Marco d'Ambrosio
Le AN sono da prendere come esempi sicuramente funzionanti, ma sono
soluzioni assolute,

Manca un "non", la frase è "non sono soluzioni assolute".

Ciao

Marco d'Ambrosio

[Stefano Murri]

Post by Marco d'Ambrosio
logico usare l'interrupt per gestire le richieste I2C da parte del master,
in tutti i casi non viene attivato sullo start e stop, ma solo

quando c'è un

Post by Marco d'Ambrosio
byte valido, sia dato che address, nel registro SSPBUF, poi l'ISR in base ai
vari flag decide cosa fare.

Posso fare una domanda che prende spunto da questa frase?

Io nei miei software (pochi e incompleti) realizzo le routine a
stati, la ISR la utilizzo solo per azionare dei flag che poi uso in
uno stato della relativa routine di gestione, ovviamente quando gli
verrà passato il controllo del flusso.

Questa frantumazione del codice mi fa soffrire (per questo volevo
provare un rtos).

Dalla frase sopra esposta mi sembra di capire che le routine che usi
tu e a cui fai riferimento sono un po meno "frantumate", insomma
tengono il controllo fino a fare ciò che è necessario (anche se in
fondo c'è qualche piccola pausa ....), mentre la ISR invece di
settare solamente dei flag partecipa attivamente all'esecuzione delle
cose da fare.

Insomma sfrutti molto gli ISR a costo di ritardare anche di molto il
flusso normale del programma.

Mi sbaglio?

In questa maniera in effetti se ci sono delle attese minime non
comportano la necessità di suddividere il controllo in più stati
tanto per l'urgenza c'è sempre l'ISR che diventa attiva come se si
stesse in un rtos.

Esempio: scrivere su un display comporta attese abbastanza lunghe e
se uno nel contempo deve gestire una risposta su una seriale entro un
tempo minore ci si può trovare in overflow. Con la gestione della
trasmissione nella ISR .... si risolverebbe il problema .... anche a
costo da far durare la ISR un pò, sempre gestendo la disabilitazione
degli interrupt dove serve.

Ciao Nonno

[Marco d'Ambrosio]

Post by Stefano Murri
Insomma sfrutti molto gli ISR a costo di ritardare anche di molto il
lusso normale del programma.
Mi sbaglio?

All'interno delle ISR va fatto tutto quello che serve, cosa esattamente
dipende dal tipo di programma, dalle priorità e da chi ha generato
l'interrupt.
Esempio pratico, se l'interrupt è attivato da una porta seriale ad alta
velocità è obbligatorio gestire la porta all'interno della ISR, altrimenti
rischi di perderti i dati per strada, ma non è logico gestire il parser
all'interno della ISR, questo verrà attivato dal main tramite apposito flag.

Post by Stefano Murri
Esempio: scrivere su un display comporta attese abbastanza lunghe e
se uno nel contempo deve gestire una risposta su una seriale entro un
tempo minore ci si può trovare in overflow.

Non si scrive su un display all'interno della ISR, non ha senso farlo, come
ti ho detto cosa fare esattamente all'interno della ISR dipende da cosa stai
facendo, in tutti i casi la direttiva primaria da seguire è che l'ISR deve
durare il minimo possibile.
Nel caso reale di cui stiamo discutendo è obbligatorio gestire l'I2C slave
all'interno della ISR, i dati arrivano a 400 kbps, un byte ci mette solo
25us per essere ricevuto, dopo di che scatta l'interrupt, se non sei lesto a
prenderlo e metterlo in un buffer puoi dirgli addio, sopratutto quando
parliamo di periferiche sincrone con un master che comanda i giochi.
Quando crei una ISR devi anche valutarne l'impatto sul resto del programma,
sia come durata che esecuzioni ripetute, e dedicere se è il caso di
disabilitarla durante l'esecuzione di alcune funzioni.

Ciao

Marco d'Ambrosio

[Stefano M.]

Si ok, anche io gestisco la ISR in questa maniera, quindi non stavo
sbagliando nell'interpretarne l'uso. Per il display, intendevo dire
che la sua gestione all'interno di una task comporta molto tempo (per
una riga di 16 caratteri ci vuole circa 1 ms, io per questo ho
spezzettato la scrittura inviando un carattere per volta e
restituendo fra un carattere e l'altro il controllo al main).

Sfruttare la ISR per ricevere o trasmettere una stringa da un buffer
è naturale, non sapevo se la ISR la spingessi fino a fare il parser.
Mi hai risposto di no!

Il mio dubbio oltre che dal risparmiarmi un po di frazionamento del
codice della task, mi veniva anche dalla possibilità di trovarmi
all'interno di una task lunga e nel contempo avere la necessità di
rispondere in tempi brevi su una seriale o su una i2c (insomma ad una
periferica esterna che si aspetta l'invio di un byte entro un certo
tempo). Leggendo il post pensavo di poter sfruttare la ISR per
impostare una risposta veloce, invece non è consigliabile.

Il tutto per un discorso teorico che come hai già detto varia da caso
a caso. altro esempio, pensavo ad esempio alla tua motion controller,
che fa viaggiare i dati sul bus esterno a 400 kbs, sfruttando la ISR
per non perdere neanche un carattere, ma nel contempo se alla fine
della ricezione della stringa si trova all'interno della gestione del
PID o di una task particolarmente lunga per elaborare i dati e
rispondere sul bus devrà aspettare 500 o 600 ns, mi sembrava una
incongruenza, anche se pensandoci bene non lo è!

Ciao Nonno

Post by Marco d'Ambrosio

Post by Stefano Murri
Insomma sfrutti molto gli ISR a costo di ritardare anche di molto il
lusso normale del programma.
Mi sbaglio?

All'interno delle ISR va fatto tutto quello che serve, cosa

esattamente

Post by Marco d'Ambrosio
dipende dal tipo di programma, dalle priorità e da chi ha generato
l'interrupt.
Esempio pratico, se l'interrupt è attivato da una porta seriale ad alta
velocità è obbligatorio gestire la porta all'interno della ISR, altrimenti
rischi di perderti i dati per strada, ma non è logico gestire il parser
all'interno della ISR, questo verrà attivato dal main tramite

apposito flag.

Post by Marco d'Ambrosio

Post by Stefano Murri
Esempio: scrivere su un display comporta attese abbastanza lunghe e
se uno nel contempo deve gestire una risposta su una seriale entro un
tempo minore ci si può trovare in overflow.

Non si scrive su un display all'interno della ISR, non ha senso farlo, come
ti ho detto cosa fare esattamente all'interno della ISR dipende da cosa stai
facendo, in tutti i casi la direttiva primaria da seguire è che l'ISR deve
durare il minimo possibile.
Nel caso reale di cui stiamo discutendo è obbligatorio gestire l'I2C slave
all'interno della ISR, i dati arrivano a 400 kbps, un byte ci mette solo
25us per essere ricevuto, dopo di che scatta l'interrupt, se non sei lesto a
prenderlo e metterlo in un buffer puoi dirgli addio, sopratutto quando
parliamo di periferiche sincrone con un master che comanda i giochi.
Quando crei una ISR devi anche valutarne l'impatto sul resto del programma,
sia come durata che esecuzioni ripetute, e dedicere se è il caso di
disabilitarla durante l'esecuzione di alcune funzioni.
Ciao
Marco d'Ambrosio

[Marco d'Ambrosio]

Post by Stefano M.
Leggendo il post pensavo di poter sfruttare la ISR per
impostare una risposta veloce, invece non è consigliabile.

Tutto dipende dalle condizioni e dalle esigenze del programma, comunque
nella ISR per l'I2C slave che uso sulla motion controller i byte di risposta
ad una read operation vengono trasmessi all'interno della ISR, ovviamente
uno per volta e per ognuno c'è un interrupt attivato dall'ACK trasmesso dal
Master quando finisce di ricevere un byte, però lo slave in questo caso ha
la facoltà di mettere in attesa, impegnando il bus, il master fino a che non
è pronto a trasmettere il bytei.
In pratica la cosa funziona così, quando il master inizia una operazione sul
bus l'ISR si attiva non appena viene ricevuto un address che combina con
quello assegnato alla periferica, tutte le altre trasmissioni sul bus sono
ignorate e non viene generato nessun interrupt.
Dopo la prima attivazione l'ISR verifica i vari flag di stato della
periferica e determina se il byte ricevuto è un address oppure un data, nel
caso che sia una address anche il tipo di operazione, read o write, che è
determinata dal valore del bit 0, in base a questo viene predisposto il
comportamento della ISR.
Nel caso di write operation è necessario seguire fedelmente il master
pertanto l'interrupt rimane sempre attivo fino alla ricezione dell'ultimo
byte, nel mio caso sono pacchetti a lunghezza fissa di 12 byte con "@"
iniziale e "#" finale che servono per vericare l'inizio e fine della stringa
e per sincronizzare le operazioni.
Nei restanti 10 byte vi sono la velocità in RPM (int), la distanza in PPR
( long int), il comando da eseguire (char), un checksum (char),
l'accelerazione per il generatore di rampa (char), la decelerazione (char),
complessivamente per trasmettere i 12 byte occorrono meno di 300 us durante
i quali l'ISR viene invocata 13 volte, 12 + una per l'address, con una
durata minore di 8us per ogni attivazione della ISR, tempi
misurati con il DSO tramite test point comandati da software.
Dato che l'unica operazione critica per il calcolo del pid è l'istante di
acquisizione dati dalla periferica QEI, il decoder in quadratura, che deve
essere fatta a intervalli regolari molto precisi, basta disattivare
l'interrupt della periferica SSP per tutta la durata della lettura dati
encoder, che complessivamente richiede mendo di 3 us, in questo modo sono
certo che non viene introdotto nessun errore di jitter aggiuntivo, ci sono
quelli dell'encoder ottico stesso, dovuto ad una attivazione dell'ISR, poi
anche se viene attivata l'ISR tot volte mentre eseguo l'algoritmo pid vero e
proprio questo non è un problema.
Nel caso di una read operation invece blocco l'interrupt per tutta la durata
del ciclo PID, mediamente 160 us, durante questo tempo il MASTER attende
l'OK da parte dello slave prima di ricevere il byte.
In pratica abbiamo ogni tot secondi una operazione di write, che è quella
più critica, che indica l'arrivo di un nuovo comando per il PID, mentre
abbiamo una operazione di read ogni 10 ms, in pratica il micro che fa da
governor interroga ciclicamente i due pid ogni 10 ms e ottiene lo status
corrente che include velocità istantanea (int), posizione raggiunta (long
int), flag di stato (due byte), questi dati servono al governor sia per
decidere il da farsi che per trasmetterli, su richiesta, al brain principale
del robot e alla telemetria.

Post by Stefano M.
ma nel contempo se alla finedella ricezione della stringa si trova
all'interno della gestione del
PID o di una task particolarmente lunga per elaborare i dati e
rispondere sul bus devrà aspettare 500 o 600 ns, mi sembrava una
incongruenza, anche se pensandoci bene non lo è!

Non è così, alla fine di un pacchetto, se i due header e il cheksum
risultano corretti, viene attivato il flag per il parser che poi verrà
invocato dal main, le risposte su I2C sono automatiche e sono gestite
direttamente dal ciclo pid, in pratica c'è un vettore che contiene la
stringa di risposta e questo vettore viene aggiornato ad ogni ciclo pid,
l'ISR si limita a trasmettere il vettore quando richiesto (ogni 10 ms).

p.s.
Lo so che tutto questo sembra complicato, infatti lo è :-)

Ciao

Marco d'Ambrosio

[Guido Ottaviani]

Post by Marco d'Ambrosio
p.s.
Lo so che tutto questo sembra complicato, infatti lo è :-)
Ciao
Marco d'Ambrosio

E non potrebbe essere altrimenti. Stiamo parlando di eventi che
scatenano interrupt con tempi paragonabili a quelli di esecuzione
delle routine. Si deve tener conto in ogni momento di quello che
sta accadendo intorno e con gli interrupt, asincroni per definizione,
non è sempre semplice ne prevederlo ne debuggarlo.
Certo, avendo a disposizione 30 Mips e un vettore di interrupt
con priorità assegnabile a piacere per ogni periferica c'è un po'
più di tempo per fare le cose ma i tempi sono comunque stretti
e quello che si fa dentro una ISR deve essere sempre ridotto al
minimo o, comunque, va previsto ogni comportamento.

Per semplificarsi la vita, consiglio vivamente di studiarsi bene
il simulatore dell'MPLAB.
Si riesce a provare quasi tutto, anche gli interrupt.
Si possono analizzare gli stati delle porte in tempo reale con il
logic analyzer, iniettare segnali analogici e digitali, a qualsiasi
frequenza e con qualsiasi duty cycle.
Si possono vedere in real time le variabili con il "Data monitor
and control interface".
Si riesce a sapere esattamente il tempo di esecuzione di ogni
pezzetto del proprio codice.
Si riescono a scoprire molti bug prima ancora di alimentare il
circuito. Dopo diventa più difficile e richiede l'utilizzo di
generatori di segnali, oscilloscopi o analizzatori di stati logici
che sono, sicuramente, più costosi e più difficili da usare.

ciao
Guido

[Marco d'Ambrosio]

Post by Guido Ottaviani
Si deve tener conto in ogni momento di quello che
sta accadendo intorno e con gli interrupt, asincroni per definizione,
non è sempre semplice ne prevederlo ne debuggarlo.

Esatto, spesso succede che quando si lancia il programma, che in teoria
funzionava bene, poi ci si trova di fronte a malfunzionamenti strani e
difficilmente spiegabili solo perchè un'interrupt è arrivato nel momento
sbagliato e noi non lo avevamo preventivato.

Post by Guido Ottaviani
Certo, avendo a disposizione 30 Mips e un vettore di interrupt
con priorità assegnabile a piacere per ogni periferica c'è un po'

Bella la vita con i dsPIC :-)
Meglio ancora con un dsPIC serie 33 con tanto di DMA.

Post by Guido Ottaviani
Per semplificarsi la vita, consiglio vivamente di studiarsi bene
il simulatore dell'MPLAB.

Saggio consiglio, inclusi tutti i tool abbinati al simulatore.
Tra l'altro con questa release di MPLAB è stato ampliato il supporto allo
spice di Proteus, ora è possibile simulare anche graficamente i circuiti,
per molti test non serve nemmeno disegnare lo schema dato che sono
disponibili di serie la virtualizzazione della PICDEM2 Microchip, con sopra
il 16F877 o il 18F452 a scelta, e la stupenda explorer 16 con sopra un PIC
24FJ128

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Speravo di riuscire a finire tutta la parte hardware, meccanica +
elettronica, di Gino entro fine Agosto, massimo primi di Settembre, e a
quanto pare c'è l'ho quasi fatta, attualmente è pronto tutto l'hardware
indispensabile per il funzionamento di Gino, manca solo una piccola scheda
con sopra un dsPIC che sarà dedicata per le sorgenti sonore a 4 kHz e devo
installare i sensori per le sorgenti di luce.
Ad oggi Gino è completo al 100% per la meccanica e al 90% per l'elettronica,
tutte le schede sono già cablate a livello di singolo piano, manca solo di
portare in giro il bus RS485 che mette il tutto in comunicazione e la linea
di alimentazione principale, per quest'ultima è già stato fatto il cablaggio
di base con tanto di interruttori per l'accensione elettronica e potenza
motori.
Complessivamente Gino è alto 24 cm, volendo possono recuperare 3-4 cm
realizzando delle colonnine distanziali su misura, se avrò tempo le farò
fare in ergal anodizzato rosso, ma questo è solo un vezzo estetico, la base
ottagonale è inscritta in un cerchio di 20 cm quindi c'è il pieno rispetto
delle dimensioni massime previste per un Explorer.
Il peso complessivo è minore di quello che mi aspettavo, senza batterie poco
meno di 1.8 kg, a seconda del tipo di celle impiegate questo peso aumenta di
195 gr con le LiPo ( 4 celle da 2100 mAh), 340 gr con le NiMh (12 celle da
2700 mAh), 650 grammi con una batteria al piombo da 12V 1200 mAh.
Ho previsto fin dall'inizio un alloggiamento batterie (100x40x50 mm) in
grado di ospitare diverse tipologie di celle, a seconda delle condizioni di
impiego del robot può convenire usare un tipo piuttosto che un'altro, ma
anche per non avere problemi per utilizzare fonti di energia alternativa in
caso di avaria di quella principale, le batterie hanno il brutto vizio di
guastarsi dalla mattina alla sera senza avvisare.
Attualmente Gino viene alimentato con una batteria al piombo da 1200 mAh,
economiche e non critiche da ricaricare, ma ho già preparato il pacco LiPo
da quattro celle con il quale avrà un'autonomia di funzionamento di qualche
ora.
La propulsione di Gino è affidato a due motoriduttori da 200 rpm 3.5 kg*cm
di coppia dotati di encoder da 300 cpr, le ruote hanno un diametro di 82 mm
e una larghezza di 12 mm e sono dotate di pneumatici scolpiti, per chi è
interessato sono ruote del Lego Technik e costano circa 15 Euro la coppia,
l'interasse delle ruote è di 192 mm.
La velocità massima di crociera di Gino è 75 cm/s (massimo possibile con PWM
fisso al 100% 87 cm/s), quella dove si ottiene la massima potenza meccanica
è di 43 cm/s, la massima accelerazione possibile è di 62 cm/s^2, massima
decelerazione tramite frenatura elettrica oltre 150 cm/s^2 (siamo al limite
del ribaltamento), la costante di tempo elettromeccanica dei motoriduttori,
a vuoto, è di 35 ms, tutti questi valori sono stati verificati
strumentalmente, si discostano di pochi punti percentuale rispetto ai valori
teorici che avevo calcolato in fase di dimensionamento.
Tanto per dare un'idea di cosa significano questi numeri posso dirvi che
Gino partendo da fermo può balzare ad un metro distanza in meno di tre
secondi fermandosi con precisione al mm nel punto di arrivo, se interessa
posso mettere on line un filmato di Gino che parte a tutta velocità e si
ferma alla distanza di 80 cm esatti dal punto di partenza in un batter
d'occhio, in tutti i casi il precedente filmato
http://www.roboteck.org/Twister.wmv esprimeva lo stesso concetto ma
applicato alla rotazione piuttosto che all'incedere.

Ecco alcune immagini aggiornate di Gino
Vista frontale globale
Loading Image...
Dettaglio dell'elettronica sui vari pianali
Loading Image...
Pianale IrDAR e sensori ottici perimetrali già cablato
Loading Image...
Vista da sopra con lettura dell'Heading bussola.
Loading Image...

Ciao

Marco d'Ambrosio

[Stefano M.]

M E R A V I G L I O S O

Ma non c'è bisogno che lo dica io!

Nonno


PS per l'individuazione del punto di arrivo dei suoni userai la
pressione sonora muovendo il gino oppure userai tre microfoni per
farti una triangolazione .....

Ariciao Nonno

Post by Marco d'Ambrosio
Speravo di riuscire a finire tutta la parte hardware, meccanica +
elettronica, di Gino entro fine Agosto, massimo primi di Settembre, e a
quanto pare c'è l'ho quasi fatta, attualmente è pronto tutto

l'hardware

Post by Marco d'Ambrosio
indispensabile per il funzionamento di Gino, manca solo una piccola scheda
con sopra un dsPIC che sarà dedicata per le sorgenti sonore a 4 kHz e devo
installare i sensori per le sorgenti di luce.
Ad oggi Gino è completo al 100% per la meccanica e al 90% per

l'elettronica,

Post by Marco d'Ambrosio
tutte le schede sono già cablate a livello di singolo piano, manca solo di
portare in giro il bus RS485 che mette il tutto in comunicazione e la linea
di alimentazione principale, per quest'ultima è già stato fatto il cablaggio
di base con tanto di interruttori per l'accensione elettronica e potenza
motori.
Complessivamente Gino è alto 24 cm, volendo possono recuperare 3-4 cm
realizzando delle colonnine distanziali su misura, se avrò tempo le farò
fare in ergal anodizzato rosso, ma questo è solo un vezzo estetico, la base
ottagonale è inscritta in un cerchio di 20 cm quindi c'è il pieno rispetto
delle dimensioni massime previste per un Explorer.
Il peso complessivo è minore di quello che mi aspettavo, senza batterie poco
meno di 1.8 kg, a seconda del tipo di celle impiegate questo peso aumenta di
195 gr con le LiPo ( 4 celle da 2100 mAh), 340 gr con le NiMh (12 celle da
2700 mAh), 650 grammi con una batteria al piombo da 12V 1200 mAh.
Ho previsto fin dall'inizio un alloggiamento batterie (100x40x50 mm) in
grado di ospitare diverse tipologie di celle, a seconda delle

condizioni di

Post by Marco d'Ambrosio
impiego del robot può convenire usare un tipo piuttosto che

un'altro, ma

Post by Marco d'Ambrosio
anche per non avere problemi per utilizzare fonti di energia

alternativa in

Post by Marco d'Ambrosio
caso di avaria di quella principale, le batterie hanno il brutto vizio di
guastarsi dalla mattina alla sera senza avvisare.
Attualmente Gino viene alimentato con una batteria al piombo da 1200 mAh,
economiche e non critiche da ricaricare, ma ho già preparato il pacco LiPo
da quattro celle con il quale avrà un'autonomia di funzionamento di qualche
ora.
La propulsione di Gino è affidato a due motoriduttori da 200 rpm 3.5 kg*cm
di coppia dotati di encoder da 300 cpr, le ruote hanno un diametro di 82 mm
e una larghezza di 12 mm e sono dotate di pneumatici scolpiti, per chi è
interessato sono ruote del Lego Technik e costano circa 15 Euro la coppia,
l'interasse delle ruote è di 192 mm.
La velocità massima di crociera di Gino è 75 cm/s (massimo

possibile con PWM

Post by Marco d'Ambrosio
fisso al 100% 87 cm/s), quella dove si ottiene la massima potenza meccanica
è di 43 cm/s, la massima accelerazione possibile è di 62 cm/s^2, massima
decelerazione tramite frenatura elettrica oltre 150 cm/s^2 (siamo al limite
del ribaltamento), la costante di tempo elettromeccanica dei

motoriduttori,

Post by Marco d'Ambrosio
a vuoto, è di 35 ms, tutti questi valori sono stati verificati
strumentalmente, si discostano di pochi punti percentuale rispetto ai valori
teorici che avevo calcolato in fase di dimensionamento.
Tanto per dare un'idea di cosa significano questi numeri posso

dirvi che

Post by Marco d'Ambrosio
Gino partendo da fermo può balzare ad un metro distanza in meno di tre
secondi fermandosi con precisione al mm nel punto di arrivo, se interessa
posso mettere on line un filmato di Gino che parte a tutta velocità e si
ferma alla distanza di 80 cm esatti dal punto di partenza in un batter
d'occhio, in tutti i casi il precedente filmato
http://www.roboteck.org/Twister.wmv esprimeva lo stesso concetto ma
applicato alla rotazione piuttosto che all'incedere.
Ecco alcune immagini aggiornate di Gino
Vista frontale globale
http://www.roboteck.org/EXP/fronte.jpg
Dettaglio dell'elettronica sui vari pianali
http://www.roboteck.org/EXP/dettaglio.jpg
Pianale IrDAR e sensori ottici perimetrali già cablato
http://www.roboteck.org/EXP/IrDAR.jpg
Vista da sopra con lettura dell'Heading bussola.
http://www.roboteck.org/EXP/Compass.jpg
Ciao
Marco d'Ambrosio

[Marco d'Ambrosio]

Post by Stefano M.
per l'individuazione del punto di arrivo dei suoni userai la
pressione sonora muovendo il gino oppure userai tre microfoni per
farti una triangolazione .....

Top secret :-)
Ti dico solo che i microfono sono due.

Ciao

Marco d'Ambrosio

[John Fischetti]

Post by Marco d'Ambrosio

Post by Stefano M.
per l'individuazione del punto di arrivo dei suoni userai la
pressione sonora muovendo il gino oppure userai tre microfoni per
farti una triangolazione .....

Top secret :-)
Ti dico solo che i microfono sono due.
Ciao
Marco d'Ambrosio

Ricordo di aver letto tempo fa di un sistema di simulazione
dell'udito umano con due microfoni collocati nella posizione delle
orecchie di una "testa". La direzione di provenienza del suono era
data dall'analisi della fase dei due segnali. Mi chiedo come faccia
il sistema a riconoscere la differenza tra due segnali centrati, uno
di fronte e uno dietro. Forse con gli echi? Mi sembra complicato.

Comunque complimenti per l'oggetto che stai sviluppando.

Io sto lavorando su una idea di navigazione del robot explorer
mediante telecamere e con un sensore inerziale per la rilevazione
della posizione. Penso che i classici tre minuti di gara siano
compatibili con gli errori inevitabili di un sistema inerziale.
Questo permetterebbe di evitare gli encoder sulle ruote. Oltretutto
intendo montare l'oggetto su una base lynxmotion a 6 ruote (il sumo
predator) per cui diverrebbe anche difficile evitare gli errori da
pattinamento di una ruota rispetto all'altra.

Ottimo l'accenno che facevi sull'accelerometro ST. Ho trovato un
altro oggetto che funge anche da giroscopio: ADIS16350. Costa di
piu' ma forse rende più semplice l'implementazione completa del
sistema di navigazione evitando anche l'uso della bussola.

Che ne pensate?

John

[Marco d'Ambrosio]

Post by John Fischetti
Forse con gli echi? Mi sembra complicato.

Si è molto complicato, anzi nessuno sa esattamente come l'udito umano
basandosi solo un sistema biaurale riesca a determinare la posizione dei
suoni su 360°.
Dell'orecchio sappiamo tutto dal punto di vista anatomico, ma sappiamo poco
di come vengono elaborate le informazioni, ci sono diverse teorie in
proposito, attualmente la teoria che va per la maggiore è quella
"idrodinamica o spaziale"

*** breve descrizione della teoria presa da un testo di anatomia ***
Le vibrazioni della staffa generano delle onde che si propagano lungo la
chiocciola deformando la membrana basilare e provocando la formazione di
scariche di eccitazione, dovute all'impatto delle ciglia acustiche contro la
membrana tectoria. La regione della membrana basilare, che entra in
vibrazione dipende dall'altezza delle frequenze: iniziale per quelle acute,
media per quelle medie e apicale per quelle basse.
****

Però questa teoria non ci dice come facciamo a percepire i suoni su 360,
pure con discreta precisione nell'identificazione della direzione.
Io non ho certo la pretesa di realizzare un sistema in grado di trovare la
direzione di un suono nell'arco di 360° con solo due microfoni, però mi
aspetto di coprire almeno 120° e di poter determinare la direzione con la
precisione di +/- 2°.
Il vero problema è che sul campo di gara non c'è una sola sorgente a 4 kHz,
ce ne sono diverse e tocca fare in conti con gli echi, le riflessioni e il
rumore di fondo, il che non è poco ne tantomeno semplice.

Post by John Fischetti
Comunque complimenti per l'oggetto che stai sviluppando.

Grazie.

Post by John Fischetti
Io sto lavorando su una idea di navigazione del robot explorer
mediante telecamere e con un sensore inerziale per la rilevazione
della posizione.

Intendi usare una cosa commerciale , tipo la CMUCAM 3, oppure vuoi
realizzare da 0 il sistema di visione artificiale ?
Per il sensore inerziale c'è il problema che a causa delle basse
accelerazioni in gioco, parliamo di decimi, se non centesimi di G, è molto
difficile discriminare le reali accelerazioni dalle vibrazioni della
struttura.
Avevo fatto dei test con i classici ADXL202 realizzando un sensore a due
assi che si comportava come il mouse Logitch se usato a mano su un tavolo,
non appena lo mettevo su una base mobile le misure impazzivano per via delle
vibrazioni, però con gli accelerometri ST dovrebbe essere possibile
risolvere il problema.

Post by John Fischetti
Penso che i classici tre minuti di gara siano
compatibili con gli errori inevitabili di un sistema inerziale.

Penso di si.

Post by John Fischetti
Questo permetterebbe di evitare gli encoder sulle ruote. Oltretutto
intendo montare l'oggetto su una base lynxmotion a 6 ruote (il sumo
predator) per cui diverrebbe anche difficile evitare gli errori da
pattinamento di una ruota rispetto all'altra.

Lo scopo primario degli encoder è far girare in modo controllato i motori in
modo da ridurre al minimo vibrazioni e scatti improvvisi del robot, se vuoi
usare un INS ritengo che l'uso di un pid controller sia inevitabile.

Post by John Fischetti
Ottimo l'accenno che facevi sull'accelerometro ST. Ho trovato un
altro oggetto che funge anche da giroscopio: ADIS16350. Costa di
piu' ma forse rende più semplice l'implementazione completa del
sistema di navigazione evitando anche l'uso della bussola.

Adesso mi vado a vedere il gyro, però trovo meglio l'uso della bussola
perchè è un riferimento assoluto e non relativo come il gyro, è vero che
nell'uso indoor le bussole non indicano il nord magnetico perchè sono
influenxate dai campi magnetici presenti, comunque compensabili se sono di
natura statica, ma in tutti i casi fornisce una lettura precisa riferita ad
un punto 0 fatto al momento dell'accensione, nell'ottica della gara
Explorer sicuramente una bussola, meglio se del tipo a fluxgate, è
decisamente più precisa di un gyro.

Ciao

Marco d'Ambrosio

[Marco d'Ambrosio]

Post by John Fischetti
Forse con gli echi? Mi sembra complicato.

Si è molto complicato, anzi nessuno sa esattamente come l'udito umano
basandosi solo un sistema biaurale riesca a determinare la posizione dei
suoni su 360°.
Dell'orecchio sappiamo tutto dal punto di vista anatomico, ma sappiamo poco
di come vengono elaborate le informazioni, ci sono diverse teorie in
proposito, attualmente la teoria che va per la maggiore è quella
"idrodinamica o spaziale"

*** breve descrizione della teoria presa da un testo di anatomia ***
Le vibrazioni della staffa generano delle onde che si propagano lungo la
chiocciola deformando la membrana basilare e provocando la formazione di
scariche di eccitazione, dovute all'impatto delle ciglia acustiche contro la
membrana tectoria. La regione della membrana basilare, che entra in
vibrazione dipende dall'altezza delle frequenze: iniziale per quelle acute,
media per quelle medie e apicale per quelle basse.
****

Però questa teoria non ci dice come facciamo a percepire i suoni su 360,
pure con discreta precisione nell'identificazione della direzione.
Io non ho certo la pretesa di realizzare un sistema in grado di trovare la
direzione di un suono nell'arco di 360° con solo due microfoni, però mi
aspetto di coprire almeno 120° e di poter determinare la direzione con la
precisione di +/- 2°.
Il vero problema è che sul campo di gara non c'è una sola sorgente a 4 kHz,
ce ne sono diverse e tocca fare in conti con gli echi, le riflessioni e il
rumore di fondo, il che non è poco ne tantomeno semplice.

Post by John Fischetti
Comunque complimenti per l'oggetto che stai sviluppando.

Grazie.

Post by John Fischetti
Io sto lavorando su una idea di navigazione del robot explorer
mediante telecamere e con un sensore inerziale per la rilevazione
della posizione.

Intendi usare una cosa commerciale , tipo la CMUCAM 3, oppure vuoi
realizzare da 0 il sistema di visione artificiale ?
Per il sensore inerziale c'è il problema che a causa delle basse
accelerazioni in gioco, parliamo di decimi, se non centesimi di G, è molto
difficile discriminare le reali accelerazioni dalle vibrazioni della
struttura.
Avevo fatto dei test con i classici ADXL202 realizzando un sensore a due
assi che si comportava come il mouse Logitch se usato a mano su un tavolo,
non appena lo mettevo su una base mobile le misure impazzivano per via delle
vibrazioni, però con gli accelerometri ST dovrebbe essere possibile
risolvere il problema.

Post by John Fischetti
Penso che i classici tre minuti di gara siano
compatibili con gli errori inevitabili di un sistema inerziale.

Penso di si.

Post by John Fischetti
Questo permetterebbe di evitare gli encoder sulle ruote. Oltretutto
intendo montare l'oggetto su una base lynxmotion a 6 ruote (il sumo
predator) per cui diverrebbe anche difficile evitare gli errori da
pattinamento di una ruota rispetto all'altra.

Lo scopo primario degli encoder è far girare in modo controllato i motori in
modo da ridurre al minimo vibrazioni e scatti improvvisi del robot, se vuoi
usare un INS ritengo che l'uso di un pid controller sia inevitabile.

Post by John Fischetti
Ottimo l'accenno che facevi sull'accelerometro ST. Ho trovato un
altro oggetto che funge anche da giroscopio: ADIS16350. Costa di
piu' ma forse rende più semplice l'implementazione completa del
sistema di navigazione evitando anche l'uso della bussola.

Adesso mi vado a vedere il gyro, però trovo meglio l'uso della bussola
perchè è un riferimento assoluto e non relativo come il gyro, è vero che
nell'uso indoor le bussole non indicano il nord magnetico perchè sono
influenxate dai campi magnetici presenti, comunque compensabili se sono di
natura statica, ma in tutti i casi fornisce una lettura precisa riferita ad
un punto 0 fatto al momento dell'accensione, nell'ottica della gara
Explorer sicuramente una bussola, meglio se del tipo a fluxgate, è
decisamente più precisa di un gyro.

Ciao

Marco d'Ambrosio

[John Fischetti]

Post by Marco d'Ambrosio
Io non ho certo la pretesa di realizzare un sistema in grado di
trovare la direzione di un suono nell'arco di 360° con solo due
microfoni, però mi aspetto di coprire almeno 120° e di poter
determinare la direzione con la precisione di +/- 2°.
Il vero problema è che sul campo di gara non c'è una sola sorgente
a 4 kHz, ce ne sono diverse e tocca fare in conti con gli echi, le
riflessioni e il rumore di fondo, il che non è poco ne tantomeno
semplice.

Ti aspetti davvero un ottimo risultato. Forse una buona strada
consiste nel tenere bassa la sensibilità dei microfoni per evitare
interferenze dalle altre sorgenti e dagli echi. Non so quasi niente
di acustica, ma penso che la legge di distribuzione della "potenza"
sia quadratica o addirittura cubica rispetto alla distanza, visto
che ha a che fare con volumi di aria da spostare, e non solo con
superfici di impatto, come accade con la luce. Per questo il nostro
orecchio ha una caratteristica logaritmica e un range molto ampio.

Post by Marco d'Ambrosio
Intendi usare una cosa commerciale , tipo la CMUCAM 3, oppure vuoi
realizzare da 0 il sistema di visione artificiale ?

Ho già acquistato le telecamere (normali CCD in bianco e nero con
illuminatore infrarosso incorporato) e ho adocchiato una scheda di
acquisizione e quattro canali su PC104+ a basso costo (circa 120$).
Sto cercando una scheda con un processore decente (pentium 2 a 500
MHz o simili) che mi consenta di far girare gli algoritmi di
riconoscimento e vettorializzazione del contorni ad almeno 30 frame
al secondo.

Per la gestione del sensore inerziale e dei motori invece penso
all'uso di un dsPIC30Fqualcosa. Tenendo bassa la velocità
dell'anello di reazione dovrei farcela a usare lo stesso sistema
inerziale come sensore di velocità ed evitare così gli encoder sui
motori. Tutto da sperimentare.

Stessa cosa per la bussola. Se il gyro mi da' un riferimento stabile
per tre minuti dovrei evitare la bussola. Altrimenti saro' costretto
a installare anche quest'ultima, ma allora il problema e' quello dei
campi magnetici generati dallo stesso robot, dal motori e dalla
corrente di alimentazione che scorre nei cablaggi.

Vedremo.

Bye.

John

[Marco d'Ambrosio]

Post by John Fischetti
Ti aspetti davvero un ottimo risultato.

Diciamo che spero di ottenerlo, per il momento sono in grado di trovare una
singola sorgente sonora, con basso rumore di fondo, con la precisione di 0.5
gradi, ma c'è ancora molto lavoro da fare per risolvere i problemi legati
alla presenza delle altre sorgenti e dei vari echi.

Post by John Fischetti
consiste nel tenere bassa la sensibilità dei microfoni per evitare
interferenze dalle altre sorgenti e dagli echi.

Attualmente l'analogica ha un gain variabile tra 75 e 1500 sotto il diretto
controllo del micro tramite potenziometro digitale, in questo modo posso sia
calibrare il sistema senza dover smanettare con trimmer vari e sopratutto
posso attenuare i disturbi mano a mano che mi avvicino alla fonte isolandola
dal resto del rumore.

Post by John Fischetti
Non so quasi niente di acustica, ma penso che la legge di distribuzione
della "potenza"
sia quadratica o addirittura cubica rispetto alla distanza, visto

Il suono si attenua con il quadrato della distanza in propagazione diretta,
per gli echi c'è un fattore aggiuntivo legato al materiale che in parte
assorbe l'energia acustica.
Questo tipo di attenuazione nel nostro caso fa pure comodo perchè le
sorgenti sonore si trovano abbastanza vicino al robot e possiedono un
elevato livello, chi ha visto una gara di Explorer sa bene quanto da
fastidio il fischio a 4kHz quando si è vicini al campo, mentre le varie
sorgenti del rumore ambientale sono tutte poste a distanza di gran lunga
maggiori e sono anche minori come livello anche se la loro sommatoria
produce una discreta pressione acustica quasi costante per tutto l'ambiente.

Post by John Fischetti
addocchiato una scheda di acquisizione e quattro canali su PC104+ a basso
costo (circa 120$).

Interessante, dove si compra questa scheda ?

Post by John Fischetti
Sto cercando una scheda con un processore decente (pentium 2 a 500
MHz o simili) che mi consenta di far girare gli algoritmi di
riconoscimento e vettorializzazione del contorni ad almeno 30 frame
al secondo.

Una nano ITX dovrebbe andarti bene, dimensioni contenute e prestazioni
paragonabili a quelle di un celeron 800, se gli metti sopra un RTOS leggero,
tipo QNX lite, sei a posto e puoi sfruttare le Open CV tranquillamente.

Post by John Fischetti
Per la gestione del sensore inerziale e dei motori invece penso
all'uso di un dsPIC30Fqualcosa.

Guardati la nuova serie 33, ora ci sono pure alcuni modelli in DIP28, p.e.
33FJ12MC202 , 40 mips fanno sempre comodo.

Ciao

Marco d'Ambrosio

[John Fischetti]

Post by Marco d'Ambrosio

Post by John Fischetti
addocchiato una scheda di acquisizione e quattro canali su PC104+
a basso costo (circa 120$).

Interessante, dove si compra questa scheda ?

La scheda è la IEI PM-1056 e si trova presso BWI a quel prezzo.

http://www.bwi.com/

http://www.bwi.com/prodroot/488452

Hanno anche interessanti schede PC104+ per il processore.

Post by Marco d'Ambrosio
Una nano ITX dovrebbe andarti bene, dimensioni contenute e
prestazioni paragonabili a quelle di un celeron 800, se gli metti
sopra un RTOS leggero, tipo QNX lite, sei a posto e puoi sfruttare
le Open CV tranquillamente.

Ma ne esistono con bus PC104+ ? Altrimenti devo cercare un'altra
scheda di acquisizione.

Post by Marco d'Ambrosio
Guardati la nuova serie 33, ora ci sono pure alcuni modelli in
DIP28, p.e. 33FJ12MC202 , 40 mips fanno sempre comodo.

Provero' a vedere. Grazie.

Bye.

John

[John Fischetti]

Post by Marco d'Ambrosio
Attualmente l'analogica ha un gain variabile tra 75 e 1500 sotto il
diretto controllo del micro tramite potenziometro digitale, in
questo modo posso sia calibrare il sistema senza dover smanettare
con trimmer vari e sopratutto posso attenuare i disturbi mano a mano
che mi avvicino alla fonte isolandola dal resto del rumore.

Dimenticavo... furbo :-)

Ma con questo hai disvelato quasi tutto il "top secret". :-)

John

[Marco F.]

Post by Marco d'Ambrosio
Diciamo che spero di ottenerlo, per il momento sono in grado di trovare una
singola sorgente sonora, con basso rumore di fondo, con la precisione di 0.5
gradi, ma c'è ancora molto lavoro da fare per risolvere i problemi legati
alla presenza delle altre sorgenti e dei vari echi.

Mezzo grado! complimenti!!

Non so se può essere utile o semplicemente ricollegarsi ai post fatti su
questioni anatomiche dell'orecchio ecc. ma volevo far notare che in alcune
schede audio, il SW per la gestione delle performance della scheda ha tra i
test oltre a far passare il suono tra destra e sinistra anche l'effetto 360
gradi che viene simulato da una mosca che ti ronza attorno, l'effetto con le
4 casse è piuttosto realistico ma anche con due casse l'idea che da è
accettabile, forse, ma è solo un'idea, vedendo come è gestito il segnale per
simulare le varie posizioni si può fare un percorso a ritroso.

Ciao

[Guido Ottaviani]

Post by Marco d'Ambrosio
di alimentazione principale, per quest'ultima è già stato fatto il cablaggio
di base con tanto di interruttori per l'accensione elettronica e potenza
motori.

Cosa intendi per accensione elettronica?

Non mi ricordavo che avessi usato un motore a scoppio :-)

ciao
Guido

[Marco d'Ambrosio]

Post by Guido Ottaviani
Cosa intendi per accensione elettronica?
Non mi ricordavo che avessi usato un motore a scoppio :-)

Infatti uso due microturbine camuffate da motoriduttori :-)

Ciao

Marco d'Ambrosio

[Stefano M.]

Post by Marco d'Ambrosio
Saggio consiglio, inclusi tutti i tool abbinati al simulatore.
Tra l'altro con questa release di MPLAB è stato ampliato il supporto allo
spice di Proteus, ora è possibile simulare anche graficamente i circuiti,
per molti test non serve nemmeno disegnare lo schema dato che sono
disponibili di serie la virtualizzazione della PICDEM2 Microchip, con sopra
il 16F877 o il 18F452 a scelta, e la stupenda explorer 16 con sopra un PIC
24FJ128

Ecco qui devo studiare ancora molto.

Saluti Nonno

[Stefano M.]

Come dicevo prima in pratica non è così facile, ma in linea teorica
si capisce bene cosa bisogna fare.

Ciao Nonno

PS con l'MPLAB mi difendo bene, anche se ancora devo imparare molto.

Post by Guido Ottaviani

Post by Marco d'Ambrosio
p.s.
Lo so che tutto questo sembra complicato, infatti lo è :-)
Ciao
Marco d'Ambrosio

E non potrebbe essere altrimenti. Stiamo parlando di eventi che
scatenano interrupt con tempi paragonabili a quelli di esecuzione
delle routine. Si deve tener conto in ogni momento di quello che
sta accadendo intorno e con gli interrupt, asincroni per

definizione,

Post by Guido Ottaviani
non è sempre semplice ne prevederlo ne debuggarlo.
Certo, avendo a disposizione 30 Mips e un vettore di interrupt
con priorità assegnabile a piacere per ogni periferica c'è un po'
più di tempo per fare le cose ma i tempi sono comunque stretti
e quello che si fa dentro una ISR deve essere sempre ridotto al
minimo o, comunque, va previsto ogni comportamento.
Per semplificarsi la vita, consiglio vivamente di studiarsi bene
il simulatore dell'MPLAB.
Si riesce a provare quasi tutto, anche gli interrupt.
Si possono analizzare gli stati delle porte in tempo reale con il
logic analyzer, iniettare segnali analogici e digitali, a qualsiasi
frequenza e con qualsiasi duty cycle.
Si possono vedere in real time le variabili con il "Data monitor
and control interface".
Si riesce a sapere esattamente il tempo di esecuzione di ogni
pezzetto del proprio codice.
Si riescono a scoprire molti bug prima ancora di alimentare il
circuito. Dopo diventa più difficile e richiede l'utilizzo di
generatori di segnali, oscilloscopi o analizzatori di stati logici
che sono, sicuramente, più costosi e più difficili da usare.
ciao
Guido

[Stefano M.]

Post by Marco d'Ambrosio

Post by Stefano M.
Leggendo il post pensavo di poter sfruttare la ISR per
impostare una risposta veloce, invece non è consigliabile.

Non è così, alla fine di un pacchetto, se i due header e il cheksum
risultano corretti, viene attivato il flag per il parser che poi verrà
invocato dal main, le risposte su I2C sono automatiche e sono

gestite

Post by Marco d'Ambrosio
direttamente dal ciclo pid, in pratica c'è un vettore che contiene la
stringa di risposta e questo vettore viene aggiornato ad ogni ciclo pid,
l'ISR si limita a trasmettere il vettore quando richiesto (ogni 10 ms).

Volevo dire che se attivi il parser in una task chiamata dal main
questa dovra attendere il suo turno, in pratica aspetterà che le
rutine più importanti o che vengono prima nella scaletta del main
eseguano il loro codice.

Ovviamente se te tieni un buffer gia pieno con gli ultimi dati e lo
invii ciclicamente aggiornandolo quando puoi il tutto funziona lo
stesso.

questo funziona anche per una richiesta del tipo stai andando a
sbattere, lo slave ha già il buffer da inviare pronto e lo invia
nella ISR, se lo stato cambia, all'interno della task che gestisce i
sensori verra modificato il buffer da inviare, alla prossima
richiesta lo slave risponderà diversamente, con i nuovi dati inseriti
nel buffer.

Però nn funziona se servono dati in tempo reale tipo quanti tic sono
stati fatti dalla ruota adesso .... non al tempo x, oppure se la
domanda del master può chiedere decine di paramatri ai quali va
risposto sempre con un pacchetto di soli 10 byte, in questi casi è
ovvio che prima si devono elaborare i dati poi metterli nel buffer e
infine inviarli.

Io in questi casi (per ora solo in teoria) rispondo con una stringa
che dice al master di riproporre la domanda più tardi, così non tengo
bloccato il bus e al contempo rispondo entro il timeout del bus, alla
successiva richiesta potrò rispondere con congruenza alla domanda.

Post by Marco d'Ambrosio
p.s.
Lo so che tutto questo sembra complicato, infatti lo è :-)

In teoria non è per nulla complicato *_*, ti seguo come un bambino
che vede nutella davanti a se ..... in pratica magari è difficile
anche accendere un led se uno non ci a mai provato.

Ciao Nonno

[Marco d'Ambrosio]

Post by Stefano M.
Volevo dire che se attivi il parser in una task chiamata dal main
questa dovra attendere il suo turno, in pratica aspetterà che le
rutine più importanti o che vengono prima nella scaletta del main
eseguano il loro codice.

Certamente, in tutti i casi quando si scrive il software si tiene conto
delle priorità e di quali routine devono essere eseguite per prime,
solitamente i parser sono sempre a bassa priorità rispetto al resto del
programma, nel mio caso il parser viene eseguito dentro il ciclo principale
che si ripete ogni ms, un timer dedicato stabilisce quando eseguire la main,
se l'ISR ha messo a 1 il flag del parser questo viene immediatamente
eseguito all'interno del ciclo corrente.

Post by Stefano M.
Ovviamente se te tieni un buffer gia pieno con gli ultimi dati e lo
invii ciclicamente aggiornandolo quando puoi il tutto funziona lo
stesso.

Si ma queste sono due cose diverse, il parser è legato alle operazioni
write, cioè il master invia dei byte allo slave, byte che vanno a comporre
la stringa di comando, questo avviene ogni qualche secondo durante il
normale funzionamento del robot, o comunque ogni volta che il cervello
principale decide di far muovere il robot.
La read operation, cioè il master chiede allo slave l'invio di dati, è
assistita dall'array che ti dicevo prima, l'array viene aggiornato ad ogni
ciclo pid, nel momento in cui arriva la richiesta di read i byte contenuti
nell'array sono inviati al master, questa operazione può anche avvenire a
cavallo tra due cicli pid.

Post by Stefano M.
Però nn funziona se servono dati in tempo reale tipo quanti tic sono
stati fatti dalla ruota adesso .... non al tempo x, oppure se la
domanda del master può chiedere decine di paramatri ai quali va
risposto sempre con un pacchetto di soli 10 byte, in questi casi è
ovvio che prima si devono elaborare i dati poi metterli nel buffer e
infine inviarli.

Questa non l'ho capita, se c'è una cosa che funziona real time è proprio un
pid dove tutti gli eventi seguono una ben precisa scaletta cronologica, il
concetto di real time quando si applica ad un computer comporta sempre una
quantizzazione temporale, l'importante è che questi tempi devono essere
precisi e ripetibili.
Il pid ha un ciclo macchina di 1 ms, durante questo tempo vengono eseguite
tutte le varie routine dle programma, in particolare ad ogni inzio ciclo,
con precisione di 0.1 us sull'istante di avvio, viene letta la periferica
QEI dalla quale ottengo gli impulsi encoder dall'ultima lettura e la
velocità istantanea sotto forma di periodo, leggere questi dati in altri
momenti non solo non serve ma è pure deleterio per il funzionamento del pid.
Il governor interroga i due pid ogni 10 ms, ottiene posizione attuale,
velocità corrente e stato pid, questo significa che sul bus I2C ci sono
costantemente 200 interrogazioni al secondo, 100 per ogni pid, andare più
veloce non serve per quello che deve fare il governor, poi a sua volta il
governor comunica i sui dati al cervello principale dle robot quando gli
viene richiesto.

Post by Stefano M.
Io in questi casi (per ora solo in teoria) rispondo con una stringa
che dice al master di riproporre la domanda più tardi, così non tengo
bloccato il bus e al contempo rispondo entro il timeout del bus, alla
successiva richiesta potrò rispondere con congruenza alla domanda.

Tutto dipende da quello che devi fare, ogni programma ha una sua storia e le
sue soluzioni, non esiste una regola generale che risolve tutti i problemi,
non a caso oltre che all'indispensabile teoria serve anche tanta esperienza
pratica.

Ciao

Marco d'Ambrosio

[Stefano M.]

Post by Marco d'Ambrosio
non a caso oltre che all'indispensabile teoria serve anche tanta esperienza
pratica.

Già, ed io non ne ho così tanta .....

Ciao Nonno

[bobboteck]

Cavolo manco una settimana e guarda quanti messaggi arrivano, vi siete
scatenati!

Bene, vedo che l'argomento I2C slave interessa a molti, volevo sapere se
è mai arrivata una mia mail dove ho rimandato il codice SLAVE scritto da
me sulla base di quello di Marco. Purtroppo il tutto continua a non
funzionare, l'avevo mandato per avere un parere da Marco se era scritta
bene la routine di gestione dell'interrupt.
Se non è arrivato lo rimando, scusate, ma ho un po' di problemi con la
posta inviata al gruppo usando Gmail e Thunderbird.

Bobbo

[Marco d'Ambrosio]

Post by bobboteck
Bene, vedo che l'argomento I2C slave interessa a molti, volevo sapere se
è mai arrivata una mia mail dove ho rimandato il codice SLAVE scritto da
me sulla base di quello di Marco.

Per arrivare è arrivato, però non ho avuto tempo per guardare bene il
codice.

Ciao

Marco d'Ambrosio

[Spad 05]

A parte l'indubbia utilita' didattica per unneofita dei pic, sinceramente non trovo troppo difficoltosa la cosa. Peraltro l'i2c slave e' gestito via hardware il che vuol dire non dover controllare il clock del master per sapere se c'e' un bit in arrivo.

Tuttosommato nella ISR basta fare una piccola macchina a stati, vedere se il master scrive o legge, vedere se ha mandato addr e se e' il tuo, leggere o scrivere il byte.... e ovviamente resettare i flag dove necessario e dare gli opportuni ack.... Insomma, la prima volta mi fara' un po' tribolare, ma non credo che ci moriro' :)

Per rispondere a nonno, e' vero che ho fatto il reverse eng del protocollo del pad ps2, pero' li sono sempre il master.... lo do' io il clock, e alla fine sono 2-3 funzioni....


To: roboteck-hHKSG33Tihig7M29m/***@public.gmane.org: nonno_62-***@public.gmane.org: Sat, 18 Aug 2007 09:41:56 +0000Subject: [roboteck] Ogg: MPLAB 7.62




Infatti! Saverio deve far dialogare solo due PIC.Comunque è ovvio che hai ragione sia tu che Saverio, usare la i2c è più affidabile e poi dopo aver fatto le routine si possono sempre riusare per altri lavori. Io volevo dire che se era roso dalla voglia di far correre "subito" il ragno dietro al bimbo ...... poteva prendere in considerazione l'opzione seriale, tutto qui. Opzione bocciata, non insisto, anzi ragionandoci bene magari in C con la seriale software si incasinerebbe la vita più che l'i2c .....Ciao Nonno--- In roboteck-***@public.gmane.org, Marco d'Ambrosio <***@...> ha scritto:>> >Parlavo di usare una seriale simulata in software .... io l'ho fatto> >su un 16f628 (partendo dal an585) e non mi è sembrato così> >scandaloso.> > La seriale software è poco efficiente, consuma molto tempo CPU, in tutti i > casi c'è sempre il problema che puoi dialogare solo con un altro IC e non > con più IC in parallelo come si fa con l'I2C.> > Ciao> > Marco d'Ambrosio>


_________________________________________________________________
Cinema, Tv, Gossip e Oroscopo… Tutto su MSN Intrattenimento!
http://intrattenimento.it.msn.com/

[Sono state eliminare la parti non di testo del messaggio]