Contiki: Programa de escritura para controlador de sensor (CC26xx)

Si, eso es correcto. Sugeriría usar SCS ya que es mucho más fácil de usar, pero es posible escribir programas para el controlador del sensor sin usar SCS. La CPU principal deberá cargar el programa en la RAM del controlador del sensor. Sugiera ver los entrenamientos del controlador del sensor aquí: ti.com/simplelinkacademy

Gracias @jonnteolsson. Me las arreglé para escribir un programa en SCS. El ADC y el código de evento funcionan bien en Task Testing de SCS. Ahora necesito incluir este programa en Contiki. Simplelink Academy de TI describió este proceso para TI-RTOS, pero no para Contiki. ¿Qué necesito para importar estos archivos a Contiki y compilarlos?

Por lo que miro a través del puerto Contiki de CC26xx, hay un mecanismo para interactuar con AUX, pero no puedo encontrar información sobre cómo incluir el código de aplicación AUX en Contiki.

Puede utilizar SCS para generar un código completo mediante CCS.

La integración con contiki es muy sencilla.

Verá que generará un código de inicio (que puede ejecutar en
en cualquier lugar de contiki) y algunas interrupciones (que idealmente pueden desencadenar eventos en
contiki para señalar su aplicación).

Hemos estado usando esto por un tiempo sin ningún problema con contiki y
con otros RTOS.

Marco Casaroli

El miércoles 28 de diciembre de 2016 a las 10:43 a. M., Semyon Tarakanov < [email protected]

escribió:

Gracias @jonnteolsson https://github.com/jonnteolsson . Me las he arreglado
escribir un programa en SCS. El ADC y el código de evento funcionan bien en la prueba de tareas de
SCS. Ahora necesito incluir este programa en Contiki. Simplelink de TI
Academy describió este proceso para TI-RTOS, pero no para Contiki. Qué hago
¿Necesita importar estos archivos a Contiki y compilarlos?

Por lo que miro a través del puerto Contiki de CC26xx, hay un mecanismo para
interactuar con AUX, pero no puedo encontrar información sobre cómo incluir AUX
código de aplicación a Contiki.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/contiki-os/contiki/issues/2019#issuecomment-269472189 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADszaHFjy9moPwSfd4zUiZOkQhfYw29lks5rMlljgaJpZM4LVLeg
.

Además de copiar el código a la RAM del controlador del sensor e iniciar el controlador, sospecho que también necesita un código para que la MCU principal pueda manejar eventos desde el controlador. También creo que tendrías que manipular los relojes dentro de AUX para que el controlador pueda seguir funcionando mientras el resto del chip está apagado.

Marco, ¿tuviste que hacer algo de esa manipulación del reloj y el poder?

Hola George.

En mi experiencia, el código generado ya hace los lpm y los relojes.
inicialización

Necesito verificar si había algo que necesitáramos cambiar en contiki lpm
código pero creo que no lo hicimos.

No tengo una computadora disponible en este momento para que la revise. Voy a publicar
algunas instrucciones sobre cómo hacerlo en enero.

BR

El miércoles 28 de diciembre de 2016 a las 11:25 George Oikonomou [email protected]
escribió:

Además de copiar el código a la RAM del controlador del sensor e iniciar el
controlador, sospecho que también necesita un código para que la MCU principal pueda manejar
eventos del controlador. También pensaría que tendrías que manipular
relojes dentro de AUX para que el controlador pueda seguir funcionando mientras el resto del
el chip está apagado.

Marco, ¿tuviste que hacer algo de esa manipulación del reloj y el poder?

-
Estás recibiendo esto porque hiciste un comentario.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/contiki-os/contiki/issues/2019#issuecomment-269476639 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADszaEI9Bcop7xjSvKmKZEYgQWan2tLnks5rMmNBgaJpZM4LVLeg
.

