Re: [beagleboard] Re: Tuning the watchdog timer - correct place?

rs_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature> > > On Tue, Jun 18, 2019 at 7:55 AM, Hugh Frater > wrote: > Update: The kernel watchdog driver support tuning the timout through ioctl > calls. A quick and dirty bit of C code: > > > int main() > { > int fd = open(&q

[beagleboard] Re: Tuning the watchdog timer - correct place?

timeout); close(fd); return 0; } Will tune the watchdog. I use node.js' child_process to call the above code (when compiled, obviously), if my node.js app crashes then the BBB will reboot. Perfect On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote: > > Where does one go

Re: [beagleboard] Tuning the watchdog timer - correct place?

ion/watchdog/watchdog-api.txt Looks relevant. Does anyone know if the Watchdog driver supports on the fly timeout adjustment? On Tuesday, 4 June 2019 10:57:40 UTC+1, Hugh Frater wrote: My experience of working directly with the i2c and eqep parts of the > silicon from within the PRU suggest that re

Re: [beagleboard] Tuning the watchdog timer - correct place?

d > <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature> > > On Mon, Jun 3, 2019 at 7:07 AM, Hugh Frater > > wrote: > Where does one go to tune the watchdog timer? Is it a > kernel-recompilation-required thing, or

[beagleboard] Re: Tuning the watchdog timer - correct place?

Update: page 4492 of the TRM details the watchdog timer. I'll probably use the PRU to configure the registers unless there is an easier way... On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote: > > Where does one go to tune the watchdog timer? Is it a > kernel-recompilation

[beagleboard] Tuning the watchdog timer - correct place?

Where does one go to tune the watchdog timer? Is it a kernel-recompilation-required thing, or can it be done through uBoot? Or should I just use my PRU code to tune the watchdog control register when it boots? This would be the easiest option for me, if someone can point me at the correct

[beagleboard] cape-universal vs custom overlay

I'm getting our product ready for production... During the development phase I've been using cape-universal and have a script that runs at boot time that just serially runs config-pin to setup all of the 30 pins we need. There is a mix of GPIO, eQEP, i2c and some uarts... this little script

Re: [beagleboard] firmware loads fail, remoteproc error codes

. I've modified my pru-rebooting script to instead start the PRU. Configure the script to start with the following: 1. Copy script to /etc/init.d 2. chmod 755 script 3. sudo update-rc.d start-pru.sh defaults On Tuesday, 28 May 2019 17:36:09 UTC+1, Hugh Frater wrote: > > Fixed it... >

Re: [beagleboard] firmware loads fail, remoteproc error codes

Fixed it... sudo sh -c "echo 'start' > state" from within /sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2 On Tuesday, 28 May 2019 17:25:44 UTC+1, Hugh Frater wrote: > > My takeaway from Mark's excellent writeup is th

Re: [beagleboard] firmware loads fail, remoteproc error codes

/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2$ cat state offline For PRU1 Hmmm On Tuesday, 28 May 2019 17:00:04 UTC+1, Hugh Frater wrote: > > Reading it now, I'll be back... Cheers for all your help up till now > > On Tuesday, 28 May 2019 16

Re: [beagleboard] firmware loads fail, remoteproc error codes

Reading it now, I'll be back... Cheers for all your help up till now On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote: > > On Tue, May 28, 2019 at 10:41 AM Hugh Frater > wrote: > > > > Tried both those fixes Robert, no joy. Is it still acceptable practice >

Re: [beagleboard] firmware loads fail, remoteproc error codes

+1, RobertCNelson wrote: > > On Tue, May 28, 2019 at 10:27 AM Hugh Frater > wrote: > > > > Does anyone know what the remoteproc error codes are? > > > > pru_rproc doesn't start the pru's at boot time, I assume this is the new > behaviour in 4.14 with the uB

[beagleboard] firmware loads fail, remoteproc error codes

Does anyone know what the remoteproc error codes are? pru_rproc doesn't start the pru's at boot time, I assume this is the new behaviour in 4.14 with the uBoot overlays. I've updated initramfs since symlinking my binary to /lib/firmware/am335x-pru1-fw, that hasn't helped. I've done an

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

; > GND TP1 then run as root: > > dd > if=/opt/scripts/device/bone/bbbw-eeprom.dump > of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom > > reboot. > > Everything works fine now! > > Thanks Robert and Hugh > > On Saturday, May 25, 2019 at 2:37

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

Robert, is it ok to use this image in production or should I use the current stretch IOT image and flash the eMMC to overwrite this old bootloader? On Saturday, 25 May 2019 20:55:58 UTC+1, RobertCNelson wrote: > > > This is what I think is relevant from my uBoot console: > > > > U-Boot SPL

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

uEnv.txt so that the new image would > flash to BBBW and rebooted. As expected the lights cycle while flashing. > However, when I rebooted without SD card BBBW is bricked with all LEDs on. > > Any idea what's going on? > > > On Thursday, May 23, 2019 at 9:56:39 AM UTC-7, Robe

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

application we use a bunch of the eMMC pins for other hardware so we're forced to use an SD card. On Saturday, 25 May 2019 21:39:23 UTC+1, Hugh Frater wrote: > > I will get that sorted and put it on my dropbox. I've got to flash eMMC > with the sd card contents then reboot with anothe

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

I will get that sorted and put it on my dropbox. I've got to flash eMMC with the sd card contents then reboot with another sd card in the USB-A port - I'm working from home and don't have any cables other than a 232r on the debug header and a 5v power brick. Give me half an hour... On

[beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

uiet cape_un iversal=enable] ... debug: [bootz 0x8200 0x8808:43836f 8800] ... On Wednesday, 22 May 2019 13:42:57 UTC+1, Hugh Frater wrote: > > This thread is a followup to my post over in the PRU section. Tl;Dr -

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

I'm not sure, sounds like the flashing of eMMC wasn't successful. I have a new SD card writer so I will try this image this evening and report my findings... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

I think it is related to uboot overlays. I started a new thread over in the uBoot section... You might like to take a look over there, Robert has posted an image for me to try but perhaps you can test it for me? I'm currently sd-card-writer-less... -- For more options, visit

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

I will try this and report back Robert. I need to get hold of another sd card adapter tomorrow, the card reader in my laptop has decided to stop mounting cards rw... :( On Thursday, 23 May 2019 17:56:39 UTC+1, RobertCNelson wrote: > > On Thu, May 23, 2019 at 3:39 AM Hugh Frater &

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

BBB On Wednesday, 22 May 2019 19:13:57 UTC+1, Hugh Frater wrote: > > Interesting that it works for you... Might be something to do with our > 50Hz wall power :p > > I'll get back on this when I'm in work tomorrow and I'll try updating the > bootloader and get you a fresh outp

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

Interesting that it works for you... Might be something to do with our 50Hz wall power :p I'll get back on this when I'm in work tomorrow and I'll try updating the bootloader and get you a fresh output from version.sh -- For more options, visit http://beagleboard.org/discuss --- You received

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

Hi Robert, I'm no longer in front of the hardware for today but you can see the output of version.sh on my thread over in the PRU section. You can also see I tried zero-ing out the mmc in case that had a version of uboot that didn't support overlays. Didn't make a difference. -- For more

[beagleboard] Trouble enabling pru-rproc uBoot overlay

This thread is a followup to my post over in the PRU section. Tl;Dr - latest stretch IOT image using 4.14.108-ti-r104 wouldn't enable the PRUs when I un-commented: ###pru_rproc (4.14.x-ti kernel) #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo I attached a serial debug

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

changed and improved! > > On Friday, May 17, 2019 at 9:17:24 AM UTC-4, Hugh Frater wrote: >> >> If you can live with using the universal-cape and just configuring the >> pins once booted using the config-pin utility, that's a good way to go. >> What progra

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

> > > > On Thursday, May 16, 2019 at 5:53:38 AM UTC-4, Hugh Frater wrote: >> >> Hi Walter, I'm afraid I can't help with your custom device overlay issue, >> it us really a topic for a new thread in the uBoot section I would have >> thought? >> >>

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

:27 UTC+1, Hugh Frater wrote: > > I have the same problem as this user: > https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 > in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) > and doesn't seem to detect the PRUs on boot. >

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

