[beagleboard] Connecting NAND using GPMC - Partitions creation

2018-09-12 Thread LYB 
Hi.
I'm not sure that is the exact place to ask, but...
I'm trying to connect an external NAND to the GPMC pins. I updated the 
device tree for that, and the NAND is identified correctly.
Yet, later during the nand init, the partitions, as defined in the device 
tree, are not created.
I used to the same partitions definition on a different AM335x board, which 
used kernel version 3.x, while BBB uses now 4.14.x, and the NAND support 
code was changed a lot.
My device tree looks quite fine, as much as I can tell (see below).
Again, the nand works, it is being identified, all signals work correctly 
(had to remove one of the MMC's for that). the issue is linux creating 
partitions.
does any one have any clue about it?

_pinmux {
bbcape_nand_flash_pins: bbcape_nand_flash_pins {
pinctrl-single,pins = <
0x00 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad0.gpmc_ad0 */
0x04 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad1.gpmc_ad1 */
0x08 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad2.gpmc_ad2 */
0x0c (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad3.gpmc_ad3 */
0x10 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad4.gpmc_ad4 */
0x14 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad5.gpmc_ad5 */
0x18 (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad6.gpmc_ad6 */
0x1c (MUX_MODE0 | PIN_INPUT_PULLUP) /* gpmc_ad7.gpmc_ad7 */
0x70 (MUX_MODE0 | PIN_INPUT_PULLUP ) /* gpmc_wait0.gpmc_wait0 */
0x74 (MUX_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpmc_wpn */
0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_csn0.gpmc_csn0  */
0x90 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_advn_ale.gpmc_advn_ale */
0x94 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_oen_ren.gpmc_oen_ren */
0x98 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_wen.gpmc_wen */
0x9c (MUX_MODE0 | PIN_OUTPUT) /* gpmc_be0n_cle.gpmc_be0n_cle */
>;
};
};

 {
status = "okay";
};

 {
  status = "okay";
ranges = <0 0 0x0100 0x1000>; /* address range = 16MB (minimum GPMC 
partition) */
  nand@0,0 {
compatible = "ti,omap2-nand";
reg = <0 0 4>; /* device IO registers */
pinctrl-names = "default";
pinctrl-0 = <_nand_flash_pins>;
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
/* generic bindings */
nand-bus-width = <8>;
/* vendor specific bindings */
gpmc,device-width = <2>;
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <80>;
gpmc,cs-wr-off-ns = <80>;
gpmc,adv-on-ns = <0>;
gpmc,adv-rd-off-ns = <80>;
gpmc,adv-wr-off-ns = <80>;
gpmc,we-on-ns = <20>;
gpmc,we-off-ns = <60>;
gpmc,oe-on-ns = <20>;
gpmc,oe-off-ns = <60>;
gpmc,access-ns = <40>;
gpmc,rd-cycle-ns = <80>;
gpmc,wr-cycle-ns = <80>;
gpmc,wait-pin = <0>;
gpmc,wait-on-read;
gpmc,wait-on-write;
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
/* MTD partition table */
/* All SPL-* partitions are sized to minimal length
* which can be independently programmable. For
* NAND flash this is equal to size of erase-block */
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "NAND.SPL";
reg = <0x 0x0004>;
};
partition@1 {
label = "NAND.SPL.backup1";
reg = <0x0004 0x0004>;
};
partition@2 {
label = "NAND.SPL.backup2";
reg = <0x0008 0x0004>;
};
partition@3 {
label = "NAND.SPL.backup3";
reg = <0x000c 0x0004>;
};
partition@4 {
label = "NAND.u-boot-spl-os";
reg = <0x0010 0x0008>;
};
partition@5 {
label = "NAND.u-boot";
reg = <0x0018 0x0010>;
};
partition@6 {
label = "NAND.u-boot-env";
reg = <0x0028 0x0004>;
};
partition@7 {
label = "NAND.u-boot-env.backup1";
reg = <0x002c 0x0004>;
};
partition@8 {
label = "NAND.kernel";
reg = <0x0030 0x0070>;
};
partition@9 {
label = "NAND.file-system";
reg = <0x00a0 0x1f60>;
};
};
};



-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dc22655c-903a-4334-a9cb-bb9a55f5f43e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2018-09-12 Thread TJF 
Am Freitag, 9. Mai 2014 16:23:18 UTC+2 schrieb TJF:
>
>
> 
>

Version 0.6 is out now! Major highlights:

   1. Debian packages, easy installation
   2. Python bindings and examples available
   3. Advanced Pinmuxing: faster and unlimited
   
Click this link for details 
 
or check the online documentation. 


-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02f8813f-b2cf-460b-aee2-62ad091e1388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] ETL/BI Manual Tester (VA) (NO H1B)

2018-09-12 Thread naveen tripathi 
*ETL/BI Manual Tester *

· ETL Database Manual Testing experience 5+ years

· SQL querying experience

· Edifecs and Spec builder experience
-- 




*Naveen Tripathi*
* Technical Recruiter*

*Zenith tech Solutions*
* Desk: **518 621 0048* *Fax:* *518-244-4977* <518-244-4977>
*3 COMPUTER DR West,*

*Suite #107*

*ALBANY, NY 12205*

*naveen.tripa...@zenithtechsolutions.com *

*Hangout id: tripathi3...@gmail.com *



*DISCLAIMER:*
Note: This is not an unsolicited mail. Under Bill 1618 Title III passed by
the 105th USACongress this email cannot be considered as spam as long as we
include our contact information and an option to be removed from our
emailing list. If you have received this message in error or, are not
interested in receiving our emails, please accept our apologies.To be
removed from our mailing list, please reply with the subject line. All
removal requests will be honored ASAP. We sincerely apologize for any
inconvenience caused to you

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHo3s0F%2BSmmRWbs546aDe4NMA7RAdsok0joy3W4O9whQ0brZrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PocketBeagle PRU's not loading in Buildroot Image

2018-09-12 Thread Jaremy Creechley 
It's easiest to start off with the uboot overlay setup:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

And configure the pins as PRU pins:

http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/

Best, Jaremy



Jaremy Creechley
creech...@gmail.com
το ευαγγελιον


On Mon, Sep 10, 2018 at 6:08 AM  wrote:

> Hello PRU experts,
>
> Newcomers like myself struggle getting the PRUs enabled on PocketBeagle.
>
> (1) I've downloaded the image Debian 9.4 2018-06-17 4GB SD IoT
> 
>  from
> website (https://beagleboard.org/latest-images)
>
> Do we have steps of what to do from this clean installion point, that
> would allow me to toggle a GPIO pin using a PRU?
>
> Many Thanks,
> Brijen
>
>
>
> On Friday, March 30, 2018 at 9:24:25 PM UTC+1, Jaremy Creechley wrote:
>>
>>
>> I'm working on creating a variant of a Buildroot image using the
>> 4.9.82-ti-rt kernel (taken from @RCN's stretch/ sources) and modified to
>> use u-boot overlays. The buildroot image works well on the Beaglebone Green
>> (with the PRU's loading much quicker than the 4.4.x branch I'd used
>> previously using TI's recently modified `/sys/class/remoteproc/` scheme).
>>
>> The image also boots the PocketBeagle and loads `g_ether` and boots fine.
>> However, it does not load the PRU units and only loads `remoteproc0` [the
>> omap timer (?)]. There are no `/sys/class/remoteproc/` entries for either
>> of the PRU units. The kernel logs don't show anything, no errors, or
>> anything regard the PRU units (aside from remoteproc0).
>>
>> Based on the serial output from the BBG, the U-Boot version correctly
>> boots using U-Boot 2018.03. Also, the u-boot based cape manager loads on
>> both the BBG and PB boards after some tweaking with the uEnv.txt file.
>> Still I have not been able to get remoteproc to load the PRU units.
>>
>> Does anyone have any suggestions? Do I need to load another cape? I've
>> tried setting the 4-9 PRU dtbo in `uEnv.txt` to no avail.
>>
>> I've been reading through the DTS and DTSI sources in the Linux kernel as
>> well as the bb.org-overlays. It seems that the linux in-tree dtsi files for
>> the PocketBeagle don't mention the PRUSS hardware units at all. This is in
>> contrast to the BBB and BBG which both set the `status` field to "ok" for
>> both PRU units. My suspicion based on that is that the PRUSS and remoteproc
>> configurations aren't updated for the PB. The bb.org overlay's also do
>> not mention the PB at all that I've found. However, it appears that several
>> people have the PRU's loading and working on the PB's. Hence my confusion!
>>
>> Thanks, Jaremy
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/ci_v6wD_exU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/0f4ed650-b692-4e3f-836e-4df02c22d12f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMh_G9vs6thhChrD_i4fOPnhfUMvMtvENV2cYkVRUGJ1Zj9c6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fw: [beagleboard] Inquiry about whether it is possible to use PRU-ICSS to control the built-in bluetooth module in OSD3358-512M-BAS

2018-09-12 Thread drhunter95 
Hi WenZhan,
The only access you have to the Bluetooth inside the WL183x device is via 
an HCI interface over UART. There is no specification I am aware of that 
would allow you to infer time of Rx/Tx at the bluetooth physical layer from 
the time the HCI interface delivers information. 

If you are looking to do time sychronisation within a network then the wifi 
part of WL183x has the option to do that 
http://processors.wiki.ti.com/index.php?title=WL18xx_Clock_Synchronisation_with_NTP_in_SDK3

This uses the Access Points  Wi-Fi beacon to synchronise all the stations 
connected to the AP. It was done on BBGW using TI's SDK.

You would need to merge some of the specific time synchronisation code from 
TI's R8.7 driver release into a mainline kernel to get it working on a 
current kernel.
Iain


On Wednesday, September 12, 2018 at 3:27:45 AM UTC+1, WenZhan Song wrote:
>
> Thanks for reply! But Bluetooth speed itself is not a decision factor of 
> time sync accuracy as time sync message is small, we only concern about the 
> delay/jitter caused by Linux OS - or perhaps it is not a concern at all? We 
> will find out. Thanks!
>
> On Tue, Sep 11, 2018 at 5:52 PM, Robert Nelson  > wrote:
>
>> On Tue, Sep 11, 2018 at 4:29 PM WenZhan Song > > wrote:
>> >
>> > Robert,
>> >
>> > Thank you for replying our questions! To be clear, what we intend to do 
>> is: we want to design a time synchronization protocols among a group of 
>> BBBWs using the bluetooth radio in BBBW, with the goal to achieve 10 us 
>> accuracy. Thus, we want to program PRU to send and receive bluetooth 
>> messages with low-level timestamping for that accuracy. The hypothesis is 
>> that ARM with Linux perhaps has too much uncertainty and delay while PRU 
>> can reduce that.
>>
>> and "how" exactly is the PRU going to reduce that? It doesn't control
>> the radio directly...
>>
>> > Is this possible? If not, do you happen to know any mature way to 
>> achieve 10 us accuracy with Bluetooth or WiFi radio. I currently use GPS 
>> but it does not work well indoor.
>>
>> PS, If you look at:
>>
>> http://blog.bluetooth.com/exploring-bluetooth-5-how-fast-can-it-be
>>
>> It would be better to just use a Bluetooth 5 usb dongle..
>>
>> Regards,
>>
>> -- 
>> Robert Nelson
>> https://rcn-ee.com/
>>
>
>

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f48353e0-29b3-43b1-94e4-973043e70d17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Cyclops for Beaglebone Black

2018-09-12 Thread Chao 


 The exposed Cyclops method is employed to guarantee a synchronised speed 
between CPU and RPU of the Beaglebone Black.  While it always says the 
error when configures pins through all required overlays have been 
installed and loaded as the README introduction.


/sys/devices/ocp.*/P8_46_pinmux.*/state: No such file or directory


Overlays are loaded:

 0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-- Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,NESL-PRU
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,NESL-PRU-PINS
 9: ff:P-O-L Override Board Name,00A0,Override Manuf,NESL-PRU-QOT


In my view, the problem probably occurs in the NESL-PRU-PINS, which I 
cannot find out its dts file in upload files, 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 stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/744c67ce-bde7-4261-a020-d0f6056685c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wiring up an ili9341 2.4" TFT LCD display to the Black

2018-09-12 Thread Mark A. Yoder 
How do I removed the audio pins so I can test it?

--Mark

On Tuesday, September 11, 2018 at 2:33:12 PM UTC-4, RobertCNelson wrote:
>
> On Tue, Sep 11, 2018 at 1:15 PM Robert Nelson  > wrote: 
> > 
> > On Tue, Sep 11, 2018 at 12:49 PM Mark A. Yoder  > wrote: 
> > > 
> > > Robert Nelson has answered my question.  There are a number of pins 
> already used on the BeagleBone Green Wireless that can't otherwise be used. 
> > > 
> > > I've made a list of them[1]. 
> > > 
> > > --Mark 
> > > 
> > > [1] https://elinux.org/EBC_Exercise_10b_Green_Wireless_Pins_Used 
> > 
> > We should add a few details, 
> > 
> > Pins: 
> > P8_11, P8_16, and P8_15 can be recovered, by sticking the wl1835 wifi 
> > module in 1-bit mode vs 4-bit mode.. 
> > 
> > sudo rm /lib/firmware/BB-BBGW-WL1835-00A0.dtbo 
> > sudo cp /lib/firmware/BB-BBGW-WL1835-1BIT-00A0.dtbo 
> > /lib/firmware/BB-BBGW-WL1835-00A0.dtbo 
> > 
> > P8_12 = WL1835: mmc2_dat0 
> > P8_18 = WL1835: mmc2_clk 
> > 
> > P8_14 = WL1835: Wireless enabled 
> > P8_17 = WL1835: Wireless IRQ 
> > 
> > P9_12 = WL1835: Bluetooth enabled 
> > 
> > Pins: 
> > P8_26, P9_30 are "gpio hogged" at startup, not user changeable. 
> > 
> > Pins: 
> > P9_28, P9_29, and P9_31 are used by audio, which isn't actually used, 
> > but tied up.. 
> > 
> > @mark, random thought, do you want to try booting with 
> > P9_28/P9_29/P9_31 removed from bbgw.. 
> > 
> > for example.. 
> > 
> > 
> https://github.com/beagleboard/bb.org-overlays/commit/502c3d228dd6a6902cc6d7b32014075b7c6b8eb6
>  
>
> Okay, wifi/bluetooth correctly came up on restart and cold boot with 
> those pins removed from the overlay. 
>
> Give them a try with a spi device connected up. If they work without 
> breaking the wl1835, we will just nuke those 3 audio pins.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f50737f5-bdfc-4fac-b598-f41f8df0c1d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wiring up an ili9341 2.4" TFT LCD display to the Black

2018-09-12 Thread Mark A. Yoder 
Robert:
  I've updated the page[1], but didn't know what to say about recovering 
P8_12, P8_18, P8_1,4, P8_17 and P9_12.  

Do you have to edit the device tree? 


--Mark

[1] https://elinux.org/EBC_Exercise_10b_Green_Wireless_Pins_Used

On Tuesday, September 11, 2018 at 2:33:12 PM UTC-4, RobertCNelson wrote:
>
> On Tue, Sep 11, 2018 at 1:15 PM Robert Nelson  > wrote: 
> > 
> > On Tue, Sep 11, 2018 at 12:49 PM Mark A. Yoder  > wrote: 
> > > 
> > > Robert Nelson has answered my question.  There are a number of pins 
> already used on the BeagleBone Green Wireless that can't otherwise be used. 
> > > 
> > > I've made a list of them[1]. 
> > > 
> > > --Mark 
> > > 
> > > [1] https://elinux.org/EBC_Exercise_10b_Green_Wireless_Pins_Used 
> > 
> > We should add a few details, 
> > 
> > Pins: 
> > P8_11, P8_16, and P8_15 can be recovered, by sticking the wl1835 wifi 
> > module in 1-bit mode vs 4-bit mode.. 
> > 
> > sudo rm /lib/firmware/BB-BBGW-WL1835-00A0.dtbo 
> > sudo cp /lib/firmware/BB-BBGW-WL1835-1BIT-00A0.dtbo 
> > /lib/firmware/BB-BBGW-WL1835-00A0.dtbo 
> > 
> > P8_12 = WL1835: mmc2_dat0 
> > P8_18 = WL1835: mmc2_clk 
> > 
> > P8_14 = WL1835: Wireless enabled 
> > P8_17 = WL1835: Wireless IRQ 
> > 
> > P9_12 = WL1835: Bluetooth enabled 
> > 
> > Pins: 
> > P8_26, P9_30 are "gpio hogged" at startup, not user changeable. 
> > 
> > Pins: 
> > P9_28, P9_29, and P9_31 are used by audio, which isn't actually used, 
> > but tied up.. 
> > 
> > @mark, random thought, do you want to try booting with 
> > P9_28/P9_29/P9_31 removed from bbgw.. 
> > 
> > for example.. 
> > 
> > 
> https://github.com/beagleboard/bb.org-overlays/commit/502c3d228dd6a6902cc6d7b32014075b7c6b8eb6
>  
>
> Okay, wifi/bluetooth correctly came up on restart and cold boot with 
> those pins removed from the overlay. 
>
> Give them a try with a spi device connected up. If they work without 
> breaking the wl1835, we will just nuke those 3 audio pins.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9ea7e9b9-9c07-497e-b4d9-d4442224a46e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Capacitve Touchscreen Driver HY461x from HYCON on BBB

2018-09-12 Thread mex . electron18 
Hi there,

I want to use a 4.3 display with capacitve touch for a project on my BBB. 
The touch controller is a HY4614 from HYCON.
https://www.hycontek.com/en/category/products-en/touch-en#tab1
As far as I can see there is no mainline driver for this device in any 
kernel version.

HYCON is offering a driver sample code here: 
http://www.hycontek.com/wp-content/uploads/Linux_driver_sample_code.zip
Has anybody here tried to get this controller running with the code? I am a 
bit afraid of doing. Writing the DTO is no problem, but playing around with 
driver source code is completly new to me.Maybe it´s better to choose a 
display with a FT controller that has a mainline driver.

Thanks

Max


-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b073d73d-385b-4022-87da-4f3ddfaada92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Replace PixHawk with BB Blue

2018-09-12 Thread Marius Liebenberg 
Hi

I am relatively new to the RC world so please forgive stupid questions. I 
am replacing the PixHawk APM on a plane I bought with a BB Blue loaded with 
Ardupilot.

I would like to keep whatever hardware already installed if possible. All 
the GPS and telemetry stuff seems to be OK but I cannot see a way to 
connect the 3DR Power Module to the Bone. Has anyone done this kind of 
conversion and how would I do the PM integration if possible?

-- 
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 it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6ea88926-a01b-43fd-8386-1b3947c20654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.