Problema con dsiplay de 7 segmentos

[Carmelo]

One issue is that you have the thermistor connected to AN13 - this is the same as the common pin for one of the displays - and will probably cause an issue. (I changed to AN8)

Also in supervisaTempMax - you attempt to re-enable the TMR2 interrupt at a much higher rate.

Still getting odd stuff on the display though... This seems to be a bug - closing FC and restarting it and it works fine.
I'd rewritten bits - try and work out where the issue was.... Mostly I changed the temperature to an integer value...

Martin

Thanks for the response Martin.

The thermistor must be at AN0. I have changed it in your example and the example still works fine.
Regarding the temperature value, I had it in float type because I need to see the temperature with a decimal on the display. The temperature will range from 0 to 99.9 degrees Celsius.

For the multiplexing I see that it has been done in a different way than mine (taken from the wiki) and it does seem to be more stable.

On the other hand, I don't need to see negative numbers. When the temperature is less than 0, display 1 should only remain at 0. But also when the temperature exceeds 99.9 degrees, the displays must illuminate segment G of the 3 displays, which is why my supervision routineMaxima.


There is also the error that when stopping the simulation it requires me to save the project again even though I have not made changes

[Carmelo]

Hola

El insomnio no es algo por lo que perder el sueño...

Descargué su gráfico más reciente y puedo confirmar que durante la simulación aparecen caracteres aleatorios como los que usted describe.

Sin embargo, esto es una simulación y puede que en realidad no sea el caso en el hardware. No puedo probar eso ahora. Los PC son enormemente más rápidos que los microcontroladores y, como tales, las simulaciones no siempre funcionan como nos gustaría, especialmente cuando se simulan interrupciones.

Como prueba muy rápida, miré su interrupción y vi que tenía una frecuencia de 150 Hz. Bajar esto a alrededor de 50 Hz en mi PC mejoró la estabilidad de la pantalla y redujo los caracteres aleatorios. Por lo tanto, creo que el problema es la simulación y no lo que creaste.

Intentaré mirar más a fondo más tarde en la mañana.

Saludos


--- All hail Google translate ---

Hi

Insomnia isn't something to lose sleep over.........

Downloaded your latest chart and can confirm that during simulation random characters appear as you describe.

However this is in simulation and may not actually be the case in hardware. I can't test such just now. PC's are hugely faster than microcontrollers and as such simulations don't always work as we would like, especially when interrupts are being simulated.

As a very quick test I looked at your interrupt as saw it had a frequency of 150Hz. Dropping this to around 50Hz on my PC improved the stability of the display and reduced the random characters. Therefore I think the problem is simulation rather than what you created.

I'll try and look further later in my morning.

Regards

Edit...
I see Martin replied as I was

Thanks chipfryer27 for your response.

Yes, I lowered the frequency and things seemed more stable, but most of the time the represented values ​​were not correctly distinguished.

[Carmelo]

Hola

El insomnio no es algo por lo que perder el sueño...

Descargué su gráfico más reciente y puedo confirmar que durante la simulación aparecen caracteres aleatorios como los que usted describe.

Sin embargo, esto es una simulación y puede que en realidad no sea el caso en el hardware. No puedo probar eso ahora. Los PC son enormemente más rápidos que los microcontroladores y, como tales, las simulaciones no siempre funcionan como nos gustaría, especialmente cuando se simulan interrupciones.

Como prueba muy rápida, miré su interrupción y vi que tenía una frecuencia de 150 Hz. Bajar esto a alrededor de 50 Hz en mi PC mejoró la estabilidad de la pantalla y redujo los caracteres aleatorios. Por lo tanto, creo que el problema es la simulación y no lo que creaste.

Intentaré mirar más a fondo más tarde en la mañana.

Saludos


--- All hail Google translate ---

Hi

Insomnia isn't something to lose sleep over.........

Downloaded your latest chart and can confirm that during simulation random characters appear as you describe.