and if so what syntax do i use? Where did you > find these instructions? I'm so lost and need to keep moving forward. it > was going so well... > > I'm on 4.4.14 > > On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote: >> >> I have the same problem as t

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

Thought I would try zero-ing the eMMC boot partition, just in case there was a resident uBoot that was old and didn't support overlays no joy :( On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote: > > I have the same problem as this user: > https://groups.google.com/forum/#

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

Anybody? I would really like to complete a migration to Stretch and 4.14 due to the awesomeness of uBoot overlays and the pre-built overlay-root setup that is available from a setting in uEnv.txt, that's a big help for my project. On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote

[beagleboard] remoteproc not detecting PRUs under 4.14, am I missing something?

I have the same problem as this user: https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) and doesn't seem to detect the PRUs on boot. This is a fresh install of Sretch IOT from beagleboard.org,

[beagleboard] Re: PRU remoteproc[12] not appearing under /sys/class/remoteproc/

I have the exact same issue, except my output from version.sh indicates the board id eeprom is programmed correctly? Any other ideas Robert?... I'm playing around with migrating our device from 8.7 with 4.4 kernel up to something more recent and am coming up against this PRU issue... On

Re: [beagleboard] I2C random read of off-board device from within PRU not working correctly

ur code works on it. > Good Luck > > > Sent from Yahoo Mail on Android > <https://overview.mail.yahoo.com/mobile/?.src=Android> > > On Thu, Sep 13, 2018 at 8:06 AM, Hugh Frater > > wrote: > Does anyone know the correct programming sequence for doing an I2C random

[beagleboard] Re: header file for CCSv6 & PRU

: > > Hugh, > Thanks for sharing your research. > Any chance you could also include a reference (ie where did you find this > info)? > > Thanks > > On Friday, August 17, 2018 at 9:43:47 AM UTC-5, Hugh Frater wrote: >> >> I forgot this from my previo

[beagleboard] Re: header file for CCSv6 & PRU

just stuffed it in the top of my PRU code... Registers for other I2C modules are in the memory map from the am335X_trm On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote: > > Does anyone know the header file I need to include to get access to the > i2c2 control registers fr

[beagleboard] Re: header file for CCSv6 & PRU

8 12:29:12 UTC+1, Hugh Frater wrote: > > Does anyone know the header file I need to include to get access to the > i2c2 control registers from within the PRU subsystem? Having a hard time > getting any info and my google-foo is usually pretty decent... > -- For more options, visit

[beagleboard] Re: PRUs realtime data acquisition, I2C bus and ADC

Did you figure out access to the i2c registers from within the PRU? I'm working on that at the moment and could use a header file or similar... On Tuesday, 13 February 2018 17:49:23 UTC, pierric...@gadz.org wrote: > > Hi all, > > I am trying to use the PRUs for real time data acquisition on the

Re: [beagleboard] header file for CCSv6 & PRU

:30:01 UTC+1, Charles Steinkuehler wrote: > > On 8/14/2018 6:29 AM, Hugh Frater wrote: > > Does anyone know the header file I need to include to get access to the > > i2c2 control registers from within the PRU subsystem? Having a hard time > > getting any info and my goog

[beagleboard] header file for CCSv6 & PRU

Does anyone know the header file I need to include to get access to the i2c2 control registers from within the PRU subsystem? Having a hard time getting any info and my google-foo is usually pretty decent... -- For more options, visit http://beagleboard.org/discuss --- You received this

