Skip to first unread message
Geni Suarez
Mar 8, 2017, 3:56:17 AM3/8/17
to Embebidos32
Hola a todos!
Tengo un código que configura e inicializa el periférico y en un while infinito una transmisión, sin interrupción, de caracteres. Estoy trabajando con un L4. Estoy queriendo ver directamente por los pines TX y RX del micro qué sale, para empezar, antes de conectar nada. Sin tener transciever ni al otro lado un receptor montado, a modo de empezar a hacer pruebas. La cosa es que el mismo código que no tiene más complicación que hacer la llamada al hal_can_transmit en modo infinito, unas veces del micro y puedo verlo en osciloscopio y otras no. Las veces que pude ver al señal por osciloscopio traté de conectarle el transciever que a su vez se conecta a un conersor can-usb, conectado a mi pc. En seguida dejaba de tener señales en los pines. Desaparecía del osc. Esto sí lo asocio a que el controlador de can puede ser sensible al estado del bus y otros factores de la capa física que pueden influir si no está la red bien montada o receptor configurado al otro lado, etc..
Pero al caso que voy, me pregunto si cuando lo tengo fuera de una red, sin conectar, debiera tener siempre las 2 salidas del micro (GPIOs) correspondientes a TX y RX con el dato que transmito (como cuando mandas 1 ó 0 para un GPIO que irá a un led o un dato serie USART y pinchas en los pines y ahí lo tienes en todos los casos: conectado o no a un terminal). Pero al estar fuera de la red no sé si puede afectar por la naturaleza del protocolo al comportamiento del periférico y hacer que no muestre señal. Con esta pregunta pretendo descartar si el problema de esto es mi código o es simplemente de montaje y hardware. Depurando tengo el dato en el mailbox correspondiente en todos los casos que probé. Pero, unas veces puedo verlo con osc y otras no, cuando no, se me queda a 'nivel alto'.
Consideráis que no es estable hacer este tipo de prueba por tema de hardware? o que es independiente y debiera tener señal (tren de datos transmitidos) a la salida (pines) del micro?
Aún tengo rato para tener una red bien montada y mientras tanto quisiera dotar de robustez mi código. De ahí que hago estas pruebas básicas de ver qué sale y saber dónde está la causa del comportamiento inestable de esta salida.
Espero haberme explicado con claridad y que se entienda lo que quiero decir :)
Saludos.
martin ribelotta
Mar 8, 2017, 9:18:12 AM3/8/17
to embebidos32@
Nunca trabaje con CAN sobre STM32 y menos con los L4 nuevos, pero para hacer pruebas CAN sin transceiver he usado algo como esto:
Con las HAL de ST, lo que mejor me ha resultado es partir de un ejemplo, en este caso, el mejor seria del CAN loopback y luego pasar al CAN entre dos placas con el mismo micro/codigo (can pingpong creo que era)--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Geni Suarez
Mar 8, 2017, 10:05:01 AM3/8/17
to embeb...@googlegroups.com
Ostras, muy agradecida por tu aporte!
Sólo un par de aclaraciones sobre tu propuesta si no es mucho pedir:
-por ejemplo nodo A mi placa y nodo B
otra?
-y el modo loopback es muy difícil de lograr? tiene alguna peculiaridad que te parezca relevante a tener en cuenta en cuanto al montaje o whatever..
de nuevo gracias.
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/qW3B_cUZVso/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
martin ribelotta
Mar 8, 2017, 11:08:56 AM3/8/17
to embebidos32@
El 8 de marzo de 2017, 12:04, Geni Suarez <geni...@gmail.com> escribió:
Ostras, muy agradecida por tu aporte!Sólo un par de aclaraciones sobre tu propuesta si no es mucho pedir:-por ejemplo nodo A mi placa y nodo Botra?
Lo que vi en su momento, era para la STM32F4 eval board, pero alguien lo porto con el hardware de mas arriba a una discovery F4. En este momento, no encuentro el link especifico, pero se que anda dando vueltas en internet.
El ejemplo particular esta en:
https://github.com/Joe-Merten/Stm32-Tools-Evaluation/tree/master/STM32Cube_FW_F4_V1.9.0/Projects/STM324xG_EVAL/Examples/CAN/CAN_Networking
https://github.com/Joe-Merten/Stm32-Tools-Evaluation/tree/master/STM32Cube_FW_F4_V1.9.0/Projects/STM324xG_EVAL/Examples/CAN/CAN_Networking
El ejemplo requeriria dos placas STM324xG_EVAL pero como te decia, se puede hacer con dos nucleo L4 (en tu caso) con el hardware de diodo y cable. Ambas placas deberian tener el mismo firmware.
-y el modo loopback es muy difícil de lograr? tiene alguna peculiaridad que te parezca relevante a tener en cuenta en cuanto al montaje o whatever..
El modo loopback no necesita hardware porque es solo del core y no requiere conectar ningu hardware externo:
https://github.com/Joe-Merten/Stm32-Tools-Evaluation/tree/master/STM32Cube_FW_F4_V1.9.0/Projects/STM324xG_EVAL/Examples/CAN/CAN_LoopBack
https://github.com/Joe-Merten/Stm32-Tools-Evaluation/tree/master/STM32Cube_FW_F4_V1.9.0/Projects/STM324xG_EVAL/Examples/CAN/CAN_LoopBack
El loopback es muy util para probar el software porque estas segura de que el hardware anda (no sale a los cables, pero es como si cualquier mensaje que mandaras al can te vuelve a tu nodo -sin pasar por ninguna salida en este caso-)
martin ribelotta
Mar 8, 2017, 11:11:51 AM3/8/17
to embebidos32@
Solo una anotación... el hardware dice +5v pero los micros estos son de 3.3v, deberías usar ese voltaje en la resistencia a VCC
El 8 de marzo de 2017, 12:04, Geni Suarez <geni...@gmail.com> escribió:
Geni Suarez
Mar 8, 2017, 11:27:24 AM3/8/17
to embeb...@googlegroups.com
Estupendos consejos Martín.
Ahora tocará configurar bien la recepción. Con el ejemplo de loop back seguro que saco ideas.
Un saludo.
Geni Suarez
Mar 16, 2017, 4:24:54 AM3/16/17
to Embebidos32
La verdad que vino muy bien. Usé el modo loop back y pude ver la trama correctamente. Después he pasado al modo normal con un nodo kvaser y la verdad es que va fino fino.
Muy agradecida.
El miércoles, 8 de marzo de 2017, 17:11:51 (UTC+1), El Ruso escribió:
Solo una anotación... el hardware dice +5v pero los micros estos son de 3.3v, deberías usar ese voltaje en la resistencia a VCC
El 8 de marzo de 2017, 12:04, Geni Suarez <geni...@gmail.com> escribió:
Ostras, muy agradecida por tu aporte!Sólo un par de aclaraciones sobre tu propuesta si no es mucho pedir:-por ejemplo nodo A mi placa y nodo Botra?-y el modo loopback es muy difícil de lograr? tiene alguna peculiaridad que te parezca relevante a tener en cuenta en cuanto al montaje o whatever..de nuevo gracias.
El 8 mar. 2017 15:18, "martin ribelotta" <martinr...@gmail.com> escribió:
Nunca trabaje con CAN sobre STM32 y menos con los L4 nuevos, pero para hacer pruebas CAN sin transceiver he usado algo como esto:Con las HAL de ST, lo que mejor me ha resultado es partir de un ejemplo, en este caso, el mejor seria del CAN loopback y luego pasar al CAN entre dos placas con el mismo micro/codigo (can pingpong creo que era)
El 8 de marzo de 2017, 5:56, Geni Suarez <geni...@gmail.com> escribió:
Hola a todos!Viendo que varios son los que trabajan o trabajaron con HAL y este micro quisiera saber si entre ellos alguien usó la HAL de st para tratar con el periférico CAN. Soy nueva con este periférico y a la hora de medir o hacer pruebas tengo dudas sobre la parte del montaje.Tengo un código que configura e inicializa el periférico y en un while infinito una transmisión, sin interrupción, de caracteres. Estoy trabajando con un L4. Estoy queriendo ver directamente por los pines TX y RX del micro qué sale, para empezar, antes de conectar nada. Sin tener transciever ni al otro lado un receptor montado, a modo de empezar a hacer pruebas. La cosa es que el mismo código que no tiene más complicación que hacer la llamada al hal_can_transmit en modo infinito, unas veces del micro y puedo verlo en osciloscopio y otras no. Las veces que pude ver al señal por osciloscopio traté de conectarle el transciever que a su vez se conecta a un conersor can-usb, conectado a mi pc. En seguida dejaba de tener señales en los pines. Desaparecía del osc. Esto sí lo asocio a que el controlador de can puede ser sensible al estado del bus y otros factores de la capa física que pueden influir si no está la red bien montada o receptor configurado al otro lado, etc..Pero al caso que voy, me pregunto si cuando lo tengo fuera de una red, sin conectar, debiera tener siempre las 2 salidas del micro (GPIOs) correspondientes a TX y RX con el dato que transmito (como cuando mandas 1 ó 0 para un GPIO que irá a un led o un dato serie USART y pinchas en los pines y ahí lo tienes en todos los casos: conectado o no a un terminal). Pero al estar fuera de la red no sé si puede afectar por la naturaleza del protocolo al comportamiento del periférico y hacer que no muestre señal. Con esta pregunta pretendo descartar si el problema de esto es mi código o es simplemente de montaje y hardware. Depurando tengo el dato en el mailbox correspondiente en todos los casos que probé. Pero, unas veces puedo verlo con osc y otras no, cuando no, se me queda a 'nivel alto'.Consideráis que no es estable hacer este tipo de prueba por tema de hardware? o que es independiente y debiera tener señal (tren de datos transmitidos) a la salida (pines) del micro?Aún tengo rato para tener una red bien montada y mientras tanto quisiera dotar de robustez mi código. De ahí que hago estas pruebas básicas de ver qué sale y saber dónde está la causa del comportamiento inestable de esta salida.Espero haberme explicado con claridad y que se entienda lo que quiero decir :)Saludos.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/qW3B_cUZVso/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages