[beagleboard] Re: uart1 works via serial debugger, but not via UART1_TXD P9_24 pin

Hi Andrey, did you try a 3V3 connection (J1 is 5V, the other UARTs are 3V3). Regards -- 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 stop receiving

[beagleboard] Re: ds18b20 with BBGW

*@Sebastián SáezPerhaps you're ready to *test* the li <http://users.freebasic-portal.de/tjf/Projekte/libpruw1/doc/html/ChaMonitor.html>* b <http://users.freebasic-portal.de/tjf/Projekte/libpruw1/doc/html/ChaMonitor.html> <http://users.freebasic-portal.de/tjf/Projekte/li

[beagleboard] Re: PWM generation using libpruio

Hi! Am Mittwoch, 30. November 2016 06:30:41 UTC+1 schrieb Akshay Gahlot: > > I want to use for PWM generation to control servo motor. The problem i m > facing is : > > To enable libpruio i m using this dts file > >

[beagleboard] Re: PWM generation using libpruio

Hi! Am Mittwoch, 30. November 2016 06:30:41 UTC+1 schrieb Akshay Gahlot: > > I want to use for PWM generation to control servo motor. The problem i m > facing is : > > To enable libpruio i m using this dts file > >

[beagleboard] Re: BeagleBone Green Wireless

Hi James! You neither need a Grove Cape nor any other additional hardware. Just configure header pins as GPIO input with pull-up resistor and connect simple buttons to pull the pins down to ground when pressed. Check out the button example <http://users.freebasic-portal.de/tjf/Proje

