Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

20/04/2015 #1

Avatar de hamster

Mpab X, Elm-Chan SD card, error con sprintf
Hola amigos.

Estoy jugando con un PIC24FJ32GA002, MPLAB X, y la última versión de la lib de ELM-CHAN para FAT.

El asunto es el siguiente: Compilo (sin sprintf<stdio.h>) la librería elm-chan (FF) en el mplabx para un pic24fj. El resultado lo compruebo con proteus y Todo bien.
Luego agrego de la lib STDIO.h la función; SPRINTF. Y ahí luego ya no compila y el mplabx me da error.
si entonces quito la LIb de elm-chan y compilo solo con la STDIO, si funciona.

En resumen me da error si compilo ambas librerías al mismo tiempo ff.h y stdio.h.
Les dejo la simulación en proteus, los archivos, la imagen para proteus sdc.mmc,
Gracias por su ayuda y su tiempo.
21/04/2015 #2

Avatar de Ardogan

Mmmm, si, pasa que el printf ocupa un montón de memoria, y la FAT tampoco es nada liviana...
Fijate en la misma página de elm-chan, que tiene una librería printf más apropiada para microcontroladores, incluí eso y sacá el #include <stdio.h>
http://elm-chan.org/fsw/strf/xprintf.html

A ver si con eso podes usar printf (o mejor dicho xprintf), y FAT a la vez.
21/04/2015 #3

Avatar de hamster

Hola Ardogan. Gracias por responder!
En los archivos va la librería otorgada por ELM-CHAN (xprintf.h), anteriormente lo había intentado y también me dio error. Voy a intentarlo de nuevo, puede ser que omití algo.
Lo que enserio no entiendo, es este asunto del error al usar simultáneamente ff.h y stdio.h
Cuál será exactamente el error con nombre y apellido?
21/04/2015 #4

Avatar de Ardogan

El error es que el código compilado no entra en la memoria flash del micro.
En algún lado de la salida del compilador debería decir "blabla doesn't fit blabla", o algún error de segmentación...
¿Qué compilador estás usando? (viene restringido en tamaño de código?), ¿probaste tocar opciones de compilación para optimizar tamaño? (optimization level 2 por ejemplo):


Para más detalles, guía del compilador XC16, página 111, 5.7.6 Options for Controlling Optimization:
http://ww1.microchip.com/downloads/e.../50002071E.pdf

¿Podes mostrarnos la salida del compilador? (en la ventana principal el cuadrito de abajo, donde dice output)
22/04/2015 #5

Avatar de hamster

Gracias Ardogan. Muy buena info.

parece interesante... voy a revisar, yo no he probado con lo niveles de optimizaci{on.

estoy usando el C30 y el XC16.
y con respecto a la librería xprintf.h logre compilarla pero esta no soporta flotante(lastima).
22/04/2015 #6

Avatar de Ardogan

Probaste distintas configuraciones de la librería FF de elm-chan?:
http://elm-chan.org/fsw/ff/en/appnote.html#memory

Según lo que dice ahí para un pic24 la librería debería ocupar ~12KB con varias opciones habilitadas, y quitando algunas se puede llegar a 8KB.
Por ejemplo, veo en el código fuente que habilitaste las funciones para formatear (#define _USE_MKFS 1), que ocupa bastante pero si es necesario se deja; o las opciones de búsqueda de archivos (#define _USE_FIND 1).

Y con el xprintf deberías andar cómodo, difícil llegar a los 32 KB del micro. El #include <stdio.h> ya no está no?, o sí?.

¿Que dice la salida del compilador?.
23/04/2015 #7

Avatar de hamster

Gracias Ardogan.

Gracias a tus consejos logre compilar ambas librerías simultáneamente. El problema era el nivel de optimización, a como tu dices con nivel 2 funciona correctamente. Y me funciona para ambos C30 y XC16.

anteriormente había logrado compilar la xprintf pero no soportaba flotantes. Esto sin incluir <stdio.h>
24/04/2015 #8

Avatar de Ardogan

Un par de opciones que sirven también para bajar tamaño de código es eliminar el código no utilizado. Sirve sobre todo al usar librerías de las cuales usamos solo una parte, es decir, no llamamos en nuestro programa a todas las funciones de la librería.

Página 103 de http://ww1.microchip.com/downloads/e.../50002071C.pdf
--gc-sections que sería algo así como garbage collector sections.
Esa opción es para el enlazador/linker, para que funcione hay que agregar al compilador/compiler la opción -ffunction-sections (crea una sección de memoria para cada función).

De nada
25/04/2015 #9

Avatar de hamster

Probé con esas opciones para no compilar funciones no utilizadas y el resultado fue muy bueno.
Logre una reducción aproximada de 44%. Gracias por esos tips sobre el compilador... ya sabia que el compilador tenia esas opciones pero la verdad nunca creí realmente necesitarlas, ahora veo estaba equivocado.
25/04/2015 #10

Avatar de Ardogan

Y... son cosas que se aprenden cuando no hay otro remedio
Me pasó cuando quería usar una librería USB y no había forma de hacerla entrar en la memoria del micro. Claro, yo quería usar el perfil CDC y me estaba compilando y enlazando también código para HID (que no ocupa tanto) y MSD (que ocupa un montón).

Cuidado al depurar, si ejecutás código paso a paso vas a ver que "misteriosamente" el código no se ejecuta una línea atrás de la otra tal como lo escribimos, sino que salta 10 instrucciones más adelante, después vuelve al principio de la función, después va al medio, etc. Eso se debe justamente a que está optimizado, y para ahorrar memoria no respeta la secuencia de código escrita.
O también el compilador puede decidir escribir el cuerpo de una función directamente en el código que la llama (suponiendo que esa función se llame desde 1 solo lugar en todo el código). Ahí al depurar y ejecutar paso a paso también se van a ver cosas "raras".

Lo que se puede hacer es -como el código "peligroso" suele ser el que acabamos de escribir y todavía no estamos seguro de que funcione- usar diferentes opciones de compilación para los archivos que escribimos nosotros, y los que incorporamos de una librería que ya sabemos que está probada y funciona bien.
La librería podemos compilarla con opciones O2 por ejemplo, mientras que nuestro código lo podemos dejar con opción O0 para que no optimice nada, y así al depurar las instrucciones se van a ejecutar tal como las escribimos (en el mismo orden, respetando todas las llamadas a función, etc).
Puede ser más fácil para detectar bugs, si el código se ejecuta en cualquier orden uno se distrae con eso y no en ver que es lo que hace el programa que escribimos.
Entonces, por ejemplo, el archivo main.c se puede compilar con O0 (ventana de proyecto donde esta la lista de archivos y carpetas del código fuente, click derecho sobre main.c, propiedades, y ahí debería poder establecer el nivel de optimización para ese archivo) y la librería de elm-chan con O2.

Pero tengo que confesar que esto último lo hice 1 vez, 2 como mucho... es que toma trabajo (muchos clicks, jajaja) . Lo haría solo si estoy muy apretado de memoria y quiero probar todo el programa a la vez. Pero lo que sí es cierto es que depurar es más fácil con O0 que con O2.
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.