Introducción
El objetivo de nuestro proyecto fue diseñar un receptor
de radio FM de bajo costo y fácil de usar.
Nuestro proyecto utiliza un circuito integrado de
receptor FM para realizar las unidades de preprocesamiento que se necesitan
antes de que se puedan escuchar las señales de audio deseadas. La frecuencia de
radio es demasiado rápida para procesar con nuestro hardware disponible y el
ATMega644. Hemos integrado una pantalla LCD para comunicarse con el usuario y
un teclado para permitir al usuario interactuar con el receptor y cambiar
estaciones. Nuestra idea de proyecto inicial era crear un receptor que pudiera
almacenar audio, y más tarde diseñar una radio que pudiera crear una lista de
reproducción de la estación de radio dada. La información del título de la
canción se envía junto con la señal de audio modulada a través de un sistema
denominado RBDS (Radio Broadcast Data System). Aunque no pudimos trabajar con
la función RBDS, hemos incluido algunos de los componentes de fondo, hardware y
software en la sección RBDS del Apéndice para que tal vez un grupo futuro pueda
expandir nuestro proyecto para implementar una característica usando RBDS.
Diseño de alto
nivel
Antecedentes
Las señales de radio FM (modulada en frecuencia) se
transmiten en una frecuencia portadora dentro del rango de 87.5MHz a 108.0MHz.
Cada estación está provista de 0,2MHz para emitir su señal (en los Estados
Unidos), sin embargo, un máximo de .15MHz se utiliza típicamente para evitar la
interferencia con los canales adyacentes. La señal entrante necesita primero
ser desmodulada, lo que implica múltiples etapas incluyendo el amplificador de
bajo ruido, el mezclador de frecuencia y otras unidades de procesamiento de
señal FM de nivel de hardware. Utilizamos un Receptor de Radio FM Single Chip
AIROHA AR1010 para realizar estas etapas de preprocesamiento para nosotros.
Vale la pena mencionar en este momento que a veces nos referimos al receptor
AR1010 FM y los documentos para el receptor AR1000 intercambiablemente. Ambos
AR1010 y AR1000 son receptores de AIROHA. La única diferencia entre los dos es
que el AR1000 admite RBDS mientras que el AR1010 no. No pudimos obtener un
AR1000 que hubiera sido útil para los propósitos de nuestro proyecto, pero gran
parte de la literatura de apoyo para nuestro diseño de receptor de FM se
especifica para el AR1000.
Funcionabilidad:
Nuestro receptor de radio puede realizar las siguientes
funciones:
Sintonice hacia arriba o hacia abajo una frecuencia
Escanear hacia arriba o hacia abajo para la siguiente
estación con una señal fuerte
Configure hasta 3 emisoras favoritas que estarán
disponibles más tarde para sintonizar rápidamente
Ajuste el umbral de exploración para captar estaciones
más fuertes o más débiles
Como se mencionó, Estados Unidos separa las frecuencias
por .2MHz (100.1, 100.3, 100.5 ect). Sin embargo, en otras regiones de la
palabra, las estaciones pueden ser separadas por solamente .1MHz. Por lo tanto,
para dar cabida a ambas posibilidades, decidimos permitir al usuario afinar
hacia arriba o hacia abajo por incrementos de 0.1MHz.
Keypad used to control radio.
El usuario controla el receptor a través del teclado
mostrado en la figura a la derecha. Los botones se asignan a la funcionalidad
de la siguiente manera:
1, Sintonice
2, Escanear hacia arriba
3, Aumentar el umbral de exploración
4, Sintonizar
5, escanear hacia abajo
6, Disminuir el umbral de exploración
9, Restablecer el umbral de exploración
0, Ir a la estación favorita de la tienda 1
F, Ir a la estación favorita de la tienda 2
E, Ir a la estación favorita 3
D, Establecer estación favorita
El resto de los botones no están conectados y al
presionarlos no tendrá ningún efecto en el receptor. Para configurar una
estación favorita, el usuario debe realizar los siguientes pasos:
Sintonice la emisora deseada
Pulse el botón Set (D)
Pulse uno de los botones favoritos (0, F o E) en el que
se almacenará la emisora. Cualquier estación previamente almacenada en ese
botón se sobrescribirá.
Arquitectura
general
Nuestro diseño se puede dividir en cuatro subcomponentes
principales: la comunicación con el receptor, el almacenamiento de estación
favorito, el teclado y la pantalla LCD. Aunque no pudimos incorporar las
características RBDS al producto final, también hemos incluido el trabajo que
hemos hecho con los aspectos de hardware y software que soportarían esa
funcionalidad adicional. Estos componentes y la comunicación entre ellos se
muestran en el siguiente diagrama.
Logic diagram of receiver.
La señal de radio entrante se transfiere a través de la
antena al receptor de radio FM AR1010. La placa de ruptura con el receptor
luego procesa la señal, y de ahí extrae las salidas izquierda y derecha, que
conectamos a una toma de audio. El usuario puede simplemente conectar un
altavoz para escuchar la emisora. Sin embargo, se necesita algún tipo de
amplificador. Sin ella, la salida no es lo suficientemente fuerte para ser
escuchada a través de los auriculares, incluso con el receptor ajustado a
volumen completo. Cualquier pulsación de botón desde el teclado se procesa por
el microcontrolador, que enviará los controles correspondientes al receptor y
el mensaje correspondiente a la pantalla LCD.
Diseño del
programa / hardware
Software
Cada uno de los cuatro componentes de nuestro diseño
tiene componentes de software: la comunicación con el Receptor FM AR1010, el
botón de interpretación presiona desde el teclado, establece las estaciones
favoritas en la memoria a largo plazo y muestra el mensaje en la pantalla LCD.
Receptor FM
Decidimos el protocolo I2C para comunicarnos con el
AR1010. La razón principal por la que elegimos I2C sobre SPI fue que el código
de ejemplo disponible en línea utilizó I2C. Además, la interfaz de 3 hilos
utiliza 26 señales de reloj para realizar una función de escritura simple, lo
que habría complicado el soporte de SPI en el ATmega644. Gran parte de nuestro
código que involucraba la comunicación I2C con el receptor se modificó a partir
del código de ejemplo AR1000 ATMega168 disponible en Sparkfun Electronics.
Nos topamos con dificultades significativas con la
comunicación I2C con el AR1010, el principal problema fue que una bandera
enviada desde el esclavo (AR1010) al maestro (Mega644) nunca fue enviada para
señalar que la condición de inicio fue recibida, y por lo tanto el
microcontrolador Se estaba quedando atascado en el estado de espera. Pasamos
por muchos otros conjuntos de código de ejemplo, incluyendo el proporcionado
por la solicitud de NKC Electronics y trató de crear un programa desde cero,
incorporando información de la Guía de Programación y los ejemplos de código
disponibles para el AR1010 / AR1000. Sin embargo, nuestro problema persistió
hasta que regresamos a nuestro código de ejemplo original. Si bien todavía no
estamos seguros de por qué exactamente el indicador STC no estaba siendo
configurado para los otros códigos, hemos concluido que el intento inicial
falló debido a errores de hardware, lo más probable es una falta de
resistencias pull-up (discutido en la sección de hardware a continuación) Los
datos y la línea de reloj, que fueron remediados en nuestro intento de
encontrar una secuencia de comandos I2C que funcionaría para nuestro chip.
Los registros en el AR1010 necesitaban inicialmente ser
inicializados antes de que cualquier comunicación pudiera seguir. Los valores
para los registros fueron recomendados por la Guía de Programación, y
determinamos que el Mega644 funcionando en 16MHz no requería ninguna
modificación a estos valores. Una vez que el AR1010 señaló que los registros
habían sido escritos, pudimos iniciar la comunicación.
Todas las funciones de I2C se proporcionaron en el código
de ejemplo, y también se modelan de los protocolos TWI como se proporciona en
la hoja de datos Mega644. El volumen del receptor se ajusta por defecto al
máximo, y como esto aún resulta en una salida demasiado demasiado para ser oído
en los auriculares, no sentimos la necesidad de ajustar el registro que
determina el volumen.
El receptor permite un ajuste fácil y rápido a una frecuencia
dada. El canal del receptor se almacena en el segundo registro. Elegimos
almacenar la frecuencia actual de la estación en una variable global, ya que
queríamos poder acceder a la estación que estábamos escuchando en otros
aspectos del programa sin tener que leer el registro cada vez. La frecuencia
siempre tendrá un mínimo de un decimal (en MHz) y estará entre 87.5MHz (875KHz)
y 108MHz (1808KHz), por lo que el almacenamiento de la estación en KHz permite
que el valor sea representado con un entero de 16 bits. El canal a escribir en
el registro 2 que corresponde a la frecuencia dada se puede calcular de la
siguiente manera:
Frecuencia de RF (en KHz) = 690 + CHAN
Esta función también fue proporcionada por la Guía de
Programación. Una vez que se escribió el nuevo canal, se envió un mensaje a la
pantalla LCD para notificar al usuario de la estación actualizada. La función
de sintonización toma un valor simple de 1 o 0 para determinar si el
sintonizador debe subir o no (0).
El código de ejemplo también proporcionó una función para
permitir una afinación más dinámica. La función Tune Hi-Lo mira el RSSI (valor
de registro que refleja la intensidad de la señal) para ayudarlo a ajustar la
frecuencia. Al probar esta función, no notamos una diferencia significativa en
la afinación, por lo que decidimos utilizar el método más directo como se
describió anteriormente.
El algoritmo principal para la exploración se describe en
la Guía de programación y se implementa en el código de ejemplo. Al igual que
la función de sintonización, el receptor puede explorar hacia arriba o hacia
abajo, dependiendo del parámetro de entrada. Además, la resistencia mínima de
la estación de radio necesaria para que la exploración se detenga en esa
frecuencia particular depende de un valor de umbral establecido en un registro.
Modificamos el código para que el usuario pueda aumentar, disminuir o
restablecer el umbral a su valor original. De esta manera, si el usuario decide
que el receptor está saltando las emisoras que todavía son audibles, tal vez no
es ideal, puede disminuir el umbral a través de la función changeThreshold.
Determinamos experimentalmente el mejor valor por defecto
para el umbral intentando valores diferentes y realizando una exploración para
determinar qué umbral detectó estaciones verdaderas en el área. Los resultados
de esto se discuten más adelante en la sección Análisis de Sensibilidad del
Receptor de FM.
Teclado
Nuestro programa, una vez hecho inicializando todos los
componentes del proyecto, entra en un bucle que escanea el teclado para
presionar los botones. Modelando el KeytestGCC644.c del Laboratorio 2, el
código reconoce cuándo puede haber ocurrido un empuje y confirma el empuje a
través de una máquina de estado. A continuación, procesa qué botón se ha
presionado antes de ejecutar las funciones apropiadas para ese botón, como se
describe en la sección de funcionalidad anterior.
Memoria de estación favorita
La mayoría de las radios permiten a los usuarios
almacenar estaciones de radio favoritas a las que se puede acceder con un solo
botón de empuje. Para admitir esta función, designamos los cuatro botones
inferiores al almacenamiento de la memoria de la estación favorita. Los tres de
la izquierda eran para almacenar las estaciones. Una bandera global determinó
si una prensa indicaba o no que el usuario quería escuchar la emisora
actualmente almacenada, en lugar de establecer la estación. Esta bandera
podría ser conmutada por el botón inferior derecho del teclado.
Las estaciones favoritas se almacenan en la EEPROM del
Mega644. Optamos por usar la EEPROM para que cuando el microcontrolador se
restablezca, o se encienda después de estar apagado (un uso razonable) las
estaciones favoritas todavía se establecerá. La única manera de borrar las
estaciones es con una reprogramación del microcontrolador. Escribimos las tres
estaciones favoritas como tres palabras (la estación está en KHz por lo que
necesita 16 bits) en lugares pares, ya que la memoria es un byte direccionable.
Sin embargo, antes de almacenar las estaciones, comprobamos un byte designado
(dirección 1 ya que la ubicación de memoria 0 de EEPROM no es completamente
fiable) para asegurar que las ubicaciones de memoria de emisoras favoritas
contenían valores significativos. En un re-programa, estos podrían ser fijados
a cualquier valor, por lo que en este caso hemos inicializado todas las
estaciones favoritas a 88.0MHz.
LCD
Todas las funciones que utilizamos para controlar la
pantalla LCD se obtuvieron de la biblioteca LCD proporcionada en Lab 1. Para
asegurar que el usuario esté informado en todo momento sobre lo que el receptor
estaba haciendo, designamos la línea superior como uno de los siguientes
mensajes:
LCD Inicializado: al restablecer, permite al usuario
saber que todo está bien con la pantalla
Actualmente on : estás sintonizado a la estación de abajo
Still looking : el escaneo está todavía en proceso y no
se ha establecido en una estación todavía
Establecer favorito: si presiona una de las teclas
favoritas, se ajustará a la estación actual
Scan Thresh +: aumenta el umbral de exploración en 1
Thresh de exploración: disminuye el umbral de exploración
en 1
Restablecer el umbral (establecer el umbral de
exploración al valor original
Uh oh: se ha producido un error al recuperar o configurar
una estación favorita de la memoria, este mensaje se puede incorporar en otros
aspectos de depuración del programa, así
La segunda línea de la pantalla LCD muestra la estación
actualmente configurada. Cada vez que se llama a la función de sintonía (señalando
que el receptor está en una nueva frecuencia), la línea inferior de la pantalla
LCD se actualiza. Algunos ejemplos de las pantallas LCD se muestran a la
derecha.
Harware:
Tres de
nuestros componentes requieren hardware: el receptor de radio FM AR1010, la
pantalla LCD y el teclado. Cada uno de estos componentes principales tiene su
propio hardware correspondiente. Las conexiones para el LCD y el teclado fueron
modeladas de los esquemas en Lab 1 y Lab 2 respectivamente.
AR1010
El AR1010
necesita ser alimentado por una fuente de alimentación de 3V. Con el fin de
crear esta fuente de alimentación, creamos un circuito de cambio de voltaje,
que tomó nuestra fuente de alimentación de 5V y creó una fuente constante de
3V. Vea el convertidor 3V en el apéndice para el esquema. El cambiador de
voltaje consiste en un transistor, que crea un voltaje constante de la tensión
en la base - 0.7V. El voltaje en la base es creado por un trimpot de 10k
ohmios. Por lo tanto, hemos ajustado la tensión procedente del trimpot hasta
que fue de 3,7V y, por lo tanto, creó la fuente de alimentación de 3V.
El AR1010
habla con el Mega644 a través de una interfaz de dos hilos usando el protocolo
I2C. Para que la interfaz de dos hilos funcione, los datos de conexión y las
líneas de reloj deben estar conectados a las resistencias de pull-up.
Utilizamos resistencias de 10k ohmios para las resistencias pull-up, como lo
recomendó el esquema de configuración AR1010.
Finalmente,
el AR1010 requiere una antena para recibir la señal de radio. NKC Electronics,
los distribuidores que nos donaron con una muestra del chip AR1010 y la placa
de desmontaje, recomendaron un alambre calibre 31 ", 22. Primero probamos
unos 3 pies de alambre de laboratorio y funcionó perfectamente.
LCD y
teclado
La pantalla
LCD se configuró exactamente como en la descripción del laboratorio 1 de ECE
4760. Lo hemos conectado al puerto A de la placa STK500. Controlamos el
contraste usando un trimpot de 10k Ohm.
El teclado
se configuró exactamente como en la descripción de ECE 4760 lab 2. Lo hemos
conectado al puerto D de la placa STK500.
Resultados
En general,
con la excepción de nuestra implementación RBDS, tanto nuestro hardware como
nuestros diseños de software funcionaron muy bien. Al final, nuestro receptor
FM, LCD y teclado funcionaron exactamente como se había planeado. Analizamos la
función general del receptor FM, la funcionalidad del umbral de sensibilidad
del receptor FM, la evolución de nuestro diseño de receptor FM y la funcionalidad
de nuestro diseño. Nuestra implementación RBDS, incluyendo sus fallas, está en
el apéndice.
Análisis de
funcionalidad del receptor FM
Al probar
cada una de las funciones de nuestro receptor de FM no encontramos problemas.
El teclado controla las funciones sin ningún problema y la pantalla LCD muestra
correctamente los mensajes apropiados. La única función que requirió más
pruebas fue la función de exploración y el efecto del umbral de sensibilidad.
Análisis de
umbral de sensibilidad del receptor FM
Una de las
consideraciones de diseño de software que probamos fue el efecto del umbral de
sensibilidad sobre las estaciones que el receptor de FM fue capaz de captar. El
umbral de sensibilidad era una variable de 7 bits, permitiendo ajustes que
variaban de 0 a 127. La siguiente tabla muestra qué estaciones podríamos captar
a diferentes umbrales:
Como era de
esperar, el establecimiento del umbral de sensibilidad muy bajo permitió
detectar más estaciones, pero el problema es que algunas de estas emisoras de
radio no existían realmente. Las estaciones 100.3, 103.5 y 107.1 no son
estaciones de radio reales en la zona de Ithaca, NY. Mientras que 92.8, 96.0 y
108.0 no son emisoras de radio reales, 92.7, 95.9, 96.1 y 107.9 existen y el
receptor estaba realmente recogiendo esas estaciones. Además, al establecer el
umbral demasiado alto no se detectaron estaciones.
Problemas de
diseño del receptor FM
Durante
nuestro desarrollo del receptor de FM encontramos muchos problemas. Estos
problemas incluían tanto hardware como software. Cuando primero probamos el
chip AR1010 con el código de ejemplo de Sparkfun, lo conectamos y nada sucedió.
No hubo comunicación a través de la interfaz de dos hilos. Sin saber si se
trataba de un problema de hardware o software, intentamos depurar ambos a la
vez. En primer lugar, descubrimos que estábamos dando una fuente de
alimentación de 5V, en lugar de la necesaria 3V. Esto llevó al desarrollo de
nuestro cambiador de voltaje. A continuación, como se mencionó anteriormente en
la sección del programa, vimos que no habíamos incluido las resistencias
pull-up en las líneas I2C. Durante el proceso de estas correcciones de hardware,
conseguimos quemar uno de nuestros chips AR1010. Esto fue causado cuando
teníamos las resistencias pull-up accidentalmente conectadas como resistencias
pull-down. Durante la depuración del hardware, también intentamos depurar el
software. Una descripción completa de este problema se discutió anteriormente
en la sección de software. De esto concluimos que nuestro problema no era con
el código de ejemplo de Sparkfun, sino, en cambio, con la implementación del
código.
Análisis de
la funcionalidad
Nuestro diseño
es muy funcional y utilizable por la mayoría de la gente. Nuestra pantalla LCD
le dice al usuario qué estación están escuchando y qué funciones están
realizando en ese momento. El único grupo de personas que posiblemente podría
luchar con nuestro diseño son los discapacitados visuales. Nuestro diseño no
tendrá ningún efecto en otros proyectos ya que no crea ninguna interferencia.
La única consideración de la funcionalidad que se debe tener en cuenta es si
una señal de radio FM se puede recibir en el área que está planeando usarla.
Conclusión
En general,
nuestro proyecto no cumplió con nuestras expectativas iniciales. Nuestra idea
original del proyecto era nuestro producto final con las características
adicionales de exhibir el título de la canción en nuestro LCD y poder almacenar
canciones y tener la reproducción. Nos dimos cuenta de que no teníamos
suficiente tiempo para un proyecto de esta magnitud, así que eliminamos el
almacenamiento y la reproducción de canciones y decidimos tener la capacidad de
almacenar los nombres de las canciones y crear una lista de reproducción de la
radio. Estas funciones se basaban en un decodificador de sistema de datos de
emisión de radio (RBDS). Pero tuvimos que abandonar el almacenamiento de la
función de título de la canción y la capacidad de mostrar el título de la
canción porque nos quedamos sin tiempo. Conseguir que el receptor de FM
funcione tomó demasiado tiempo y no tuvimos bastante tiempo de depurar los
problemas que teníamos con el decodificador de RBDS. Por lo tanto, no pudimos
implementar una función de lista de reproducción porque, sin el decodificador
RBDS, no pudimos obtener el título de la canción de la señal de radio. No estoy
seguro de cómo podríamos haber mejorado nuestro enfoque de nuestro proyecto. Si
hubiéramos podido evitar los problemas iniciales de hardware al configurar
nuestro receptor de FM, podríamos haber tenido tiempo suficiente para depurar
el decodificador RBDS y hacerlo operativo.
El único
estándar utilizado en nuestro proyecto es el estándar I2C para la interconexión
de dos hilos. Nuestro receptor de FM afirmó ser capaz de I2C y encontramos que
cumplía con la norma. Si no fuera por problemas de hardware iniciales, el
código de ejemplo que nos dio Sparkfun habría funcionado con su implementación
I2C.
En nuestra
idea original del proyecto, la única consideración legal que teníamos era la
infracción de derechos de autor, ya que estábamos permitiendo que la gente
almacenara canciones. La gente posiblemente podría haber salvado
permanentemente esas canciones y las ha distribuido ilegalmente. Pero una vez
que cambiamos nuestra idea de proyecto a crear una lista de reproducción de la
radio, eliminamos la única consideración legal que teníamos.
En todos los
aspectos del desarrollo de este proyecto, seguimos el Código de Ética del IEEE.
En primer lugar, en el desarrollo de nuestro código, damos crédito a cada
contribuyente. Hemos citado no sólo el código de ejemplo que construimos, sino
también los autores de otro código que inspiró nuestro diseño. Además de citar
colaboradores, también nos abstuvimos de comentar su código, para evitar dañar
falsamente su reputación. Además, cuando estábamos obteniendo el módulo
receptor FM y el decodificador RBDS, éramos francos y honestos con lo que
estábamos planeando usar las fichas. Explicamos que íbamos a usar las fichas
para nuestro proyecto de diseño senior, incluiríamos sus nombres en nuestro
informe de proyecto y no usaríamos las fichas comercialmente. Además, a través
de nuestro proyecto, buscamos aportes de Bruce Land y los asistentes de la
enseñanza de ECE 4760. Nos ayudaron a solucionar problemas que no sabíamos cómo
arreglar y evitar descuidos en nuestros diseños. Con el fin de mejorar los
conocimientos técnicos sobre todos los temas que estudiamos, incluyendo el
AR1010, I2C y RBDS, publicamos este informe en línea en el sitio web de la ECE
4760. Esperamos que las personas que busquen información sobre los receptores
de FM, la implementación de I2C y la implementación de RBDS puedan encontrar
nuestro trabajo tanto como una guía para empezar como como un trampolín para
desarrollos futuros.
Apéndice
Sistema de
datos de radiodifusión (RBDS) - no incluido en el diseño final
Fondo
RBDS es un
estándar utilizado en transmisiones de radio para transmitir otros datos junto
con la canción. Estos otros datos incluyen las letras de llamada de la emisora
de radio emisora, el nombre de la canción que se está reproduciendo, el
género de la canción, las advertencias meteorológicas y los anuncios. Fue
publicado en 1998 por el Comité Nacional de Sistemas de Radio.
Funcionalidad
Un
decodificador RBDS funciona recibiendo una señal de radio y luego decodificando
la información RBDS que se está enviando con ella. Los datos RBDS consisten en
4 paquetes de datos que se envían continuamente con señales de radio. Cada uno
de estos paquetes consiste en un identificador de grupo, que identifica qué
información contiene este grupo y el mensaje de datos de 16 bits. Utilizando el
identificador de grupo, puede traducir el mensaje de datos utilizando el juego
de caracteres apropiado dado en el documento estándar RBDS.
Para nuestro
proyecto, íbamos a usar la información del título de la canción del mensaje
RBDS y mostrarla en la pantalla LCD. También vamos a permitir que el usuario
cree una lista de reproducción de canciones en la radio al guardar los nombres
de las canciones que el usuario ha indicado. Esta característica habría sido
muy útil, ya que no pudimos encontrar ningún dispositivo que realizó esta
función que no sea a través de los flujos de radio por Internet.
Diseño de
Hardware
Nuestro
decodificador RBDS fue un TDA7333N de STMicroelectronics. Vea el apéndice para
esquema de circuito. Este chip requería una tensión de alimentación de 3V, tres
tensiones de referencia de 2,65V, 1,65V y 0,65V, un oscilador de cristal
externo, datos I2C y líneas de reloj, y la señal de radio. Utilizamos el mismo
suministro de 3V del receptor de FM. Hemos creado las tensiones de referencia
utilizando potenciómetros. La razón para el oscilador de cristal externo es que
TDA7333N requirió una frecuencia de sistema específica de 8.55MHz o 8.664MHz.
Para crear esta frecuencia, utilizamos una frecuencia externa de 16Mhz y luego
ajustamos los valores PLL dentro del TDA7333N para crear la frecuencia deseada.
Las líneas I2C son las mismas líneas de la AR
Diseño de
software
Nuestra idea
era utilizar el software para comprobar el grupo de RBDS que contiene la
información del título de la canción y mostrar que a la pantalla LCD. Se trata
de una comprobación simple, ya que el TDA7333N proporciona el número de
identificador del grupo.
Nuestro
software permitió que el Mega644 controlara el TDA7333N mediante el uso de una
interfaz I2C de dos hilos. Vea el código TDA_I2C.c en el apéndice. ADVERTENCIA:
EL CÓDIGO NO FUNCIONA. No nos dieron código de ejemplo para empezar y no
pudimos encontrar ningún código escrito para este chip en cualquier lugar, así
que todo el código para esto es nuestro. El código implementa las mismas
funciones I2C que el código del receptor FM. Nuestro código aún no comprueba el
grupo RBDS que contiene la información del título de la canción, ni muestra
esta información en la pantalla LCD. La razón de esto es que necesitábamos
averiguar qué grupo contenía la información del título de la canción, que
requería comunicación a lo largo de la línea I2C entre el Mega644 y el
TDA7333N. Esta comunicación I2C no funcionaba.
En este
momento, el código es capaz de escribir en los registros de la TDA7333N, pero
no somos capaces de leer de ellos. Cuando se da un comando de lectura, el ACK
nunca es recibido por el Mega644. Una razón para esto es que el TDA7333N no
sigue exactamente el estándar I2C de cómo leer los registros del esclavo. El
protocolo I2C dice que primero se envía un comando de escritura para inicializar
el registro al que va a leer, luego se envía el comando de lectura. El TDA7333N
no funciona de esta manera. Para ello, sólo se da un comando de lectura, y los
registros se leen en un orden específico. Debe leer todos los registros antes
del registro deseado y, a continuación, puede detener la transacción después de
haber leído el registro deseado. Creemos que esta discontinuidad entre el
protocolo TDA7333N y I2C es lo que está causando nuestros problemas de
comunicación
Conclusión
Se
necesitaba más tiempo para implementar el decodificador RBDS. No pudimos
resolver los problemas de comunicación entre el Mega644 y el TDA7333N y, por lo
tanto, no pudimos recibir los datos RBDS.
0 comentarios:
Publicar un comentario