RS485 example

[Carmelo]

Si, en Flowcode está a 4MHz y en la simulación de Proteus también. Ambas coinciden.

[Carmelo]

Lo que no comprendo es porque si realizo lo indicado en la captura de pantalla, asignando 2 valores fijos a cada uno de las posiciones del array la transmisión y recepción es correcta.

Del mismo modo, ya que es prácticamente lo mismo, si se configura el bloque de cálculo según la captura de pantalla 2 también la transmisión y recepción es correcta. Enviando los respectivos valores de cada uno de los bytes.

En cambio en cuanto le asigno a la variable tecla el valor de la tecla pulsada ya no funciona. Incluso, en el momento inicial, si el valor de tecla pulsada y por tanto tecla es =0 entonces el segundo byte siempre es 04. Es más, si a continuación se acciona cualquier tecla, esta ya no es detectada salvo los números 5,8 y 0 y en en esos 3 casos el valor transmitido del segundo byte es 07 que no se corresponde con ningún valor de ninguna tecla.

[chipfryer27]

Hi

I don't use Proteus so I can't help with that.

Your latest chart simulates correctly in Flowcode. When a key is pressed and held, the correct value is captured and stored in the array for transmission. Note though that this value only changes when you press a key and whatever is contained in the array is constantly transmitted until the value changes.

Following on from Leigh, your latest chart does appear to have a clock setup issue which won't bother the Flowcode simulation but would cause incorrect operation in hardware. I don't know if it would affect Proteus.

In your latest chart, in Project Options your clock is HFINTOSC at 32MHz.
In Other Options you need to change clock speed from 4MHz to 32MHz as Flowcode uses this for delay related timings.
In your Main chart, your very first icon needs to be a C-Code block to set the clock. Flowcode has a helper for this. If you navigate to Component Libraries > Runtime you will find IntOscHelper. Drag this into your chart and in properties set to your speed (32000000). This will create your c-code to use in a C-Block (OSCFRQ = 0x06;).

- - -

No uso Proteus, así que no puedo ayudar con eso.

Su último gráfico se simula correctamente en Flowcode. Cuando se presiona y mantiene presionada una tecla, el valor correcto se captura y almacena en la matriz para su transmisión. Sin embargo, tenga en cuenta que este valor solo cambia cuando presiona una tecla y todo lo que contiene la matriz se transmite constantemente hasta que el valor cambia.

Siguiendo a Leigh, su último gráfico parece tener un problema de configuración del reloj que no afectará la simulación de Flowcode pero provocaría un funcionamiento incorrecto en el hardware. No sé si afectaría a Proteus.

En su último gráfico, en Opciones de proyecto, su reloj es HFINTOSC a 32MHz.
En Otras opciones, debe cambiar la velocidad del reloj de 4 MHz a 32 MHz, ya que Flowcode usa esto para tiempos relacionados con retrasos.
En su gráfico principal, su primer ícono debe ser un bloque de Código C para configurar el reloj. Flowcode tiene una ayuda para esto. Si navega a Bibliotecas de componentes > Tiempo de ejecución, encontrará IntOscHelper. Arrastra esto a tu gráfico y a las propiedades configuradas según tu velocidad (32000000). Esto creará su código C para usarlo en un bloque C (OSCFRQ = 0x06;).

Regards

[Carmelo]

Gracias por las ayudas y por las respuestas.

Después de observar que los datos fijos se transmiten siempre sin ningún problema y que se localiza en la lectura del teclado, creo haber localizado el problema.

Pienso que lo que no está bien es que la configuración de los pines de filas y columnas que tengo puesto en Proteus no se corresponde con la que hay configurada en Flowcode.

Voy a ver en la ayuda como estay la distribución de la conexión de dichos pines y llevarlos a Proteus.
A lo largo del día de hoy voy a ver si doy con el problema

[Carmelo]

Adjunto una captura de pantalla de como creo que debería de estar de forma correcta la asignación de pines en el teclado matricial.

Si estoy equivocado, agradecería me indicasen en que estoy equivocado. Con esta configuración no funciona la lectura del teclado.

[Carmelo]

Bueno creo que ye he encontrado el posible error que les comento haber que les parece:
- Las conexiones de Proteus las he mantenido de forma igual a la captura del post anterior.
- En Flowcode he cambiado la asignación de pines de acuerdo a la imagen siguiente.