"En cierto modo" integré el SC con Contiki, pero estoy experimentando algunos problemas.
Estoy usando el código de emulación SC UART, y solo puedo obtener aproximadamente 6-8 caracteres TX'ed sin corrupción.
Curiosamente, RX funciona absolutamente perfecto.
Mi código de prueba init (basado en cc26xx-demo.c) se ve así:
`static aux_consumer_module_t uart_aux = {
NULL, AUX_WUC_SMPH_CLOCK | AUX_WUC_AIODIO0_CLOCK |
AUX_WUC_AIODIO1_CLOCK | AUX_WUC_TIMER_CLOCK |
AUX_WUC_ANAIF_CLOCK | AUX_WUC_TDCIF_CLOCK |
AUX_WUC_OSCCTRL_CLOCK | AUX_WUC_ADI_CLOCK | AUX_WUC_TDC_CLOCK |
AUX_WUC_ADC_CLOCK | AUX_WUC_REF_CLOCK
};

/ ------------------------------------------------- -------------------------- /
PROCESS_THREAD (cc26xx_my_process, ev, datos)
{

PROCESS_BEGIN ();
printf ("prueba CC26XX v43 \ n");
// para ser utilizado en la devolución de llamada de alerta para RX
softuart_event = process_alloc_event ();

ti_lib_sys_ctrl_power_everything ();

// Detén a SC.
ti_lib_aon_wuc_aux_image_invalid ();

// Ejecuta todos los relojes a toda velocidad por ahora.
ti_lib_prcm_inf_clock_configure_set (PRCM_CLOCK_DIV_1, PRCM_RUN_MODE);
ti_lib_prcm_inf_clock_configure_set (PRCM_CLOCK_DIV_1, PRCM_SLEEP_MODE);
ti_lib_prcm_inf_clock_configure_set (PRCM_CLOCK_DIV_1, PRCM_DEEP_SLEEP_MODE);
// recursos de reloj
aux_ctrl_register_consumer (& uart_aux);
AUXWUCClockFreqReq (AUX_WUC_CLOCK_HIFREQ);
AUXWUCPowerCtrl (AUX_WUC_POWER_ACTIVE);
aux_ctrl_power_up ();
// Acceso al dominio AUX
scifOsalEnableAuxDomainAccess ();
// Iniciar controlador SC
scifInit (& scifDriverSetup);
// Inicie el emulador UART
scifExecuteTasksOnceNbl (BV (SCIF_UART_EMULATOR_TASK_ID));
// Habilitar la generación de velocidad en baudios
scifUartSetBaudRate (9600);
// mi devolución de llamada de alerta
scifOsalRegisterTaskAlertCallback (& ​​uartAlertCallback);
// Habilitar RX (se requieren 10 períodos de bits inactivos antes de habilitar la detección de bits de inicio)
scifUartSetRxFifoThr (SCIF_UART_RX_FIFO_MAX_COUNT / 2);
scifUartSetRxTimeout (10 * 2);
scifUartSetRxEnableReqIdleCount (10 * 2);
scifUartRxEnable (1);

// Habilitar eventos (medio RX FIFO completo o tiempo de espera de período de 10 bits
scifUartSetEventMask (BV_SCIF_UART_ALERT_RX_FIFO_ABOVE_THR | BV_SCIF_UART_ALERT_RX_BYTE_TIMEOUT);

scifUartTxPutChars ("Hola, ¿cómo va todo? Esta es una cadena larga \ r \ n", 47);
'
Un poco más de mis intentos anteriores está en una publicación que hice en el foro de TI:
https://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/p/567025/2088653#2088653
¿Alguna idea de lo que podría estar matando a mi TX? Parece que el temporizador utilizado para la velocidad en baudios se está apagando, pero desde que declaré el uso de AUX_WUC_TIMER_CLOCK, ¿no debería estar protegido?

De acuerdo, el código que publiqué antes funciona como un encanto para la emulación UART en Contiki a través del controlador de sensor.
¿Mi problema de TX? agonizante interfaz USB <-> UART conectada a los pines de emulación UART; lo reemplazó por otro, incluso con el mismo chipset, y ¡voilá! Funciona a la perfección, así que sí, aux_ctrl_register_consumer () de hecho previene cualquier apagado de los relojes requeridos en el SC.
Incluí todos los relojes AUX, que creo que deben recortarse a lo que usa el código UART, pero funciona.

está bien. No es tan fácil hacer esto. Aquí están mis dos pequeños pasos. Primero escribo el programa más simple para el controlador de sensor en SCS y uso solo el código de ejecución con una línea de código:
gpioSetOutput(AUXIO_O_LED_DP1);
Después de la generación de código, llevo estos archivos a Contiki (al directorio platform/srf06-cc26xx/sensortag ):

scif.c
scif.h
scif_framework.c
scif_framework.h
scif_osal_none.c
scif_osal_none.h

Los incluyo en la compilación agregando BOARD_SOURCEFILES += scif_framework.c scif_osal_none.c scif.c al archivo Makefile.sensortag . Luego agrego un proceso al proyecto Contiki (modifico cc26xx-demo.c ) con este fragmento de código:

#include "aux-ctrl.h"
#include "scif.h"
#define BV(x)    (1 << (x))

//Other code here

static aux_consumer_module_t blink_aux = {NULL, AUX_WUC_SMPH_CLOCK };
PROCESS_THREAD(cc26xx_demo_process, ev, data)
{
  PROCESS_BEGIN();
  printf("CC26XX demo\n");
  aux_ctrl_register_consumer(&blink_aux);
  scifInit(&scifDriverSetup);
  scifExecuteTasksOnceNbl(BV(SCIF_BLINK_TASK_ID));

// Other code here

Entonces make TARGET=srf06-cc26xx BOARD_SENSORTAG=1 BOARD=sensortag/cc2650 BOARD_CONF_DEBUGGER_DEVPACK=1 . Con este código, Sensortag encenderá el LED (conecté el LED a DP0 de la placa DevPack). Entonces creo que es el programa de integración mínima.

Para mi segundo paso, traté de iterar sobre el Código de ejecución con horario. Para iterar sobre el código de ejecución, debe agregar fwScheduleTask(1); para programar la siguiente iteración en un tic. El tiempo de tick lo define Contiki invocando selfStartRtcTicksNow(0x00010000); El tiempo de tick se define entre paréntesis en formato de 16,16 bits. Por ejemplo, 0x00010000 es 1 segundo.
El código de ejecución es (y funciona bien en SCS):

U16 buttonState; //attach button to DP0 of DevPack
gpioGetInputValue(AUXIO_I_BUTTON_DP0; buttonState);

if (buttonState == 1) {
  gpioClearOutput(AUXIO_O_LED_DP1);
} else {
  gpioSetOutput(AUXIO_O_LED_DP1);
}
fwScheduleTask(1);

Código del proyecto Contiki:

#include "aux-ctrl.h"
#include "scif.h"
#define BV(x)    (1 << (x))

//Other code here

static aux_consumer_module_t blink_aux = {NULL, AUX_WUC_SMPH_CLOCK };

PROCESS_THREAD(cc26xx_demo_process, ev, data)
{
  PROCESS_BEGIN();
  printf("CC26XX demo\n");
  aux_ctrl_register_consumer(&blink_aux);
  scifInit(&scifDriverSetup);
  selfStartRtcTicksNow(0x00010000);
  scifExecuteTasksOnceNbl(BV(SCIF_BLINK_TASK_ID));

// Other code here

Este código debe verificar el estado del botón cada 1 segundo y encender el LED. Pero falla. En realidad, si presiona el botón mientras enciende la placa, SC lo verá y encenderá el LED. Indica que se realizó una iteración del código de ejecución. Entonces sucedió algo: el código falló o la programación falló.
SCS dice que fwScheduleTask() usa el canal 2 AON_RTC en modo de comparación continua para generar activaciones periódicas para el AUX. La sintonización del canal 2 de RTC se realiza a través de selfStartRtcTicksNow(); y parece que no hay problema (a partir del código). Contiki usa el canal 0 y el canal 1 de RTC (a partir de soc-rtc.c ). También creo que el código de ejecución debería iterarse incluso sin dicho horario.

Así que estoy atrapado aquí. ¿Alguien ha tenido éxito con esto?

hola @tarakanov , estoy atrapado en la misma posición en tu publicación anterior. Quería comprobar si había hecho algún progreso con esto.

Me las arreglo para ejecutar la imagen SC periódicamente. Recuerde, para ejecutar el código de ejecución, debe agregar fwScheduleTask(1) por un tick. Contiki define el tiempo de tick invocando selfStartRtcTicksNow(0x00010000) . El tiempo de tick se define entre paréntesis en formato de 16,16 bits. Por ejemplo, 0x00010000 es 1 segundo. Después de esta configuración, debe iniciar la ejecución llamando a scifStartTasksNbl(BV(SCIF_BLINK_TASK_ID)) con el nombre de la tarea como argumento. Pero no llame a scifExecuteTasksOnceNbl como mencioné anteriormente, ya que ejecutará la tarea una vez y no configurará eventos para la siguiente iteración. Aquí está parte del código Contiki:

  PROCESS_BEGIN();
  printf("CC26XX demo\n");
  aux_ctrl_register_consumer(&blink_aux);
  scifInit(&scifDriverSetup);
  scifStartRtcTicksNow(0x00010000);
  scifStartTasksNbl(BV(SCIF_BLINK_TASK_ID));

Pero está en conflicto con el controlador de interrupciones AON RTC en el código soc-rtc.c . Los temporizadores de software RTC usan el canal 0 y el canal 1 de RTC, pero soc_rtc_isr() está programado para capturar eventos combinados de los tres canales (ch0, ch1, ch2) con este comando:
ti_lib_aon_rtc_combined_event_config(AON_RTC_CH0 | AON_RTC_CH1 | AON_RTC_CH2)
Y cuando configura correctamente la imagen SC y la ejecuta por primera vez, RTC ch2 generará un evento después del tiempo de tic que también llamará a esta rutina. Y esta rutina deshabilitará RTC ch2 con este código:

  if(ti_lib_aon_rtc_event_get(AON_RTC_CH2)) {
    /* after sleep; since a rtimer is already scheduled, do nothing */
    ti_lib_aon_rtc_channel_disable(AON_RTC_CH2);
    HWREG(AON_RTC_BASE + AON_RTC_O_EVFLAGS) = AON_RTC_EVFLAGS_CH2;
  }

Cambio el evento de combinación a esto, y soc_rtc_isr no manejará eventos de ch2:
ti_lib_aon_rtc_combined_event_config(AON_RTC_CH0 | AON_RTC_CH1)

@ g-oikonomou por favor avise aquí. Si Contiki usa solo ch0 y ch1 para temporizadores, tal vez sea bueno eliminar todos los usos de ch2 de soc-rtc.c.

Me las arreglo para hacer una alerta a Contiki a través de eventos. Para alertar al núcleo principal, necesita agregar fwGenAlertInterrupt (); en la Tarea de ejecución. Cuando inicializa SC en Contiki, necesita registrar la función de devolución de llamada para esta alerta:

  scifOsalRegisterTaskAlertCallback(scTaskAlertCallback);
  scifInit(&scifDriverSetup);

La función de devolución de llamada asignará un evento al proceso ( scinterrupt_test_process en mi caso):

process_event_t sc_event;
void scTaskAlertCallback(void)
{
    scifClearAlertIntSource();
    sc_event = process_alloc_event();
    process_post(&scinterrupt_test_process, sc_event, NULL);
    scifAckAlertEvents();
}

Entonces puedes identificar este evento por su nombre:

    PROCESS_YIELD();
     if (ev == sc_event) {
        printf("Hello from SC\n");
    }

sc_event = process_alloc_event ();

Esa expresión debe hacerse una sola vez, en el código de iniciación. Asigna un número único que representa esos eventos del controlador de sensor.

Mmm ...
¿Se ejecuta scTaskAlertCallback() durante una interrupción? Si es así, no debe usar process_post() . Solo process_poll() es seguro para los manejadores de interrupciones.

Si es así, entonces no debe usar process_post (). Solo process_poll () es seguro para los manejadores de interrupciones.

No estoy tan seguro de eso, process_post() es asincrónico. La diferencia es que podemos generar un evento específico, mientras que con process_poll() siempre enviamos el mismo evento genérico de "encuesta"

No estoy tan seguro de eso, process_post() es asincrónico.

está bien. Volví a mirar el código. Ahora, creo que tienes razón. process_post() puede "interrumpir" do_event() sin causar problemas.

Gracias por tus instrucciones @tarakanov ¡ Muy útil! Parece que ha descubierto una incompatibilidad de contiki con CC1350 AUX. Otra forma de solucionar el problema es NO deshabilitar RTC_CH2

if (ti_lib_aon_rtc_event_get (AON_RTC_CH2)) {
/* después de dormir; como ya está programado un temporizador, no haga nada * /
// ti_lib_aon_rtc_channel_disable (AON_RTC_CH2);
HWREG (AON_RTC_BASE + AON_RTC_O_EVFLAGS) = AON_RTC_EVFLAGS_CH2;
}

Investigué un poco más y descubrí que aux_ctrl_register_consumer () activa AONWUC_AUX_WAKEUP, lo que hace que soc_rtc.c desactive AON_RTC_CH2. Mi pregunta aquí es por qué contiki (soc-rtc.c) deshabilita AON_RTC_CH2. Lo que está haciendo es eliminar cualquier interrupción del AUX, inmediatamente después de despertarlo.

Lo que me lleva a la pregunta: ¿es seguro deshabilitar AON_RTC_CH2. ¿Algún otro código en el entorno contiki lo usa?