[beagleboard] Re: More pimux woes

On Monday, 22 January 2018 17:42:03 UTC, lgil...@tethers.com wrote: > > Thanks!! Very helpful. One issue with just using the config-pin utility > is that it doesn't always give you access to all the configurations > possible for a peripheral (not pin), for instance, setting a pin to eqep >

[beagleboard] Re: More pimux woes

Robert, everything is working nicely at this end with the new version of bb-cape-overlays. Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and

[beagleboard] Re: More pimux woes

You basically have 2 options regarding pinmuxing on a bb the config-pin utility requires the universal cape to be loaded as the only dtbo, you then use configure-pin to setup the pins you want. 2nd option, specify the overlays for the actual hardware you want to use, e.g robotics cape,

Re: [beagleboard] Re: More pimux woes

Thanks Robert, I won’t be back in front of my BBB till Monday now but I’ll be sure to test it first thing. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this

Re: [beagleboard] Re: More pimux woes

Top man, thanks for taking care of this. Let me know when it gets pushed up and i'll re-run apt update On Friday, 19 January 2018 16:17:21 UTC, RobertCNelson wrote: > > On Fri, Jan 19, 2018 at 5:45 AM, Hugh Frater <hugh@gmail.com > > wrote: > >>> > >>

[beagleboard] Re: More pimux woes

> > >> Running: > > sudo apt update ; sudo apt install bb-cape-overlays > > Has fixed the eqep errors and the clash between p9_26 and p8_24 that I was > seeing - however, pru_ecap has now gone as a mode for p9_42 - argggh > I see from the most recent commit that this has been added back

[beagleboard] Re: More pimux woes

On Thursday, 18 January 2018 12:53:59 UTC, Hugh Frater wrote: > > I've been trying to get my test hardware back up and running after > corrupting node and bonescript, see my earlier post. > > I'm trying to get up and running with an 8.6 image as I couldn't get a 9.2 >

[beagleboard] More pimux woes

I've been trying to get my test hardware back up and running after corrupting node and bonescript, see my earlier post. I'm trying to get up and running with an 8.6 image as I couldn't get a 9.2 image to provide pru_rproc support debian@beaglebone:~$ uname -r 4.4.54-ti-r93 I'm trying to get

Re: [beagleboard] pru_rproc on latest Stretch IoT image

On Wednesday, 17 January 2018 10:41:56 UTC, Hugh Frater wrote: > > >>>> >>> Robert, thanks for the input so far. I had just come across this post >>> >>> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc >>>

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

On Wednesday, 17 January 2018 12:37:03 UTC, Hugh Frater wrote: > > > > On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote: >> >> It looks like we are good-to-go. Thanks for sorting this out guys :) >> >> Hugh >> >> On Wednesday,

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote: > > It looks like we are good-to-go. Thanks for sorting this out guys :) > > Hugh > > On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote: >> >> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater

Re: [beagleboard] pru_rproc on latest Stretch IoT image

> > >>> >> Robert, thanks for the input so far. I had just come across this post >> >> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc >> >> * >> >> And tried the steps you outlined in

Re: [beagleboard] pru_rproc on latest Stretch IoT image

On Tuesday, 16 January 2018 16:00:33 UTC, Hugh Frater wrote: > > > > On Tuesday, 16 January 2018 15:52:23 UTC, RobertCNelson wrote: >> >> > Gotcha - here is the output after correcting /boot/uEnv.txt: >> > >> > debian@beaglebone:~$ sudo /opt/s

Re: [beagleboard] pru_rproc on latest Stretch IoT image

On Tuesday, 16 January 2018 15:52:23 UTC, RobertCNelson wrote: > > > Gotcha - here is the output after correcting /boot/uEnv.txt: > > > > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh > > [sudo] password for debian: > > git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]

Re: [beagleboard] pru_rproc on latest Stretch IoT image

