[beagleboard] Re: Darlington Array Help

2014-02-25 Thread godsfshrmn
Thank you for the fantastic explanation. I haven't gotten a chance to give 
it a try yet, but will let you know

On Thursday, February 20, 2014 5:32:41 PM UTC-5, Dennis Cote wrote:
>
>
>
> On Friday, February 14, 2014 3:51:08 PM UTC-7, Dennis Cote wrote:
>>
>> Is there a secret to attaching a file?
>>
>>
> File attaching started working after updating to latest Chrome (and 
> therefore restarting Chrome). 
>
> Schematic is attached.
>
> Dennis Cote
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.


[beagleboard] Darlington Array Help

2014-02-13 Thread godsfshrmn
I am looking to control three SSR's 
(datasheet). 
I have tried directly hooking them up to the BB, but only one of them will 
actually switch when the GPIO pin is set to high. The datasheet says the 
trigger current is 7.5mA / 12 V (max 3-32V). I obviously need to augment 
the voltage and/or current, so I ordered a ULN2003. This is spec'd to do a 
max 500mA current (per driver) and 50V. I have tried to get a little basic 
understanding of the darlington array, but I can't figure out a few things:


   1. For these SSRs' input voltage, I can't go over 32V. Does the input 
   voltage on the ULN2003 match the output voltage?
   2. If I were able to use the BB's 3.3V pin as the input voltage, would 
   there be enough current to trigger the SSR?
   3. How many channels on the ULN could I power if I used the 3.3V on the 
   BB? As I understand, the GPIO are not for sourcing current.

Another option (what makes the most sense to me) is using the BB's 5V power 
supply for both the BB and the ULN2003. I don't know where that puts the 
output voltage (question #1). The BBB docs suggest 2A supply if you are 
running a USB peripheral. I have a WiFi USB dongle being used. The supply 
is rated at 2A. According to my Kill-a-watt, I don't see a draw of over 
100mA. It draws 70-80mA at idle/load. I'm not sure if you can use the 
kill-a-watt as the amperage draw though?

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.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] BeagleBone Black: v3.8.13-bone37 kernel flash slowly fills up

2014-02-10 Thread godsfshrmn
Can someone tell me how to apply the built kernel on debian? I followed the 
above instructions to download from git and then compiled. I don't know how 
to apply the built kernel. Thanks

On Wednesday, February 5, 2014 9:45:23 AM UTC-5, tir...@gmail.com wrote:
>
> update done ! 
> all fine :-) 
>  
> Thank you for your quick reply ;-) 
> cheers 
> Eric
>
>
> Le mercredi 5 février 2014 15:35:45 UTC+1, RobertCNelson a écrit :
>>
>> On Wed, Feb 5, 2014 at 5:43 AM,   wrote: 
>> > Hi Robert 
>> > I've (of course ) the same problem with my distro that is a 
>> 3.8.13-bone37 
>> > I did the bone35 kernel update and it worked perfectly.  yet I'm 
>> wondering 
>> > If I will have to "suffer" from any regression from 37 to 35 ? 
>>
>> Well, bone40 has been out with the /var/log/ overflow from driver fix. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> http://www.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.
For more options, visit https://groups.google.com/groups/opt_out.


[beagleboard] Flashing Compiled Kernel

2014-02-10 Thread godsfshrmn
I have compiled the latest debian kernel using instructions I found on 
another post:

git clone git://github.com/RobertCNelson/linux-dev.git
cd linux-dev/
git checkout origin/am33x-v3.8 -b tmp
./build_kernel.sh

The build is complete. I can't figure out how or which file I need to use 
to flash it to the eMMC. If I try to run ./tools/install_kernel.sh it tells 
me "Please update MMC variable in system.sh", which I did: 
"MMC=/dev/mmcblk1"
mmcblk1 corresponds to my emmc. Any thoughts?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.


[beagleboard] Re: OneWire (w1) Stopped Detecting Sensors

2014-02-07 Thread godsfshrmn

I found this command: cat /sys/kernel/debug/gpio


GPIOs 0-31, gpio:
 gpio-6   (mmc_cd  ) in  lo