[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

Am Dienstag, 1. November 2016 18:20:02 UTC+1 schrieb RobertCNelson: > > On Tue, Nov 1, 2016 at 5:08 AM, Pantelis Antoniou > wrote: > > Hi Robert, > > ... > > I should have something for this in the next couple of week or so. > > > > Heavy rework, and I’d

[beagleboard] Re: implement ADC using mmap

Am Montag, 24. Oktober 2016 21:31:14 UTC+2 schrieb Akshay Gahlot: > > It's great that it is compatible with libpruio. > I said it "seems to be". I don't know it and didn't test yet. > Any suggestion on how to setup the serial communication along with > libpruio. > Thanks in advance. > I

[beagleboard] Re: implement ADC using mmap

Am Montag, 24. Oktober 2016 21:01:48 UTC+2 schrieb Akshay Gahlot: > > I am using a velocity controller which work on the input of encoders and > communicates with BeagleBone using *serial communication*, It's library > was designed by the company for ARDUINO ( >

[beagleboard] Re: implement ADC using mmap

Am Montag, 24. Oktober 2016 19:01:56 UTC+2 schrieb Akshay Gahlot: > > Is this library compatible with "wiringBone" : > https://github.com/AbhraneelBera/wiringBone as other components of my > project are dependent on wiring bone. > Which components do you miss? I don't know that project. The

[beagleboard] Re: implement ADC using mmap

reebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html> are included in the package. Regards. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsub

Re: [beagleboard] Time beween pulses

(C syntax) in libpruio <http://beagleboard.org/project/libpruio/> package, documentation here <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaPwmCap> . Regards -- For more options, visit http://beagleboard.org/discuss --- You received thi

[beagleboard] Re: gdbserver shared library PRU loader

Am Donnerstag, 13. Oktober 2016 10:42:13 UTC+2 schrieb Jelle Spijker: > > The PRU program is genereted in C with the CCS IDE, the compiler is TI > V2.1.2 en the linker command file is AM335x_PRU.cmd > That doesn't work. You'd have to extract the .text section from that file and load only that

[beagleboard] Re: gdbserver shared library PRU loader

Am Donnerstag, 13. Oktober 2016 09:16:31 UTC+2 schrieb Jelle Spijker: > > When I run the test as a normal user and output the return values to the > cout it returns > prussdrv_init returns: 0 > prussdrv_open returns: -1 > Segmentation fault (core dumped) > > I'm not sure ATM. It may also need

[beagleboard] Re: gdbserver shared library PRU loader

Just found another issue: Am Mittwoch, 12. Oktober 2016 15:05:12 UTC+2 schrieb Jelle Spijker: > > Fragment of the Shared library: > > void BBB::loadPRUfirmware(const unsigned int , const std::string > ) { > //Initialize structure used by prussdrv_pruintc_intc > tpruss_intc_initdata

[beagleboard] Re: gdbserver shared library PRU loader

Hi! Am Mittwoch, 12. Oktober 2016 15:05:12 UTC+2 schrieb Jelle Spijker: > > Hi All, > > I'm running Arch Linux on my BBB, so no remoteproc for me :-( when working > with the PRU. > > You're lucky, you didn't waste time for testing remoteproc. > Because I work with prussdrv the program should

[beagleboard] Re: High speed encoder input capability of BBB?

Am Donnerstag, 6. Oktober 2016 16:20:39 UTC+2 schrieb beezerlm: > > I didn't use JTag yet. And I don't use the bloated TI tools. Instead I use >> the lightweight pasm assembler and uio_pruss driver. > > > What do you mean by "bloated"? Do you think my CCSv6/Jtag approach is > overly

[beagleboard] Re: High speed encoder input capability of BBB?

Hi beezerlm! Am Mittwoch, 5. Oktober 2016 18:11:18 UTC+2 schrieb beezerlm: > > Well I have obtained a BBB along with the PRU cape. I soldered the Jtag > header on and I purchased a blackhawk XDS100v2 JTAG Emulator. I istalled > CCSv6 and I have completed the PRU labs 1 through 4 - found here:

[beagleboard] Re: Trying to run the ADC from the PRU

Am Freitag, 23. September 2016 18:11:57 UTC+2 schrieb Phil: > > A question though: Under what circumstances would the ADC not start? > Thunderstorm, lightning, cosmic rays, ... hardware damage. I don't know. In any case it's better to stop with an error message, than configuring a subsystem

[beagleboard] Re: Trying to run the ADC from the PRU

Hi Phil! Your code is incomplete. The error handling is missing, for the case that the ADC subsystem doesn't come up. Your code just continues. Am Mittwoch, 21. September 2016 18:13:59 UTC+2 schrieb Phil: > > *PRU Code* > // >

[beagleboard] Re: Want to PRU binary using prussdrv_exec_program - Can't seem to get .bin file loading on PRU

Why don't you use pasm assembler from am335x_pru_package ? It's reliable, fast, has better syntax and the resulting bin files are loading directly by prussdrv functions. Regards -- For more options, visit http://beagleboard.org/discuss ---

[beagleboard] Re: Trying to run the ADC from the PRU

Am Donnerstag, 15. September 2016 23:26:24 UTC+2 schrieb Phil: > > (1) I know this because I tried reading the ADC REVISION register using > the PRU and got zero as a result. > It takes some cycles before the ADC is up and running. Check the ID register several times. In libpruio it works

Re: [beagleboard] Re: Remote Proc and examples to fill PRU data memory, store/read data in PRU shared memory

Hi Paul! Am Mittwoch, 14. September 2016 12:45:04 UTC+2 schrieb paulandre...@gmail.com: > > Chris, yes uio_pruss/prussdrv examples seem to give me better control > than Remote Proc/RpMsg, I am thinking of trying to rebuild the kernel with > the pruss_io kernel objects instead, then use

[beagleboard] Re: High speed encoder input capability of BBB?

Am Sonntag, 11. September 2016 21:28:52 UTC+2 schrieb beezerlm: > > Hi TJF, > > So basically the libpruio is a driver that makes it easier to access > the PRU and assign I/O and create a subsystem program loop? Is that > correct? What would be the downside of using t

[beagleboard] Re: High speed encoder input capability of BBB?

Hello beezerim! Am Sonntag, 11. September 2016 02:22:54 UTC+2 schrieb beezerlm: > > Is this within the capabilities of the BBB? > Yes, it is. As Charles mentioned, the BBB CPU has three PWM subsystems. Each of them contains one eQEP module. The modules are clocked at 100 MHz, so they can

[beagleboard] Re: Trying to run the ADC from the PRU

Hi Phil! After boot the ADC subsystem is disabled by default. You have to enable the CM_WKUP_ADC_TSC_CLKCTRL register in the CONTROL MODULE before you can use it: mov r0, 0x44E004BC mov r1, 2 sbbo r1, r0, 0, 4 Place this snippet after OCP enbled and before any ADC register access. Regards

[beagleboard] Re: Trying to run the ADC from the PRU

Hi Phil! After boot the ADC subsystem is disabled by default. You have to enable the CM_WKUP_ADC_TSC_CLKCTRL register in the CONTROL MODULE before you can use it: mov r0, 0x44E004BC mov r1, 2 sbbo r1, r0, 0, 4 Place this snippet after OCP enabled and before any ADC register access. Regards

[beagleboard] Re: adc code in BBB

Check out libpruio examples: - Simple <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaSimple> - IoInput <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaIoInput> - PwmAd

[beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

Hi Matthew! Am Freitag, 12. August 2016 06:15:51 UTC+2 schrieb matthew...@daf.qld.gov.au: > > Hi TJF, > Now that is really interesting. I was just thinking about using the PRU's > for the job > ... > What do you think? Maybe I don't need the mbed after all. > At my so

[beagleboard] Re: Halt or reboot ...

Hi Philippe! Am Freitag, 5. August 2016 18:13:28 UTC+2 schrieb philippe.frossard: > > Is there a way to know if the system halt or reboot ? There're several ways, depending on the operating system working on your board. Usually current boards ship with Debian Linux. Check the output of

Re: [beagleboard] One Wire Device Tree

Hello Mark! Am Dienstag, 2. August 2016 16:33:56 UTC+2 schrieb Mark A. Yoder: > > Robert: > When I do: > echo BB-W1-P9.12 > $SLOTS > I get the following dmesg: > [Aug 2 10:25] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.12', > version 'N/A' > [ +0.71] bone_capemgr bone_capemgr: slot

[beagleboard] Re: AM335x unable to initialize ECAP0 from userspace

ard.org/project/libpruio/>. It drives the eCAP modules in PWM mode. Check out the examples pwm_cap <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaPwmCap> or pwm_adc <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_ex

[beagleboard] Re: Serial Communication with BBB

Hi Dror! Am Sonntag, 31. Juli 2016 13:17:41 UTC+2 schrieb Dror Lugasi: > > hey guys, > i am new to BBB and i need to use it for serial communication: reading > data from IMU and controlling motor drivers according to the readings. > > what is the best (easiest and fastest) way to do this? > >

Re: [beagleboard] Re: Web control for BBB based device

Am Mittwoch, 27. Juli 2016 07:11:24 UTC+2 schrieb William Hermans: > > Additionally you may wish to start reading about, and understanding what a > "web appliance" *is*. > Didn't you read the initial post? This isn't the issue here. The Question is Device should be controlled via Web

Re: [beagleboard] Web control for BBB based device

Am Dienstag, 26. Juli 2016 21:58:59 UTC+2 schrieb john3909: > > The downside to this solution is that it doesn’t scale very well. Using > Nodejs and Angularjs, you can support 100s of simultaneous sessions on the > BBB. > "100s of simultaneous sessions" are not required here (yet). The

[beagleboard] Re: Web control for BBB based device

Am Dienstag, 26. Juli 2016 19:05:53 UTC+2 schrieb ivbsd1: > > Hi TJF, > > Thanks a lot for suggestions. But, if possible, can you make it more clear > ? > If possible, can you give me a reference to project of such type ? > Broadway is a GDK (= sub-layer of GTK) b

[beagleboard] Re: Web control for BBB based device

Hi! You don't need any web framework. Write a simple GTK application and use the Broadway backend to run the GUI in any HTML-5 browser window. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

Am Donnerstag, 21. Juli 2016 07:35:23 UTC+2 schrieb john3909: > > Why not use the A & B suffix? Surely this just needs modification to your > regular expressions? > Just renaming doesn't solve the issue. There's just one P9_42 and the features of P9_92 should get merged in to this pin. Check

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

Am Mittwoch, 20. Juli 2016 21:36:59 UTC+2 schrieb john3909: > > Looking at: > > > https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin > >

[beagleboard] Re: cape-universal & 4.1.x = default.. ;)

Hi William! Am Dienstag, 19. Juli 2016 19:54:02 UTC+2 schrieb William Hermans: > > SO, after talking with Robert and finding that all these kernel modules > that get loaded from cape_universal=enable. I wonder how this impacts other > capes such as the Logic supply RS232 / CAN cape that

Re: [beagleboard] Microphone Bias Voltage Level

Hi! Am Freitag, 15. Juli 2016 00:33:44 UTC+2 schrieb keerthana@gmail.com: > > I'm looking to use an electret microphone with a beaglebone black for my > project. Can't I directly plug the mic into an analog pin and use the data? > Do I need a pre amplifier circuit kind of thing to use the

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

we could find a solution for the config part together (no BBW nor BBG for testing here). If you agree, just send your response to either the email adress here, or (prefered) the one in the documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_changelog.html#SecFur

[beagleboard] Trouble with SSH over eth0, kernel 4.4.14-ti-r34

Hi all! On a BBB Rev C with kernel 4.4.14-ti-r34 (console image) I have trouble with SSH connection over eth0. The PC blocks, while the BBB is running, but emitting the following error message in dmesg omap_hwmod: davinci_mdio: wait_target_ready failed: -16 cpsw 4a10.ethernet eth0: Link

[beagleboard] Re: 4.4.x-ti kernel with rproc & uio (r34)

I forgot to mention: the line wrapping is confusing here Am Mittwoch, 6. Juli 2016 16:56:13 UTC+2 schrieb RobertCNelson: > > Step 2: > > Install dtb-rebuilder: > > git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder > dtb-4.4-ti

[beagleboard] Re: 4.4.x-ti kernel with rproc & uio (r34)

@John BTW, I added TJF to the list since his persistence lead us to this > solutions. > Thank you! Am Mittwoch, 6. Juli 2016 16:56:13 UTC+2 schrieb RobertCNelson: > > Okay, starting with r34, (4.4.14-ti-r34/4.4.14-ti-rt-r34) > > You can swap between rproc and uio for the pr

[beagleboard] Re: beaglebone black pwm pin can't find duty, period, ...

Hi Ray! Am Samstag, 2. Juli 2016 18:34:54 UTC+2 schrieb Ray Madigan: > > Any guidance would be appreciated. > You could use libpruio . Your code will execute faster than any sysfs solution and it's more easy to use (single source, no user device tree).

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

e option. > Rick Mann > It sure seems to me that if both can exist in the source tree and be > selected at runtime with configuration (ideally via device tree, > switchable later by loading and unloading modules) ... > TJF > I'd try to make both optional and choise in device

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Good morning John! Am Mittwoch, 29. Juni 2016 17:07:05 UTC+2 schrieb john3909: > > What a silly argument. It is well known that when you don’t have physical > security, you don’t have any security. Once you can replace the storage > media, you can make the hardware do whatever you want. This is

Re: [beagleboard] PRU Pattern bigger than 8k

Just found another problem: Am Mittwoch, 29. Juni 2016 18:47:38 UTC+2 schrieb TJF: > > (sequence Data is my array of data store define as is : > >> unsigned int sequenceData[NUMBER_DATA]; >> > > Don't dim an array, use a pointer instead unsigned int *sequenceData;

Re: [beagleboard] PRU Pattern bigger than 8k

Am Mittwoch, 29. Juni 2016 18:25:45 UTC+2 schrieb Vincent lc: > > Here it was to ask you how will you load the data in assembly because I'm > guessing that you advise me to do it with LBBO (LBBO > REG1,Rn2,OP(255),IM(124)) , > And I know my REG1 because it will be what I will receive from this

Re: [beagleboard] PRU Pattern bigger than 8k

... Note: the ERam has a default size of 256 kB. In order to get 1 MB, you'll have to load the driver manually (8 MB max.). See this documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_memory.html> (section ERam at the bottom) for details. BR -- F

Re: [beagleboard] PRU Pattern bigger than 8k

ll have to load the driver manually (8 MB max.). See this documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_memory.html> (section ERam at the bottom) for details. BR -- For more options, visit http://beagleboard.org/discuss --- You received this messag

Re: [beagleboard] PRU Pattern bigger than 8k

a default size of 256 kB. In order to get 1 MB, you'll have to load the driver manually (8 MB max.). See this documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_memory.html> (section ERam at the bottom) for details. BR -- For more options, visi

Re: [beagleboard] PRU Pattern bigger than 8k

the driver manually (8 MB max.). See this documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_memory.html> (section ERam at the bottom) for details. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Good morning John! Am Dienstag, 28. Juni 2016 17:48:24 UTC+2 schrieb john3909: > > It is hard to keep up with your changing priorities. > My priorities are 1. Security 2. Speed 3. Resources That didn't change for years. What you mean is that my focus changed in this discussion.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

NOW*. Loadable module, that can play nice with the rest of the > module world. Then mark it as experimental. Worry about the actual > remoteproc implementation after that. BR @John If RPMSG implements mmap(), then we might have a solution that should works > for TJF. > Y

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John3909: Am Montag, 27. Juni 2016 11:19:13 UTC+2 schrieb john3909: > > While I haven’t tried this, I don’t believe there is anything in the > RemoteProc/RPMSG framework that prevents you from doing this now. You can > still use RemoteProc to load/start/stop your PRU firmware and you don’t >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John3909: Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: > > It makes no sense to discuss that in detail here, since you obviously have > no idea on rapid prototyping controllers. (I can give you a private lesson > if you like.) > On the contrary, perhaps you should explain the use

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John3909: Am Samstag, 25. Juni 2016 21:53:10 UTC+2 schrieb john3909: > > Why don’t you use the “bone” kernel which pruss_uio as default. > That's what I do. > The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you > problem here. > There'll be no more problem when we

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John: ... so what do you want removed? There is nothing left to be removed. > I want removed: pru_rproc 12632 0 pruss_intc 7223 1 pru_rproc Do you remember, that's the main topic in this discussion? I think TJF is confusing throughput with latency. F

Re: [beagleboard] PRU Pattern bigger than 8k

@John: ... so what do you want removed? There is nothing left to be removed. > I want removed: pru_rproc 12632 0 pruss_intc 7223 1 pru_rproc Do you remember, that's the main topic in this discussion? I think TJF is confusing throughput with latency. F

[beagleboard] Re: PRU Pattern bigger than 8k

Hello Vincent! Am Donnerstag, 23. Juni 2016 12:55:01 UTC+2 schrieb Vincent lc: > > However, the time to load 8k data into the ram is really high, it takes > between 3 to 8 s to do so. > Can you please explain that? Which code do you use to load the DRam? How do you measure the time? -- For

[beagleboard] Re: Capture one Analog channel in continuous mode at near maximum speed?

Hello Stewart! Am Montag, 20. Juni 2016 21:29:43 UTC+2 schrieb Stewart: > > (None of the libpruio built-in examples deal with rapid sampling or large > amounts of data.) > Next libpruio version contains an example called rf_file, which will exactly do want you target. It uses the ring buffer

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

Am Montag, 20. Juni 2016 18:09:36 UTC+2 schrieb john3909: > > It is simply a device address and a label. The driver needs this > information, so you can either hard code it (not a good idea because it > leads to duplicate code) or you can define it in the device tree. Same > thing for gpio

Re: [beagleboard] disable edid (hdmi, rgb video output)

Am Sonntag, 19. Juni 2016 00:18:00 UTC+2 schrieb epi kao: > > thanks, and yes i already knew this link. > But there is only explained how to read (for debug) the EDID infos. That > is not really usefull. I need more functions as only resolution and refresh > rate > > So it seems that with

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Hi Suman, thanks for your statements. [Suman: Where do you use this from, I assume userspace? Using what - Shared > DRAM or regular PRU DRAM.] > Yes, libpruio is a userspace library. I'm not familiar with your terminologie: Shared DRAM = SRam (12k@0x1) and PRU DRAM = DRam

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@John Syne: Correct, remoteproc is stabil since month. Stabil in the point that it isn't usable. And that's why it is and it should be experimental. And experimental features shouldn't polute the main stream images! @Jason Reeder and Suman Anna: Thanks for joining that discussion and for

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Hi John! Yes, you're right. The task is to load or reload firmware to the PRUSS and run it, controlled by host software executing under user privilegues. Prussdrv fulfills this task, the other doesn't. So I compared apples and oranges. Apples and oranges shouldn't go into the same

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Am Mittwoch, 15. Juni 2016 23:47:11 UTC+2 schrieb Jason Kridner: > > How is it nonsense? There's no realistic concept up to now. Significant changes every now and then, like the one documented here. Some developers may see some advantages anytime in the future, at least if they use the

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Am Mittwoch, 15. Juni 2016 14:35:12 UTC+2 schrieb Jason Kridner: > > Anyone look at migrating these into the > http://github.com/beagleboard/am335x_pru_package > >

[beagleboard] Re: trouble with image bone-debian-8.5 / 2016-06-05

Thanks for your answer, Rahul. Unfortunatelly you didn't understand the problem. In the path you mentioned, the bone-pinmux-helper looks for a node named interrupt-controller@4820 and failed to find it, obviously because its name is now 4820.interrupt-controller This has to get

[beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

capemgr doesn't load device tree overlays: dmesg reports ... [ 200.132514] bone-pinmux-helper ocp:pruio-08: could not find pctldev for > node /ocp/interrupt-controller@4820, deferring probe > but node name is ocp/4820.interrupt-controller -- For more options, visit

[beagleboard] Re: Board-customization

Hi Eric! I guess you mean ESP8266. You'll not need to customize the BBB. Just connect an Esp module to the BBB headers and use a serial port for communication. The pins depend on the serial port in use. I recommend UART-4. The following commands work on a 'bone' kernel supporting the capemgr:

[beagleboard] Re: Set a registers bit according to another registers bit PRU

None of the codes will work, since the last executed instruction is always CLRr29.t1 in the first code or SETr29.t1 in the second code. This will always clear or set the bit, independend from r0.t0. Either use QBBS SENDHIGH, r0.t0 CLR r29.t1 JMP Finish SENDHIGH: SET

[beagleboard] Re: Set a registers bit according to another registers bit PRU

None of the codes will work, since the last executed instruction is always CLRr29.t1 in the first code or SETr29.t1 in the second code. This will always clear or set the bit, independend from r0.t0. Either use QBBS SENDHIGH, r0.t0 CLR r29.t1 JMP Finish SENDHIGH: SET

[beagleboard] Re: Set a registers bit according to another registers bit PRU

r29.t1 Finish: But, does this simple solution don't work? MOV r29.t1, r0.t0 Am Sonntag, 22. Mai 2016 18:06:00 UTC+2 schrieb TJF: > > None of the codes will work, since the last executed instruction is always > CLRr29.t1 > in the first code or > SETr29.t1 >

[beagleboard] Re: Set a registers bit according to another registers bit PRU

None of the codes will work, since the last executed instruction is always CLRr29.t1 in the first code or SETr29.t1 in the second code. This will always clear or set the bit, independend from r0.t0. Either use QBBS SENDHIGH, r0.t0 CLR r29.t1 JMP Finish SENDHIGH: SET

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Arend, thanks for the detailed installation guide/protokol. It's looking good. Full sure, it'll help BBG users to adapt the code. And all BBx users find information on how to fix the ADC sampling rate limitation. Two notes: 1. You need not disable UART2 for BBG. Instead you can disable

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Arend, thanks for the detailed installation guide/protokol. It's looking good. Full sure, it'll help BBG users to adapt the code. And all BBx users find information on how to fix the ADC sampling rate limitation. Two notes: 1. You need not disable UART2 for BBG. Instead you can disable

[beagleboard] Re: 1 Wire device with universal overlay

Why don't you adapt the 1-wire overlay? It should be easy to use a pin not connected to any PWMSS. Ie. use P9_11 or P8_07. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To

[beagleboard] Re: PRU Cross compile with libpruio

Fine, thanks for the info! But you cannot test nor debug on the PC, right? -- 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 stop receiving emails from

[beagleboard] Re: Second 1-wire

You can use the broadcast triggering, but you need an other driver (or you have to adapt the existing). Ie. you can use *owfs, *which needs additional hardware. This hardware also supports long cable networks. In my case I want to avoid extra hardware (for maintenance reasons). So I made a

Re: [beagleboard] Re: 1-Wire

Check out man pages for - lsmod: list loaded kernel modules - modprobe: load or unload modules BR -- 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

[beagleboard] Re: Second 1-wire

1.) The cable radius is the same, regardless if you use one or two pins for the W1 bus. So it only makes a difference regarding the cable weight, wich isn't as critical as the radius. 2.) To speed up the conversation time trigger all sensors by a broadcast message. After a delay of 750 ms you

Re: [beagleboard] Re: 1-Wire

What happens when you pass the parameter at module load time? (In order to test, unload the kernel driver and reload with option w1_max_slave_count=30 ) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

[beagleboard] Re: 1-Wire

Am Donnerstag, 28. April 2016 19:40:19 UTC+2 schrieb hoerting...@gmx.at: > > Hello! > > *1. Max sensors* > When I try: > echo 20 > w1_master_max_slave_count > > I get: > bash: w1_master_max_slave_count: Permission denied > (of course I´m root > sudo su echo 20 > w1_master_max_slave_count exit

[beagleboard] Re: 1-Wire

Hi! Am Donnerstag, 28. April 2016 15:52:40 UTC+2 schrieb hoerting...@gmx.at: > > Hello, > > I want to use 1-wire DS18B20+ sensors with the BBB. > On my breadcrump is work with 2 sensors. > > My question: > with: > cat w1_bus_master1/w1_master_max_slave_count > he show me max 10 sensors ... why? >

[beagleboard] Re: Fast Pin Toggling Using MMAP

Hi Frank! Your example controls one GPIO subsystem. The pins P9_11 to P9_18 are connected to two GPIO subsystems. That's why you cannot control all pins at 2.6 MHz. You'll have to find a set of pins connected to a single GPIO subsystem (either GPIO0 or GPIO1). As John mentioned, this is stuff

[beagleboard] Re: Is is possible to communicate over serial (big USB ) between BBB and Teensy 2.0?

Hi! You can execute dmesg | grep tty in order to get information on the serial ports. You'll find lines like [...] 481a8000.serial: *ttyS4* at MMIO 0x481a8000 (irq = 187, base_baud = 300) is a 8250 which informs about the port used for a connection, ie. when you plug in the Teensy

[beagleboard] Re: I have a program running on boot that is preventing me from SSH'ing into the BBB.

When your system is booting from SD card, plug the card in a PC and rename the script on the card When booting from EMMC, what happens when you connect a monitor (HDMI), do you see a login prompt? If so, connect a keyboard and disable the service (or rename the script). -- For more options,

[beagleboard] Re: PRU Cross compile with libpruio

With Geany you can edit the code on your PC, load and save it over ethernet to the BBB. Then compile and test (and GDB for the ARM code) on the BBB via SSH. The kernel 4.x limitation is that the run-time pinmuxing does not work (since the paths in the sysfs changed). You can set the pins

[beagleboard] Re: PRU Cross compile with libpruio

Hi! Even if you find a way to cross compile, you cannot test on your VM since there's no PRU. So why not compile where you (have to) test? BTW: libpruio-0.2 has some limitations on kernel versions > 3.8 (due to sysfs changes). BR -- For more options, visit http://beagleboard.org/discuss ---

Re: [beagleboard] Re: beaglebone black PWM

Am Dienstag, 19. April 2016 12:00:25 UTC+2 schrieb Brainiac: > > any idea how can setup Geany on my BBB ??? i think it's the best and short > (time speaking) solution > Execute sudo apt-get install geany -- For more options, visit http://beagleboard.org/discuss --- You received this

[beagleboard] Re: beaglebone black PWM

org/project/libpruio/>. Once installed, it's very painless to configure (by single source) and to control (in a fast manner) the pins. It's written in FreeBASIC, but provides a C wrapper, so you can make your "master" happy. Check out some examples: ie. pwm_cap <http://users.free

[beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

Hi Matt! A year ago I started with those sensors and I didn't have trouble to connect them by the w1 kernel driver. But I don't remember what I did that time, because I dropped that solution. The kernel driver doesn't support broadcast messages and the sensors are triggered one after the

[beagleboard] Corintech Dataloggers

Hi all! Did anybody connect a Corintech Datalogger to a BB or any other Linux system yet? I don't want to use the cloud feature, just fetch the data packages from a BBB over local WLAN. There's no software for Linux from the manufacturer and I

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

Why don't you first load and start your PRU code and then load the overlay (or switch the pin mode) when the PRU is running? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Andrea! Am Mittwoch, 30. März 2016 23:07:55 UTC+2 schrieb a.toma...@brainsomeness.com: > > My mistake was to build only the FreeBasic library and not the one in the > folder `c_wrapper` > No mistake, a lucky find. Just use the matching compiler. > I have another question: I'm trying to

Re: [beagleboard] Re: How to read PWM in BBB GPIO....?

Am Mittwoch, 30. März 2016 17:34:58 UTC+2 schrieb Alex: > > So to do that we need to put the Pin PR1_ECAP0_ECAP_CAPIN_APWM_O > in input mode. > > Where can we find the source code of the libpruio doing that in the pru ? > libpruio doesn't use PR1_ECAP0_ECAP_CAPIN_APWM_O pin configuration.

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Andrea! It compiles OK, but the linker doesn't find the symbols (= doesn't find the binary libpruio.so). Where did you place the new binary? It should work when you override the original binary (ie. in /usr/local/lib). Otherwise you have to update the linker cache first: sudo ldconfig Or

[beagleboard] Re: How to read PWM in BBB GPIO....?

<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaPwmCap> . BR -- 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 gr

<    1   2   3   4   5   6   7   >