However this is in simulation and may not actually be the case in hardware. I can't test such just now. PC's are hugely faster than microcontrollers and as such simulations don't always work as we would like, especially when interrupts are being simulated.

As a very quick test I looked at your interrupt as saw it had a frequency of 150Hz. Dropping this to around 50Hz on my PC improved the stability of the display and reduced the random characters. Therefore I think the problem is simulation rather than what you created.

I'll try and look further later in my morning.

Regards

Edit...
I see Martin replied as I was

Thanks chipfryer27 for your response.

Yes, I lowered the frequency and things seemed more stable, but most of the time the represented values ​​were not correctly distinguished.

[mnfisher]

Hi Carmelo & Iain,

I'd allowed negative numbers as the thermistor component was set to go to -5C
If you want to display an 'error' at >=100 I would be tempted to do this in multiplex (in a similar manner to negative numbers)
If you need a dp I would multiply the fp by 10 - floating point is rather more hardworking for the MCU.

Hardware and simulation differ slightly - on hardware it would be possible to use a single component and the switching off the common pin (rather than changing the thermistor pin, change the common for the display - it probably won't work correctly in hardware ) will clear (turn off) the LEDs... This reduces code duplication if memory is tight.

Martin

[mnfisher]

Saving after running is because the values of variables have changed.... FC thinks the project is changed.

Martin

[chipfryer27]

Hi

Using Martin's suggestion, I moved the sensor to B2.

With regards to the attached.

Termostato_10_90_v02_modified.fcfx

(38.28 KiB) Downloaded 20 times

In servicaTempMax I added a decicion. If the temp is actually above 100 then it proceeds with the macro, if not it exits. You could have this decision in your main loop. I see no need to perform the macro unless it is required, but of course that is up to you.

I dropped the interrupt frequency to around 40Hz to test with (simulate). Less likely to bother my laptop during simulation.

PCs are far faster than microcontrollers and they have a lot of other stuff going on at the same time (e,g reading keyboards/ displaying your screen etc) so they are not perfect for simulating. That said they do provide invaluable help as long as you appreciate that not everything can be simulated perfectly.

One of the features I like about Flowcode is that I can Step-Into the chart and see what is going on at each step.

I went to Debug > Step-Into and when clicked starts the simulation and holds it at that step. The program debugger appears and I selected variables of interest and a speed of Fast No Updates.

I single stepped through the chart and it showed me my variables. All good. As I continued to step through I would see digits appear in turn on the display. First corresponding to "tens", then "units" then the decimal point value.

If I changed the sensor value, the next iteration of the loop as I stepped through gave the updated value. Shortly after (as I continued to step) the display would update. As I stepped through the display, digits although only being displayed one at a time, were correct.

I then clicked "Run". This then had the program running by itself and as I had chosen Fast No Updates the variables in the program debugger were not updated. The display however was displaying all three digits correctly and remained solid and stable.

If I mess too much with settings, either slowing down the simulation speed or increasing the interrupt frequency then things become problematic with the messed up display as before. I believe this to be solely due to simulation and the PC / program trying to keep in sync with each other. I do not think it will be an issue in hardware, although I cannot test. My PC will be different to yours in terms of speed and what else is going on, so my settings may be different to yours when simulating.

Of course how we read or rather see the three digits as a number (e.g. 27.4) is through persistance of vision. We display each digit/number in turn but do it so fast we fool our brains into seeing all the digits. You will need to use an interrupt frequency high enough to avoid flicker when implementing in hardware.

As for saving your chart. Every time you run a simulation you are asked to save before exiting, even if you have made no changes. I don't know why but it has to my mind always been like that.

Regards

[Carmelo]

Hi Carmelo & Iain,

I'd allowed negative numbers as the thermistor component was set to go to -5C
If you want to display an 'error' at >=100 I would be tempted to do this in multiplex (in a similar manner to negative numbers)
If you need a dp I would multiply the fp by 10 - floating point is rather more hardworking for the MCU.

Hardware and simulation differ slightly - on hardware it would be possible to use a single component and the switching off the common pin (rather than changing the thermistor pin, change the common for the display - it probably won't work correctly in hardware ) will clear (turn off) the LEDs... This reduces code duplication if memory is tight.

Martin

Thanks Martin for the response.

Well, the truth is, I would appreciate it if you could show me how you do, within multiplex, being able to show, when the temperature is greater than 99.9, that only the "G" segments illuminate in the 3 segments and if possible flashing every, for example, 300ms.
In the same way that when the temperature was less than 0º, only "0.0" was shown on the siplay

This more than anything to be able to study and learn how to properly carry out the multiplexing process in a way other than what is indicated in the wiki example.

Once this is achieved, then my project will advance using 2 or 3 buttons to be able to program the actuation values ​​of the relay, which at this moment I have set with a fixed value, at the beginning of the program, to be able to check the macro of its actuation.

[Carmelo]

Saving after running is because the values of variables have changed.... FC thinks the project is changed.

Martin

I think that before this was not like that, but well, if it has been changed for me, there is no problem, more than anything it was a piece of information to know why.

[Carmelo]

Hi

Using Martin's suggestion, I moved the sensor to B2.

With regards to the attached.


Termostato_10_90_v02_modified.fcfx



In servicaTempMax I added a decicion. If the temp is actually above 100 then it proceeds with the macro, if not it exits. You could have this decision in your main loop. I see no need to perform the macro unless it is required, but of course that is up to you.

I dropped the interrupt frequency to around 40Hz to test with (simulate). Less likely to bother my laptop during simulation.

PCs are far faster than microcontrollers and they have a lot of other stuff going on at the same time (e,g reading keyboards/ displaying your screen etc) so they are not perfect for simulating. That said they do provide invaluable help as long as you appreciate that not everything can be simulated perfectly.

One of the features I like about Flowcode is that I can Step-Into the chart and see what is going on at each step.

I went to Debug > Step-Into and when clicked starts the simulation and holds it at that step. The program debugger appears and I selected variables of interest and a speed of Fast No Updates.

I single stepped through the chart and it showed me my variables. All good. As I continued to step through I would see digits appear in turn on the display. First corresponding to "tens", then "units" then the decimal point value.

If I changed the sensor value, the next iteration of the loop as I stepped through gave the updated value. Shortly after (as I continued to step) the display would update. As I stepped through the display, digits although only being displayed one at a time, were correct.

I then clicked "Run". This then had the program running by itself and as I had chosen Fast No Updates the variables in the program debugger were not updated. The display however was displaying all three digits correctly and remained solid and stable.

If I mess too much with settings, either slowing down the simulation speed or increasing the interrupt frequency then things become problematic with the messed up display as before. I believe this to be solely due to simulation and the PC / program trying to keep in sync with each other. I do not think it will be an issue in hardware, although I cannot test. My PC will be different to yours in terms of speed and what else is going on, so my settings may be different to yours when simulating.

Of course how we read or rather see the three digits as a number (e.g. 27.4) is through persistance of vision. We display each digit/number in turn but do it so fast we fool our brains into seeing all the digits. You will need to use an interrupt frequency high enough to avoid flicker when implementing in hardware.

As for saving your chart. Every time you run a simulation you are asked to save before exiting, even if you have made no changes. I don't know why but it has to my mind always been like that.

Regards

Thank you Ian for the response and especially for the time you have taken to review the program and/or make the changes that you have indicated.

The same gratitude is extended to Martin.

I'm going to see if I can physically assemble all the connections of the project to test everything in a real way. If I did it this way until now, it is because I have good help and know if I am on the right track with the software design.

[mnfisher]

I rewrote 'multiplex' to show with decimal point and '---' if temp >= 100 (note that to allow integer maths - I multiple the actual temp by 10)

I removed the negative numbers for clarity.

If you want the '---' to flash then you need a counter and swap between '-' and ' ' for segments (0x40 and 0). I lifted the lookup table for the character set from the component (and added the '-')

And for fun - I changed the LEDs to green

Martin