GPIOs 32-63, gpio:
 gpio-45  (w1  ) in  lo
 gpio-52  (eMMC_RSTn   ) out lo
 gpio-53  (beaglebone:green:usr) out lo
 gpio-54  (beaglebone:green:usr) out lo
 gpio-55  (beaglebone:green:usr) out hi
 gpio-56  (beaglebone:green:usr) out lo
 gpio-59  (McASP Clock Enable P) out hi
 gpio-60  (sysfs   ) in  hi


It looks like the appropriate PIN is loading and listening correctly. I'm 
at a loss

On Thursday, February 6, 2014 6:05:21 PM UTC-5, godsf...@gmail.com wrote:
>
> I previously had a few DS18b20 sensors working fine. I can't really 
> pinpoint what happened, but it all of a sudden they stopped working. Can 
> anyone provide some direction?
> I'm running: Linux debian-armhf 3.8.13-bone30
> cat /sys/devices/bone_capemgr.9/slots:
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,w1
>
> dmesg:
> [1.663645] bone-capemgr bone_capemgr.9: loader: done slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [1.672272] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.695708] bone-capemgr bone_capemgr.9: loader: after slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.721104] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
> 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
> '00A0'
> [1.764142] usb usb1: Manufacturer: Linux 3.8.13-bone30 musb-hcd
> [1.775711] bone-capemgr bone_capemgr.9: slot #6: dtbo 
> 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
> [1.796045] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN 
> conflict P8.45 (#5:BB-BONELT-HDMI)
> [1.805652] bone-capemgr bone_capemgr.9: slot #6: Failed verification
> [1.812426] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [   95.047835] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
> [   95.059627] bone-capemgr bone_capemgr.9: slot #7: generic override
> [   95.066271] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 7
> [   95.074344] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,w1'
> [   95.085875] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'w1-00A0.dtbo
> [   95.095993] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [   95.134512] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' 
> loaded; converting to live tree
> [   95.148143] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
> [   95.166203] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.
>
> bb@debian-armhf:~$ ls /sys/bus/w1/devices
> w1_bus_master1
>
> What else should I check? There are a few errors popping up in dmesg, but 
> it appears that it is loading correctly. I double and triple checked my 
> wiring- I've tried three different sensors plugged directly into the BB and 
> some via breadboard connection.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] Re: device tree dallas 1 wire ubuntu - loads but odd behaviour

2014-02-07 Thread godsfshrmn
Matt, 
Did you solve your problem? I have a very similar issue to yours right now. 
I've been trying to find a solution for a few days.

Andrew

On Wednesday, December 11, 2013 7:13:39 AM UTC-5, Sika wrote:
>
> Pretty recent, actually, Mike...
>
>  3.8.13-bone20
>
> And the pins are changing -- it's outputing 37:
>
> sudo cat $PINS|grep 840
> pin 16 (44e10840) 0037 pinctrl-single
>
> and the multimeter says it is pulled up.
>
> I used a different overlay tree as well -- and get the same thing
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "BB-W1";
> version = "00A0";
>
> exclusive-use = "P9.15", "gpio1_16";
>  
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
>  bb_w1_pins: pinmux_bb_w1_pins {
>  pinctrl-single,pins = <
>  0x040 0x37  /*pin P9_15 input with pullup mode 7  - 
> w1-gpio */
>  >;
>  };
> };
> };
>
> fragment@1 {
> target = <&ocp>;
> __overlay__ {
> onewire@0 {
> status  = "okay";
> compatible  = "w1-gpio";
> pinctrl-names   = "default";
> pinctrl-0   = <&bb_w1_pins>;
>
> gpios = <&gpio2 16 0>; /*grrr I think this means gpio1_16 
> (using 1 to 4 instread of 0-3)*/
> };
> };
> };
> };
>
>
> I'd greatly appreciate any help on this I can get!
>
> Kind regards
>
> Matt
>
>
>
>
>
>
> On Wednesday, December 11, 2013 7:57:21 PM UTC+10, Mike Bremford wrote:
>>
>> Which kernel - "uname -a"? I don't think you can change the pinmux for 
>> pins under 3.12 yet - well I couldn't anyway, although it worked for me 
>> under 3.8. Check by doing "grep 44e10840 
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins" - is it 0037? Is the 
>> pin actually pulled up? Test with a multimeter and/or add an external 
>> pullup resistor.
>>
>>
>> On 11 December 2013 08:29, Sika  wrote:
>>
>>> Well it says it loads -- but it does not work.  Help appreciated!
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>>
>>> On Tuesday, December 10, 2013 6:31:12 PM UTC+10, Sika wrote:

 Oh, by the way ...the blob is loaded:


 grubby@ubuntu-armhf:~/python/projects$ cat $SLOTS
  0: 54:PF---
  1: 55:PF---
  2: 56:PF---
  3: 57:PF---
  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
  6: ff:P-O-L Override Board Name,00A0,Override Manuf,w1


