I've recently had some reason to start experimenting with PWM myself, and found that (as pointed out by one of the comments) the frequency seems to vary with duty cycle - bizzare, right? It turns out that Broadcom implemented "balanced" PWM in order to make the on and off PWM pulses as evenly distributed as possible. They give a description of the ...
According to this formula:
pwmFrequency in Hz = 19.2e6 Hz / pwmClock / pwmRange
We can set pwmClock=1920 and pwmRange=200 to get pwmFrequency=50Hz:
50 Hz = 19.2e6 Hz / 1920 / 200
I test it on alarmpi:
$ pacman -S wiringpi
$ gpio mode 1 pwm
$ gpio pwm-ms
$ gpio pwmc 1920
$ gpio pwmr 200 # 0.1 ms per unit
$ gpio pwm 1 15 # 1.5 ms (0º)
$ gpio pwm 1 ...
I think your problem is that when motion is detected the loop runs at full speed. I would suggest one of the following sollutions:
Use a blocking read from the GPIO pin. That way your program will hang untill there is new data ready, i.e. if the GPIO pin has changed state.
When using polling you should make your program sleep at least once with run of the ...
This is the code I'm using. I'm trying to see what will change as i change the settings.
int main (void)
printf ("Raspberry Pi wiringPi test program\n") ;
if (wiringPiSetupGpio() == -1)
exit (1) ;
Yes it's safe. Judging from the source code of the library, it doesn't cache the values but reads them each time you call digitalRead function so it should work as expected.
It isn't really documented in the wiringPi documentation but at least the documentation also doesn't say it's forbidden (for example for digitalWrite there ...
To set a pin numbering scheme you use one of four Setup functions:
int wiringPiSetup (void);
int wiringPiSetupGpio (void);
int wiringPiSetupPhys (void);
int wiringPiSetupSys (void);
To use BCM GPIO numbering you would replace you would use wiringPiSetupGpio(void); and modify the pin numbers in your code appropriately.
I'm wondering, may understand that Raspberry Pi's I2C is in fact the SMBus version of I2C ?
I don't think it is limited in that sense but that is the normative way to use it. There is no such limitation with the kernel, since the protocol docs for the interface say, "If you write a driver for some I2C device, please try to use the SMBus commands if at all ...
On many electronics boards, GPIO pins are set to a "floating voltage" (not on, not off, just somewhere in the middle) until the pin actually gets initialized or used for the first time.
Remember, when you turn the Pi on, it has to load a bunch of kernel modules and drivers, including the ones to use the GPIO pins. The pins are part of an electrical circuit, ...
Most of the pins are configured as inputs. This is normal, and usually the safest option.
All of these inputs are put into a defined state with either a pullup or pulldown. The normal values are shown in http://elinux.org/RPi_BCM2835_GPIOs These are quite high impedance ~50kΩ.
The only pins set as output are those specifically configured as such e.g. TxD. ...
Shared or dynamic libraries are needed at run time. So you need the library not only on the build system but in on the target system, in this case on the PI.
This is different from static libraries. If you use a static library at build time, all the needed code from the library would be included in the executable, and the library would not be needed to run ...
If you need low latency communication, know that interpreted code is always going to be relatively slow. Code compiled into CPU-native instructions, as C and C++ almost always are, will run much faster, 50:1 or more in some cases. For extreme cases, once your application works, re-visit the critical code and see if it can be improved by hand-writing it, or a ...
Interrupts are not supported in the python version of wiringPi2 because it's a wrapper of the original wiringPi C library. To quote the publisher of the module in issue 8 of it's github:
... I will have to look at implementing Python-wrapped interrupts in a different manner. At the moment your only choice is to set up a polling loop. Sorry!
Try using RPI....
The most common error in crontabs seems to be not giving the full paths to programs or data used.
Use the which command to find where gpio is stored on your machine (probably /usr/local/bin/gpio) and change the command as follows
15 18 * * * /usr/local/bin/gpio -g write 10 1
The Pis with 40 pin expansion header (and the compute module) have two hardware PWM channels which you should be able to use with wiringPi.
That would give you control of two ESCs.
From the software side there are several modules which provide DMA timed PWM on any or all GPIO (e.g. my pigpio, servoblaster etc.). These modules provide a pipe interface to ...
It's possible with a very minor caveat.
When you set a GPIO high or low you write to one of two registers.
A set register to set selected GPIOs high.
A clear register to set selected GPIOs low.
The set and clear registers are 32 bits in size and control GPIO 0-31.
To set GPIO x high you write 1<<x to the set register. E.g. to set GPIO 4 high you ...
I ran into this same problem using Java with Raspbian on a Pi 3 and found a posting from the Pi4J development team indicating that the problem is that when Pi4J is automatically installed, a copy of the wiringPi library is also installed and the copy of wiringPi in the installation package is old. I think this is a problem with Pi 3.
The side where your micro sd card is the upper side, the first number is your gpio pin number from the RPi itself (in ascending order) then there is the Broadcom number, and between the parenthesis as you can see are the matching Wiring Pi numbers.
First the left row from up to down:
1 3v3 Power
3 BCM 2 (WiringPi 8)
5 BCM 3 (WiringPi 9)
7 BCM 4 (WiringPi 7)...
The use of UTC time seems to be hardcoded in ds1302 utility. Note the following line:
gmtime_r (&now, &t) ;
This converts your system time to UTC, before writing it to the DS1302 chip. When the chip is read back, your system time is set to whatever is received from the chip, without any conversion (which frankly looks like a bug).
There are two ...
The programmable pins (General Purpose Input/Output) can be used in a variety of ways - but not all at the same time. Before the point where power is applied to the RPi's Systen-on-Chip (Soc) AND it has performed a reset the state of those pins is entirely dependent on the design of the circuity inside the SoC - it is likely (I haven't checked the ...
WiringPi is not supported on any other operating systems than Raspbian - so its likely this feature is not supported in Ubuntu.
WiringPi is developed directly on a Raspberry Pi running 32-bit Raspbian. I do not support any other platform, cross compiling or operating systems. It has been ported to other platforms, other operating systems and some are ...
Your card reader is a usb card reader that acs like a keyboard and spits out the value as if keys were being pressed.
It looks as if you should be able to use the
fgetc()function in php to get keyboard input from the keyboard. Assuming your usb card reader gives an enter key when you scan a card the you should be able to take that usb card reader. ...
Lucky to see this question, I just spent weeks on controlling two servo (SG90) using WiringPi and programming in C, there're three things that I recommend.
1.Using BCM GPIO instead of WiringPi Pin because controlling more than one servo, you might need more than one pin such like 1(WiringPi Pin)/18(BCM GPIO) for another servo, For RPi3 B+ version, it give ...
Yes, you can determine the current mode of a gpio.
You'd have to search the wiringPi documentation and source code to see if a method is implemented by wiringPi.
My pigpio library provides the C I/F gpioGetMode function as well as Python and command line methods.
For example code see Minimal gpio access.
int gpioGetMode(unsigned gpio)
int reg, shift;...
Between a Raspberry Pi and an Arduino, using UART is the best option. I know because this is my 3rd project doing so. (And also USB is impossible) You should run the UART at 1000000 baud. Default UART configuration is 9 bits per character. This leaves a latency of 1/(1000000/9) or 0.000009 aka 9 microseconds. If you are sending mouse commands I would guess ...
It's a limitation of wiringPi. It only implements a couple of SMBus commands.
As you say using SMBus commands you are limited to 32 bytes.
Using the raw device you can send hundreds at a time. I'm not sure what limit, if any, is imposed by the kernel driver.
Personally I'd just use the raw device (/dev/i2c-1) as it's much simpler and more flexible.
There are several different GPIO numbering schemes.
You need to ensure that the software you are using is using the numbering scheme you expect.
See https://pinout.xyz/ for the gory details.
The most popular numbering schemes are
the (physical) expansion header pin number
the (Broadcom) GPIO number
I use this chart.
GPIO pin pin GPIO