I just encountered the phrase "8254 clock source" in The Well Grounded Java Developer.
Unfortunately, I don't know the definition of 'clock source'.
Is it similar to the Clock signal or is it some kind of source code that makes a timer?
The quote from the book is:
The 8254 is a programmable timer chip that’s been kicking around since
the dawn of time. The clock source for this is a 119.318 kHz crystal,
which is one-third of the NTSC color subcarrier frequency, for reasons
that go back to the CGA graphics system. This is what once was used
for feeding regular ticks (for timeslicing) to OS schedulers, but
that’s done from elsewhere (or isn’t required) now.
Yes, the "clock source" is the thing that is providing the "clock signal", which in turn determines the rate at which the 8254 timer counts.
Note that while TWGJD says
"The clock source for this is a 119.318 kHz crystal"
this doesn't mean that the timer is necessarily receiving a clock signal of this frequency: any given design might have dividers between the crystal and the timer chip.
Related
for a battery powered project I would like to put an Attiny85 into deep sleep mode immediately after program start and let it wake up only when a sensor value (in this case a photo resistor) changes. Unfortunately I could only find examples for interrupts by a button and not for photo resistors in the internet. Does anyone have an idea how I could implement it, or if it is impossible?
Turn out that this is probably a software question.
Probably to lowest power and simplest way to implement this would be to...
Connect the analog sensor value to any one of the analog input pins on the ATTINY.
Make sure you disable the digital buffer on that pin.
Set up the ADC to point to the pin and set other relevant values like precaller.
Set up a watchdog timer to fire a periodic interrupt.
Go into deep sleep and wait for the watchdog timer to fire.
Each time the watchdog fires...
Enable the the ADC.
Take a sample.
Jump to main code if the value has changed more than your threshold.
Disable ADC.
Go back to deep sleep.
How power efficient this will be really depends on how often the timer interrupt fires - the less often the better. If your application can live with only checking the sensor, say, once per second then I bet power usage will be single digits of microamps or less.
If you really need very low latency when that sensor values changes, then you could instead use the build in analog comparitor...
.. to generate an interrupt when the input voltage goes above or below a threshold value, but this will likely use much more power since just the analog comparitor itself uses ~30ua while on, and you will also need to generate the voltage that you are comparing to either with the internal 1.1 voltage reference or an external resistor bridge or buffer capacitor.
The configCPU_CLOCK_HZ option explanation starts with this:
Enter the frequency in Hz at which the internal clock that driver the peripheral used to generate the tick interrupt will be executing.
Although I do more or less understand what it means, I need some finer explanation of what exactly is said there. Removing obvious "the peripheral used to generate the tick interrupt" from the middle I'm getting the "Enter the frequency in Hz at which the internal clock that driver will be executing", and this phrase looks a bit uncoordinated to me. What did the autor want to say with this? Some "that" driver, unlike, say, "this"? What "that"? The context doesn't imply any "that" here.
I think 'driver' should be 'drives' in that explanation.
configCPU_CLOCK_HZ is the frequency of the platform dependent timer that generates the tick interrupt. It is used by some ports to program the timer so it generates the correct FreeRTOS tick rate (see configTICK_RATE_HZ).
Example: configCPU_CLOCK_HZ is 1000000 (1 MHz) and configTICK_RATE_HZ is 100, then you configure the timer to generate an interrupt every 1000000/100 = 10000 ticks. That interrupt is your FreeRTOS system tick.
Take a look at an ARM Cortex-M port for one of the most common examples of this that uses the Cortex-M SysTick
I Quote from Wikipedia:
A watchdog timer (WDT; sometimes called a computer operating properly or COP timer, or simply a watchdog) is an electronic timer that is used to detect and recover from computer malfunctions.
While using STM32F429I-Discovery, I came across a term [in "stm32f4xx.h"] which uses a register to disable Watchdog:
#define ADC_CR1_AWDIE ((uint32_t)0x00000040) //Analog Watchdog interrupt enable
Here, I am unable to understand Analog Watchdog
And if possible,
#define ADC_CR1_JAWDEN ((uint32_t)0x00400000) //Analog watchdog enable on injected channels
What is injected channel here?
A watchdog timer can be thought of as two separate circuits, a timer circuit and a watchdog circuit. The timer circuit merely counts the time that passes. The watchdog circuit actively monitors the timer to see if a certain amount of time has passed without being reset by software. If so, the software is no longer running and the watchdog typically performs an automated function such as resetting the processor. The watchdog needs only to be told at initialization how much time to monitor for and it handles the rest of its operation without additional software interaction.
An analog watchdog operates in a similar manner. Only instead of monitoring a timer, it monitors an analog input channel. At initialization, you tell the watchdog what analog thresholds to monitor for. If a converted value on an analog input passes one of these thresholds, it will fire an interrupt for you to process the signal sample. This means you don't have to write code to continuously poll the analog inputs and check their levels. It is all handled autonomously in the background by the analog watchdog circuitry.
An injected channel can just be thought of as a high priority conversion channel. If a regular analog input is in the middle of performing a conversion and a conversion is triggered (either by a timer or because it is programmed in continuous conversion mode) on an injected channel, the conversion on the regular channel will halt and wait while the injected channel is converted before completing its own conversion. This is useful if you have an analog input that must be responded to in a realtime manner.
Here is an application note (which, for some strange reason, doesn't seem to be available in ST's website) that give a few examples of the use of the various ADC features. And here is another explanation of the two features your question was about.
The term "watchdog" in this context refers to the fact that the ADC channel is continuously monitored.
In this context the term is not related to a processor operation watchdog - which monitors processor operation. Although you could use it for brown-out detection or power-supply failure detection if your power supply as a reservoir capacitor or battery back-up capable of keeping the processor up long enough after the supply side drops-out.
The analogue watchdog on STM32 is simply a means of generating an interrupt when some external voltage drops below or exceeds a programmable threshold level. This is done without software intervention when the ADC conversion s configured to free-run, so if the application only needs to respond to thresholds, this can be implemented with zero software overhead for ADC polling.
You might use the feature for example for carrier sense detection in an RF application by using it to monitor the RSSI signal from an FM demodulator. Or it might be used in a in a bang-bang controller, such as a boiler thermostat. The AWD has upper and lower thresholds so can be used to implement hysteresis, and you can modify the thresholds dynamically to generate multiple events on a curve for example.
Hi Im using the following RF module
http://www.apogeekits.com/rf_receiver_module_rx433.htm
on an embedded board with the PIC16F628A. Sadly, I realized that the signal strength was in analog form and couldn't get any ideas to get the RSSI reading off the pin because well my PIC is digital DUH!.
My basic idea was
To get the RSSI value from my Receiver
Send it to the PIC
Link the PIC to a PC via RS232
Plot a graph of time vs RSSI of the receiver (so I can make out how close my TX is to my RX)
I thought it was bloody brilliant at first but ive hit a dead end here. Any ideas on getting the RSSI data to my PC from this receiver would be nice.
Thanks in Advance
You can get a PIC that has an integrated ADC for sampling the analog signal. Or, you can use an external ADC chip to do the conversion. You would connect that to your PIC using SPI or I2C.
The simplest thing to do is obviously to use a more appropriate microcontroller - one with an ADC! There are many (most), including PICs (though that wouldn't be my first choice).
Attaching an external SPI or I2C ADC might be a bit tedious since having no SPI or I2C on your part, you'd have to bit-bash it. If you do that, use an SPI part - its simpler. Your sample rate will suffer and may end-up being a bit jittery if you are not careful.
Another solution is to use a voltage controlled PWM, then use the timer input capture to time the pulse width. That will give you good regularity and potentially good resolution. You can get a chip (example) to do that, or grow your own. That last option requires a triangle wave input as well as the measured (control) voltage, but on the same site...
In a similar vein, you could use a low frequency VCO (example) and use the output to clock one of the timers, then using a second timer periodically sampling the first and reset it. The count will relate to the voltage, though not necessarily a linear relationship, linearisation could be none on the PIC or at the receiving PC - I'd go for the latter - your micro will suck at arithmetic (performance wise) - even integer arithmetic, especially if it involves division.
I need to drive a 32Khz square wave on pin 19 of a Renesas R8C/36C µController. The pin is non-negotiable (the circuit design is already complete.)
The software design uses a 250 µsec interrupt for simulating multi-tasking, but that's only good for 2Khz full-wave.
Do I need to create another higher-priority interrupt for driving 32 Khz, or is there some other trick that I'm not aware of?
R8C/36C Hardware Manual
R8C/36C Software Manual
I am not familiar with the RC8 and Renesas don't say much on the subject of performance, but it is a CISC processor with typically 4 cycles per instruction, so lets estimate about 4 MIPS? Some instructions are much longer with division up to 30 cycles.
So if you create a 64KHz timer and flip the output on each interrupt, you have about 63 instructions between each interrupt, you have the interrupt latency plus the code to flip the bit. If it works at all, it is likely to constitute a significant CPU load and may affect the timeliness of other operations.
Be realistic, without a redesign, the project may not be viable. You are already stressing it with the 4KHz OS tick in my opinion - the software overhead at that rate is likley to be a significant chunk of your CPU load.
[ADDED]
I previously suggested 6 instructions between interrupts - finger trouble in the calculator, I have changed that estimate to 63, and moderated my conclusion to "barely feasible".
However I looked again at the data sheet, interrupt latency is variable because the instruction execution is variable, and the current instruction must complete before the interrupt is serviced, the worst case is when the DIVX instruction is executing, when it takes up-to 51 cycles before the first instruction of the interrupt routine. That's 2.55us, when you need the interrupt to trigger every 15.625us, the variable latency will impose significant jitter and constitutes 6 to 16 % of your total CPU time without even considering that used by the ISR itself.. Plus if the interrupt itself is pre-empted, or a higher priority interrupt is running when this one becomes due, further jitter will be imposed.
Whether it works will depend on the accuracy and jitter constraints of the 32KHz, and whatever else your code needs to get done.
As many people have pointed out, this design doesn't seem to be very good from a hardware standpoint if the 32khz clock is meant to be generated with a gpio.
However, I don't know How desperate is your situation, nor do I know the volume involved. But if it is a prototype or very short series, and pin 20 is free, you can short-circuit pins 19 and 20, setup pin 19 as an input and 20 as output. Since pin 20 can be used as output from timer rd, you could set up that timer to output the 32khz without using any interrupts.
I am not a renesas micro expert, but I'm talking from what I've seen in the data sheet you attached and previous experience with other mcu's.
I hope this helps.
Looking at the datasheet for that chip:
It looks like your only real option is to use the pin as a generic output port.
the only usable output mode seems to be the generic output port.
If you can't strap pin 19 to another pin that has the hardware to generate 32KHz and just make pin 19 an input? Not a proud moment but it was easy on a DIL package.
Could you call an interrupt every 15.6us and toggle pin19 then on the sixteenth interrupt do the multi-tasking stuff but that is likely to be wasteful. With an interrupt rate of 32Khz, setting pin19 then eighth of the time doing the multi-tasking decisions and the other seven times wait till a point you can reset pin19 and do some background code for less than half the CPU time