On Tuesday, 16 January 2018 15:08:51 UTC, RobertCNelson wrote: > > > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh > > > kernel:[4.4.91-ti-r133] > > > > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo] > > > > > I edited this line: > > >

Re: [beagleboard] pru_rproc on latest Stretch IoT image

On Tuesday, 16 January 2018 14:56:03 UTC, RobertCNelson wrote: > > On Tue, Jan 16, 2018 at 8:12 AM, Hugh Frater <hugh@gmail.com > > wrote: > > I broke my installation (screwed up node.js and bonescript versions, > stuff > > went bad) so re-flashed my test ha

[beagleboard] pru_rproc on latest Stretch IoT image

I broke my installation (screwed up node.js and bonescript versions, stuff went bad) so re-flashed my test hardware with the latest Stretch IoT image... I'm now figuring out how U-Boot overlays work, which seem pretty straightforward, just a few changes in uEnv.txt... How the heck do I get

[beagleboard] Timers, interrupts and other such delights

I have a mechatronic device which has a couple of 'jog' buttons, these are working nicely on a interrupt. The interrupt code fires on level change then checks the value - corresponding code sections send a command to the PRU via /dev/rpmsg_pru31. Part of the command sent is a numeric value

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

problem is in your PRU code. > > Saludos, > Nahuel Greco. > > On Fri, Oct 27, 2017 at 5:30 PM, Hugh Frater <hugh@gmail.com > > wrote: > >> I know the stream is transmitting OK, my PRU code reacts as expected to >> the messages I'm sending over. I

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

d cat'ing the device to see if the characters > are shown. What's the value of the 'data' received in the callback? > > > Saludos, > Nahuel Greco. > > On Fri, Oct 27, 2017 at 11:05 AM, Hugh Frater <hugh@gmail.com > > wrote: > >> Hi Nahuel, >> >&g

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

any data? do you have a github repo > with a complete sample? > > Saludos, > Nahuel Greco. > > On Mon, Oct 9, 2017 at 1:11 PM, Hugh Frater <hugh@gmail.com > > wrote: > >> Does anyone have any experience of working with /dev/rpmsg_pruXX files >>

[beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

Does anyone have any experience of working with /dev/rpmsg_pruXX files from within Node.Js/Bonescript? I've been playing around with the file-duplex package and have data going into the PRU just fine, but I'm having an issue getting data back into my userspace program. I've got the

Re: [beagleboard] pru-rproc failing on boot, working manually

2017 15:27:34 UTC+1, RobertCNelson wrote: > > On Thu, May 18, 2017 at 5:54 AM, Hugh Frater <hugh@gmail.com > > wrote: > > Despite googling the heck out of this simple problem, I can't find > > anything... > > > > Problem is: > > > > [

[beagleboard] pru-rproc failing on boot, working manually

Despite googling the heck out of this simple problem, I can't find anything... Problem is: [ 34.358783] remoteproc1: 4a338000.pru1 is available [ 34.358802] remoteproc1: Note: remoteproc is still under development and considered experimental. [ 34.358811] remoteproc1: THE BINARY

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

It looks like we are good-to-go. Thanks for sorting this out guys :) Hugh On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote: > > On Wed, May 10, 2017 at 10:20 AM, Hugh Frater <hugh@gmail.com > > wrote: > > Thanks guys, I'll keep an eye on the repository

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

dp7...@gmail.com > > wrote: > > I actually ran into this too recently and have modified > > cape-universala-00A0.dts to enable pins P8_33 and P8_35 for eqep1: > > https://github.com/beagleboard/bb.org-overlays/pull/46 > > > > Thanks > > Drew > > > &

[beagleboard] Re: eQEP1 setup problems with latest debian iOT

Found it - cape-universal doesn't support eqep1, this was added to cape-universalh 4 months ago but the code wasn't merged into cape-universal. I will look at doing this now. On Wednesday, 10 May 2017 10:20:56 UTC+1, Hugh Frater wrote: > > Anyone? > > On Thursday, 20 April 2017 15

