MSIP SPI de PIC = rareza, pero ¿funciona el bit banging?

2

Estoy tratando de obtener un PIC16LF1825 para comunicarme con un ADXL362 esclavo sobre SPI en 1.8v.

Primero probé el MSSP (puerto serie de PIC) configurado para hardware SPI a 4MHz FOSC, tasa de SPI de 1MHz (mínimo recomendado por ADXL) a 3.2v. Funcionó, produciendo los siguientes SCK y MOSI para el ADXL:

TengaencuentaquelaMOSIsemantienealtaentrebytes.Elprimerbyteenviadoes0x0B(comandoderegistrodelectura),seguidodeun0x00(IDdedispositivo).Asíqueeltercerbytedeberíaserlosdatosdevueltos...

LoqueelADXLdevolviósinembargo,fueincorrecto.Deberíaser0xAD,peroensulugarobtuvetodotipodevaloresincorrectos,semuestra0x90.ProbétodoslosmodosCPOLyCPHAenvano.¿SeestámanteniendoelMOSIaltoentrelosbytescausandolacorrupcióndelosdatosinterpretadosporelADXL?Nolopensaría...Lomásextrañoesqueestevalordevueltocambiaría,aparentementedemaneraaleatoria,apesardequenadaleestabasucediendoaSCKolosotrospines.Verifiquéunpatróncontraposiblesvaloresdevueltos(¿estabamostrandoelcontenidorealdelregistro?)Peronoencontrécorrelación.Ladesconexióndelassondasdealcance(capacitanciaparásita)notuvoningúnefecto.ElcódigoXC8queprobéinicialmenteteníaesteaspecto:

/*RoutinetofullyexchangeabytewiththeADXL362-requiresMSSP*/externuint8_tExchangeADXL(uint8_ttxCommand,uint8_ttxAddress,uint8_ttxData){SS_ADXL_SetLow();//SSlowSSP1CON1bits.WCOL=0;//clearanywritecollisionflagSSPBUF=txCommand;//sendread/write/fifobytewhile(!SSP1STATbits.BF);//waitforexchangeSSPBUF=txAddress;//sendaddressbytewhile(!SSP1STATbits.BF);//waitforexchangeSSPBUF=txData;//sendbyteordummybytewhile(!SSP1STATbits.BF);//waitforexchange(readresult)SS_ADXL_SetHigh();//SShighreturn(SSPBUF);//returnresult}

EstoestáusandoelConfiguradordeCódigodeMicrochip(MCC)paragenerarunaconfiguracióndelíneadebaseparaeldispositivo(eltiempoesalgoesencial,porsupuesto).

Entoncesintentégolpearlosbits.Asíqueescribíunfragmentodecódigodeaspectorealmentevelludo,específicamenteparadejarqueMOSIsecoloqueentrelosbytes,¡yfuncionó!(ElFOSCseredujoa250kHzyVdda1.8vaquí).

Sinembargo,tengaencuentael"ruido" en la línea MISO. Esto es nuevo y no estaba allí antes. Revisó dos veces todas las mayúsculas de derivación, las bases, los Vdd, las interferencias, las sondas de alcance, etc. No tengo idea de lo que lo está causando aparte del ADXL.

De todos modos, volví a cambiar el código para usar el MSSP en lugar del bit bit, para ver si el hardware funcionaría a una velocidad muy reducida. Los comandos se envían muy claramente al ADXL, pero lo único que devuelve es lo siguiente:

¿Alguien tendría alguna idea de lo que está pasando aquí? El ruido no es una gran preocupación ... la falta de respuesta es. Respondió (erróneamente) antes a una tasa SPI de 62.5 hHz y 1.8v, ahora no está haciendo nada y el ruido es visible . Preferiría usar el controlador de hardware para SPI si es posible.

(No se muestra), SS se está comportando como debería para todas las instancias. Por lo que puedo decir, todos los tiempos están dentro de las especificaciones de la hoja de datos de ADXL bastante exigente. Gracias por su ayuda!

    
pregunta rdtsc

2 respuestas

2

Encontré el problema. De hecho, era el reloj alto entre bytes. Bueno no exactamente; fue que el ADXL estaba malinterpretando el segundo byte debido a que el reloj estaba alto al inicio inicio del segundo byte. Lo que es bastante ambiguo, ya que la hoja de datos ADXL muestra claramente en el diagrama de tiempo que el reloj está bajo antes de la transmisión, y bajo después. En esa configuración, no funcionaría. En la configuración del reloj opuesto, desafiando la hoja de datos, funciona.

La solución fue invertir el borde del reloj en el software:

Intentéestoantes,peronohizonada...probablementeuncasodetratardehacerdemasiadascosasdemasiadorápido.

ElMOSIyMISOresultantes(FOSCde250kHz,tasaSPIde62.5kHz,1.8v)es:

El PIC puede leer la respuesta correcta, 0xAD. Todavía hay algo de ruido en MISO antes de que ADXL dirija la línea, pero cuando lo hace, es muy nítido y claro.

La depuración de SPI hubiera sido imposible sin un DSO.

    
respondido por el rdtsc
1

Su pregunta es demasiado larga para leerla en su totalidad, pero por un momento, parece que se ha olvidado de la línea de selección de esclavos. No solo tiene que ser afirmado para que el dispositivo escuche y responda, sino que también suele usarse para sincronizar el inicio de paquetes. No puedes dejar la selección de esclavos activada todo el tiempo.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas