I am driving external LEDs on my development board. I am using the Linux 'timer' trigger to blink them. However, the trigger allows the blinking of LEDs at a fixed rate. Is it possible to configure the rate at which the LEDs blink using the 'timer' trigger?
ledtrig-timer.c should provide delay_on and delay_off device files for the LED which can be used to set how long the LED is on and how long the LED is off.
Setting both of them to a small value will result in a fast flash rate.
Setting both of them to a small value will result in a slow flash rate.
Setting one longer than the other will result in varying "on" and "off" durations.
The LED Kernel Timer Trigger file ledtrig-timer.c is well commented and should help you figure out how to control the LEDs.
Note that the link is for an older 2.6 kernel, but it is better documented than the newer versions of the file.
Related
On my STM32H753 I've enabled an interruption on the rising edge of one of the GPIOs. Once I get the interrupt (provided of course that the handler acknowledges the IT in the EXTI peripheral), when the signal goes low again, I will be able to get another interruption at the following rising edge.
My question is: what is the minimal duration between the falling edge and the rising edge for the latter to be detected by EXTI ? The datasheet specifies many characteristics of the IOs, in particular the voltage values to consider the input low or high but I didn't find this timing.
Thank you
For the electonic part, you need to refere to you MCU datasheet.
However I beleive you need the information about the software part:
You will be able to handle a new GPIO IRQ (EXTI) as soon as you've aknowlegded the former one by clearing the IRQPending Flag or via HAL APIs.
If two IRQs occurred and you did not clear the IRQPending flag yet, then they will be considered as one IRQ. Benchamrking such delay depends on the Clock speed you're using and the complexity of your EXTI_IRQ_Handler routine.
An interesting issue arose with a device whose SWD_CLK pin is shared as a 'device boot mode' pin (ROM/Flash boot, etc.). The specification states that the SWD_CLK should be held high for some time before functioning as SWD_CLK.
The origen_swd plugin drives the clock high to 'enable' it, so the timeset for this pin must be 'return low' in order to clock. But, when I try to drive this high and hold it high, it begins clocking. Is there a way to disable the timeset for some time, then re-enable it when ready?
The workaround is to change the origen_swd to accept an option to either drive high or drive low to enable, then change the timeset in my application to return high.
Using metaprogramming to just grab and edit instance variables of the timeset may also be a solution, but is there a supported API to handle the tasks like the above?
Thanks
The way to do this would be by making two timing options for the given pin, one with the return low and one without.
tester.set_timeset "mode_entry", 40
pin(:swd_clk).drive!(1)
# Sometime later once in mode
tester.set_timeset "func_swd", 40
If the tester supports (e.g. V93K) you can also define multiple wave forms for a pin within the same timeset, as shown at the end of this guide section - http://origen-sdk.org/origen/guides/pattern/timing/#Complex_Timing
Then you would just have a single timeset selection and control the wave you want on the pin like this:
pin(:swd_clk).drive!(1) # Would be defined in the timing as always high
pin(:swd_clk).drive!('P') # Now start the clk pulse
Both of these approaches will work in the generated ATE patterns, however at the time of writing I believe that OrigenSim does not yet support the second approach, so you will have to use the multiple timesets.
As an aside, you sound like you are only looking for a solution that works in simulation and not necessarily required to have the two types of waves within the final ATE pattern.
In that case, you could also try poking the testbench's pin driver force data bit, though I haven't tried this:
tester.simulator.poke('origen.pins.swd_clk.force_data[1]', 1);
If you have success with that, we should think about adding a convenience API to do this kind of thing in simulation:
pin(:swd_clk).force!(1)
I have a raspberry pi, I want to use one single pwm channel to control a rgb led. There are 2 pins available for pwm0. So I connected red led on first pin and green led on second pin. I connected the blue one on a gpio. When I enable pwm0, the red and green leds are on. I would like to control them individually. I know it will be same period and duty cycle but is there a way to turn one pin off without disabling the entire pwm channel ?
You need to provide more information, such as a code snippet, the library you are using and the schematic. You can find more information on this specific stackexchange thread for raspberry: PWM on Raspberry. You must be having trouble configuring your pins. For sure, you are able to do it.
I am trying to adapt a circuit for soft-power from Raspberry to Cubieboard (http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch). It appears to be working just fine but it needs a pin from the board to be set high while it is running (actually the description is for input with pull-up, but that's not the problem).
I have managed to set the PH15 pin as output high in uBoot script via gpio set 263. However about 3 seconds into the boot process something sets it low back again. The fex file is set correctly to adjust it to output high (tried input with pull-up too) but that appears to kick in several seconds later (about 7-8 seconds in the boot). As a result during the boot process the soft-power circuit just dies reacting to the low state of the pin.
So that is the puzzling question - how to set a pin on the Cubieboard immediately during boot and keep it that way? What brings it down?
Using kernel 3.4.79 with some config options (rtc, drivers, etc - nothing exotic).
Any help appreciated. Modifications to the circuit acceptable too!
I build a small game controller for the Z1.
I have a process reading values from a Joystick sensor. It works fine.
Then, I added a second process, reading the value of the battery sensor every 5 minutes. But it makes the Joystick stop working: the value does not update anymore!
I found a workaround: when I have to read the value of the battery, I deactivate the phidget_sensor, activate the battery_sensor, read the value and then deactivate the battery_sensor and reactivate the phidget_sensor.
But I would like to know why I can not have both sensors activated at the same time ?
Thanks
Comes from Here.
The ADC is the "analogue to digital converter", basically is the component that provides you the voltage signal levels of an analogue sensor, so then it can later be used to translate to a meaningful value.
What happens is the battery sensor driver and the phidget driver each when starts configures the ADC on its own, thus overwriting the ADC configuration.
The expected use of both of these components is actually how you are actually using: enable, measure, then disable. This way you ensure at all times the ADC is configured the way your application expects. If you want to have this done in a single operation then I'm afraid you will need to modify probably the phidget driver and include this.
I hope this is the answer you expected, as you are asking why does this happens.