>>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.


[beagleboard] OneWire (w1) Stopped Detecting Sensors

2014-02-07 Thread godsfshrmn
I previously had a few DS18b20 sensors working fine. I can't really 
pinpoint what happened, but it all of a sudden they stopped working. Can 
anyone provide some direction?
I'm running: Linux debian-armhf 3.8.13-bone30
cat /sys/devices/bone_capemgr.9/slots:
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,w1

dmesg:
[1.663645] bone-capemgr bone_capemgr.9: loader: done slot-5 
BB-BONELT-HDMI:00A0 (prio 1)
[1.672272] bone-capemgr bone_capemgr.9: loader: check slot-6 
BB-BONELT-HDMIN:00A0 (prio 2)
[1.695708] bone-capemgr bone_capemgr.9: loader: after slot-6 
BB-BONELT-HDMIN:00A0 (prio 2)
[1.721104] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
'00A0'
[1.764142] usb usb1: Manufacturer: Linux 3.8.13-bone30 musb-hcd
[1.775711] bone-capemgr bone_capemgr.9: slot #6: dtbo 
'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
[1.796045] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN 
conflict P8.45 (#5:BB-BONELT-HDMI)
[1.805652] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[1.812426] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
BB-BONELT-HDMIN:00A0 (prio 2)
[   95.047835] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
[   95.059627] bone-capemgr bone_capemgr.9: slot #7: generic override
[   95.066271] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 7
[   95.074344] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,w1'
[   95.085875] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'w1-00A0.dtbo
[   95.095993] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[   95.134512] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' 
loaded; converting to live tree
[   95.148143] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
[   95.166203] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.

bb@debian-armhf:~$ ls /sys/bus/w1/devices
w1_bus_master1

What else should I check? There are a few errors popping up in dmesg, but 
it appears that it is loading correctly. I double and triple checked my 
wiring- I've tried three different sensors plugged directly into the BB and 
some via breadboard connection.


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.


[beagleboard] Re: Dallas 1-Wire BeagleBone Black

2014-01-20 Thread godsfshrmn
Can you post a photo of how you have them wired please?

On Wednesday, December 4, 2013 8:51:26 AM UTC-5, Doug Edey wrote:
>
> I've got 3 DS18B20 sensors on my bus at the moment, providing you've got 
> the sensors running in non-parasitic mode, I think you'll be fine.
>
> On Tuesday, December 3, 2013 8:13:31 PM UTC-5, lorena...@gmail.com wrote:
>>
>> Thinking of replacing the dedicated microcontroller that runs my house 
>> with a BBB. Being able to read the existing 1-Wire network will be 
>> critical. Currently have 12 18B20 sensors on one bus, need more. Can the 
>> kernel module described here actually address and read multiple sensors on 
>> the same bus? Can it search and retrieve addresses from unknown sensors? 
>>
>> I see people selling 8-port capes, as if maybe this is a simple one 
>> device per bus routine...  Wouldn't help me! 
>>
>> As for the "considerations" of long buses, yes there was a learning 
>> curve. I have both active pull-up and active pull-down, with careful 
>> source-end termination. All cable is CAT-5, and all sensors are within 1m 
>> of a single linear topology installation. In several cases the bus goes out 
>> one pair of the CAT-5 to a distant sensor and comes back on another pair of 
>> the same cable to continue to the next destination. Branching.in a star 
>> fashion is death to 1-Wire. My current system works, reliably controlling 
>> serious solar hot water and outdoor wood boiler operation that could blow 
>> off expensive antifreeze fluid (a huge hassle to recharge) if anything 
>> overheated. 
>>
>> Great long-bus reference:
>> http://www.1wire.org/Files/Articles/1-Wire-Design%20Guide%20v1.0.pdf
>>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.