so you are reporting success… splendid!
thanks very much for helping
gomer
No. I’m working to ensure the pulses are visible if they exist - but they are not visible.
The pin remains at logic 0.
Ok, but even if it is working, it will be at logic 0 for 90% of the time…
if I understand you correctly… you are able to manipulate /sys/class/pwm to the point that you are able to enter the period and duty cycle… that is significant… it tells me that the pin is set to the ‘pwm mode’… do you get any error message when entering these values? … can you cat out these values to verify that they are being entered correctly? What values are you using for the period and duty cycle?
just a guess, but it is easy to put in incorrect values that would result in the appearance that the led is never on… missing one decimal place would result in not a 10% duty cycle but a 1% duty cycle (perhaps inperceptible to the eye) …
the scale is in nanoseconds, so the period is 1 billion (1 sec) and the duty cycle is 100 million (1/10 sec) … what if you change the duty cycle to 500 million (1/2 sec)?
sad that you don’t have a scope…
but thanks for the effort.
gomer
Yes, I can manipulate the files in /sys/class/pwm. I totaly agree that this significant. I suggests to me that things are working, that perhaps there is some other fault. I’ve never used pwm on the bbb, so I could well be missing something.
As I said earlier, cat-ing the files period, duty_cycle and enable do show that the values wrote are what they should be.
I’m meticulous about entering correct data. I checked and rechecked the values I entered multiple times. I can assure you that they are the values that you posted in your original message. I also tried duty cycle values of 1% 10% 50% and 90%. I’m confident this would show the led blinking if it was doing so. I could check with the scope next week, though I dont have any confidence this would be meaningful.
please understand that I mean no offense, I’ve got no idea how skilled or meticulous you are… you might have not toggled the ‘enable’ correctly, or your led might be blown … or, or, or…
if /sys/class/pwm is being updated correctly, I’m betting that it is working.
just my 2 cents…
gomer
Just to be sure and to verify the pin output is not blown, I configured P9.22 as GPIO output and am able to switch the led on and off without problems.
Thats Ok, we cant know who’s on the other end.
As someone who has this working you seem to be key to figuring out why it isn’t working for others. If others can repeat these commands, maybe we can get a consensus - whether my results are an outlier or whether there really is a problem and if so figure out what that is.
The most important part is if this is actually hardware pwm, not kernel pwm. For hardware pwm more nodes are exposed than it is for kernel pwm. Kernel is okay for buzzers and lights but to control a motor its a non-starter.
I have the kernal module for the hardware pwm and its copyright 2012!! No updates, so that is more than likely severely broken. It loads but it does not work. Am I not going to touch that, no way. That turns into major waste of time. Its cheaper to find another solution. If we were selling 10’s of thousands of the product with the bbb it would be worth the effort to pay a kernel expert to fix the driver for us.
I’m willing to run this down if you are… I see that @foxsquirrel is no longer interested.
I dusted off a BBB that I had in an abandoned project box and set up a test with a LED in addition to my scope… all worked as expected.
I could repost the command history, but that would be redundant as the first one still is valid (I think).
my question to you: how did you determine that the logic level was 0? without setting it up myself, I imagined that you had some ‘value’ pseudo file that you were checking, such as exists when the pin is configured for gpio … after redoing the exercise I see that no such ‘value’ file exists.
I’ve forgotten where I learned that P9.22 is on pwmchip1… what if that is different on your system?
<config-pin -i P9_22> reports in the “Function information:” line that ‘ehrpwm0a’ applies to this pin … still doesn’t point to pwmchip1
Molloy’s first edition is based on UIO ($SLOTS) setup but uses P9.22 as an example… second edition is remoteproc based BUT Table 6-2 indicates that P9_22 is on pwmchip0 (hardware name EHRPWM0) … so where did I get pwmchip1? I might have just tried each of the pwmchip? in turn … I don’t remember.
so, are you, or anyone else still interested in running this down?
gomer
how about using the PRU to generate your signal… would be trickier to change values, but not subject to LINUX preemption. BUT … what if the kernel manipulation ONLY communicates with the ‘hardware’ pwm… then you would effectively get the hardware PWM (TRM chap 15) with the convenience of command line control.
also, before I used the /sys (maybe but not probably kernel) way of generating PWM, I used a Silicon Labs 5351a board to generate high frequency clock cycles … it is controlled by I2c … without revisiting it specifically that is all I remember about it.
sorry if I hijacked your thread… I didn’t understand the ‘hardware’ part of your topic.
gomer
That is off the table, an m7 in NXP bsp is easier to work with but that is still too much nonsense. Complex and tricky code leads to tail chasing and what is worse is if you have to work on that “tricky” project even just 3 months later you are back to day zero on the learning curve. It might be fine if you only had 1 product that you sold in 10’s of thousands and can justify having a specialist for that.
Another issue is the clear fact Ti does not provide a clear working example, that is the flashing red light.
You must ask yourself why is that, it comes down to three basic possibilities. First one, its a lame feature and not worth even their own time to implement, yet I am suppose to burn my dollars to find out it is lame. Second, are they protecting the top 10% of their customer base by throttling back a “smelly old Hillbilly” like myself that can possibly create a product that is a threat to one of their strategic partners. Third, is this a big infomercial that leads users into paying to have the “magic” code to turn the feature on…
Bottom line is this, if it smells walk away.
Anyone that can muster enough talent to create a 5800 page Technical Resource manual and not provide a rudimentary working example of features that are critical to a successful product, this smells.
Forgive me for posting this but, back in the old days I would log into the Motorola BBS with a 300 baud modem and down load tech data and source files. They actually printed out real manuals, with working examples, those examples ACTUALLY worked. Back then the “big tech culture” did not exist…Now, just look around…do I need to say more.
1 Like
see the chatgpt session above for its’ view of this matter. It explains that the LINUX kernel USES the hardware PWM on the AM335x SOC
FWIW
gomer
Only one way to verify it if its actually hardware is to put the scope on it. You will see it bounce around if it is scheduled in the kernel. With a truly autonomous pwm module, the scope will lock on and you can measure the signal, freq, pulse width, etc. and it should be rock solid with the core(s) fully loaded down.
I can help you with that right now… I have my scope on it and a LED for good measure… I don’t know what ‘LOAD’ you want to put on the CPU to stress it… you’d have to guide me there.
of course, my scope might not measure up to your expectations… it is an entry level (Micsig TO1104), but I find it useful.
tell me what parameters you want me to set up.
gomer
If you don’t mind sharing the link the image you are using. I went back to the angstrom images and did not have much luck.
This is one of the older images I tried:
bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
Is that close to the one you are using?
And this one:
Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img.gz
easiest way is to download the image that I used for this project: Turnkey PRU deskclock application for BBB
then, if I somehow modified the stock image and have forgotten about it, you will get that change as well… Is changing Uenv.txt disabling HDMI, etc what made it work for my system(s)… IDK b/c I dont remember.
the desk clock app does NOT use PWM in any way, but it is the image that I have on all my BBB…
let me know
gomer
1 Like
I just tried running through all the pwm chips, and I find that P9.22 is on pwmchip3/pwm0.
Success! The led does blink.
Looking at it on the scope, it appears rock solid - no jitter at all at 100ns period and 50% duty cycle.
Paul
Gr8! … if you followed @foxsquirrel … he is trying it with one of my images… he is interested in monitoring how ‘solid’ it is with the CPU under stress… any ideas how to advance that?
thanks again for your participation.
gomer
To add a bit of ‘stress’ I ran a compile of a big project - no effect on the waveform at all - still solid.
For the sake of completeness; I’m using the Bullseye Minimal Image 2023-10-07.
What overlay are you using? I removed the one I had enabled and now pwm0 and pwm1 are not exposed.
fred@bb5:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=5.10.168-ti-r78
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=BBORG_RELAY-00A2.dtbo
#uboot_overlay_addr2=BBORG_LOAD-00A2.dtbo
#uboot_overlay_addr3=<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=<file4>.dtbo
#uboot_overlay_addr5=<file5>.dtbo
#uboot_overlay_addr6=<file6>.dtbo
#uboot_overlay_addr7=<file7>.dtbo
###
###Custom Cape
#dtb_overlay=<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###
console=ttyS0,115200n8
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e
#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet overlayroot=tmpfs
##enable Generic eMMC Flasher:
#cmdline=init=/usr/sbin/init-beagle-flasher