TODOPIC
Microcontroladores PIC => Pic32 => Mensaje iniciado por: migsantiago en 30 de Noviembre de 2014, 19:58:48
-
Hola :mrgreen:
Trabajando en un proyecto con el amigo Akenafab estamos usando un PIC32MZ1024ECG100. Como es un micro nuevo de Microchip pues va a traer errores en el silicio y en su compilador y demás detalles incómodos.
Aquí la errata...
http://ww1.microchip.com/downloads/en/DeviceDoc/80000588E.pdf
El primero con el que me topo... el oscilador primario de 24MHz basado en cristal no funciona. El micro lleva un cristal de 24MHz que se divide internamente en 3, se multiplica por 50 y se divide en 2 para obtener los 200MHz del System Clock. Desafortunadamente a los de Microchip se les olvidó agregar una pull-up en OSC2 y el cristal jamás oscila... sólo tocando con los dedos a veces me funcionaba.
La solución sugerida es colocar una pull-up de 10k a 3V3, pero lo hice y funcionó una sóla vez. Medí con el osciloscopio OSC2 para ver cómo oscilaba el cristal y dejó de oscilar.
La sugerencia real... usar el FRC interno. Funciona a 8MHz y puede entrar al PLL y elevarse a 200MHz como el POSC. Un poco desafortunado ya que el cristal debería usarse para tener un USB clock preciso para High Speed, no sé si con el FRC también se pueda lograr.
Si llego a encontrar otro glitch tan incómodo como éste se los compartiré. Saludos.
-
Yo no entiendo como con un error asi tan grande pueden liberar a la venta un IC. Por que me parece realmente grande el error :/
Digo.... no van a sacar una partida y ponerle un cristal para ver si oscila ?
-
Y tanto....pedazo de cagada :shock:
-
Lo han sacado en modo "prueba" o beta como algunos llaman, es logico ya que los usuarios son los que mas cuenta se dan de los bugs entonces les viene bien que los clientes les "echen una mano" es la moda ahora, los juegos tambien los sacan beta para que la gente lo vaya probando y vaya reportando los fallos, asi se ahorran bastante tiempo y dinero en probarlos ellos mismos...
De todas formas lo bueno que tiene microchip esq si dan problemas asi te cambian el MCU sin poner pegas, yo compre unos pics que segun microchip fallaban en el modulo ADC, sin saberlo recibi un mail de microchip comentandomelo y diciendome que si queria me los podian reemplazar/devolverme el dinero, pero como no usaba el ADC me dio igual...
-
Sí, es muy desafortunado. Sin el cristal no puedo echar a volar el USB.
En la nueva versión de nuestra PCB tendremos que oscilar el cristal por fuera e inyectar los 24MHz en modo EC al PIC. Sólo así se puede proporcionar la señal de 24MHz al USB PLL.
También ayer me di varios topes con Harmony. El echar a andar la SD Card con SPI y DMA no es cosa fácil... al menos como principiante. :(
-
Lo han sacado en modo "prueba" o beta como algunos llaman, es logico ya que los usuarios son los que mas cuenta se dan de los bugs entonces les viene bien que los clientes les "echen una mano" es la moda ahora, los juegos tambien los sacan beta para que la gente lo vaya probando y vaya reportando los fallos, asi se ahorran bastante tiempo y dinero en probarlos ellos mismos...
De todas formas lo bueno que tiene microchip esq si dan problemas asi te cambian el MCU sin poner pegas, yo compre unos pics que segun microchip fallaban en el modulo ADC, sin saberlo recibi un mail de microchip comentandomelo y diciendome que si queria me los podian reemplazar/devolverme el dinero, pero como no usaba el ADC me dio igual...
Lo entiendo perfectamente. Si uno quiere probar rigurosamente las cosas no te queda otra que liberarlo a las masas y de tantas pruebas ver que no funciona, el software siempre ah sido asi.
Hasta la placa que compre de TI que deberia tener un TM4C1294NCPT , es XM4C1294NCPT, cuando mire decia que era experimental. pero hasta ahora no encontre ningun error, es decir no tuve ningun problema.
Y el tema pasa por que... es el oscilador, no es ni siquiera un perifierico como vos decis que fue el AD en tu caso. Si pones un micro y no arranca algo anda mal, creo que es lo MINIMO a probar. Pongan un programita que asigne salida y ponga a 1 todas las salidas asi como tambien leerlas, ADC tmb. SPI UART: al menos un envio/recepcion y luego liberarlo. En el tiempo de desarrollo de ese micro seguro que tuvieron tiempo en hacer el codigo.
Hay una fase de pruebas inicial para sacar los errores mas grandes y asi liberarlo para asi detectar los errores minisculos o que sucedan aleatoriamente y que no se discriminaron al comienzo. Sino el costo del envio de los integrados los asesina a Microchip o la compañia que sea si tuvieran que cambiar todos. Por que el oscilador es yo lo categorizaria como "Principal" para el funcionamiento de un integrado.
Igual mig
Con esa frecuencia, SPI DMA SD , un hermosos datalogger de USB High Speed :3
-
Igual mig
Con esa frecuencia, SPI DMA SD , un hermosos datalogger de USB High Speed :3
¡Ojalá! Ahorita el rendimiento que tengo del micro es bajo, puedo hacer toggle de GPIOs a 1MHz. Ya tiene la caché ROM habilitada, pero faltan las optimizaciones PRO.
Quise instalar el modo de evaluación de XC32, desde web, desde consola y ningún método me funciona. Sin optimizaciones el micro es tan lento como sus hermanos menores PIC16/18. :5]
-
Igual yo dije eso pero no se mig, los perifericos trabajan tambien a esa frecuencia ?
O trabajan con Fosc / 4 como las versiones PIC16/18
O es solo el nucleo el que va a 200Mhz y los perifericos a mucha menor frecuencia ?
-
Los periféricos se alimentan de unos relojes llamados Peripheral Bus Clock. Esos relojes pueden sacarse de varias fuentes, pero su máxima frecuencia tolerada es de 100MHz, o sea, la mitad de la frecuencia máxima del reloj del CPU.
El rendimiento de los PIC32 no es directo, no puedo decirte si 200MHz equivalen a 200MIPS. La equivalencia correcta son los Dhrystone MIPS.
https://en.wikipedia.org/wiki/Dhrystone
El micro corre a 200MHz, pero equivalen a 330DMIPS de acuerdo a Microchip... haciendo necesaria la optimización del compilador en PRO para llegar a tal rendimiento.
http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MZ1024ECG100
Dato curioso... los GPIOs necesitan reloj. El máximo que aceptan también es de 100MHz. No sé aún si es posible hacerlos oscilar tan rápido, sólo he visto en el foro de Microchip que lo han logrado a 20MHz... muy lejanos de mi 1MHz con la versión gratuita del compilador FREE.
Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.
http://ww1.microchip.com/downloads/en/DeviceDoc/60001183B.pdf
-
¿ Alguien sabe porque al conectar un PIC32MZ2048ECH100 con MPLABX y Pickit3, me sale el estado del Pickit3 con 2 puntos amarillos ?, cuando uso un PIC32MX me salen los dos puntos verdes, me da la sensación de que el Pickit3 necesita una actualización de firmware para soportar los PIC32MZ, pero tampoco encuentro en MPLABX como actualizarlo.
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_017_zpsf011eca3.jpg)
He estado mirando en la configuración del proyecto, a ver la revisión del chip, por si está en la lista negra de PIC32MZ chapuceros, y no lo tengo claro. Cuando le doy para que pickit3 lea y recargue, me aparece el ID de dispositivo 5113053 correspondiente al PIC32MZ2048ECH100, pero en Device ID Revisión me pone 30000000 (como se ve en esta captura de pantalla), no tengo claro si es alguna de las revisiones A3, A4 o A5 de chips malos del PDF que ha colgado migsantiago.
Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_016_zps36f9f839.jpg)
Edito: en la ventana Output, pestaña Pickit3, si que me pone que es una revisión A3, pues vaya chufa, dinero tirado a la basura.
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_018_zps4da34f6f.jpg)
-
Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.
http://ww1.microchip.com/downloads/en/DeviceDoc/60001183B.pdf
Lo suyo sería poder ejecutar código desde RAM y no sé si se puede (creo que los cortex M4 sí lo hacen). A 330mips y con una memoria flash por PMP (aunque fuese lenta) y una sram o nor por QSPI sería ideal: no habría forma de "acabarse" el micro. De hecho no sé porque no se implementa ya QSPI en todos los micros: la lógica no es muy compleja y hasta cierta frecuencia no hay mucho problema con las señales single-ended a 3.3V (a 50Mhz se puede leer a 25MB/s que no está nada mal).
Saludos.
-
Dato curioso... los GPIOs necesitan reloj. El máximo que aceptan también es de 100MHz. No sé aún si es posible hacerlos oscilar tan rápido, sólo he visto en el foro de Microchip que lo han logrado a 20MHz... muy lejanos de mi 1MHz con la versión gratuita del compilador FREE.
Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.
Si los DMIPS para mi son una mentira. por que todo depende de la aplicacion. Estos tiene cache y gracias a eso algunos codigos son super rapido pero otros no e.e. Dependeria de tu compilador como mete las instrucciones a la cache.
Y con respecto a cambiar los valores de los puertos, no quedaria otra que ASM ? Si no se tiene mucha idea se podria debuggear y que muestre el ASM asociado al mismo, lo que si no se como lo tomara el compilador que le metas ASM.
-
Lo suyo sería poder ejecutar código desde RAM y no sé si se puede (creo que los cortex M4 sí lo hacen). A 330mips y con una memoria flash por PMP (aunque fuese lenta) y una sram o nor por QSPI sería ideal: no habría forma de "acabarse" el micro. De hecho no sé porque no se implementa ya QSPI en todos los micros: la lógica no es muy compleja y hasta cierta frecuencia no hay mucho problema con las señales single-ended a 3.3V (a 50Mhz se puede leer a 25MB/s que no está nada mal).
Saludos.
Una buena idea, hay micros de 16 bits con apenas 64kB en ROM que son capaces de correr desde RAM, no veo por qué éste no pueda. Es cosa de investigar.
Si los DMIPS para mi son una mentira. por que todo depende de la aplicacion. Estos tiene cache y gracias a eso algunos codigos son super rapido pero otros no e.e. Dependeria de tu compilador como mete las instrucciones a la cache.
Y con respecto a cambiar los valores de los puertos, no quedaria otra que ASM ? Si no se tiene mucha idea se podria debuggear y que muestre el ASM asociado al mismo, lo que si no se como lo tomara el compilador que le metas ASM.
Sí, sería bueno probar, pero prefiero conseguir la licencia de evaluación para agilizar el trabajo. Imagínate terminar todo el proyecto en ASM... jejej
-
Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.
Hola, yo pienso inyectar la salida dividida de 200MHz, siendo de 24MHz, del FRCPLL hacia el POSC, configurado como EC. No me importa mucho la precisión de la señal... por el momento es una prueba y así sí podría usar el USBPLL. Hay que ver qué pasa. :S
-
Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.
Hola, yo pienso inyectar la salida dividida de 200MHz, siendo de 24MHz, del FRCPLL hacia el POSC, configurado como EC. No me importa mucho la precisión de la señal... por el momento es una prueba y así sí podría usar el USBPLL. Hay que ver qué pasa. :S
En los datasheet de los PIC32MX, Microchip recomienda usar el cuarzo para USB, yo nunca lo he probado con el oscilador interno y USB, no se si funcionará. En este caso el A3 que tengo lo usaré para experimentos, pero no lo voy a instalar en un producto final, menudo castaña nos han vendido.
Lo que no se es como está ahora la cosa, ¿ ya podemos comprar un PIC32MZ en condiciones, o siguen sirviendo los, A3, A4 y A5, plagados de problemas ?, ya no se puede uno fiar, porque los proveedores pueden tener en stock todas estas versiones malas hasta que agoten el producto, no hay manera de saberlo hasta que lo conectamos y leemos la versión, es como jugar a la lotería.
-
En los datasheet de los PIC32MX, Microchip recomienda usar el cuarzo para USB, yo nunca lo he probado con el oscilador interno y USB, no se si funcionará. En este caso el A3 que tengo lo usaré para experimentos, pero no lo voy a instalar en un producto final, menudo castaña nos han vendido.
Sin duda. Pero dadas las condiciones y que ya tenemos una PCB hecha... voy a truquearlo (si me da tiempo). La señal de reloj de sistema puede dividirse de nuevo internamente y entregarse en un pin de salida del PIC. Pienso dividir los 200MHz u otra señal compatible y entregar 24MHz por ese REFCLKO. Esos 24MHz los conecto a POSC en modo EC y el PIC ni se enterará de que le estoy dando gato por liebre jejej... espero... porque el gato ya es él :5]
No importa mucho la precisión... sólo es para prueba.
Saludos.
-
Hola migsantiago
me llamo la atencion tu post dado que en my trabajo estoy implementando un Nuevo projecto con dos PIC32MZ y creo que no as leido el datasheet como corresponde .
primero no existe crystal interno , si existe un oscillador RC que debe ser activado correctamente
Segundo el documento de errata señala que lo que no funciona es un resonador ceramic exterior entre OSC1 y OSC2 pero si funciona un crystal de 24Mhz o otra frecuencia que te apetezca.
yo uso un crystal oscillador y no he tenido ningun problema
cita de errata microchip
10. Module: Oscillator
The Ceramic Resonator cannot be used as an
input to the Oscillator module (OSC1/OSC2 pins).
Work around
Instead, use either a crystal oscillator or the
external clock.
Bueno espero que esto aclare un poco la desinformacion
y estos bichitos realmente puedo decir que andan muy bien (no descarto los bugs que es normal que existan )
:-/ Chau a todos
-
Hola migsantiago
me llamo la atencion tu post dado que en my trabajo estoy implementando un Nuevo projecto con dos PIC32MZ y creo que no as leido el datasheet como corresponde .
primero no existe crystal interno , si existe un oscillador RC que debe ser activado correctamente
Segundo el documento de errata señala que lo que no funciona es un resonador ceramic exterior entre OSC1 y OSC2 pero si funciona un crystal de 24Mhz o otra frecuencia que te apetezca.
yo uso un crystal oscillador y no he tenido ningun problema
cita de errata microchip
10. Module: Oscillator
The Ceramic Resonator cannot be used as an
input to the Oscillator module (OSC1/OSC2 pins).
Work around
Instead, use either a crystal oscillator or the
external clock.
Bueno espero que esto aclare un poco la desinformacion
y estos bichitos realmente puedo decir que andan muy bien (no descarto los bugs que es normal que existan )
:-/ Chau a todos
Hola, me interesa leer el documento al que te refieres. Yo leí el que publiqué en el primer post.
http://ww1.microchip.com/downloads/en/DeviceDoc/80000588E.pdf
Yo intenté varias cosas para hacer funcionar el cristal pero ninguna funcionó.
No mencioné que el micro tuviera un cristal interno, sólo mencioné que lleva un cristal de 24MHz, pero me refería a que es externo. Lo que sí es interno es el FRC, que es lo que estoy usando en este momento.
Por favor publica el link del documento que citas para leerlo completo. Gracias.
-
Hola de nuevo CapBlack
Ya encontré la referencia de la que hablas... es un problema ajeno al que yo tengo.
http://ww1.microchip.com/downloads/en/DeviceDoc/80000588F.pdf
Leíste el problema 10, que habla sobre el resonador cerámico.
(http://www.todopic.com.ar/foros/index.php?action=dlattach;topic=43803.0;attach=22971;image)
Por favor checa el problema 41, que habla sobre el oscilador primario con cristal.
(http://www.todopic.com.ar/foros/index.php?action=dlattach;topic=43803.0;attach=22973;image)
Talvez tu micro funciona sin la pull-up o la agregaron en la PCB... no lo sé, pero mi oscilador primario no funciona aun agregando la resistencia.
Saludos.
-
Talvez tu micro funciona sin la pull-up o la agregaron en la PCB... no lo sé, pero mi oscilador primario no funciona aun agregando la resistencia.
Si no lei mal
Si tiene la revision A5 entonces si con la resistencia funcionaria. si tiene la revision A3/4 esta igual que vos xD por mas resistencia que le ponga no funciona.
-
Pues tengo la A5 y puse la pull-up, pero sólo funcionó un rato. Después medí con el osciloscopio y el reloj de desbloqueó y falló. Mejor seguí con FRCPLL. :(
-
No sé si a alguien más le ha pasado que cuando uno crea nuevos archivos en MPLAB X 2.26, los archivos se agregan con rutas absolutas. Cuando uno comparte el proyecto, pues falla la compilación ya que no encuentra los archivos con una ruta relativa.
La solución es remover los archivos y agregarlos de nuevo, pero ahora sí eligiendo la opción Relative Path. Al crearlos no da opción para agregarlos al árbol del proyecto en forma relativa... o al menos no supe encontrarla.
Otra opción es modificar a mano el archivo configurations.xml y corregir los paths que quedaron absolutos. Adjunto el cómo por si a alguien le sirve.
Saludos.
-
Harmony 1.0.2.1 ya está disponible. :mrgreen: Saludos.
-
Gracias, lo acabo de actualizar! :-/
-
Hola, les paso un tip. No es un bug, es una de esas peculiaridades que los compiladores de C pueden implementar a placer.
Tengo declarada esta estructura en XC32:
typedef struct Matrix_Data_Tag
{
uint32_t total_frames; /**< How many frames the matrix will draw */
uint8_t total_submatrixes; /**< How many submatrixes the matrix has (must match size below) */
uint32_t submatrix_total_pixels[4]; /**< How many pixels each submatrix has */
uint8_t biggest_submatrix; /**< which submatrix contains the most pixels, first found */
}Matrix_Data_T;
En un compilador ideal las direcciones (offset) de los siguientes elementos son:
0 - total_frames
4 - total_submatrixes
5 - submatrix_total_pixels[0]
9 - submatrix_total_pixels[1]
13 - submatrix_total_pixels[2]
17 - submatrix_total_pixels[3]
21 - biggest_submatrix
En XC32 para optimizar el manejo de datos, el compilador está asignando estas direcciones...
Matrix_Data; file:../src/app.c] Matrix_Data_T 0x80008184
total_frames] __uint32_t 0x80008184
total_submatrixes] __uint8_t 0x80008188
submatrix_total_pixels] unsigned int[4] 0x8000818C
submatrix_total_pixels[0]] unsigned int 0x8000818C
submatrix_total_pixels[1]] unsigned int 0x80008190
submatrix_total_pixels[2]] unsigned int 0x80008194
submatrix_total_pixels[3]] unsigned int 0x80008198
biggest_submatrix] __uint8_t 0x8000819C
Le conviene más que total_submatrixes pese 4 bytes, pudiendo verlo en su dirección 0x80008188 y viendo que submatrix_total_pixels[0] empieza 4 bytes después.
¿Por qué me afecta este gap o espacio entre elementos? Porque leo los datos desde un arreglo de chars en una SD Card en donde los espacios no existen. Al momento de derreferenciar el arreglo en una estructura los bytes pierden orden.
Para solucionarlo puede copiarse elemento por elemento la estructura desde el arreglo de chars. También se puede usar la palabra clave packed.
typedef struct Matrix_Data_Tag
{
uint32_t total_frames __attribute__ ((packed)); /**< How many frames the matrix will draw */
uint8_t total_submatrixes; /**< How many submatrixes the matrix has (must match size below) */
uint32_t submatrix_total_pixels[4] __attribute__ ((packed)); /**< How many pixels each submatrix has */
uint8_t biggest_submatrix; /**< which submatrix contains the most pixels, first found */
}Matrix_Data_T;
Aparentemente sólo hay que usarla en elementos que no pesan 1 byte. Si se usa en los uint8_t, el compilador avienta un warning.
Haciendo eso, las alineaciones de los elementos ya son conocidas e ideales. :mrgreen: Eso me permite copiar una estructura al vuelo con una derreferenciación.
uint8_t data[SD_CARD_BLOCK_SIZE];
/* The first block always contains the table */
SD_Card_Read(0, data);
/* Copy the data as the expected structure */
Matrix_Data_T Matrix_Data = *((Matrix_Data_T*)data);
(http://www.todopic.com.ar/foros/index.php?action=dlattach;topic=43803.0;attach=23059;image)
Saludos.
-
Tranquilos, algún día vendrá la versión A de los PIC32MZ:
"Regarding the PIC32MZ:
· We are about to release samples of revision A5. Here’s the schedule:
o Limited samples: August
o Production release: September
· I have been told if you use an external reference it can help improve the accuracy of the PIC32MZ ADC. Mark, our FAE, can help if you have questions on this.
· We are working on a new all-layer redesign which will be released as PIC32MZxxxA. This will not only include a new ADC and (hopefully) fix all known errata, but will also include an updated SPI that will improve the speed to 50 Mbps, allow us to introduce E-temp devices, and add the missing FPU. These parts are expected to sample in March 2015 and release to production in June 2015. The ADC will be 12-bit although I don’t have any speed specs at the moment"
http://picforum.ric323.com/viewtopic.php?f=69&t=81
-
jeje Como con el PIC16F84A. Sí, qué bien que están corrigiendo cosas. El PIC32MZ que tengo es muy bueno. :mrgreen:
-
Buena tardes estoy realizando un proyecto con PIC32MZ2048ECM y me gustaría como saber si tengo la versión A5 o superior, ya que necesito el reloj externo si o si, de lo contrario debería cambiar de microcontrolador.
muchas gracias
-
Buena tardes estoy realizando un proyecto con PIC32MZ2048ECM y me gustaría como saber si tengo la versión A5 o superior, ya que necesito el reloj externo si o si, de lo contrario debería cambiar de microcontrolador.
muchas gracias
Cuando conectas el pickit3 y le das conectar.
En su pequeño consola suelta un log.
Saludos!
-
Gracias por contestear AKENAFAB, entonces no hay ninguna manera de saberlo hasta que el micro este en la placa? en mi opinión es un fallo muy grave del microcontrolador, voy a mandar la placa a fabrica y es un dinero para que luego no funcione correctamente o tenga que andar probando micros soldando y desoldando con el riesgo mas que evidente de que se dañen los pad y pistas.
Por cierto en respuesta a los que preguntan si se puede usar el USB con el cristal interno, se que en los pic32mx2xx, no se puede, se que en el diagrama del oscilador existe el camino, pero contacte con el apoyo tecnico de una compañia suministradora de microchip para preguntarlo, y me informo que no es posible, ese camino existe pero solo para algunas funciones del usb en estado latente pero no para funcionar plenamente como comunicación, quiza en los MZ si se pueda no lo se.
-
Por cierto en respuesta a los que preguntan si se puede usar el USB con el cristal interno, se que en los pic32mx2xx, no se puede, se que en el diagrama del oscilador existe el camino, pero contacte con el apoyo tecnico de una compañia suministradora de microchip para preguntarlo, y me informo que no es posible, ese camino existe pero solo para algunas funciones del usb en estado latente pero no para funcionar plenamente como comunicación, quiza en los MZ si se pueda no lo se.
Hola, tal vez sea posible hacer funcionar el USB con el oscilador interno FRCPLL. Necesitarías echar a andar un REFCLK sobre un pin de salida y luego redirigirlo a la entrada POSC en modo clk, no en modo cristal.
Es una teoría, yo la iba a probar pero no me dio tiempo.
-
Es una buena idea, me la apunto para probarla un día en esos diseños en los que esta todo muy apretado, ahorrarte colocar un cristal en el PCB es un alivio :lol:
-
En realidad es obligatorio usar el cristal para mantener una frecuencia estable en USB, sobre todo en High Speed. Si planeas certificar tu dispositivo USB necesitarás una frecuencia limpia, sin jitter, para pasar las pruebas de Eye Diagram por ejemplo.
Esta propuesta de usar el FRCPLL, sacarlo y volverlo a introducir al PIC es sólo un workaround mientras Microchip corrige los issues de su PIC32MZ.
-
Bueno espero que a dia de hoy los micros que van dando de muestras y los que se venden, puedan funcionar correctamente con el cristal externo y la resistencia como indica la errata, tengo muchas ganas de probarlo y no me va a hacer nada de gracia que después de mandar el proyecto a fabrica no funcione debidamente, ya que es un proyecto personal y saldrá de mi bolsillo
-
Veo entre el datasheet y la errata del cristal oscilador externo que si queremos utilizar el USB correctamente, 1º debemos tener el micro con la revisión de silicio "a5", y debemos colocar un cristal de cuarzo de 12 MHz ni mas ni menos
Datasheet: "If the USB module is used, the Primary Oscillator (POSC) is limited to either 12 MHz or 24 MHz."
pero en la errata dice lo siguiente: "Crystals with a speed of 4 MHz to 12 MHz that meet the following requirements will meet the PIC32MZ oscillation requirements when configured as depicted in Figure 8-1."
por lo tanto si realizais algún diseño con usb acordaros a parte de las resistecias de 10K y 1M de que el cristal debe ser de 12MHz espero que os sea útil un saludo
-
Pequeña advertencia... p32mz1024ecg100.h no contiene correctos los bits del registro IFS3 (XC32 v1.34):
typedef union {
struct {
unsigned :6;
unsigned AD1D43IF:1;
unsigned AD1D44IF:1;
unsigned CPCIF:1;
unsigned CFDCIF:1;
unsigned SBIF:1;
unsigned :2;
unsigned SPI1EIF:1;
unsigned SPI1RXIF:1;
unsigned SPI1TXIF:1;
unsigned U1EIF:1;
unsigned U1RXIF:1;
unsigned U1TXIF:1;
unsigned I2C1BIF:1;
unsigned I2C1SIF:1;
unsigned I2C1MIF:1;
unsigned CNAIF:1;
unsigned CNBIF:1;
unsigned CNCIF:1;
unsigned CNDIF:1;
unsigned CNEIF:1;
unsigned CNFIF:1;
unsigned CNGIF:1;
};
struct {
unsigned w:32;
};
} __IFS3bits_t;
extern volatile __IFS3bits_t IFS3bits __asm__ ("IFS3") __attribute__((section("sfrs")));
También está mal el IFC3...
typedef union {
struct {
unsigned :6;
unsigned AD1D43IE:1;
unsigned AD1D44IE:1;
unsigned CPCIE:1;
unsigned CFDCIE:1;
unsigned SBIE:1;
unsigned :2;
unsigned SPI1EIE:1;
unsigned SPI1RXIE:1;
unsigned SPI1TXIE:1;
unsigned U1EIE:1;
unsigned U1RXIE:1;
unsigned U1TXIE:1;
unsigned I2C1BIE:1;
unsigned I2C1SIE:1;
unsigned I2C1MIE:1;
unsigned CNAIE:1;
unsigned CNBIE:1;
unsigned CNCIE:1;
unsigned CNDIE:1;
unsigned CNEIE:1;
unsigned CNFIE:1;
unsigned CNGIE:1;
};
struct {
unsigned w:32;
};
} __IEC3bits_t;
extern volatile __IEC3bits_t IEC3bits __asm__ ("IEC3") __attribute__((section("sfrs")));
Lo pueden comprobar en la datasheet. Saludos.
-
Otro bug para el cajón, en el ultimo seminario de microchip al que asistí los puse bonitos con este tema, hay gente que había hecho sus diseños con la promesa de la gran eficiencia de los pic32mz y han tenido que poner un adC :? Encareciendo el producto.
Por lo visto no van a ofrecer solucion ni nueva revisión del producto abra que esperar a que salga la nueva generación de pic32mz, que por cierto por fin contaran con coma flotante por hardware, algo que le faltaba a los micros de microchip. :-/
Un saludo.
-
Sigo encontrando cosas... pero ésta no la puedo confirmar aún. Si utilizo la variable SPIxBUF que define el h...
extern volatile unsigned int SPI2BUF __attribute__((section("sfrs")));
Veo glitches en la escritura de SDOx.
Pero si yo mismo declaro la variable...
#define SPI2BUFFER (*(volatile uint32_t*)(0xBF821220))
Se remueven los glitches.
La variable SPIxBUF es extern, imagino que viene ya definida en una librería precompilada... tal vez plib.
:S
Busqué la errata del PIC y no ha cambiado... :?
-
La variable SPIxBUF es extern, imagino que viene ya definida en una librería precompilada... tal vez plib.
Las plib están siendo eliminadas si eso no funciona ya no lo van a arreglar, prueba con las harmony que ya tienen versión 1.0 pero ya sabes.... no te fíes del editor de código, sea de microchip o de quien sea.
Un saludo
-
No puedo usar Harmony porque no han metido interrupciones SPI sin DMA... lo tuve que hacer a mano y me apoyé en PLIB, pero ya quité todo eso. Saludos.
-
No puedo usar Harmony porque no han metido interrupciones SPI sin DMA... lo tuve que hacer a mano y me apoyé en PLIB, pero ya quité todo eso. Saludos.
hola migsantiago, supongo que estas usando el reloj interno por el bug para el cuarzo, que experiencia has tenido en las temporizaciones? va bien? tiene un tiempo estable?
por ejemplo para contar tiempos pequeños? o mejor no usarlo para eso de momento?
un saludo
-
Hola, realmente no he medido el tiempo a detalle. Uso señales de menos de 1us y funcionan muy bien.
Con los 200MHz del reloj interno no he tenido problemas... parece que los errores de SPI han sido por PLIB... el precompilado que trae.
Les paso las diferencias de código. Sólo escribo a mano los registros... no confío en PLIB ya más. :5]
#define SPI1BUFFER (*(volatile uint32_t*)(0xBF821020))
#define SPI2BUFFER (*(volatile uint32_t*)(0xBF821220))
#define SPI3BUFFER (*(volatile uint32_t*)(0xBF821420))
#define SPI5BUFFER (*(volatile uint32_t*)(0xBF821820))
#define SPI6BUFFER (*(volatile uint32_t*)(0xBF821A20))
-
Hola migsantiago, yo tambien estoy desechando las PLIB, para comunicaciones son horribles, I2C, y UART estan programados con while y causan retrasos muy graves para el codigo, estoy desarrollando ahora una comunicacion UART y en recibir 29Bytes a 9600 baudios, te mete un retraso en tu programa de 23,2 miliseguntos :? :? de que me sirve tener una comunicacion hardware si luego tengo unos retrasos brutales por las librerias?? para eso hago yo la comunicacion software que es lo mismo.
tengo ya ganas de que salgan los PIC32MZ EX family (creo que se van a llamar asi), y solventen los bug he incluyan el FPU.
Habrá que probar bien las harmony a ver si estan mejor hechas, esperemos que si.
un saludo.
-
jeje
Dudo que salgan bien.
Como que Microchip está liberando tan pronto puede para no quedarse atrás en la competencia. Ahorita los micros todos están luchando por nuestro interés.
Me quedo con el PIC32MZ... malo por conocido que bueno por conocer. :mrgreen:
-
Me quedo con el PIC32MZ... malo por conocido que bueno por conocer. Mr. Green
La verdad es que si no huvieran salido con tantos bug, ahora mismo los estaría usando para todo, tienen muy buena velocidad y los perifericos de microchip son muy buenos. Y otra preguntita, por lo que dices, veo que no has podido o querido implementar la solución para usar el cristal externo.
has podido usar el USB en algunas de sus variantes? USB HS, FS, puerto serie virtual??
Un saludo.
-
No, no he hecho nada para el USB. Tuve muchos problemas con SPI. Ya será tal vez después.
-
¡Ojalá! Ahorita el rendimiento que tengo del micro es bajo, puedo hacer toggle de GPIOs a 1MHz. Ya tiene la caché ROM habilitada, pero faltan las optimizaciones PRO.
Quise instalar el modo de evaluación de XC32, desde web, desde consola y ningún método me funciona. Sin optimizaciones el micro es tan lento como sus hermanos menores PIC16/18. redhot
Dato curioso... los GPIOs necesitan reloj. El máximo que aceptan también es de 100MHz. No sé aún si es posible hacerlos oscilar tan rápido, sólo he visto en el foro de Microchip que lo han logrado a 20MHz... muy lejanos de mi 1MHz con la versión gratuita del compilador FREE.
he revisado todo el post y he visto esto, ¿a que te refieres? yo pensaba que los compiladores y la optimización solo afectaban al tamaño que el código ocupa en memoria, tambien afecta al rendimiento del micro? funcionas los periféricos a una velocidad menor sin la optimización?
un saludo
-
No se en que se basa la optimizacion de Microchip.
Por que un codigo puede optimizarse de muchas formas, se puede optimizar para que sea muy rapido (y que ocupe lo que quiera de memoria), o se puede optimizar para que cosuma la menor cantidad de memoria.
Imagino que buscaran un intermedio de ambos. Por lo que si, una optimizacion significaria un incremento de la velocidad, obviamente respetando el maximo posible segun el clock del periferico.
Lo que si no se como manejara el compilador al tener ese cache y los perifericos a menor velocidad. Me refiero que hasta que sea posible otro cambio del puerto pueden pasar varias instrucciones, eso las rellenara con nops ?
-
Hombre esta claro que la manera de escribir el ensamblador va a condicionar el tiempo en el que se ejecuta una función, pero de hay a capar la velocidad del periférico de manera intencionada me parece muy fuerte.
Es que el ejemplo que esta diciendo migsantiago es que consigue el togle de un puerto a 1MHz con respecto a los 24 MHz que se consigue con el pro. Esto es una variación grandisima esto no puede ser por escribir un poco mas de ensamblador.
Si en el while principal solo metes el togle, y con el pro va a 24MHz y sin el pro va a 1MHz es para mandar a tomar por culo a microchip.
Es lógico que con el pro tengas mas memoria, es básicamente lo que hacen otros fabricantes limitandote a 32kb por ejemplo. Pero es la primera vez que escucho que te Capen las capacidades del micro.
Alguien sabe si microchip esta haciendo esto? En su pagina web pone que la optimización afecta solo al tamaño que ocupa el código.
Un saludo
-
Sino que realize un pequeño programa con un toggle, y que muestre el disassembly y vemos :), yo no tengo Harmony , ni XC32, menos el conocimiento para programarlos, asi que si lo bajo para hacerlo voy a estar 1 año. Si mig o vos juaperser pueden proporcionar ese codigo en ASM seria genial para poder verlo.
Hablo de un programa asi:
while(1)
{
toggle(PIN_x);
}
Y nada mas xD, Yo debo imaginar que es IMPOSIBLE que no llegue a 24.xxxxx Mhz (suponiendo que divida por 4 al clk)
Seria hecho burdametne:
bandera
cambio de puerto
nop
nop
nop
goto bandera
Es todo el codigo e.e
-
En cuanto lo vi ayer pensé en hacerlo, no me llevaría ni dos minutos, copias los fuses de otro proyecto pones el while 1 togle y ha ver como va. El problema... no tengo osciloscopio :( :( la cosa seria hacer ese while(1) togle bajarse la versión de evaluación de 30 dias y ir cambiando el nivel de optimización a ver si sube la velocidad.
Un saludo.
-
De todas formas cuando esta tarde llegue a mi casa lo hago y te enseño el ensamblador a ti KILLER que sabes mucho sobre ensamblador a ver como lo ves.
Un saludo
-
Yo no se, a mi me gusta el ASM nada mas.
-
Yo no se, a mi me gusta el ASM nada mas.
he visto tus codigos en ensamblador y si que sabes ensamblador.
no habia una manera de ver o crear el equivalente en ensamblador desde el C en MPLABX? nunca lo he usado pero habia escuchado que se podia, pero solo veo en los archivos generados el .o del codigo maquina.
un saludo.
-
Podrias ver la memoria de programa, o fijate que hay una ventana de disassembly, aunque no se si te lo muestra cuando esta simulanod nomas, luego de eso a volver a ver MIPS32 :P
-
vale, lo he conseguido en opcines de programa, marcando la opcion de no borrar archivos intermedios.
esto es un codigo en XC32 sin harmony y sin nada, solo fuses y un togle, y la configuracion de que los pines sean digitales, para un PIC32MX250F128
XC32 (1.34)
#include <xc.h>
//FUSES DE CONFIGURACION
#pragma config DEBUG = OFF
#pragma config JTAGEN = OFF
#pragma config ICESEL = ICS_PGx3
#pragma config PWP = 0x3f
#pragma config BWP = OFF
#pragma config CP = OFF
/*** DEVCFG1 ***/
#pragma config FNOSC = PRIPLL
#pragma config FSOSCEN = OFF
#pragma config IESO = OFF
#pragma config POSCMOD = HS
#pragma config OSCIOFNC = OFF
#pragma config FPBDIV = DIV_1
#pragma config FCKSM = CSDCMD
#pragma config WDTPS = PS1048576
#pragma config FWDTEN = OFF
#pragma config WINDIS = OFF
/*** DEVCFG2 ***/
#pragma config FPLLIDIV = DIV_5
#pragma config FPLLMUL = MUL_20
#pragma config FPLLODIV = DIV_2
#pragma config UPLLIDIV = DIV_5
#pragma config UPLLEN = ON
/*** DEVCFG3 ***/
#pragma config USERID = 0xffff
#pragma config PMDL1WAY = ON
#pragma config IOL1WAY = ON
#pragma config FUSBIDIO = ON
#pragma config FVBUSONIO = OFF
void main (void)
{
ANSELB = 0; //Puerto B digital
while(1)
{
LATBbits.LATB0=~LATBbits.LATB0;
}
}
el codigo en ensamblador me parece una burrada, y no me entero de nada, el ensamblador de PIC32 lo he tocado muy muy poquito, a ver si tu lo entiendes mejor:
.section .mdebug.abi32
.previous
.gnu_attribute 4, 3
.section .debug_abbrev,info
.Ldebug_abbrev0:
.section .debug_info,info
.Ldebug_info0:
.section .debug_line,info
.Ldebug_line0:
.section .text,code
.Ltext0:
.align 2
.globl main
.LFB2 = .
.file 1 "c:/users/juanjo/desktop/borrar/prueba.x/main.c"
.loc 1 42 0
.set nomips16
.set nomicromips
.ent main
.type main, @function
main:
.frame $fp,8,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x40000000,-4
.fmask 0x00000000,0
.set noreorder
.set nomacro
# End mchp_output_function_prologue
addiu $sp,$sp,-8
.LCFI0:
sw $fp,4($sp)
.LCFI1:
move $fp,$sp
.LCFI2:
.loc 1 43 0
lui $2,%hi(ANSELB)
sw $0,%lo(ANSELB)($2)
.L2:
.loc 1 47 0
lui $2,%hi(LATB)
lw $2,%lo(LATB)($2)
ext $2,$2,0,1
andi $2,$2,0x00ff
nor $2,$0,$2
andi $2,$2,0x00ff
andi $2,$2,0x1
andi $4,$2,0x00ff
lui $3,%hi(LATB)
lw $2,%lo(LATB)($3)
ins $2,$4,0,1
sw $2,%lo(LATB)($3)
.loc 1 48 0
j .L2
nop
.set macro
.set reorder
# Begin mchp_output_function_epilogue
# End mchp_output_function_epilogue
.end main
.LFE2:
.size main, .-main
.section .debug_frame,info
.Lframe0:
.4byte .LECIE0-.LSCIE0
.LSCIE0:
.4byte 0xffffffff
.byte 0x1
.ascii "\000"
.uleb128 0x1
.sleb128 -4
.byte 0x1f
.byte 0xc
.uleb128 0x1d
.uleb128 0x0
.align 2
.LECIE0:
.LSFDE0:
.4byte .LEFDE0-.LASFDE0
.LASFDE0:
.4byte .Lframe0
.4byte .LFB2
.4byte .LFE2-.LFB2
.byte 0x4
.4byte .LCFI0-.LFB2
.byte 0xe
.uleb128 0x8
.byte 0x4
.4byte .LCFI1-.LCFI0
.byte 0x9e
.uleb128 0x1
.byte 0x4
.4byte .LCFI2-.LCFI1
.byte 0xd
.uleb128 0x1e
.align 2
.LEFDE0:
.section .text,code
.Letext0:
.file 2 "c:/program files (x86)/microchip/xc32/v1.34/pic32mx/include/proc/p32mx250f128b.h"
.section .debug_info,info
.4byte 0x2a0
.2byte 0x2
.4byte .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.ascii "GNU C 4.5.2 MPLAB XC32 Compiler v1.34\000"
.byte 0x1
.ascii "main.c\000"
.ascii "C:/Users/JUANJO/Desktop/borrar/Prueba.X\000"
.4byte .Ltext0
.4byte .Letext0
.4byte .Ldebug_line0
.uleb128 0x2
.byte 0x4
.byte 0x7
.ascii "unsigned int\000"
.uleb128 0x3
.byte 0x4
.byte 0x2
.2byte 0x11b5
.4byte 0x1a5
.uleb128 0x4
.ascii "LATB0\000"
.byte 0x2
.2byte 0x11b6
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1f
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB1\000"
.byte 0x2
.2byte 0x11b7
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1e
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB2\000"
.byte 0x2
.2byte 0x11b8
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1d
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB3\000"
.byte 0x2
.2byte 0x11b9
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1c
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB4\000"
.byte 0x2
.2byte 0x11ba
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1b
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB5\000"
.byte 0x2
.2byte 0x11bb
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x1a
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB7\000"
.byte 0x2
.2byte 0x11bd
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x18
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB8\000"
.byte 0x2
.2byte 0x11be
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x17
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB9\000"
.byte 0x2
.2byte 0x11bf
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x16
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB10\000"
.byte 0x2
.2byte 0x11c0
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x15
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB11\000"
.byte 0x2
.2byte 0x11c1
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x14
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB13\000"
.byte 0x2
.2byte 0x11c3
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x12
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB14\000"
.byte 0x2
.2byte 0x11c4
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x11
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x4
.ascii "LATB15\000"
.byte 0x2
.2byte 0x11c5
.4byte 0x6e
.byte 0x4
.byte 0x1
.byte 0x10
.byte 0x2
.byte 0x23
.uleb128 0x0
.byte 0x0
.uleb128 0x3
.byte 0x4
.byte 0x2
.2byte 0x11c7
.4byte 0x1bf
.uleb128 0x4
.ascii "w\000"
.byte 0x2
.2byte 0x11c8
.4byte 0x6e
.byte 0x4
.byte 0x20
.byte 0x0
.byte 0x2
.byte 0x23
.uleb128 0x0
.byte 0x0
.uleb128 0x5
.byte 0x4
.byte 0x2
.2byte 0x11b4
.4byte 0x1d3
.uleb128 0x6
.4byte 0x7e
.uleb128 0x6
.4byte 0x1a5
.byte 0x0
.uleb128 0x7
.ascii "__LATBbits_t\000"
.byte 0x2
.2byte 0x11ca
.4byte 0x1bf
.uleb128 0x2
.byte 0x4
.byte 0x7
.ascii "long unsigned int\000"
.uleb128 0x2
.byte 0x4
.byte 0x5
.ascii "long int\000"
.uleb128 0x2
.byte 0x4
.byte 0x5
.ascii "int\000"
.uleb128 0x2
.byte 0x1
.byte 0x6
.ascii "char\000"
.uleb128 0x2
.byte 0x2
.byte 0x7
.ascii "short unsigned int\000"
.uleb128 0x2
.byte 0x2
.byte 0x5
.ascii "short int\000"
.uleb128 0x8
.byte 0x1
.ascii "main\000"
.byte 0x1
.byte 0x29
.byte 0x1
.4byte .LFB2
.4byte .LFE2
.byte 0x1
.byte 0x6e
.uleb128 0x9
.ascii "ANSELB\000"
.byte 0x2
.2byte 0x1167
.4byte 0x260
.byte 0x1
.byte 0x1
.uleb128 0xa
.4byte 0x6e
.uleb128 0xb
.4byte .LASF0
.byte 0x2
.2byte 0x11cb
.ascii "*LATB\000"
.4byte 0x279
.byte 0x1
.byte 0x1
.uleb128 0xa
.4byte 0x1d3
.uleb128 0x9
.ascii "ANSELB\000"
.byte 0x2
.2byte 0x1167
.4byte 0x260
.byte 0x1
.byte 0x1
.uleb128 0xb
.4byte .LASF0
.byte 0x2
.2byte 0x11cb
.ascii "*LATB\000"
.4byte 0x279
.byte 0x1
.byte 0x1
.byte 0x0
.section .debug_abbrev,info
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0x8
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.uleb128 0x1b
.uleb128 0x8
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x13
.byte 0x1
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x1
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0xd
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x49
.uleb128 0x13
.uleb128 0xb
.uleb128 0xb
.uleb128 0xd
.uleb128 0xb
.uleb128 0xc
.uleb128 0xb
.uleb128 0x38
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x17
.byte 0x1
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x1
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x6
.uleb128 0xd
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x7
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x8
.uleb128 0x2e
.byte 0x0
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0xc
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x9
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x49
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3c
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0xa
.uleb128 0x35
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xb
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x2007
.uleb128 0x8
.uleb128 0x49
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3c
.uleb128 0xc
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,info
.4byte 0x17
.2byte 0x2
.4byte .Ldebug_info0
.4byte 0x2a4
.4byte 0x23b
.ascii "main\000"
.4byte 0x0
.section .debug_pubtypes,info
.4byte 0x1f
.2byte 0x2
.4byte .Ldebug_info0
.4byte 0x2a4
.4byte 0x1d3
.ascii "__LATBbits_t\000"
.4byte 0x0
.section .debug_aranges,info
.4byte 0x1c
.2byte 0x2
.4byte .Ldebug_info0
.byte 0x4
.byte 0x0
.2byte 0x0
.2byte 0x0
.4byte .Ltext0
.4byte .Letext0-.Ltext0
.4byte 0x0
.4byte 0x0
.section .debug_str,info
.LASF0:
.ascii "LATBbits\000"
.section .text,code
.ident "GCC: (Microchip Technology) 4.5.2 MPLAB XC32 Compiler v1.34"
# Begin MCHP vector dispatch table
# End MCHP vector dispatch table
# Microchip Technology PIC32 MCU configuration words
# Configuration word @ 0xbfc00bfc
.section .config_BFC00BFC, code, keep, address(0xBFC00BFC)
.type __config_BFC00BFC, @object
.size __config_BFC00BFC, 4
__config_BFC00BFC:
.word 0x7FFFFFEA
# Configuration word @ 0xbfc00bf8
.section .config_BFC00BF8, code, keep, address(0xBFC00BF8)
.type __config_BFC00BF8, @object
.size __config_BFC00BF8, 4
__config_BFC00BF8:
.word 0xFF74CE5B
# Configuration word @ 0xbfc00bf4
.section .config_BFC00BF4, code, keep, address(0xBFC00BF4)
.type __config_BFC00BF4, @object
.size __config_BFC00BF4, 4
__config_BFC00BF4:
.word 0xFFF97CDC
# Configuration word @ 0xbfc00bf0
.section .config_BFC00BF0, code, keep, address(0xBFC00BF0)
.type __config_BFC00BF0, @object
.size __config_BFC00BF0, 4
__config_BFC00BF0:
.word 0x7FFFFFFF
aunque creo que aqui lo que vale es esto:
si te fijas aqui:
.L2:
.loc 1 47 0
lui $2,%hi(LATB)
lw $2,%lo(LATB)($2)
ext $2,$2,0,1
andi $2,$2,0x00ff
nor $2,$0,$2
andi $2,$2,0x00ff
andi $2,$2,0x1
andi $4,$2,0x00ff
lui $3,%hi(LATB)
lw $2,%lo(LATB)($3)
ins $2,$4,0,1
sw $2,%lo(LATB)($3)
.loc 1 48 0
j .L2
nop
se ve un nop al final :?
un saludo
-
Hola, el rendimiento del micro se ve afectado por la lectura de la ROM. El micro corre más rápido que la lectura de la ROM. Para eso se usa la caché, que va pre-leyendo por donde cree que el micro va a pasar. Sin embargo, bajo ejecuciones inesperadas del programa la caché no va a usarse y se tienen que cargar las siguientes instrucciones desde la ROM.
Para poder ver la conversión de C a ASM ingresen este comando:
${MP_CC_DIR}\xc32-objdump -S ${ImageDir}\${PROJECTNAME}.${IMAGE_TYPE}.elf > list.lst
En project properties, building, execute this line after build.
Esto es lo que genera:
while(1)
++APP_DEBUG_PIN;
9d002428: 3c02bf86 lui v0,0xbf86
9d00242c: 8c440120 lw a0,288(v0)
9d002430: 7c8400c0 ext a0,a0,0x3,0x1
9d002434: 38840001 xori a0,a0,0x1
9d002438: 8c430120 lw v1,288(v0)
9d00243c: 7c8318c4 ins v1,a0,0x3,0x1
9d002440: ac430120 sw v1,288(v0)
9d002444: 0b40090b j 9d00242c <APP_Read_SD_Card_Table+0x84>
9d002448: 00000000 nop
Tengo optimización 1, que es la que ofrece el compilador gratuito.
Ya se acabó mi periodo de prueba del completo.
Saludos.
-
Esto es lo mismo con optimización 0.
while(1)
++APP_DEBUG_PIN;
9d003e64: 3c02bf86 lui v0,0xbf86
9d003e68: 8c420120 lw v0,288(v0)
9d003e6c: 7c4200c0 ext v0,v0,0x3,0x1
9d003e70: 304200ff andi v0,v0,0xff
9d003e74: 24420001 addiu v0,v0,1
9d003e78: 30420001 andi v0,v0,0x1
9d003e7c: 304400ff andi a0,v0,0xff
9d003e80: 3c03bf86 lui v1,0xbf86
9d003e84: 8c620120 lw v0,288(v1)
9d003e88: 7c8218c4 ins v0,a0,0x3,0x1
9d003e8c: ac620120 sw v0,288(v1)
9d003e90: 0b400f99 j 9d003e64 <APP_Read_SD_Card_Table+0xc0>
9d003e94: 00000000 nop
-
Y este se soluciona con el nivel de optimización pro? El micro siempre deberá cargar instrucciones desde la ROM... ante interrupciones por ejemplo? No?
Lo que tampoco me gusta es ese nop al final, de todas formas un nop no es como para retrasar un togle de 20mhz a 1mhz.
Llegaste a probar lo del togle con tu versión de evaluación pro con un osciloscopio?
Un saludo
-
Es curioso... muchas funciones terminan en un NOP. Quién sabe para qué.
No, en esos entonces no probé ya eso.
Puedes activar la evaluación si estás interesado en ver cómo optimiza... yo ya no puedo activarla...
http://www.microchip.com/xcdemo/GetDemoLicense.aspx
-
Pues si lo probaré en cuanto pueda pero no sera hoy ni mañana, pero lo hare ,
Por cierto esto antes funcionaba, instalate el virtual box he instalate un linux o window o lo que quieras instala mplabx y xc32 y activa la versión de evaluación, congela la maquina, todo lo que guardes he instales a partir de ahora se te borrara cuando lo vuelvas a encender, pero las versiones de evaluación no te caducan en mi uní hacían eso, puedes programar en tu OS host y cuando lo tengas terminado compilarlo con la optimización a tope, no se si esto sigue funcionando pero merece la pena intentarlo si lo necesitas.
Un saludo
-
No tuve tiempo de mirarlo, pero si no mal recuerdo el nop esta por el tema del pipeline.
Una de las cosas que supe ver cuando miraba el ASM de MIPS
-
jeje sí, hay muchas maneras de truquear el compilador, pero no lo necesito. :mrgreen:
Ah OK Killer, pues cosas raras de ASM que al menos están ahí para que funcione el micro.
-
Bueno estuve mirando un poco el codigo y por lo que parece las optimizaciones hacen que utilize menos instrucciones para llegar al punto deseado. Registros propios de la CPU, Lo feo es que por ahi usa demasiadas instrucciones para cosas demasiados simples.
Para que me entiendan un poco
Una CPU MIPS32 posee 32 registros generales + 3 especiales, el tema es que de los registros generales tienen sus "funciones" en realidad es una convencion, en ASM puedo usar los que quiera y como quiera. Pero siguiendo la linea de C, deberia respetarlos
Los Registros son:
R0...R31 --- Registros generales, Particularidades
R0 es siempre 0, util para desechar resultados o poner a 0 algo.
R2/R3 para valores de retorno tambien llamados V0/V1
R4-R7 Para valores de argumento, primeros 4 sino lo demas al stack, tambien llamado A0 - A3
R8-R15 /R24/R25 Registros "temporales" . Tambien llamados T0-T9
R16-R23 "Saved Registers" S0-S7
R26/R27 "Kernel Reserved Registers" K0/K1
R28 "Global Pointer" Usado para direccionar variables globales estaticas o GP
R29 Stack Pointer o SP
R30 Frame Pointer o FP
R31 Return Address o RA
Registros especiales
HI, LO --- Registros especiales, para resultados de multiplicacion/division , no confundir con %hi del codigo de juaperser
PC --- Program Counter
Ahora voy a analizar el codigo de cada uno que me pasaron:
addiu $sp,$sp,-8 -------- SP = SP - 8 , Modifica el stack pointer para hacer lugar y guardar los Frame Pointer, 8 bytes
.LCFI0:
sw $fp,4($sp) -------- Store Word Frame pointer -> SP , FP -> (SP + 4) , Guarda el Frame Pointer es los primeros 4 bytes que ya habiamos reservados
.LCFI1:
move $fp,$sp -------- FP -> SP , Guarda nuevamente el Frame Pointer en los otros 4 bytes y completamos los 8 reservados, ni idea por que 2 veces.
.LCFI2:
.loc 1 43 0
lui $2,%hi(ANSELB) ---- R2 = HI<<16 , guarda los 2 bytes de la direccion superior de ANSELB en R2
sw $0,%lo(ANSELB)($2) [LO + R2] = R0 , Pone 0 en ANSELB, Direccion de arriba(2 bytes) + direccion de abajo(2 bytes)
.L2:
.loc 1 47 0
lui $2,%hi(LATB) R2 = &LATB AND 0xFFFF.0000 , es decir la parte superior de la direccion se guarda en R2 quedando 0xaaaa.0000
lw $2,%lo(LATB)($2) R2 = [R2 + LO] , conteniedo en R2 + offset apuntando a LATB y termina almacenando el Word(32bits) en R2
ext $2,$2,0,1 Extract bit field, Extrae los bits desde el bit 0, con una longitud de 1 y almacena eso nuevamente en R2, quedando solo el bit LATB0
andi $2,$2,0x00ff R2 = R2 & 0xFF
nor $2,$0,$2 R2 = ~ (R0|R2) , R2 ( que contenia LATB0 ) se realiza una OR y luego se nega con R0 ( que siempre es 0), Lo mismo que negar el bit LATB0 y todos los demas tambien
andi $2,$2,0x00ff R2 = R2 & 0xFF Nuevamente lo ajusta a 8 bits (pero de la NOR quedaron muchos 1 ademas del bit de interes)
andi $2,$2,0x1 R2 = R2 & 0x1 Finalmente solo deja LATB0
andi $4,$2,0x00ff R4 = R2 & 0xFF Vuelve a limitarlo a 8 bits y guarda en R4
lui $3,%hi(LATB) R3 = Upper 2 byte address LATB << 16
lw $2,%lo(LATB)($3) R2 = [LO + R3] Carga nuevamente lo que esta en la direccion de LATB
ins $2,$4,0,1 R2 = (R2 & 0xFFFF.FFFE )+ LATB0 (desde R4), la instruccion copia la seccion desde la posicion 0, longitud 1 de R4 a R2 dejando R2 con sus demas bits intactos
sw $2,%lo(LATB)($3) [LO + R3] = R2 Finalmente guardo mi LATB modificado
.loc 1 48 0
j .L2 Salto a L2, por el pipeline si hay otra instruccion puede que se ejecute a pesra que se produjo el salto, asi que se pone un NOP
nop
Se puede observar que hace uso de los registros 2 , 3 y 4, cada instruccion esta explicada.
El frame pointer es para ordenar las subrutinas en las pilas, con cada llamado a subrutina se guarda el puntero de Frame, este Frame contiene algunos registros+espacio para las variables nuevas, etc, luego cuando se vuelve , se vuelve al anterior FP
En fin, ese programa hace desastres, es impresionante la cantidad de AND que hace y un NOR, cuando podria hacer un XOR. Otra cosa lee 2 veces el la memoria para obtener ese valor.
Algo parecido es lo que paso con el codigo de migsantiago sin optimizacion:
9d003e64: 3c02bf86 lui v0,0xbf86 ; Utiliza un registro nomas para almacenar la direccion de memoria
9d003e68: 8c420120 lw v0,288(v0)
9d003e6c: 7c4200c0 ext v0,v0,0x3,0x1
9d003e70: 304200ff andi v0,v0,0xff ; Multiples AND sin sentido
9d003e74: 24420001 addiu v0,v0,1
9d003e78: 30420001 andi v0,v0,0x1
9d003e7c: 304400ff andi a0,v0,0xff
9d003e80: 3c03bf86 lui v1,0xbf86 ; Lo cual lo hace cargarlo de nuevo
9d003e84: 8c620120 lw v0,288(v1)
9d003e88: 7c8218c4 ins v0,a0,0x3,0x1
9d003e8c: ac620120 sw v0,288(v1)
9d003e90: 0b400f99 j 9d003e64
9d003e94: 00000000 nop
Es identico al anterior (por eso no lo explico), nomas que aqui se puede ver realmente la direccion de los registros. si observan el %hi(LATx) y %lo(LATx) se transforma en 0xBF86.0120
Esto por que aceptan solo 16bits esa instruccion
Por ultimo con optimizacion 1:
9d002428: 3c02bf86 lui v0,0xbf86 V0 = 0xbf86.0000
9d00242c: 8c440120 lw a0,288(v0) A0 = [V0 + 288] = [0xBF86.0120]
9d002430: 7c8400c0 ext a0,a0,0x3,0x1 Extrae el bit 4 de A0 y solo eso guarda en el bit0 en A0. (A0 & 0x00 + A0.bit0) = A0.bit4
9d002434: 38840001 xori a0,a0,0x1 A0 = A0 XOR 0x1 , Negar bit0
9d002438: 8c430120 lw v1,288(v0) V1 = [V0 + 288] = [0xBF86.0120] , Vuelvo a cargar el valor del registro
9d00243c: 7c8318c4 ins v1,a0,0x3,0x1 Inserto el bot. V1.bit4 = A0.bit0
9d002440: ac430120 sw v1,288(v0) [V0 + 288] = [0xBF86.0120] = V1 Guardo mi registro
9d002444: 0b40090b j 9d00242c Salto
9d002448: 00000000 nop
Muy parecido al anterior pero aun asi vuelve a hacer cosas sin sentido, como extraer el bit, insertarlo, etc. Ademas de cargar 2 veces lo que esta en memoria.
Si tuviera que hacer algo similar bastaria con 6 intrucciones.
loop:
lui v0,0xBF86 ; Direccion
lw a0,288(v0) ; Cargo valor de registro en A0
xori a0,a0,0x1 ; A0 = A0 XOR 0x1
sw a0,288(v0) ; Guardo A0 en el registro que sea
j loop
nop
Y el loop se puede hacer mas corto si el lui y el lw fuera de este loop. Algo asi:
start
lui v0,0xBF86 ; Direccion
lw a0,288(v0) ; Cargo valor de registro en A0
loop
xori a0,a0,0x1 ; A0 = A0 XOR 0x1
sw a0,288(v0) ; Guardo A0 en el registro que sea
j loop
nop
-
Muy interesante el análisis ASM que hiciste Killer.
Sería bueno poder ver lo que la optimización máxima logra. Seguro esas AND ADD de más desaparecen... o usan algo mejor... como el registro toggle atómico que trae el micro por sí solo jeje.
Gracias.
-
No encontre nada sobre el registro atomico, lo que si hay 2 instrucciones atomicas, aunque no permiten el cambio de 1 bit, sino es otra funcion. Las funciones son LL y SC, se usan juntos
Permiten compartir variables entre procesos y que siempre este actualizado. Al intentar guardarlo si nadie lo modifico entonces en el registro queda un 1.
L1:
LL T1, (T0) # load counter
ADDI T2, T1, 1 # increment
SC T2, (T0) # try to store, checking for atomicity
BEQ T2, 0, L1 # if not atomic (0), try again
NOP # branch-delay slot
Por otro lado, para que no quede en el aire, aqui esta la explicacion del por que se necesita un NOP luego de un salto
http://people.ece.cornell.edu/land/courses/ece4760/PIC32/Microchip_stuff/MIPS-M4K-Core.pdf
Bajo el titulo de Branch Delay
Y aca un ejemplo de como funciona:
http://en.wikipedia.org/wiki/Delay_slot
A pesar que vi un poco de ASM del SHARK DSP no recordaba que tuviera 2 branch delay :/.
En fin, es malo y tampoco TAN malo, ya que podrias ejecutar una instruccion que de otra forma tirarias.
Se podra mejorar el codigo haciendo esto?:
start
lui v0,0xBF86 ; Direccion
lw a0,288(v0) ; Cargo valor de registro en A0
loop
xori a0,a0,0x1 ; A0 = A0 XOR 0x1
j loop
sw a0,288(v0) ; Guardo A0 en el registro que sea
-
Yo en otros micros y versiones (xc16 y xc8) lo que hacia la optimizacion era lo siguiente:
Sin optimizacion creaba mucho codigo basura tipo:
PORTA=0x0000;
Se traducia en codigo asm como
-Copiar 0x0000 a una variable temporal
-Copiar de esa variable a PORTA
Luego en codigo optimizado al maximo lo hacia asi:
-Copia 0x0000 a PORTA
Y eso es solo un ejemplo, para cosas mas complicadas como sumas, if, y cosas por el estilo creaba mucho mas codigo, no es que la optimizacion te cree un supercodigo, mas bien seria que sin optimizar te crea codigo inservible o mas bien para hacer 1 paso simple te crea 3 pasos mas.
-
no es que la optimizacion te cree un supercodigo, mas bien seria que sin optimizar te crea codigo inservible o mas bien para hacer 1 paso simple te crea 3 pasos mas.
No será tan inservible cuando el Debug no funciona correctamente sin ese código.
-
Si la diferencia desde C a ASM puede ser grande, yo hace un tiempo hice una comparacion de XC8 versus ASM, con un caso particular que era una formula y lo habia realizado en ASM.
El Problema principal que luego de hacer muchas formulas rebuscandolas, logre terminar casi con mi mismo codigo en ASM. Pero tuve que rebuscarmelas.
Por ejemplo, esto:
LATBbits.LATB0=~LATBbits.LATB0;
Se podria escribir como
LATB ^= 0x1;
LATB ^= (1 << 0);
Por supuesto, es rebuscarselas y puede que logres un mejor codigo.
El thread en cuestion aunque es XC8:
http://www.todopic.com.ar/foros/index.php?topic=44247.msg367049
-
Buenas killer, luego dices que no sabes ensamblador :D :D
Bueno pues siguiendo tu explicacion, coincido contigo, es malo, pero me lo esperaba peor con nop a mala leche para bajarle velocidad.
No obstante, algo malo se esta cociendo en microchip :(. Hoy he vuelto a meterle mano al bootloader msd AN1388, para empezar los ejemplos están hechos con la máxima optimización y mips16 activado, para que si tienes la versión gratuita te den bien por culo, si lo dejas así tal como, al compilarlo el bootloader msd(fat32 y USB) ocupan 16k, esto quiere decir que los micros pic32 de 16k se quedan sin bootloader msd y los de 32kb pierden la mitad de memoria solo con esto.
Como ya he denunciado en otros post desde hace un tiempo los compiladores de microchip cada vez comen mas memoria.
Bueno pues he adaptado el bootloader msd quitando las mips16 y la optimización y toda la morralla de las placas de evaluación para un pic32mx250 con 128kb, y me he quedado a cuadros cuando he visto que se ha comido el 47% de la memoria¡¡¡¡¡¡¡¡¡ 64 kb de memoria en bootloader¡¡¡¡¡ los micros de 64kb para abajo no sirven.
Increible, donde están los tiempos donde ni te preocupabas de la memoria del pic salvo para aplicaciones un poco mas especiales? La están cagando, a nadie le gusta este tipo de cosas y no están como para ir perdiendo confianza, en un mercado donde cada día mas fabricantes ofrecen herramientas gratuitas ellos se permiten el lujo de ir al revés y cada vez mas caro, desde cuando un ANxxxx te pide versión pro para usarlo? O es que les daba vergüenza que vean que su bootloader msd sin optimizacion ocupe 64k por sus cada vez peores compiladores?
También hice la prueba de ver que entraba en un pic32 16kb sin optimización con las harmony, sin ningúna librería ni nada, bueno pues entraron 8 funciones¡¡¡¡ y pequeñitas emm. 8 funciones no entra ni en la categoría de chiste por dios.
muchas gracias killer por tu exposición de asm y la explicación de los nop finales.
Posdata: he probado en una maquina virtual a pedir otra vez la versión de evaluación y se puede, por lo tanto se puede seguir congelando o rwinstalando maquinas virtuales y tener la versión pro siempre.
Un saludo
-
no es que la optimizacion te cree un supercodigo, mas bien seria que sin optimizar te crea codigo inservible o mas bien para hacer 1 paso simple te crea 3 pasos mas.
No será tan inservible cuando el Debug no funciona correctamente sin ese código.
si funciona, el problema es que la optimizacion elimina y/o ordena el codigo de una manera distinta por lo cual puede que al eliminar partes el debug se quede "loco" sin saber donde tener que dirigirse. Por ejemplo si hacemos:
var=4;
var=3;
la optimizacion elimina el var=4; y deja solo el 3, entonces si hacemos debug habra desaparecido esa linea y no sabra donde acudir, sin embargo sin optimizacion haria todo tal y como lo escribas, aunque hagas cosas del estilo.
-
No encontre nada sobre el registro atomico, lo que si hay 2 instrucciones atomicas, aunque no permiten el cambio de 1 bit, sino es otra funcion. Las funciones son LL y SC, se usan juntos
Son los SET, CLR e INV registers.
(http://www.todopic.com.ar/foros/index.php?action=dlattach;topic=43803.0;attach=23790;image)
Sirven para levantar, bajar o invertir bits en los registros. Sólo los registros I/O tienen ese modo. Es curioso notar que prefieren meter registros con esas funcionalidades especiales a meter códigos de operación MIPS que hagan lo mismo (BSF, BCF en ASM de PIC sencillo, por ejemplo).
Con el INV, fácilmente en una sola instrucción se llevaría a cabo mi instrucción en C.
++APP_DEBUG_PIN;
Pero bueno, sólo el modo pro lo ha de soportar... espero.
OK, gracias por el link del NOP intruso.
Sobre tu pregunta de si se puede mejorar el ciclo, ¿qué te parece si usas el INV? Sobre ensamblador MIPS estoy en ceros jejej.
Gracias.
-
Esta bueno, no lo vi por que yo busque exclusivamente del MIPS32 M4K, te permite ahorrarte la XOR:
start
lui v0,%hi(LATxINV) ; Direccion del registro INV
adi a0,R0,0x1 ; Cargo el valor 0x0000.0001 para invertir el bit0
loop
j loop
sw a0,%lo(LATxINV)(v0) ; Guardo A0 en el registro que sea
La instruccion que cambiaria el pin seria ese SW (Store Word), es el que hace el cambio. Graba el valor al registro y permite el cambio del pin. Y cambia la direccion a la del LATxINV (ya que no la se cual es)
Es curioso notar que prefieren meter registros con esas funcionalidades especiales a meter códigos de operación MIPS que hagan lo mismo (BSF, BCF en ASM de PIC sencillo, por ejemplo).
Es que el nucleo es de MIPS, microchip compra los derechos para usarlos en sus chips, pero la arquitectura es de ellos. Es lo mismo que ocurre con ARM, que estan en micros de NXP,ST,TI,FREESCALE, etc.
Lo bueno que un Cortex-M3 en un ST funciona igual que un Cortex-M3 de un NXP. Lo que si cambian son los perifericos.
Asi que no pueden modificar a libre voluntad el nucleo.
Esto lleva a usar el registro ese en C, para que sea mas corto el programa. Aun sin optimizacion, si se carga directo al registro imagino que debe ser bastante corto.
En ves de hacer:
LATBbits.LATB0=~LATBbits.LATB0;
hacer:
LATBINV = 0x1;
Con lo cual el loop completo en su peor estado ocuparia 6 instrucciones
-
Killer, me gustaría pedirte tu opinión...
Tengo este código súper sencillo en una interrupción de SPI2 TX...
if(sent_bytes_per_submatrix < submatrix_total_bytes[4])
{
SPI2BUFFER = simulated_spi_bit[4];
}
else
{
SPI2BUFFER = 0;
/* Set the RPE5 output as GPIO temporarily to avoid writing glitches */
RPE5R = OUTPUT_FUNC_NO_CONNECT;
}
¡Pero rarísimamente el compilador genera código duplicado! :shock:
if(sent_bytes_per_submatrix < submatrix_total_bytes[4])
9d0005b8: 11e00005 beqz t7,9d0005d0 <_Int_SPI_TX_2+0x318>
9d0005bc: 00000000 nop
{
SPI2BUFFER = simulated_spi_bit[4];
9d0005c0: 95820008 lhu v0,8(t4)
9d0005c4: ad621220 sw v0,4640(t3)
else
{
SPI2BUFFER = 0;
/* Set the RPE5 output as GPIO temporarily to avoid writing glitches */
RPE5R = OUTPUT_FUNC_NO_CONNECT;
9d0005c8: 0b400177 j 9d0005dc <_Int_SPI_TX_2+0x324>
9d0005cc: 25c50001 addiu a1,t6,1
{
SPI2BUFFER = simulated_spi_bit[4];
}
else
{
SPI2BUFFER = 0;
9d0005d0: ad601220 sw zero,4640(t3)
/* Set the RPE5 output as GPIO temporarily to avoid writing glitches */
RPE5R = OUTPUT_FUNC_NO_CONNECT;
9d0005d4: ae801614 sw zero,5652(s4)
9d0005d8: 25c50001 addiu a1,t6,1
9d0005dc: 30a500ff andi a1,a1,0xff
}
/* Only read the buffer if it's ready to be read */
if(1 == SD_Buffer_Can_Be_Read[Sys_Current_Buffer])
{
for(bit_count = 0; bit_count < SPI_FIFO_SIZE_16_BITS; ++bit_count)
9d0005e0: 2ca20008 sltiu v0,a1,8
9d0005e4: 1440ffc7 bnez v0,9d000504 <_Int_SPI_TX_2+0x24c>
9d0005e8: 00a07021 move t6,a1
9d0005ec: 24020005 li v0,5
9d0005f0: a3828040 sb v0,-32704(gp)
9d0005f4: a3858041 sb a1,-32703(gp)
RPE5R = OUTPUT_FUNC_NO_CONNECT;
}
}
Es una optimización tremendamente rara... código duplicado... ¿cómo para qué?
Voy a probar con la VM e instalar la versión PRO.
Tengo problemas con la escritura del SDO2. Los demás SPIs que escribo también están duplicados en ASM... no me lo explico.
¿Por qué crees que el compilador haga eso?
Gracias. :(
-
Ahi lo veo....
Estoy intentado buscar las direcciones xD, de todas formas parece que hay algo mas en ese codigo :/, como un for y seguro debe haber algo mas antes ya que no esta la parte donde carga las primeras direcciones de memoria.
Listo, no veo que lo haga 2 veces, a pesar que sale muchas veces en el disassembler la parte de C. Segun la parte del codigo que me diste(aunque parece que es mas extenso):
9d0005b8: 11e00005 beqz t7,9d0005d0 <_Int_SPI_TX_2+0x318> ;Si t7==0 salta a 9d005d0 (no es correcta la instruccion ya que acepta solo 18bits, pero se entiende), seguro hay una instruccion de comparacion y que almacena el resultado en t7 antes
9d0005bc: 00000000 nop ; nop por el salto
; No se cumplio el if:
; T3 = 0xBF82.0000 , T4 puede ser bank0 o bank1, 0xA000 a 0xA0007 o 0x8000 a 0x8007, no se bien el dispositivo
9d0005c0: 95820008 lhu v0,8(t4) ; SPI2BUFFER = simulated_spi_bit[4]; Load HalfWord Unsigned V0 = [T4+8] ; T4 apunta a la base del vector simulated_spi_bit[], 8 de offset por ser de 16bits ( 4 * 2 = 8), HalfWord=16bits
9d0005c4: ad621220 sw v0,4640(t3) ; [t3+4640] = [t3 + 0x1220] = v0 , es decir la formula de arriba (Proceso: cargar el simulated_spi_bit y guardarlo en SPI2BUFFER).
9d0005c8: 0b400177 j 9d0005dc <_Int_SPI_TX_2+0x324> ; Salto a 9d0005dc, o PC = PC31:PC28 :: 0xd0005dc (acepta solo 28bits)
9d0005cc: 25c50001 addiu a1,t6,1 ; Para aprovechar el salto, A1 = T6+1; Esto es del for siguiente que tiene un preincremento (bit_count)
Se cumplio el if:
; S4 = 0xBF80.0000
9d0005d0: ad601220 sw zero,4640(t3) ; [t3+4640] = [t3 +0x1220] =0 , SPI2BUFFER
9d0005d4: ae801614 sw zero,5652(s4) ; [s4+5652] = [s4 + 0x1614]=0 , RPE5R
9d0005d8: 25c50001 addiu a1,t6,1 ; A1 = t6 + 1; Pre incremento del for, si se toma el camino que se cumple el if, no habia incremento como cuando no se cumplia
Fin del IF
; Tome o no el if ocurre A1 = T6+1;
9d0005dc: 30a500ff andi a1,a1,0xff ; A1 = A1 & 0xFF Pero lo tengo que limitar a 8bits por que asi esta definida como de 8bits (bit_count) imagino ya que luego usa un Store Byte
Comienzo de un if + un for (etc, ni idea )
9d0005e0: 2ca20008 sltiu v0,a1,8 ; V0 igual a 1 si A1 < 8, sino 0, parece ser que T6 es igual a bit_count y por ser pre,decrementado lo vemos antes
9d0005e4: 1440ffc7 bnez v0,9d000504 <_Int_SPI_TX_2+0x24c> ; Si es 1 va a la direccion 0x9d000504 y ademas hace T6 = A1, A1 registro temporal solo para incrementarlo?, y aca actualiza si o si.
9d0005e8: 00a07021 move t6,a1
9d0005ec: 24020005 li v0,5 ; V0 = 5;
9d0005f0: a3828040 sb v0,-32704(gp) ; Guarda el byte de menor peso de V0 en [GP - 0x7FC0], es decir guarda el 5 en ese lugar, supongo una RAM, Usa R28 o Global Pointer. Variables estaticas.
9d0005f4: a3858041 sb a1,-32703(gp) ; Guarda el valor del bit_count, tambien en una posicion cercana al otro. [GP - 0x7FBF]
En fin podes tomar 2 caminos, que te llevan a donde puse "Comienzo de un if + un for", Si se cumple el if anterior o no, toma los dos caminos que separe, cada camino hace lo que puse ahi, que es exactametne lo que tenes en C.
Hay una instruccion repetida que es el del pre incremento de bit_count del for que le sigue al codigo C que pusiste. Fue su forma de resolverlo, podria haber puesto un nop y utilizar solo una ves esa instruccion, pero no ganaba nada de velocidad.
Por lo demas hay un salto a otra direccion y puede que continue el codigo. Pero ahi esta masomenos explicado e intente descifrar las direcciones de algunos registros que no aparece cuando se cargan.
Lo que si no veo es el equivalente de esto:
if(1 == SD_Buffer_Can_Be_Read[Sys_Current_Buffer])
Por lo que parece es como si arrancara con el for antes de revisar eso. O tal ves una optimizacion lo saco.
-
Ohh perfecto... por la forma en cómo reportó el ensamblador pensé que lo hacía dos veces. Sí, hay más código, pero cómo quedó un poco desajustado seguro es eso.
Gracias por el análisis Killer.
-
Talvez tu micro funciona sin la pull-up o la agregaron en la PCB... no lo sé, pero mi oscilador primario no funciona aun agregando la resistencia.
Si no lei mal
Si tiene la revision A5 entonces si con la resistencia funcionaria. si tiene la revision A3/4 esta igual que vos xD por mas resistencia que le ponga no funciona.
PIC32MZ con FPU (http://www.microchip.com/pagehandler/en-us/press-release/high-performance-32-bit-mcu-fa.html)
-
Si parecen espetaculares Dominus, por fin parecen un micro de alta categoria y que compite con un ARM M4 ademas de poseer cache. Por fin le incorporan SQI ( o QSPI como se le quiera llamar ) + otras cosas, y esos 18MSPS del ADC de 12 bits uff.. muchisimo. + por fin veo sus modulos "upgradeados". Aunque sigue con su politica de poner menos Timers, 5 timers de los cuales solo 4 son de 32bits ( pueden funcionar como 2 de 16) pero solo 1 de 16.
Pero siguen habiendo cosas malas. Ejemplo, como vas a poner un "RTCC" sin una entrada de bateria? Que les costara que 1 de sus 144 pines sea una entrada de una bateria asi mantiene el valor el reloj ?
Aparte de eso, tenes que comprar el compilador si queres generar un codigo decente + su programador que sale fortuna.
Y la otra que causa mas gracia y que fue el comienzo de este hilo y que aca sigue ocurriendo lo mismo :P
Tome el mejor micro de esos 144 pines/200Mhz/ tiene de todo,
PIC32MZ2048EFM144
http://ww1.microchip.com/downloads/en/DeviceDoc/80000663A.pdf
Errores en el silicio:
Primary Oscillator Crystal: A crystal oscillator cannot be used as an input to the Primary Oscillator (OSC1/OSC2 pins).
Bueno vamos a usar el oscilador secundario
The Secondary Oscillator (SOSC) does not support crystal operation.
OK.... parece que solo lo vas a poder ejecutar con el oscilador interno, encima ethernet/USB piden relojes bastantes estables en frecuencia para su uso, por eso piden cristales.. pero digamos que tu oscilador interno esta pasado en frecuencia, pero vos recordaste que podias tocarla y disminuirla
The OSCTUN register only increases the frequency of the FRC.
Bueno con suerte espero que solo te toque incrementarla.
Fue lo primero que se me cruzo por la cabeza, no puedo creer que un micro salga asi al mercado, lo primero que haces es ir y ponerle un cristal a tu micro. Aca no podes hacerlo. es como lo mas basico de lo basico. Si puede haber errores de UART de SPI que sean manejables y se arreglen/eviten por software, etc, pero que no te permitan poner un cristal hace que tengas que crear un circuito por fuera para alimentarlo con una señal de reloj xD.
-
Si parecen espetaculares Dominus, por fin parecen un micro de alta categoria y que compite con un ARM M4 ademas de poseer cache. Por fin le incorporan SQI ( o QSPI como se le quiera llamar ) + otras cosas, y esos 18MSPS del ADC de 12 bits uff.. muchisimo. + por fin veo sus modulos "upgradeados". Aunque sigue con su politica de poner menos Timers, 5 timers de los cuales solo 4 son de 32bits ( pueden funcionar como 2 de 16) pero solo 1 de 16.
Pero siguen habiendo cosas malas. Ejemplo, como vas a poner un "RTCC" sin una entrada de bateria? Que les costara que 1 de sus 144 pines sea una entrada de una bateria asi mantiene el valor el reloj ?
Aparte de eso, tenes que comprar el compilador si queres generar un codigo decente + su programador que sale fortuna.
Y la otra que causa mas gracia y que fue el comienzo de este hilo y que aca sigue ocurriendo lo mismo :P
Tome el mejor micro de esos 144 pines/200Mhz/ tiene de todo,
PIC32MZ2048EFM144
http://ww1.microchip.com/downloads/en/DeviceDoc/80000663A.pdf
Errores en el silicio:
Primary Oscillator Crystal: A crystal oscillator cannot be used as an input to the Primary Oscillator (OSC1/OSC2 pins).
Bueno vamos a usar el oscilador secundario
The Secondary Oscillator (SOSC) does not support crystal operation.
OK.... parece que solo lo vas a poder ejecutar con el oscilador interno, encima ethernet/USB piden relojes bastantes estables en frecuencia para su uso, por eso piden cristales.. pero digamos que tu oscilador interno esta pasado en frecuencia, pero vos recordaste que podias tocarla y disminuirla
The OSCTUN register only increases the frequency of the FRC.
Bueno con suerte espero que solo te toque incrementarla.
Fue lo primero que se me cruzo por la cabeza, no puedo creer que un micro salga asi al mercado, lo primero que haces es ir y ponerle un cristal a tu micro. Aca no podes hacerlo. es como lo mas basico de lo basico. Si puede haber errores de UART de SPI que sean manejables y se arreglen/eviten por software, etc, pero que no te permitan poner un cristal hace que tengas que crear un circuito por fuera para alimentarlo con una señal de reloj xD.
Recuerda que para un nuevo proyecto, se debe recurrir a un MCU que ya esté por lo menos un año en el mercado y se conozca los problemas o bugs de silicio que podría poseer. Está muy bien para realizar un prototipo o realizar pruebas de su funcionamiento.
La siguiente imagen lo dice todo cuando quieres lanzar un producto con un micro nuevo.
(https://westsoundmodern.files.wordpress.com/2009/08/painted-into-corner.jpg)
-
Hola,
tengo que hacer un proyectito con los MZ. No tiene muchos requerimientos pero no sé si se han ido solucionando ya los bugs de los que llevais hablando casi un año... y como no tengo experiencia con estos micros... Sólo necesito:
1. FPU. ¿Funciona sola?.
2. USB esclavo con librería HID. ¿Siguen habiendo problemas con el xtal externo?.
3. Bootloader para actualizar el firmware.
Gracias.
Saludos,
-
Hola,
tengo que hacer un proyectito con los MZ. No tiene muchos requerimientos pero no sé si se han ido solucionando ya los bugs de los que llevais hablando casi un año... y como no tengo experiencia con estos micros... Sólo necesito:
1. FPU. ¿Funciona sola?.
2. USB esclavo con librería HID. ¿Siguen habiendo problemas con el xtal externo?.
3. Bootloader para actualizar el firmware.
Gracias.
Saludos,
En este hilo hay una conversación interesenta acerca del MZ nuevos:
http://www.microchip.com/forums/m793368-p5.aspx (http://www.microchip.com/forums/m793368-p5.aspx)
Respecto a MPLAB Harmony
http://www.microchip.com/forums/m793368-p5.aspx (http://www.microchip.com/forums/m793368-p5.aspx)
-
Gracias.
Los dos son el mismo link???.
No sé ni que es harmony :shock:
Saludos.
-
Gracias.
Los dos son el mismo link???.
No sé ni que es harmony :shock:
Saludos.
Lo siento. Me equivoqué, el otro enlace es: http://www.microchip.com/forums/m793368-p5.aspx (http://www.microchip.com/forums/m793368-p5.aspx)
MCHP dejó de actualizar MLA para los micros de 32 bist y actualmente propone la utilizar Harmony.
Para los PIC32MZ es obligatorio programar en Harmony si deseas utilizar librerías de MCHP. Parece que ya existe soporte de terceros con respecto a los MZ
Info de Harmony:
http://www.microchip.com/pagehandler/en_us/devtools/mplabharmony/home.html (http://www.microchip.com/pagehandler/en_us/devtools/mplabharmony/home.html)
-
Hola,
tengo que hacer un proyectito con los MZ. No tiene muchos requerimientos pero no sé si se han ido solucionando ya los bugs de los que llevais hablando casi un año... y como no tengo experiencia con estos micros... Sólo necesito:
1. FPU. ¿Funciona sola?.
2. USB esclavo con librería HID. ¿Siguen habiendo problemas con el xtal externo?.
3. Bootloader para actualizar el firmware.
Gracias.
Saludos,
Te recomiendo encarecidamente, no usar los pic32MZ, los bug de silicio no han sido solucionados, si tienes la suerte de que el micro que compres es la versión del silicio A5(creo que era) podrás poner un cristal externo pero con hardware externo.
Si no puede ponerle el cristal olvidate del hid, del cdc, del USB 2.0, del USB en general.
El adC según el micro que te vendan tampoco te funcionará,
No tiene FPU, tiene instrucciones dsp pero en punto fijo.
El bootloader si lo quieres por USB, ya sabes, reza porque funcione la chapuza de la solución del cristal y te vendan la revision del micro más nueva para que funcione la chapuza.
Dicho por microchip, no se va a reparar el micro, debido al costo del diseño de una oblea de silicio, es la primera vez que fabrican en ese tamaño de tecnología, tendrás que esperar a ala siguiente generación, para ver soluciones (y no chapuzas) además de una fpu de verdad.
Los MZ y los pic32mx2XX son los culpables de que yo nunca mas haga un nuevo diseño con pic32.
Puedes repasar mis post sobre los pic32MX2 y sus bug, sobre todo el de que no se puede usar, la memoria flash y la uart por interrupción, bug del que informe yo mismo a microchip y me lo confirmaron.
Si no te queda mas remedio que usar los pic32MZ, te deseo suerte, y reza porque no te de problemas en lo que uses.
En cuanto a las harmony ( las nuevas librerías de microchip para pic32), me parecen las mejores librerías que ha tenido microchip hasta ahora, de momento no he encontrado por ejemplo while para esperar una comunicación, como con las otras, pero tampoco las he probado mucho, así que tampoco pongo la mano en el fuego por ellas, yo nunca lo sabré.
Un saludo.
-
Si pone bien claro FPU!!!!! ¿cómo que no tiene?. Sólo necesito un micro con FPU, USB esclavo HID y un bootloader. Si no tiene eso pues vaya P.M. de micro (con perdón).
Saludos.
-
Te recomiendo encarecidamente, no usar los pic32MZ, los bug de silicio no han sido solucionados, si tienes la suerte de que el micro que compres es la versión del silicio A5(creo que era) podrás poner un cristal externo pero con hardware externo.
Supuestamente la versión EF corrige los bugs de la versión EC, pero nadie debería lanzarse a fabricar un proyecto con un MCU nuevo, tal vez un prototipo para pruebas, pero con la conciencia que un micro nuevo puede traerte sorpresas desagradables con bugs no descubiertos. Le ha pasado a Ti, a NXP, a Atmel.
Yo realicé esta duda al foro de MCHP acerca si debería o hacer un proyecto con un MZ y esto respondieron: (Traducido)
Actualmente en el medio de la primera revisión del dispositivo, después de un período de trabajar con el PIC32MZ Starter Kit. Tu experiencia dependerá de qué periféricos en tu proyecto necesitas y cuales las erratas necesitas evitar. Creo que es posible enviar un producto fiable y sólido, después de un estudio suficiente del producto, desarrollo y el tiempo de pruebas.
Si no ha trabajado con Harmony antes, esto le da suficiente tiempo para aprender. Harmony puede tener beneficio para aplicaciones muy grandes, y la integración con productos de terceras partes, pero sigue siendo muy difícil de manejar en comparación con MLA. Algunos periféricos aún no están debidamente soportados por el MCH - una característica muy agradable, pero no es útil si el soporte de periféricos no es completo. Por ejemplo, la depuración de la consola y Wifi están todavía en estado alfa/beta.
Mientras que otra persona responde:
Estamos utilizando el PIC32MZ en nuestro diseño actual. Apenas hemos terminado el software, el diseño del hardware se ha mantenido estable durante un tiempo.
Por supuesto, hay un buen número de problemas que se deben evitar, pero en general creo que las ventajas de este IC superan a las desventajas.
Estamos utilizando gráficos de LCC, USB y puertos serie, y tenemos una poderosa plataforma para nuestro producto.
Info de esta conversa:
http://www.microchip.com/forums/m861721.aspx
A la final, sólo tu deberías decisdir si tu producto puede o no teener problemas.
-
Personalmente yo migré todo mi proyecto con el PIC32MX795F512H a Harmony y funciona bastante bien
Trabajo con TCP/Ip, puerto serial RS232 y SPI.
Encontré un bug que prometen solucionar para la versión 1.07 de Harmony, pero para solucionar dicho problema tuve que hacerlo a la manera antigua y funciona de maravilla:
Información acerca de dicho problema:
http://www.microchip.com/forums/m889819.aspx (http://www.microchip.com/forums/m889819.aspx)
-
Si pone bien claro FPU!!!!! ¿cómo que no tiene?. Sólo necesito un micro con FPU, USB esclavo HID y un bootloader. Si no tiene eso pues vaya P.M. de micro (con perdón).
Saludos.
Perdón, por lo visto ya han puesto en producción a los EF, esos si tienen FPU, pero han salido al mercado hace "dos días", los piz32MZ EC NO TIENEN FPU
De estos nuevos no te puedo hablar, es una gama nueva (muy muy nueva) y no te puedo dar mi opinión subjetiva, solo la objetiva, la objetiva es que no los uses :D :D
Como ya te he dicho, para mi pic32 ha muerto. He aguantado un fallo detrás de otro sumado a sus cada vez peores compiladores gratuitos para obligarte a comprar.
Quizá con estos nuevos EF se han puesto las pilas y es un micro de verdad, tal y como prometían con los MZ EC, y no la basura que sacaron al mercado.
Como ha dicho dominus dependiendo de que tengas que lidiar con las erratas, así escaparas...
Yo de nuevo, te deseo suerte... y que dios te acompañe :D :D
-
Voy a ponerles un ticket a ver que me dicen. Juanjo: no te me tientes a irme a Freescale que te quedas sin la plaquita para programar :P
-
Voy a ponerles un ticket a ver que me dicen. Juanjo: no te me tientes a irme a Freescale que te quedas sin la plaquita para programar :P
Yo creo que deberias darle una oportunidad a los pic32MZ, seguro que ya han mejorado y son muy buenos, no creo que tengas ningun problema, si dudas buscate uno de atmel, nxp, o st que esta muy de moda y barato... no uses uno de freescale hombre, esos son una mierda...seguro que te dan muchos problemas.
Mejor asi? :D :D
-
... Como ya te he dicho, para mi pic32 ha muerto. He aguantado un fallo detrás de otro...
...Yo creo que deberias darle una oportunidad a los pic32MZ, seguro que ya han mejorado y son muy buenos...
¿Y esos cambios tan bruscos?
-
Voy a ponerles un ticket a ver que me dicen. Juanjo: no te me tientes a irme a Freescale que te quedas sin la plaquita para programar :P
Yo creo que deberias darle una oportunidad a los pic32MZ, seguro que ya han mejorado y son muy buenos, no creo que tengas ningun problema, si dudas buscate uno de atmel, nxp, o st que esta muy de moda y barato... no uses uno de freescale hombre, esos son una mierda...seguro que te dan muchos problemas.
Mejor asi? :D :D
:D :D :D :D :D :D Eres más falso que un duro de seis pesetas :D :D :D :D :D :D
-
Yo no queria responder pero...
Elegi lo que quieras manwenwe. Solo recorda que tenes que tener:
- Compilador - Costo o lo que se te cruce
- Programador - Costos
- Ejemplos ( ayudan xD )
- Que los perifericos sean los adecuados para lo que pensas hacer, es decir no te quedes corto.
- Costo de los micros
- Librerias
Seguro que me olvido algo mas. Pero solo desearte suerte en lo que elijas...
Por lo que pedis no parece que vas a necesitar un GRAN micro. O tambien podes probar cualquier Cortex-M4F que tambien posee una FPU ( como coprocesador ) y almenos yo en TI ya me ofrece una libreria con un bootloader por software el cual le puedo poner un algoritmo de desencriptado. Sino la mayoria de los ARM poseen en su ROM el bootloader, UART/SPI/USB/Ethernet , Vos tenes muchas placas con ARM asi que lo tenes que saber xD. Si tu objetivo es ir por Microchip entonces adelante.
-
¿Y esos cambios tan bruscos?
Si decide hacerlo con un freescale, me quedo sin una programadora para los kinetis que me iba a vender.
:D :D :D :D :D :D Eres más falso que un duro de seis pesetas :D :D :D :D :D :D
No se porque dices eso, solo miro lo mejor para ti, y lo he pensado mejor y creo que deberias usar un micro con FPU que no sea de freescale, ya has hecho muchas cosas con freescale, tienes que abrir mundo y usar otras marcas que si no te acostumbras y eso no puede ser...usa uno de NET de siemens esos cada vez se usan más, y tienen tecnologia punta, son el futuro de los microcontroladores... :D :D
O si no me crees a mi mira lo que dice kilerjc:
O tambien podes probar cualquier Cortex-M4F (QUE NO SEA FREESCALE)que tambien posee una FPU ( como coprocesador ) y almenos yo en TI ya me ofrece una libreria con un bootloader por software el cual le puedo poner un algoritmo de desencriptado.
-
Yo no queria responder pero...
Elegi lo que quieras manwenwe. Solo recorda que tenes que tener:
- Compilador - Costo o lo que se te cruce
- Programador - Costos
- Ejemplos ( ayudan xD )
- Que los perifericos sean los adecuados para lo que pensas hacer, es decir no te quedes corto.
- Costo de los micros
- Librerias
Seguro que me olvido algo mas. Pero solo desearte suerte en lo que elijas...
Por lo que pedis no parece que vas a necesitar un GRAN micro. O tambien podes probar cualquier Cortex-M4F que tambien posee una FPU ( como coprocesador ) y almenos yo en TI ya me ofrece una libreria con un bootloader por software el cual le puedo poner un algoritmo de desencriptado. Sino la mayoria de los ARM poseen en su ROM el bootloader, UART/SPI/USB/Ethernet , Vos tenes muchas placas con ARM asi que lo tenes que saber xD. Si tu objetivo es ir por Microchip entonces adelante.
Mis dos centavos respecto a estas sugerencias:
- Leer siempre las erratas.
- Buscar si alguien ha tenido problemas con algún dispositivo.
- La mejor información se encuentra en los foros en inglés.
- Trabajar con un dispositivo que tenga por lo menos un año de comercialización.
Y finalmente, la ingeniería es cada día enfrentar muchos retos y problemas. Y a los problemas hay que solucionarlos, no quejarse de ellos.
-
Yo tambien voy a añadir mis cosas a las de killerjc:
la infenieria es un proceso de creacion que debe ser siempre robusto y fiable.
Si utilizas componentes defectuosos, con bug, malos y chapuceros, tus productos seran iguales.
Debemos dejar de intentar defencer lo que usamos, o queremos usar y buscar siempre lo mejor, de esta manera no perderemos tiempo arreglando las chapuzas de otros y nuestros productos seran sinonimos de calidad.
Claro, que hay gente que no le importa perder tiempo de desarrollo en intentar arreglar chapuzas ajenas o fabricar sus productos con componentes defectuosos, asi hay luego en el mercado cada cosa que vaya tela.
La conclusion es utilizar componentes de calidad y no basura. Centrar el tiempo en arreglar los problemas ingenieriles y no perder el tiempo en solucionar los problemas y chapuzas ajenas. Si algo no vale, a la basura.
Un saludo
-
(http://new2.fjcdn.com/comments/5284191+_08cdff9ec987ceeccaf2b4b7cc0822dd.jpg)
-
Concuerdo con todos los puntos agregados. Tanto por Dominus como por juaperser, respecto a la eleccion de los microcontroladores.
La conclusion es utilizar componentes de calidad y no basura. Centrar el tiempo en arreglar los problemas ingenieriles y no perder el tiempo en solucionar los problemas y chapuzas ajenas. Si algo no vale, a la basura.
Yo como dije en su momento renegue mucho con una fabrica por sus "politicas" de fabricacion, envie un par de "sugerencias" pero todas pasaron como si nada. Incluso que no eran de electronica en si. Si no en la parte mecanica, la cual al hacer los services te encontrabas con esos problemas y mas cuando tenias 3 productos con los mismos problemas, que para arreglarlo debias destruir el producto y luego tratar de taparlo, a no ser que tengas un taller era imposible hacer una solucion decente, todo por que ellos le cortaban la cabeza a los tornillos o soldaban las chapas para no gastar unos centimetros mas y ponerle tornillos. les dije que los dejen y todavia siguen ahi sin eso..
Es cierto que la ingenieria esta para resolver problemas. Pero si vos compras un integrado para solucionar un problema, no vas a buscar MAS problemas. Queres que los problemas de eso sea lo menos posible y te ayude a solucionar tus problemas originales. De nada sirve estar complicandose la vida con algo que no funciona como es debido, si por el mismo precio lo hacias en menos tiempo y menos esfuerzo. No estoy diciendo que con el PIC se vaya a complicar mas por eso, que no se mal entienda. Tal ves el PIC tiene un periferico que le sirve mucho mas que cualquier otro. Creo que no se discute sobre su la ingenieria puede o no resolver los problemas (ya que vas a buscarlo y resolverlo), ni que uno se queja de estos, sino sobre saber elegir mejorando costo/tiempo en un proyecto.
-
Yo no queria responder pero...
Elegi lo que quieras manwenwe. Solo recorda que tenes que tener:
- Compilador - Costo o lo que se te cruce
- Programador - Costos
- Ejemplos ( ayudan xD )
- Que los perifericos sean los adecuados para lo que pensas hacer, es decir no te quedes corto.
- Costo de los micros
- Librerias
Seguro que me olvido algo mas. Pero solo desearte suerte en lo que elijas...
Por lo que pedis no parece que vas a necesitar un GRAN micro. O tambien podes probar cualquier Cortex-M4F que tambien posee una FPU ( como coprocesador ) y almenos yo en TI ya me ofrece una libreria con un bootloader por software el cual le puedo poner un algoritmo de desencriptado. Sino la mayoria de los ARM poseen en su ROM el bootloader, UART/SPI/USB/Ethernet , Vos tenes muchas placas con ARM asi que lo tenes que saber xD. Si tu objetivo es ir por Microchip entonces adelante.
Yo tengo muchas placas ARM pero son procesadores no miconcontrladores. De la familia M no tengo ni idea. Los que yo diseño llevan todos un linux en memoria externa. ¿Me recomiendas alguno de texas? Lo dicho necesito:
- Bootloader fácil de instalar.
- USB HID con librería facil de instalar.
- FPU.
- Preferiblemente encapsulado en pocos pines (sólo voy a usar USB).
- Que el programador no valga un pastón o que se pueda programar por jtag.
- Software de desarrollo gratuito.
Si me decis que los PICs nuevos están en pañales me fio de vosotros. No te preocupes juanjo: te mando la placa igualmente. Si utilizara freescale la compro de nuevo y la paga mi cliente como programador.
Saludos!
-
Bueno eso acorta la busqueda. La familia M, simplemente le quita el MMU y no posee cache , a no ser que te vayas al M7. el M4F posee FPU de SP, apartir del M3 en adelante pueden usar todas las instrucciones de Thumb-2 sin ningun problema, solo aceptan Thumb y no ARM. Algo que te va a importar poco obviamente.
Cortex-M4F (casi todas las placas de evalucion traen programador, lo que no se si es valido para ese micro o todos de la familia):
Ti = posee de 64 pines en adelante, 80Mhz / costo unos 4.3 dolares los mil. Placa de evaluacion a 13 dolares, pero ese integrado que posee esa placa cuesta 5 dolares y algo. Con la placa te habilita a usar el Code Composer Studio de TI sin limites de codigo.
Board: http://www.ti.com/tool/ek-tm4c129exl
Lo mas barato: http://www.ti.com/product/TM4C1233H6PM/description y mas pequeño ( hay mas que tiene una que otra cosita distinta )
ST = Aca juanjo no le gusta, pero son los mas baratos. Mircos de 48 pines, 75/80Mhz, con USB , placa de evaluacion cerca de los 10 dolares, micros de 3 dolares y algo, hay mucha info en internet sobre ST, compilador no se, pero se que puede ser usado con GCC al igual que todo ARM
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1576/LN1824/PF253741
NXP = minimo 80 pines, 5.4 dolares, pero muchas mas prestaciones, tal ves por demas de lo que buscas.
http://www.nxp.com/products/microcontrollers/core/cortex_m4_m4f/LPC4078FBD80.html
Freescale = No encontre nada relevante, placas caras incluso de evaluacion
PIC ( MIPS ):
http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MZ0512EFE064
El mas barato de los MZ, con FPU, 6 dolares los mil. Creo que ya todos se deberian poder programar por JTAG al igual que los ARM, pero solo vi "debug" por JTAG y no programacion... asi que no puedo responderte a eso.
Todo esto sin ver erratas, ni feedbacks, ni tiempo de que salieron, nada.. Hay gente que esta mas acostumbrada a manejar los demas micros. Si es por algunas placas nomas tal ves te convenga directamente buscar un micro con un ejemplo de USB y listo te solucionas la vida. Siendo el USB la parte mas complejade lo que queres conectar
Tal ves por costo/ cantidad de pines/ uso , termines con el de ST.. Los demas por ahi tienen mucha mas cosas que realmente no se si valen la pena tenerlos. Aunque todo va a depender de lo que tengas que hacer. Por eso mismo, elegi vos xD
-
Los MZ están más o menos por el coste de los de ST aunque van a mucha más frecuencia. Aunque esto tampoco me importa mucho. Lo que tengo que hacer es "una mochila": un microcontrolador que recibe ciertos comandos desde una placa ARM de más nivel y ejecuta algunas operaciones en coma flotante y devuelve datos. Así te pueden piratear el SW de la placa ARM "grande" (RPI, BBB, Wandboard, etc.) pero no lo que hay en el microcontrolador porque los fuses protegen a flash interna. Esto de la ST me mola muuuuucho:
Boot modes
At startup, Boot0 pin and Boot1 option bit are used to select one of three boot options:
● Boot from user Flash
● Boot from system memory
● Boot from embedded SRAM
The boot loader is located in the system memory. It is used to reprogram the Flash memory
by using USART1 (PA9/PA10), USART2 (PD5/PD6) or USB (PA11/PA12) through DFU
(device firmware upgrade).
Voy a investigar como están las herramientas de SW y la librería HID.
Gracias KillerJC!!!
-
Sobre el bootloader, todos los ARM tienen posibilidad de ejecutar desde la RAM. Asi que no es nada nuevo. Otros micros tambien poseen bootloader cargados en la ROM, el tema es que esos no permiten el modificarlos, asi que nada de agregar desencriptado ni nada por el estilo. En ARM me parece muy facil hacer un bootloader. ya que es crear el programa, proteger la zona del bootloader, y que al comienzo solamente se cambie la direccion de inicio de la tabla de vectores. Eso + cambiar la direccion de inicio en el linker y es todo creo yo.
Con MIPS no me meti demasiado en la arquitectura asi que no puedo hablar mucho de la misma, si mire el tema de las instrucciones ASM, pero nada mas.
-
Sobre el bootloader, todos los ARM tienen posibilidad de ejecutar desde la RAM. Asi que no es nada nuevo. Otros micros tambien poseen bootloader cargados en la ROM, el tema es que esos no permiten el modificarlos, asi que nada de agregar desencriptado ni nada por el estilo. En ARM me parece muy facil hacer un bootloader. ya que es crear el programa, proteger la zona del bootloader, y que al comienzo solamente se cambie la direccion de inicio de la tabla de vectores. Eso + cambiar la direccion de inicio en el linker y es todo creo yo.
Con MIPS no me meti demasiado en la arquitectura asi que no puedo hablar mucho de la misma, si mire el tema de las instrucciones ASM, pero nada mas.
Me gusta mucho. Si hay un bootloader que directamente carga el hexadecimal desde una app por USB ya tienes el programador hecho. Si además tiene encriptamiento mejor que mejor. Me falta ver las tools de SW y las librerías USB. Cosas malas: USB es 12mbps, la frecuencia no es muy alta y la FPU es float y no double, pero bueno por el coste que tienen tampoco se pueden pedir maravillas...
Por cierto: cual es la placa de desarrollo? No la encuentro :?
Gracias.
Saludos.
-
hola mawenwe, yo estoy de acuerdo con todo lo que ha dicho killerjc, es cierto que no me gusta ST, por sus perifericos y por la documentacion (y por algun problema que me han dado en ambientes industriales)
pero para tu aplicación yo te recomiendo:
los cortex M4F ST, Freescale, o atmel.
entorno de desarrollo gratuito los tres, el de atmel (atmel estudio) y freescale (KDS) de la propia empresa el de ST de terceros.
descarto atmel por que la herramienta de programacion es cara.
Freescale = No encontre nada relevante, placas caras incluso de evaluacion
con esto es con lo unico que no estoy de acuerdo, las freedom son baratas y con ellas puedes programar placas propias.
las de ST igual, con la placa de evaluacion discovery puedes programar otros micros ST.
por lo tanto yo te lo acoto si quieres mas todavía a ST y a freescale.
Por cierto: cual es la placa de desarrollo? No la encuentro :?
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419
la freedom de frescale ya la tienes.
lo que menos me gusta de ST es los periféricos, que por ejemplo no tiene PHY de USB, pero si lo vas a usar por HID, vas sobrado. En cuanto a las librerias y la documentación de ST es la otra pega que les pongo, es dificil tratar con ella, por lo desperdigadas que están las cosas.
-
Como que no tiene PHY de USB? en el datasheet me salen 2 pines de USB y no una ULPI.
-
uno es el usb del micro de la programadora (como la de freedom que tiene el opensda) que se llama ST link V2 (tambien venden la programadora por separado y hay tienes el JTAG y el SWD muy barata 20 euros creo que vale)
http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168?sc=internet/evalboard/product/251168.jsp
y el otro USB es un USB OTG FS, no tiene HS, si la quieres para CDC, HID, MSD... no pasa nada, pero si quieres usb 2.0 pues tienes que meterle PHY externo.
por eso te decía que no me gustan los ST, tiene un remapeo y perifericos bastante pobres si los comparas con Atmel, texas o freescale. Si le pones el PHY ya te quedas sin unos pocos de periféricos, le pones memoria externa y te quedas sin usb o sin ethernet, y cosas por ese estilo.
como ha dicho killerjc todo depende de la aplicación, a ti para esa te va a sobrar, pero yo quise hacer un proyecto gordo con ST, (un stm32F439) con USB 2.0, Ethernet y memoria externa y me quede sin pines, se pisaban los remapeos, y no me equivoque por que lo hice con las "cube" que te los remapea según los periféricos que tu le digas.
un saludo.
-
Con el FS me sobra porque HID no tira más de 64Kb/s. Lo que no me gusta nada del link que me has mandado es que leo por ahí "keil": ya estamos jo****do con el SW de pago de ARM :5]
Saludos.
-
Con el FS me sobra porque HID no tira más de 64Kb/s. Lo que no me gusta nada del link que me has mandado es que leo por ahí "keil": ya estamos jo****do con el SW de pago de ARM :5]
Saludos.
Cuando te compras la discovery te recomiendan keil, IAR, otro de pago que n me acuerdo, porque st no tiene IDE propio, con las demás compañías.
Pero por eso no te preocupes, tienes el coocox, el adblock, un plugin para eclipse que se llama AC6 (que recomienda ST y yo también si vas por ST)....
Pero si buscas un IDE desarrollado por st, no hay (otra de las cosas que no me gustan de st), pero vamos, que por eso no te preocupes los vas a programar gratis y sin ningún problema desde eclipse con el pluggin AC6
Un saludo
-
Thx ((:-))
-
Para los que queréis juguetear con ST: echad un vistazo a Em::Blocks.
Aunque or recomiendo los Kinetis de Freescale. Precios de risa y muchísimas configuraciones, desde pocos pines hasta compatibilidad total con 5V en algunos casos.
-
Para los que queréis juguetear con ST: echad un vistazo a Em::Blocks.
Aunque or recomiendo los Kinetis de Freescale. Precios de risa y muchísimas configuraciones, desde pocos pines hasta compatibilidad total con 5V en algunos casos.
Lo que no me gusta de freescale es que tengo entendido que el codewarrior ese es de pago. ¿me equivoco?.
Edito:
La verdad es que sí son de risa los precios:
http://www.mouser.es/ProductDetail/Freescale-Semiconductor/MK22FN128VLH10/?qs=%2fha2pyFadujOaTS62yr9HaoXJDqTWdReBv0b4xLD8h2GwY5t46SDMg%3d%3d
-
Manu, tienes que leer mas mis mensajes :D :D
entorno de desarrollo gratuito los tres, el de atmel (atmel estudio) y freescale (KDS) de la propia empresa el de ST de terceros.
Conde warrior es de pago, para toda la gama de productos de freescale.
Pero para sus micros ARM esta KDS (Kinetis desing estudio) totalmente gratuita y mantenida por la freescale
Ay que ver que no me haces ni put* caso :D :D
Emblock para ST, también te lo nombre, pero me lo cambio el corrector a adblock.
Pero por eso no te preocupes, tienes el coocox, el adblock, un plugin para eclipse que se llama AC6 (que recomienda ST y yo también si vas por ST)....
Tu te crees que con todo lo que he investigado, y probado, me iba a querer pasar a freescale kinetis por gusto? :D
Entorno de desarrollo gratuito, se le puede poner memoria externa, tiene micros especializados, sus periféricos son los mejores comparados con sus competidores, (adC de 16 bits, dac de 12, flexcan, PHY USB incorporado etc etc,) el cortex M7, va a 240 MHz, con doble precisión para control de motores ( ese es especializado de momento), documentación de la mejor entre las empresas (ya veras cuando veas la de ST)...
Lo único que no le gusta demasiado es que no tiene una herramienta de programación propia, tipo icd3 o jlink, pero ellos te recomiendan de terceros o puedes usar una fredom con opensda parqnprogrqmarlas y debuguearlas.
Y por ultimo pero no menos importante KDS se puede usar en linux, a diferencia de AC6( que esta experimental), el de atmel que solo esta para window, el de Texas que es de pago etc etc.
Parece que lo que quiero es convencerte, pero te digo las cosas que me han convencido a mi :D
-
Te pillas un J-LINK EDU por poco más de 50€ y a disfrutar de los Kinetis.
-
Tengo el j-link pro. Para los Cortex A son una mierda. A ver si para estos me valen porque tengo la sensación desde hace 3 años que tiré 800€ a las basura. :( :( :(.
Al final me quedo con los kinetis!!! (no cambio más de idea lo prometo jejeje).
Saludos.
-
no cambio más de idea lo prometo jejeje
haha, a mi me pasa lo mismo, pruebo una cosa no me gusta y cambio completamente, es normal que vayas de un lado a otro hasta que encuentres lo que te gusta.
yo he pasado por 3 carreras :D :D
-
El codewarrior no deja de ser el eclipse con un compilador de codewarrior. Por lo que he visto, el kinetis desing studio es un eclipse con compilador gcc, asi que no es necesario irse al codewarrior. Teneis suerte, yo con la serie de powerpc no tengo mas remedio que pasar por codewarrior.
-
Teneis suerte, yo con la serie de powerpc no tengo mas remedio que pasar por codewarrior.
claro, es otra arquitectura y desgraciadamente hay que pagarla por usar herramientas especializadas.
pero con ARM yo veo bien que hayan sacado el KDS, por que los kinetis son ARM y la tendencia es usar IDEs gratuitos, no entiendo las empresas que se aferran a cobrar los IDEs para ARM, en mi opinión los IDEs de pago para ARM, estan destinados a desaparecer.
Los hay con cara dura como microchip que cogen el compilador gcc y te lo cobran :D :D con dos c***jones :D :D
-
Bueno, pewro le añaden los "headers" y "linker scripts". ;)
-
Bueno, pewro le añaden los "headers" y "linker scripts". ;)
bueno eso verdad, algo es algo :D :D :D
-
Ponte a estudiar.
-
Ponte a estudiar.
joo que estoy en mi descanso :8} :D :D
pero es verdad, ya voy ;-)