Assembler en ARM - Probando

[KILLERJC]

Moderacion:
       <Tema Separado de Jugando en ASM con XC16 y dsPIC33F >

Mensaje Original:

Gracias elgarbe,

La verdad que siempre dicen que Microchip uso el compilador GCC lo trasformo y lo esta cobrando, si uno observa con detenimiento. Es verdad , al menos para C, tal ves tiene una que otra diferencia pero hay muchas cosas que aplican por igual.
Hace poco me tienen con lo de PIC18 y me pusieron a hablar del linker/compiladores, asi que ahi aproveche y le di una repasadita a como funciona el MPASM
http://www.todopic.com.ar/foros/index.php?topic=45254.msg376641#msg376641
Y creo que de paso es la primera ves que veo colgado un codigo ASM de PIC el cual esta unido por el linker, juntos con las variables posicionadas por el linker tambien. Mas que nada por eso quise hacerlo xD

Al final yo creo que aca termine, no se que mas agregar, por que lo demas es sobre modulos. Parece que voy a tener que centrarme en ARM nomas,

[elgarbe]

.... Parece que voy a tener que centrarme en ARM nomas,

pues ahí te espero, estoy avanzando con el cartel LED (http://www.todopic.com.ar/foros/index.php?topic=43643.0) y hay algunas cosas que me gustaría probar en ASM...

saludos

[juaperser1]

La verdad que siempre dicen que Microchip uso el compilador GCC lo trasformo y lo esta cobrando, si uno observa con detenimiento. Es verdad

claro que es verdad, no lo esconden, incluso si le das a MPLAB a las opciones de proyecto puedes tocar las opciones de GCC.

y si no os habéis dado cuenta, a cada versión nueva del compilador free, usa mas recursos, ya lo he puesto en otros post, pero lo recalco:

version free XC32, PIC32MX de 16Kb, un pograma con 8 funciones y unas cuantas variables ya no entra, bien hecho microchip

un saludo

[KILLERJC]

version free XC32, PIC32MX de 16Kb, un pograma con 8 funciones y unas cuantas variables ya no entra, bien hecho microchip

Casi todo parece un problema de la rutina de inicializacion + vectores de interrupcion (espero que no siga con sus "vectores alternativos" en el PIC32). Sino habria que crear un simple programa y pasarlo por dissasembler.
Lo que noto yo al menos en lo que es ARM es que utiliza las rutinas memset de C, son larguisimas! (al menos GCC). Y tal ves se puede achichar un poco mas.

[juaperser1]

version free XC32, PIC32MX de 16Kb, un pograma con 8 funciones y unas cuantas variables ya no entra, bien hecho microchip

este caso en concreto, es que me toco la moral, por que todavía en el curro y tenia soporte técnico de microchip, (por cierto creo que ahora me odian  , les he dejado en evidencia en algún seminario con los bug de los MZ y los mcp39f)

total, en este caso un pic32mx210f016b, 16Kb, intente hacer un bootloader por MSD (USB) y el ejemplo de microchip te viene con el linker para este micro+ el ejemplo etc etc. pues con el set de instrucciones reducido a MIP16 y con el compilador PRO de la versión de un mes, solo el bootloader, ocupaba 14,5Kb!!!! tal como venia el ejemplo, solo el bootloader vacio con las librerias del USB y el FAT32, no digas que ese micro puede con un bootloader MSD por que no puede.

me han dado tantos dolores de cabeza los pic32... enserio hoy por hoy en la familia PIC32MX2XX no puedes usar la uart y la flash en el mismo programa por un bug, que no han terminado de arreglar ni en la versión A2 del silicio.

esa fue la gota que me arto de microchip.

Lo que noto yo al menos en lo que es ARM es que utiliza las rutinas memset de C, son larguisimas!. Y tal ves se puede achichar un poco mas.

esto, no lo sabia, pero vamos, que he trabajado con ST un 103 y alguno mas de M4 (que por cierto tampoco migrare nunca a ST por que tambien me dieron muchos dolores de cabeza), y el ST con 32Kb entraba todo el código y sobraba mucho espacio.

en el pic32MX2xx mas chico nos tuvimos que ir a un 250 con 128Kb de memoria para que entrara, y mucho mas caro encima, el tema era migrarlo a pic por que el de ST daba muchisimos problemas y bug, pero no pudo ser por que el de 128Kb de memoria costaba muchisimo mas que el ST, así que pasamos de usar micros de 32 bit a micros de 8 bit y a trabajar con pic18 y con los compiladores antiguos.

me prometi a mi mismo no hacer ni un solo proyecto mas con pic32 ni con ST 

Lo que noto yo al menos en lo que es ARM es que utiliza las rutinas memset de C, son larguisimas!. Y tal ves se puede achichar un poco mas.

lo bueno seria, (cuando hagas el tutorial ejem ejemm... ) escribir las funciones en ASM y el programa principal en C

un saludo

[KILLERJC]

lo bueno seria, (cuando hagas el tutorial ejem ejemm... ) escribir las funciones en ASM y el programa principal en C

Esa es la parte mas facil ,

Código: ASM

1. .thumb
2.         .text
3.         .global _funcion
4.  
5. _funcion:
6.         @aca instrucciones
7.  
8.         .end

Y ya tenes un codigo que podes llamar desde C e.e lo unico que falta en C es que lo definas extern con el numero de argumentos que te guste xD

EDIT: Que tipo de funciones les gustaria ver implementado en ASM ? en el Ejemplo me refiero. no me digan Ethernet por que los mando a...

[juaperser1]

Y ya tenes un codigo que podes llamar desde C e.e lo unico que falta en C es que lo definas extern con el numero de argumentos que te guste xD

clarooooo aqui el experto en ASM que facil lo ve todo    pero habrá que guardar registros en la pila, recuperarlos, pasar los datos  a la función ASM tambien en la pila, retornar datos etc.

para ti muy fácil, para mi... no 

he hecho 4 cosas mal contadas en pic16 mezclando c y asm, y  en el procesador motorola 68000 en la uni, que literalmente tiene mas años que yo 

[elgarbe]

EDIT: Que tipo de funciones les gustaria ver implementado en ASM ? en el Ejemplo me refiero. no me digan Ethernet por que los mando a...

si queres algo por donde empezar.... pues mirá, estoy armando el esqueleto de lo que será el firm del cartel RGB y hasta ahora he creado este código:

Código: C++

1. uint8_t i, j;
2.         uint64_t MC = 0;
3.         MC |= 0x02 << 00;               // MC = 11.6-8.1 mA
4.         MC |= 0x7F << 03;               //BC Red = 100%
5.         MC |= 0x7F << 10;               //BC Green = 100%
6.         MC |= 0x7F << 17;               //BC Blue = 100%
7.                                                         //SID = 0; LODVLT=0; LSDVLT=0; PSMODE=0 (no PWS)
8.         MC |= (uint64_t)0x96 << 40;             //WRITE_CMD: Bits 40 a 47 en 10010110b
9.         MC |= (uint64_t)0x01 << 48;             //Data Select Bit = 1
10.  
11.         for(j=49;j>0;j--)
12.         {
13.                 if(MC & ((uint64_t)1<<(j-1)))           //Verifico si el bit es un 0 o un 1
14.                 {
15.                         HAL_GPIO_WritePin(SIN_PORT, SIN_PIN, GPIO_PIN_SET);
16.                         HAL_GPIO_WritePin(SIN_PORT, SIN_PIN, GPIO_PIN_SET);
17.                 }
18.                 else
19.                 {
20.                         HAL_GPIO_WritePin(SIN_PORT, SIN_PIN, GPIO_PIN_RESET);
21.                         HAL_GPIO_WritePin(SIN_PORT, SIN_PIN, GPIO_PIN_RESET);
22.                 }
23.                 //Pulso de CLK
24.                 HAL_GPIO_WritePin(SCLK_PORT, SCLK_PIN, GPIO_PIN_SET);
25.                 HAL_GPIO_WritePin(SCLK_PORT, SCLK_PIN, GPIO_PIN_RESET);
26.         }
27.         //una vez enviados los 49 datos hago un latch
28.         HAL_GPIO_WritePin(LAT_PORT, LAT_PIN, GPIO_PIN_SET);
29.         HAL_GPIO_WritePin(LAT_PORT, LAT_PIN, GPIO_PIN_RESET);

no sé si se entiende la idea, pero mas o menos es así:
El TLC5954 tiene un registro de desplazamiento de 49 bits. 48 son datos y 1 es para indicar si lo que escribo es dato (on/off de la salida) o comando (configuraciones ).
En este caso estoy configurando el TLC. Una vez que detecto si el bit es 1 o 0 escribo la señal en SIN_PIN. Como vez repito 2 veces la instruccion de escribir, esto es asi porque necesito un pequeño tiempo entre poner la señal en SIN y darle el pulso de clock. Obvio que se podría realizar todo esto mucho mejor, pero son las primeras pruebas básicas como para testear las placas tambien.
Algo interesante sería hacer uso de bit banding para poder obtener mayor frecuencia de salida.
serviría?
el micro en cuestion es un stm32f407 aunque en la placa final habrá un 401 o un 411.

Saludos!

[Carl47D]

Da lo mismo llamar una función como la esta definiendo el maestro Killer a tener el ASM embebido en la función en c?

Ejemplo:

Código: ASM

1. static void __INLINE nrf_delay_us(uint32_t volatile number_of_us) __attribute__((always_inline));
2. static void __INLINE nrf_delay_us(uint32_t volatile number_of_us)
3. {
4. register uint32_t delay asm ("r0") = number_of_us;
5. __ASM volatile (
6. ".syntax unified\n"
7.     "1:\n"
8.     " SUBS %0, %0, #1\n"
9.     " NOP\n"
10.     " NOP\n"
11.     " NOP\n"
12.     " NOP\n"
13.     " NOP\n"
14.     " NOP\n"  
15.     " NOP\n"  
16.     " NOP\n"
17.     " NOP\n"
18.     " NOP\n"
19.     " NOP\n"
20.     " NOP\n"
21.     " BNE 1b\n"
22.     ".syntax divided\n"  
23.     : "+r" (delay));
24. }

En el caso que no sea lo mismo, como se definiria?

Código: ASM

1. .thumb
2.         .text
3.         .global _nrf_delay_us
4.  
5. _nrf_delay_us:
6.     @ Acá no supe como hacer esto:
7.     @ register uint32_t delay asm ("r0") = number_of_us;
8.      SUBS %0, %0, #1
9.      NOP
10.      NOP
11.      NOP
12.      NOP
13.      NOP
14.      NOP  
15.      NOP  
16.      NOP
17.      NOP
18.      NOP
19.      NOP
20.      NOP
21.      BNE 1b
22.      .end

[KILLERJC]

A mi C con ASM inline no me gusta, es preferible realizarlo aparte en un archivo a mi parecer. si queres portarlo a otro micro y queres "probarlo" solo le presentas la version en C y ya esta funcionando. en cambio con inline no y deberias cambiar mas cosas, a no ser que el codigo sea simple... Y por ejemplo solo use Thumb-16

si queres algo por donde empezar.... pues mirá, estoy armando el esqueleto de lo que será el firm del cartel RGB y hasta ahora he creado este código:

Eso es un SPI, para mi deberias hacerlo por SPI (hasta aprovechar un QSPI o 2), tu "latch" seria el CS, seguro que podes mantener el CS hasta el ultimo dato enviado. Es decir enviar multiple bytes y luego recien ahi que se levante el CS. Y por hardware. Pero voy a intentar hacerlo. Indicame el micro que estas trabajando por que seguro que tengo que buscar los registros y esas cosas. Ya que por ejemplo vi que algunos poseen un registro especial para poner una salida a 1, mientras que otros usan la misma direccion para el encode.

PD: Estuve viendo y es un dolor de cabeza GCC sin optimizaciones
Y me esta siendo un dolor de cabeza acostumbrarme a ese ASM

Una cosa mas. Al comienzo es ponerle una constante, o tenes pensado hacer una funcion? si es asi pone como es la funcion. Ya que veo que estas enviando Rojo,Verde y Azul al 100%, todo terminaria en una constante e.e

MCH = 0x0000.0148
MCL = 0000 0bbb bbbb bggg gggg grrr rrrr r010

Estoy en lo correcto? Y b/r/g van a cambiar ? Y van a ser pasados por alguna funcion?
Que micro estamos hablando? Cortex-M3 ? M0+ ?

Da lo mismo llamar una función como la esta definiendo el maestro Killer a tener el ASM embebido en la función en c?
En el caso que no sea lo mismo, como se definiria?

En tu caso creaste una funcion, lo cual seria lo correcto. Pero no un Inline "bruto", en medio de la funcion, nuevamente prefiero tener separado lo que es ASM y C, no me gustaria que esten juntos.
Creo, realmente CREO, por que no estoy seguro, que esta es la funcion en puro Assembler

Código: ASM

1. .syntax unified    @Permite el uso de Thumb y Thumb2
2.         .thumb          @ Thumb
3.         .text           @ Codigo
4.         .global _nrf_delay_us
5.  
6. _nrf_delay_us:
7.     @ Primer valor pasado por la funcion esta en R0
8.      SUBS r0, #1   @ R0 = R0-1, Actualizo las flag SUB{S} , Si es 0 es lo mismo que esperar 2^32
9.      NOP                 @ Thumb instruccion, por ser un inmmediato de 3 bits tiene un encode de 16bits
10.      NOP
11.      NOP
12.      NOP
13.      NOP
14.      NOP  
15.      NOP  
16.      NOP
17.      NOP
18.      NOP
19.      NOP
20.      NOP
21.      BNE.N   _nrf_delay_us      @ forzado 16bits, Salta si Z=0
22.      BX LR                     @ Return , PC <- LR
23.      .end

Si tenes para probarlo genial , asi vemos si funciona o no xD, en C solo quedaria como:

Código: C++

1. extern void nrf_delay_us(uint32_t number_of_us);

El codigo creo que funciona. Al menos procedi a ensamblarlo y hice un dump del object, el cual me dio el codigo correctamente como lo puse.

[KILLERJC]

Dividi el tema asi otra persona puede moverlo a ARM y seguimos alla, o quieren que sigamos aca y luego se mueva para alla, a mi me da lo mismo.
Y tambien lo dividi para no mezclar ARM con dsPIC

Ya con esto estan libres de hablar de ARM lo mas que quieran xD

Respuesta del disassembler:

Código: [Seleccionar]

test.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_nrf_delay_us>:
   0: 3801      subs r0, #1
   2: 46c0      nop ; (mov r8, r8)
   4: 46c0      nop ; (mov r8, r8)
   6: 46c0      nop ; (mov r8, r8)
   8: 46c0      nop ; (mov r8, r8)
   a: 46c0      nop ; (mov r8, r8)
   c: 46c0      nop ; (mov r8, r8)
   e: 46c0      nop ; (mov r8, r8)
  10: 46c0      nop ; (mov r8, r8)
  12: 46c0      nop ; (mov r8, r8)
  14: 46c0      nop ; (mov r8, r8)
  16: 46c0      nop ; (mov r8, r8)
  18: 46c0      nop ; (mov r8, r8)
  1a: d1fe      bne.n 0 <_nrf_delay_us>
  1c: 4770      bx lr

Todas instrucciones de 16 bits
Saben que es lo peor?, una resta con un inmmediato puede tener hasta 4 opcode distinto... hay 2 de 16bits y 2 de 32 bits, ambos distintos. ... ...

[juaperser1]

yo, quiero empezar por el principio killerjc, pero despacito por que no tengo hardware para probarlo por ahora, me ocupare de eso cuando termine el tutorial de KiCad.

me gustaría que colgaras el manual del manejo del nucleo ARM.

¿sus registros son de 32 bits no?

pues quiero hacer una pregunta quizá un poco tonta:

vamos a suponer que llamamos a una función desde c que va a ser esta:

float suma (unsignen int numero1, float numero2, unsingned char numero3);

y que en ensamblador se sumen y se devuelva.

me gustaría ver, como se va llenando la pila a ser posible de manera visual, donde van quedando los datos (con celdas de excel o librecal por ejemplo)

así mas o menos si puede ser:



y como son los pasos que va siguiendo el hardware para hacer la operación (a que soy un tocapelxtas  )

ademas de los pasos en ensamblador claro 

y tambien me gustaria un ejemplo de ethernet 

un saludo

[KILLERJC]

Para eso deberia simularlo paso a paso, y es el gran problema de esto. Sino debo debuggearlo si o si. cago el micro .

Respecto a ARM es un dolor de cabeza todo xD. Y tenes poquitos (sarcasmo) registros. Que ademas te separa en Aplicacion, sistema y tal ves otra cosa mas. Por que viene de los otro procesadores.
Como le envie a Carl, yo estoy usando esto:

ARM®v7-M Architecture Reference Manual
https://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf

Cortex-M4  Revision r0p0 Technical Reference Manual
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/DDI0439B_cortex_m4_r0p0_trm.pdf

Thumb® 16-bit Instruction Set Quick Reference Card (UAL)
https://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARM_QRC0006_UAL16.pdf

ARM® and Thumb®-2 Instruction Set Quick Reference Card
https://www.lri.fr/~de/ARM.pdf

Todos obtenibles desde el sitio de ARM, el tema es que en ARM tenes que registrarte xD, o busca por google.

GNU AS compiler:
https://sourceware.org/binutils/docs/as/

GNU LD Linker:
https://sourceware.org/binutils/docs/ld/

Por supuesto tengo el Cortex-M4F, asi que voy con esa arquitectura. si es un M0+ tenes que irte por la ARMv6-M , y el M4 y M7 posee una ARMv7E-M peeeeero es una v7 igual xD.
Lo que por ahi es complejo es calcular los ciclos, hay instrucciones que si tienen los ciclos contados pero otras que dependen del pipeline, siendo variables de 1 a 3 por ejemplo. Asi que ahi se complica mas. (No se como calcularlas)

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

Una cosa tengo el codigo de GCC con 0 optimizacion y un codigo con optimizacion 1, tanto para tamaño y velocidad, mas optimizacion no modifico nada. Solo decir que es un desastre el ASM generado con 0 de optimizacion y con optimizacion creo que aun todavia se puede mejorar mas.

[elgarbe]

Eso es un SPI, para mi deberias hacerlo por SPI (hasta aprovechar un QSPI o 2), tu "latch" seria el CS, seguro que podes mantener el CS hasta el ultimo dato enviado. Es decir enviar multiple bytes y luego recien ahi que se levante el CS. Y por hardware. Pero voy a intentar hacerlo. Indicame el micro que estas trabajando por que seguro que tengo que buscar los registros y esas cosas. Ya que por ejemplo vi que algunos poseen un registro especial para poner una salida a 1, mientras que otros usan la misma direccion para el encode.

PD: Estuve viendo y es un dolor de cabeza GCC sin optimizaciones
Y me esta siendo un dolor de cabeza acostumbrarme a ese ASM

Una cosa mas. Al comienzo es ponerle una constante, o tenes pensado hacer una funcion? si es asi pone como es la funcion. Ya que veo que estas enviando Rojo,Verde y Azul al 100%, todo terminaria en una constante e.e

MCH = 0x0000.0148
MCL = 0000 0bbb bbbb bggg gggg grrr rrrr r010

Estoy en lo correcto? Y b/r/g van a cambiar ? Y van a ser pasados por alguna funcion?
Que micro estamos hablando? Cortex-M3 ? M0+ ?

Si y no (a lo de SPI) el tema es que cada TLC necesita 49 bits de datos para manear las 48 salidas. Entonces el SPI debería enviar 7 bits de más. Quizá eso no afecte mucho a la velocidad vs lo que se gana por hacerlo todo por hardware. De todos modos, como es un micro que no estoy usando mucho y las librerias de ST suelen ser un dolor de cabeza, arranque haciendo el manejo con GPIO directamente así tengo mas control de lo que hago y puedo encontrar errores facilmente. Es probable que termine en un SPI.

Los 49 bits que puse ahí son de configuracion del TLC. BC es bright control y es para equalizar los colores dandole un poquito mas de corriente o menos a cada salida para uniformar el color. El MC es la corriente maxima (que luego se atenúa con BC) por grupo de colores. En principio eso es fijo.
Pero algo similar hay que hacer para asacar el ON/OFF de las salidas. Son 49 bits, con el MSB en 0 y el resto el estado de cada salida a los LED.
Lo que me gustaba es la parte de manejo de bits, verificar si es uno o cero y sacar en cuestion... Pero era sola una idea....

El micro es un M4F (x q es lo que estoy usando en varios proyectos) aunque podría ser un M0+ de NXP (lpc11u67) mucho mas acorde....

EDITO: La idea de Juanjo es mejor! empezar por el principio siempre es buena idea! 
Saludos

[juaperser1]

Por supuesto tengo el Cortex-M4F, asi que voy con esa arquitectura. si es un M0+ tenes que irte por la ARMv6-M , y el M4 y M7 posee una ARMv7E-M peeeeero es una v7 igual xD.

hombre ya que nos ponemos que sea de v7 para arriba  , y si ya sabia lo de los lios que traen los ARM con la compatibilidad para procesadores y es un lio de cojones, por eso te preguntaba, por si acaso tu ya lo tenias claro