charge pump
-
I suspect that most devices that provide a charge pump output at above 500Hz are either generating it in hardware, or are simple devices running a very simple software loop. Generating charge pump signals at high frequencies is not very practical for a complex software system running RTOS. The tick interrupt frequency could be increased by a small factor to generate a charge pump frequency of 1kHz or a little higher, but much more would use up too much CPU time.
-
@bearer said in charge pump:
I started the (happy!) new year with a somewhat scientific experiment.
Do you know how fast it detects that the signal stoped? (e.g. feed 100KHz, 50%, then set a fixed input voltage and measure time to shutdown signal).
-
@zapta said in charge pump:
@bearer said in charge pump:
I started the (happy!) new year with a somewhat scientific experiment.
Do you know how fast it detects that the signal stoped? (e.g. feed 100KHz, 50%, then set a fixed input voltage and measure time to shutdown signal).
faster than i could observe without a scope, same result if signal went over or under about 3/97% duty cycle or below about 250hz.
-
@dc42 said in charge pump:
There are two easy outputs that could be provided. One is a square wave at 500Hz, generated in the tick interrupt service routine. The other is a lower frequency, more erratic signal generated by the main task loop. The interval between state changes could rise as high as 200ms when writing to SD card.
A charge pump signal indicating that at least the heater control processes are sane is still high on my wishlist, and I would not mind an erratic signal. Easy to cope with that in chargepump signal processing circuitry, and with a 3D printer I absolutely don't need subsecond reaction times.
Should I do an official feature request somewhere?
-
@DaBit said in charge pump:
@dc42 said in charge pump:
There are two easy outputs that could be provided. One is a square wave at 500Hz, generated in the tick interrupt service routine. The other is a lower frequency, more erratic signal generated by the main task loop. The interval between state changes could rise as high as 200ms when writing to SD card.
A charge pump signal indicating that at least the heater control processes are sane is still high on my wishlist, and I would not mind an erratic signal. Easy to cope with that in chargepump signal processing circuitry, and with a 3D printer I absolutely don't need subsecond reaction times.
Should I do an official feature request somewhere?
The Heat process runs at intervals of 250ms, so any signal it generates would either comprise short pulses at 250ms intervals, or a 2Hz square wave.
There is already a software watchdog in the tick interrupt handler to check that the heat task is active. The tick interrupt handler is monitored by the hardware watchdog.
-
A 2Hz signal would require an approximately 0,2Hz time constant for the CP detection circuitry. Completely acceptable for me. 0,02Hz would be acceptable too. But a 2Hz signal is not very useable with other off the shelf hardware unfortunately.
I don't really care where the CP signal is generated and what it's actual frequency is, as long as it is a reasonable reflection of software health state. The tick interrupt handler might be the most convenient place and the most conventient frequency. If it ever proves to be ineffective it can always be improved.