[beagleboard] Re: eQEP1 setup problems with latest debian iOT

Anyone? On Thursday, 20 April 2017 15:01:07 UTC+1, Hugh Frater wrote: > > Following on from my earlier messages related to this, I am using > cape-universal now to setup and control the pins for my mechatronics > project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2

[beagleboard] eQEP1 setup problems with latest debian iOT

Following on from my earlier messages related to this, I am using cape-universal now to setup and control the pins for my mechatronics project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2 on P8_11, P8_12 and P8_16 is working, but I can't get config-pin to setup eQEP1 on P8_31,

[beagleboard] Re: Custom device overlay or cape-universal - decisions...

and eqep2b. monitoring this from /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups Perhaps I'll just use those 2 overlays to configure the eqeps and do everything else in a cut down version of my custom overlay... On Wednesday, 29 March 2017 11:51:58 UTC+1, Hugh Frater wrote: > > Ok, l

[beagleboard] Re: Custom device overlay or cape-universal - decisions...

this? On Tuesday, 28 March 2017 17:07:16 UTC+1, Hugh Frater wrote: > > Hi everyone, I'm building a custom piece of mechatronics as part of my day > job. We have a custom interface cape laid out (it doesn't have an eeprom) > and I've mapped out the 16 lines we need to go back to the BBB. I'v

[beagleboard] Custom device overlay or cape-universal - decisions...

Hi everyone, I'm building a custom piece of mechatronics as part of my day job. We have a custom interface cape laid out (it doesn't have an eeprom) and I've mapped out the 16 lines we need to go back to the BBB. I've written a custom device tree for these lines which compiles with dtc fine,

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

I was getting weird values - it turns out I didn't correctly understand how to use pin-config & the universal overlay. When I configured the pins correctly, everything works. On Friday, 3 February 2017 21:18:35 UTC, Drew Fustini wrote: > > On Fri, Feb 3, 2017 at 6:02 AM, Hugh Fr

Re: [beagleboard] eQEP not reading meaningful values

I got it to work properly in 4.4.x - using the universal cape and running config-pin P8_11 qep & config-pin P8_12 qep On Friday, 3 February 2017 16:55:42 UTC, abhilash h wrote: > > For sure it will work. > On Fri, 3 Feb 2017 at 9:33 PM, Hugh Frater <hugh@gmail.com > >

Re: [beagleboard] eQEP not reading meaningful values

I'll give 7.9 a go and let you know my findings, thanks. On Friday, 3 February 2017 13:40:05 UTC, abhilash h wrote: > > I had used debian 7.9 > On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater <hugh@gmail.com > > wrote: > >> Thanks, I'm currently trying to downgrade to

Re: [beagleboard] eQEP not reading meaningful values

On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater <hugh@gmail.com > > wrote: > >> Hi Abhilash, >> >> That's interesting, I will try and downgrade. May I ask what image you >> are using now (Angstrom, Debian etc)? >> >> Hugh >> >> >>

Re: [beagleboard] eQEP not reading meaningful values

; swutched back to 3.8 kernel . > > On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater <hugh@gmail.com > > wrote: > >> Hi, I'm getting started on a control system that needs to read 2x >> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is >&g

[beagleboard] eQEP not reading meaningful values

Hi, I'm getting started on a control system that needs to read 2x quadrature encoders. One is a 1000 line, the other a 2000 line, but that is really immaterial. I have the physical interface sorted (one needs a 26lv32 to glue it to the BBB, the other is open collector), and the traces look

[beagleboard] Re: eQEP on 4.4.19-ti-r41

Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 - but for different reasons Hugh On Wednesday, 14 September 2016 21:22:06 UTC+1, Mark A. Yoder wrote: > > Hi: > I'm running BeagleBoard.org Debian Image 2016-08-28 which is running > the 4.4.19-ti-r41 kernel. I've