Ahora con estos cambios siempre se detectan las teclas pulsadas aunque observo otros pequeños defectos:
- He modificado también un poco el proyecto de Flowcode, que adjunto.
- En la parte del transmisor mientras no se presiona ninguna tela esta mandando continuamente el valor "FE". ¿Esto es correcto?
- Cuando se presiona una tecla cualquiera, SIEMPRE se transmite y se recibe en el receptor pero su valor se transmite varias veces y de forma aleatoria, unas veces 3 repeticiones, otras 4, otras 5 , ... Después siempre vuelve a enviar FE de forma continua hasta una nueva pulsación.
¿Hay alguna forma para corregir eso y que solo se transmita una sola vez el valor de la tecla pulsada?

[chipfryer27]

Hi

Sorry for the delay in replying due to travel.

In a post above (11:38am) you show Proteus connections as Row on B0 - B3 and Column on B4 - B7

However FC has Row on B4 - B7 and Column on B0 - B3.

This would certainly cause issues in reading the keypad. Both FC and Proteus need to have the same connections.

I see in a follow up you changed connections in FC to match Proteus. I downloaded your latest file (12:41pm) and the values generated on keypress seem correct (well as far as FC is concerned) and get transmitted.

You say you get FE (254 decimal) constantly transmitted if no keypress, but in the FC file this does not occur. You only transmit if the value of Tecla_Pulsada is less than 16 (decimal) and once you transmit your value you then set Tecla_Pulsada to 255 (decimal) therefore nothing transmits until you press a key. Well as far as FC is concerned, Proteus is another matter...

Getting multiple repetitions sounds like a "key bounce" issue. When you press any key it is rarely, if ever "clean". Contacts bounce many times before settling. If you search for switch debounce you will get tonnes of information. Whilst this is a physical hardware issue, you can get similar in simulation as computers are fast, very fast and may sample again when you don't expect it especially if timings are incorrect.

In your latest chart your oscillator seems incorrect. I think it is looking for a clock between 16MHz and 48MHz but you have set your clock speed in "Other Options" to only 4MHz. Actual oscillator speed and this clock speed must match. I don't have the datasheet for that chip to hand so I can't say for certain but you could be between 4 and 12 times out. That means your delay of 1-second in your branch, after you send, could only be 83mS

Did you run a check in Proteus to ensure no connections are floating as that too could cause issues.

There are a few ways to "debounce" in software. The basic theory is to detect a switch / button / key press then wait x-mS for the switch to settle before reading the value. Typical values are a few tens of mS (e.g. 30mS).

Hope this helps.


- - -

Disculpa la demora en responder por motivos de viaje.

En una publicación anterior (11:38 am), muestra las conexiones de Proteus como Fila en B0 - B3 y Columna en B4 - B7

Sin embargo, FC tiene Fila en B4 - B7 y Columna en B0 - B3.

Sin duda, esto causaría problemas al leer el teclado. Tanto FC como Proteus deben tener las mismas conexiones.

Veo en un seguimiento que cambiaste las conexiones en FC para que coincidan con Proteus. Descargué su último archivo (12:41 pm) y los valores generados al presionar una tecla parecen correctos (bueno, en lo que respecta a FC) y se transmiten.

Dice que obtiene FE (254 decimal) transmitido constantemente si no se presiona ninguna tecla, pero en el archivo FC esto no ocurre. Solo transmite si el valor de Tecla_Pulsada es menor que 16 (decimal) y una vez que transmite su valor, configura Tecla_Pulsada en 255 (decimal), por lo tanto, nada se transmite hasta que presiona una tecla. Bueno en lo que respecta a FC, Proteus es otro asunto...

Obtener múltiples repeticiones suena como un problema de "rebote de clave". Cuando presiona cualquier tecla, rara vez, o nunca, está "limpia". Los contactos rebotan muchas veces antes de estabilizarse. Si busca rebote de interruptor, obtendrá toneladas de información. Si bien se trata de un problema de hardware físico, puede obtener resultados similares en la simulación, ya que las computadoras son rápidas, muy rápidas y pueden volver a muestrear cuando no lo espera, especialmente si los tiempos son incorrectos.

