Correcciones

[DamRCorba]

Hola Nicolas, como estas?

Esta correcta, tanto la memoria como el diagrama. Lo unico a observar es que el micro AVR8 que vimos en clase y que les pase las APIs es el ATMEGA128. En principio funciona tambien para el ATMEGA328 que elegiste.

Lo elegiste por algo en particular?

[NLahorcaKatzow]

Buenas tardes profe, lo elegi por mi arduino UNO que tiene un ATMEGA328, pensando que era el mismo que vimos en clase pero veo que le erré de numero. Lo elegí basicamente para poder probarlo en una placa que ya tengo, porque no creo que pueda comprar la otra, pero si quiere arranco el tp tomando en cuenta que es ATMEGA128 no tengo problema.

[DamRCorba]

Claro, en caso de AVR8. La idea es simularlo en proteus, como mostré en clase. Da un poco lo mismo hacerlo con 128 o 328. El único inconveniente de hacerlo con la placa de arduino es que el tp tiene que ser en C con la api que vimos en clase. Por lo que al no poder programarlo con arduino, necesitas el programador del micro, y eso ademas pisa el bootloader de Arduino, por lo que después deberías volver a bajarle el firmware base a la placa porque deja de ser un Arduino.

Para el caso de AVR, la intención era hacerlo simulado en proteus.

[NLahorcaKatzow]

Okey joya, entonces armo el codigo y lo pruebo en proteus, gracias profe.

[NLahorcaKatzow]

Buenas tardes profe, aqui le dejo la primera version del codigo. Tengo un par de preguntas relacionadas con los pines, mas que nada con como leer y escribir, por ejemplo la linea 14 en states.c tengo que leer el pin de un boton que esta definido en libreria.h pero me salta error en el VS code, lo mismo para escribir en por ejemplo linea 72 en libreria.h donde le seteo un valor a las salidas de motores.

[DamRCorba]

Buenas Noches, varias cosas para comentar: Primero. Nunca, jamas, de ninguna manera se incluyen archivos .c. El include es solo para vincular archivos de libreria o sea ".h" Por otro lado, la libreria stdio.h es solo para PC. En el caso de AVR la api ya incluye avr/io.h que es la lib standard de avr. Los errores que te pueden estar dando el vscode estan relacionados a las compilaciones cruzadas. Vos estas escribiendo para AVR y el vscode solo entiende PC, al menos que lo configures con el toolchain necesario.

Desde la catedra sugerimos usar el compilador integrado de proteus que te sirve ya para la compilacion sobre arquitectura avr.

Ademas, todas las definiciones de variables se ponen al principio de las funciones, en varios lugares las tenes entre el código, como por ejemplo en la función de init del mcu.

La lectura del archivo en AVR no se hace de la forma que la hiciste. Lo mejor es que guardes esa info en el eeprom o como memoria de programa. NO es necesario para este tp, pero te comento que para poder hacerlo deberias conectar una memoria SD por SPI con sistema FAT16 y usar las librerias de archivos para AVR por SPI.

[NLahorcaKatzow]

Me descargue el avr gcc toolchain para poder compilarlo en el VS code, pero si proteus ya tiene el suyo mejor, también iba a preguntar si era mejor simularlo usando proteus y otro programa pero parece que proteus me va a servir. Perfecto, hago las correcciones y hoy se las subo. Gracias.

[NLahorcaKatzow]

Buenas tardes profe, ya mergee los cambios con algunas correcciones, logre simularlo en proteus, pero por ejemplo no puedo leer las entradas de los pines de sensores y del boton, probe igual que los videos de las clases pero no encontre como. Ademas tambien quise debuggear con uart y una terminal virtual en proteus conectandolo en TXD0 y RXD0 pero tampoco me funcionó.

[DamRCorba]

Por el lado de la simulacion de usart, no hay buenas experiencias para que funcione. Son de las cosas que no termina de emular bien proteus. de todas formas proba agregandole la linea "sei();" al final de la incializacion. Las funciones de UART usan interrupciones.

Por el lado de la lectura de los pines, es raro que no funcionen. En el video en que mostre las interrupciones externas y pines de entrada mostre el como leer y esas cosas. En tu codigo, parece estar bien.

Me serviria mas para ayudarte ver como estas haciendo las conexiones.

Por otro lado, el tp pide tres niveles de separacion. La primera es la del main la cual deberias correr la inicializacion del vector de puntero a funciones mas arriba, porque tambien se lo considera una variable.

En tu main current_estado lo estas usando como pasaje por valor, lo cual no esta mal. Pero deberias tomar el valor de retorno de la funcion para poder llamar al estado siguiente. Todas tus funciones de estado deberian devolver un estado. Porque las declaraste con retorno void?

Deberias dividir a "libreria.h" para que queden solo las cosas del "negocio" y agregar un archivo conf.h donde esten las cosas del micro.

Saludos

[NLahorcaKatzow]

Buenas tardes, implemente la linea sei(); y ya me funciona todo, desde las entradas hasta el uart (aunque los caracteres no sean iguales), por otro lado termino de solucionar los return de las funciones de estado y la libreria y se lo vuelvo a mandar. Gracias.

[NLahorcaKatzow]

Buenas tardes, acabo de subir mis correcciones, con respecto al puntero a funciones, me olvide que retornaba void, ya lo cambié y todas las funciones de estado retornan un estado. Tambien separé libreria.h en dos partes, conf.h que contiene las definiciones de pines y unas macros, y libreria la dejo solo para declaracion de variables y prototipo de funciones. No entiendo a lo que se refiere con 3 niveles de separacion, son 3 archivos? Ademas le añadí 5 motores mas, y los simulé, ahora tambien le paso el archivo de proteus.

[NLahorcaKatzow]

Añadi el archivo de proteus en assets

[DamRCorba]

En escencia son tres archivos .c En uno deberia estar solo el main. En otro los estados con la logica de la maquina, es decir el desarrollo de las funciones de estado. Y el tercer archivo tiene que tener todo lo que interactua con el micro. Por ejemplo, la lectura de sensores, la activacion de salidas, la configuracion, los handlers de interrupcion. Ni en el main, ni en los estados deberia haber funciones de la Avr API. Esto es para poder, el dia de mañana cambiar de micro solo cambiando las funciones del archivo de funciones.c pero el main y las funciones de estado no deberia ser necesario modificarlos.

En tu codigo tambien se ve un estado que no esta en tu diagrama. Lo cual esta mal. La idea del diagrama de estados se arme el codigo a partir de el siguiendo la regla que cada estado se representa por una funcion de estado que tiene que devolver un estado. Esto es en ambos sentidos, el codigo y el diagrama deberian leerse y ser iguales. Asique, o agregas el estado al diagrama haces la correccion en el codigo.

Sacando esos detalles. Esta todo bastante bien. Lo que falta hacer es completar el readme.md con imagenes de schematico y ejemplos de la simulacion en donde se muestren los estados.

[NLahorcaKatzow]

Joya profe, ahora añado un estado mas al diagrama y añado las imagenes, muchas gracias.

[NLahorcaKatzow]

Buenas noches profe, ya mergee los cambios del diagrama de estado, quite el estado "CLASIFICANDO" y "ERROR" basicamente porque no eran estados, eran funciones que retornaban otros estados. Ademas quité todas las referencias de la avr_api en states.c para que solo funcs.c maneje todas las funciones relacionadas con la api, asi consigo tener un archivo .c para el main, otro para los estados, y otro para las funciones que tengan relacion con la api. Tambien subi los esquematicos a assets, al readme.md y el proteus actualizado.