En su último gráfico, su oscilador parece incorrecto. Creo que está buscando un reloj entre 16 MHz y 48 MHz, pero configuró la velocidad del reloj en "Otras opciones" en solo 4 MHz. La velocidad real del oscilador y esta velocidad de reloj deben coincidir. No tengo a mano la hoja de datos de ese chip, así que no puedo decirlo con certeza, pero podría estar entre 4 y 12 veces fuera. Eso significa que su retraso de 1 segundo en su sucursal, después de enviar, solo podría ser de 83mS...

¿Ejecutó una verificación en Proteus para asegurarse de que no haya conexiones flotando, ya que eso también podría causar problemas?

Hay algunas formas de "antirrebotar" en el software. La teoría básica es detectar la pulsación de un interruptor/botón/tecla y luego esperar x-mS hasta que el interruptor se estabilice antes de leer el valor. Los valores típicos son unas pocas decenas de mS (por ejemplo, 30 mS).

Espero que esto ayude

Regards

[Carmelo]

Gracias por la respuesta y comentarios.

Si , el cambio de pines en FC lo realicé porque en Proteus observé que los valores de las teclas estaban descolocados.

No entiendo muy bien lo que me quiere indicar referente la oscilador. En otras opciones tengo seleccionado 4MHz y no comprendo lo que me indica de otra velocidad superior.

El siguiente paso es colocar un pequeño antirrebote por software para ver si elimino los múltiples valores transmitidos de forma aleatoria. Cuando realice las pruebas, informaré del resultado obtenido.

Referente al valor FE, parece una actividad constante el el pin TX del Pic emisor, sin embargo ese valor nunca se transmite por los driver 487 y por tanto en el receptor nunca le llega, recibiéndose solo los 2 bytes necesarios: uno fijo y el otro el de la tecla pulsada.

[Carmelo]

He seguido sus instrucciones para realizar el anti-rebote básico por software pero no me funciona.
Si le pongo menos de 25 msg. el efecto de las repeticiones se repite pero si le aumento a 30 ya no funciona y manda valores aleatorios dependiendo de que tecla se haya pulsado.

[chipfryer27]

Hi

Referente al valor FE, parece una actividad constante el el pin TX del Pic emisor

That isn't happening in your FC chart / simulation so may be an issue in Proteus.

Eso no sucede en su gráfico/simulación FC, por lo que puede ser un problema en Proteus.

In Project Options you can set your oscillator (clock) to various sources such as "external" or "internal". Certain external options are looking for a clock at certain rates. Care must be taken to select the correct option.

In "Other Options" you can set the speed of the clock, but this is only to let FC know what speed the oscillator is running at so that it can automatically calculate delay related features. It is very, very important that these two settings match.

Say you had an external clock running at 4MHZ connected, but you told FC (in Other Options) it was 1MHz, then FC would make calculations based on a clock of 1MHz, but in reality, as the clock is actually 4MHz, delays etc would be four times faster then expected.

En Opciones del proyecto puedes configurar tu oscilador (reloj) para varias fuentes, como "externas" o "internas". Ciertas opciones externas buscan un reloj a determinadas tarifas. Se debe tener cuidado para seleccionar la opción correcta.

En "Otras opciones" puede configurar la velocidad del reloj, pero esto es sólo para que FC sepa a qué velocidad está funcionando el oscilador para que pueda calcular automáticamente las características relacionadas con el retraso. Es muy, muy importante que estas dos configuraciones coincidan.

Supongamos que tiene un reloj externo funcionando a 4 MHZ conectado, pero le dijo a FC (en Otras opciones) que era 1 MHz, entonces FC haría cálculos basados ​​en un reloj de 1 MHz, pero en realidad, como el reloj es en realidad de 4 MHz, los retrasos, etc. será cuatro veces más rápido de lo esperado.

In your chart, you set options for a clock between 16MHz to 48MHz but told FC to use 4MHz. There is a different option setting for clocks at that speed. I don't have the datasheet so can't say what, if any, trouble it would cause.

En su gráfico, configuró opciones para un reloj entre 16 MHz y 48 MHz, pero le dijo a FC que usara 4 MHz. Hay una configuración de opción diferente para los relojes a esa velocidad. No tengo la hoja de datos, por lo que no puedo decir qué problema causaría, si corresponde.

I still think the issue is with Proteus though as FC simulates as it should.

Sigo pensando que el problema está en Proteus, ya que FC simula como debería.


Regards