<set_>
Okay, okay, okay. So, does the ServoCape come w/ the inputs populated or not?
<zmatt>
?
<set_>
There are 5v inputs on the ServoCape.
<set_>
And signals at 3.3v PWM and a GNDs.
<zmatt>
not really... what are you referring to?
<set_>
The ServoCape!
<set_>
I have signal in and mouser.com has a photo up of the signal inputs populated.
<zmatt>
the inputs are not 5v, they're 3.3v
<set_>
I think they need to change it on their site or allow for people to understand.
<set_>
Oh?
<set_>
It says 5v.
<zmatt>
where?
<set_>
On the ServoCape silkscreen.
<zmatt>
the only thing 5v is the supply input (which just connects to the 5v output on the servo output headers)
<set_>
Near the blue screw terminal, there is a silkscreen heading w/ the words Signal In.
Shadyman has joined #beagle
<set_>
Above that it shows the the signals, the gnds, and the 5v inputs.
<set_>
@zmatt: Would you like a photo?
<set_>
I notified mouser already but they are acting like what was once collective is indifferent now.
<set_>
So, I am not trying to rip or gip the system here.
<zmatt>
that 2-pin header labeled "5v" is a 5v output from the beaglebone, I have no idea why they visually grouped near the servo signal input headers
<set_>
I am trying to figure out if Mouser has some rotten apples that are keeping the signal inputs to themselves and shafting me or if I do not get signal in populated at all.
<set_>
Oh!
<set_>
Oh.
<set_>
Okay.
<set_>
Hmm. Is that in the datasheet?
<set_>
If this is an issue, I will drop it.
<zmatt>
schematic
<set_>
No concern but the fact remains, I already contacted mouser about the population again and again. Twice only actually.
<set_>
Schematic!
<set_>
Off to check it out.
<zmatt>
X2
<set_>
Wait!
<set_>
Allied is even selling them for $22.00.
<set_>
What is going on down in Cajunville?
<set_>
I just spent $40.00 on it.
<set_>
Blah.
<zmatt>
both prices sound excessively expensive to me
<zmatt>
considering how little there's on this thing
<set_>
You or whomever is in charge of the ServoCape notifications I think should adjust photos of the input headers being populated if indeed they are not.
<set_>
Right.
<set_>
I understand.
<set_>
Allied, Mouser, and now who knows who? You know?
<zmatt>
I'm not in charge of anything whatsoever, I don't work for beagleboard.org
<set_>
Me neither.
<set_>
I am just reaching out.
<zmatt>
if the product you received doesn't match the photo, you should probably notify the supplier from which you obtained the product
<set_>
As usual, GHI may get upset. Either way, I will wait to understand more in time. Right...
<set_>
That is what I thought.
<zmatt>
(i.e. the distributor0
<set_>
So, that is what I did. Again!
<zmatt>
)
<set_>
Right.
<set_>
Okay.
<zmatt>
anyway, zZ
<set_>
No!
<set_>
Wait...
<set_>
Fine.
<set_>
Anyway...sorry for stirring up trouble (as they call it).
<set_>
@zmatt: Now, w/ your knowledge from reading the proper schematic that I cannot find right now, I have realized I have a 5v output on the ServoCape to go and use.
<shree_ya>
I'm not sure what exactly is wrong here, anyone face this before? Or have any pointer to a better guide for BBG cross compiling setup?
<shree_ya>
nope, these logs are from emmc instead of sd card. It looks like I don't get any logs when I try to boot from SD card.
<zmatt>
shree_ya: in the future please don't copy-paste multi-line stuff such as logs into chat... share it using a paste service such as pastebin.com
<jfsimon1981_b>
Hi
<jfsimon1981_b>
that's what i was gonna say, there's a few sites just post the link to a pastebin pls
<zmatt>
shree_ya: any particular reason why you're trying to cross-build a custom image rather than using the standard debian image?
<shree_ya>
zmatt jfsimon1981_b sorry about it. I'll take care of it next time.
<jfsimon1981_b>
makes it easier to ready anyway
<zmatt>
shree_ya: also, beaglebone green, or beaglebone green gateway?
<zmatt>
those are very different boards
<shree_ya>
zmatt I'd like to work on adt7316 driver. I have an evaluation board for the same which I'll be connecting to BBG.
<shree_ya>
Also I'm assuming process for cross compiling is kind of same for BBG Gateway and BBG
<zmatt>
shree_ya: for developing a kernel driver I'd still be inclined to just start with a normal image (probably a bullseye minimal image) and then use rcn's kernel build tool to build a custom kernel
<shree_ya>
But don't I need to transfer the contents like zImage, dtbs etc after building the custom kernel?
<zmatt>
shree_ya: and yeah I'd expect the process to be similar, though beware that the BBGG differs significantly from the BBG... the BBG uses the built-in ethernet of the beaglebone (like every other beaglebone that has ethernet except the BBGG) while the BBGG uses an usb ethernet chip
<zmatt>
shree_ya: rcn's kernel build tool produces a debian package (.dpkg) containing the zimage, modules, and dtbs
<zmatt>
so that makes it really easy to install
<zmatt>
nevertheless, it's a good question why you're having trouble with these instructions, it does look to me like they should work
<shree_ya>
zmatt are you saying I should run rcn's kernel build tool from inside the BBG?
<zmatt>
beware that if you're trying to boot from sd card while there's a system on eMMC that's substantially older or different from the one you're trying to boot from sd, then you may need to bypass the bootloader on eMMC by powering on with the S2 button held down (you can let go once the power led turns on) or just wiping eMMC using sudo blkdiscard /dev/mmcblk1
<zmatt>
no!
<zmatt>
I'm suggesting you use rcn's kernel build tool ( https://github.com/RobertCNelson/ti-linux-kernel-dev ) on your development system, then transfer the .dpkg file to the bbb and install it with sudo dpkg -i linux-image-whatever.dpkg
<zmatt>
regardless, you'll want a working system first
<shree_ya>
I currently have 5.10 kernel running on BBG
<zmatt>
ok
<shree_ya>
But that is running through emmc. Not sure why but I've never been able to boot using sd card
<zmatt>
even if you flash an official image to sd card using Etcher ?
<shree_ya>
yes
<shree_ya>
It has never worked
<shree_ya>
I do press s2 button to bypass the emmc as well.
<zmatt>
does it detect the sd card if you insert it after booting from eMMC ?
<zmatt>
(based on the kernel log)
<zmatt>
btw it looks like the ADT7316 already has a kernel driver? or do you mean "work on" in the sense of improve it?
<shree_ya>
yes, improve it.
<zmatt>
ah
<zmatt>
anyway, I'm at work and should probably resume my focus on doing work stuff
<shree_ya>
I don't know if it detects the sd card or not. I'm not able to ssh when I have sd card inserted while I boot from emmc.
<zmatt>
ehh
<zmatt>
I mean insert the sd card after you've already fully booted
<shree_ya>
No, it doesn't detect sd card
<zmatt>
but... this sounds really weird since if it doesn't detect the sd card then it shouldn't matter at all whether the sd card is inserted or not
<zmatt>
at boot I mean
<zmatt>
anyway, I really need to go, I'll be around again later
<shree_ya>
Sorry my bad, it does detect the sd card. Not sure why it didn't when I checked it last time. See you later
brook has joined #beagle
Guest47 has joined #beagle
alan_ has quit [Quit: Leaving]
alan_ has joined #beagle
alan_ is now known as alan_o
<Guest47>
I've been beating my head against CAN on BBB - 2GB version . Using SN65HVD230 CAN Bus Transceiver Breakout and the can1 interface on the BBBs. I believe I have it wired up correctly, DCAN1 TX (pin 24) to the CTX on the breakout, pin26 to CRX, the CANH and CANL between the breakouts hooked together, and GND and 3.3V from the BBB pins 1 + 3.
<Guest47>
I've brought up the interfaces in /etc/network/interfaces and have `can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000` But using cangen on one BBB shows nothing in candump on the other. Any ideas or resources? Using the latest minimal debian install from this forum post:
<Guest47>
Well, found an article that says I have to enable the pins to be can and not default: https://www.thomas-wedemeyer.de/de/electronic/arm/beaglebone/canbus-python/ and now it's working. Now to figure out how to do this in the dtc overlays as I figure that's the way it's supposed to be done, not using a manually build service like this one says
xet7 has quit [Ping timeout: 252 seconds]
<zmatt>
Guest47: you can use either runtime pin configuration (config-pin) or an overlay indeed
<zmatt>
I'm pretty sure there are standard overlays for can...
<zmatt>
yeah, /lib/firmware/BB-CAN1-00A0.dtbo
<Guest47>
I was fooled into thinking the overlays were already applied because ip link showed them active
<Guest47>
when i checked the pin config it said default but i wasn't sure if default meant can
<zmatt>
yeah that's a side-effect of cape-universal enabling everything and the kitchen sink to be able to use them simply by muxing the pins... the peripherals themselves are unaware of runtime pin configuration
<zmatt>
for almost all pins the default mode is gpio
<zmatt>
if you want the pins enabled at boot without having to use config-pin, configure /lib/firmware/BB-CAN1-00A0.dtbo into one of the uboot_overlay_addr4..7 variables in /boot/uEnv.txt
<Guest47>
awesome, that's the road I was heading down to enable them but was running into conflicting instructions. and good on the pinmux link, that's handy
<Guest47>
now I just have to deal with the fact that with the 2GB model, I have barely any room to do things. Keep having to clear out log files to save things
<Guest47>
Hey, thanks for the help
<zmatt>
hmm, surely with the minimal install there should be enough free space?
<zmatt>
and typically you can do further cleanup of the minimal install too, since it'll have packages e.g. for wifi-enabled boards that may not matter to you
brook has quit [Remote host closed the connection]
xet7 has joined #beagle
<zmatt>
Guest47: you can try freeing up space using: sudo apt-get purge firmware-{iwlwifi,misc-nonfree,atheros,libertas,brcm80211} rtl8723bu-modules-$(uname -r)
brook has joined #beagle
otisolsen70 has quit [Quit: Leaving]
<zmatt>
or a more thorough purge of wifi-related stuff would be: sudo apt-get purge {bb-bbai,bb-wl18xx,sancloud}-firmware firmware-{atheros,brcm80211,iwlwifi,libertas,misc-nonfree,realtek,ti-connectivity,zd1211} {qcacld-2.0,rtl8723{b,d}u,rtl8821cu}-modules-$(uname -r) hostapd iw bb-wlan0-defaults wpasupplicant
<set_>
@zmatt: I saw what you typed last when directing it at me. Okay about the 5v output being sys_5v from the BBB. Thank you.
brook has quit [Ping timeout: 255 seconds]
Mahesh has joined #beagle
Mahesh has quit [Client Quit]
ikarso has quit [Quit: Connection closed for inactivity]
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
Mahesh has joined #beagle
Mahesh has quit [Client Quit]
Mahesh has joined #beagle
<Mahesh>
Hello I am new to Beagle world - I am unable to connect BB AI 64 via usb using Windows 10,then I installed the drivers by using overriding mode (as the driver are not certified my Microsoft). Still I find the driver is not compatible with the hardware. Please help to solve this issue - Thank in advance
buzzmarshall has joined #beagle
shree_ya has quit [Ping timeout: 260 seconds]
florian has quit [Quit: Ex-Chat]
<zmatt>
the dumb thing is that no driver installation should be needed, it uses RNDIS which is microsoft's own usb networking protocol which uses microsoft's own driver which is integrated into windows
<zmatt>
but somehow microsoft periodically breaks it anyway
<zmatt>
(and the bbb also supports the usb standard networking protocol CDC-NCM but microsoft doesn't bother implementing standards)
<zmatt>
the beaglebone images I mean, hardware variant shouldn't matter
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
<Mahesh>
Zmatt i understand that, but how to connect / over this issue
<Mahesh>
*Over come this issue
<zmatt>
I don't know, my understanding was that it should currently just work fine plug and play
<zmatt>
if you can ping it then the network interface is working and you should be able to log in on the beaglebone
<Mahesh>
In device manager I see and error - that looks like drive error or non compatible drive
<zmatt>
my guess would that's the usb standard network interface (CDC-NCM), which isn't supported by microsoft, but that's why there's also a microsoft-proprietary network interface (RNDIS), which is clearly working fine for you if you can ping it
ft has joined #beagle
<zmatt>
so I wouldn't worry about that
<Mahesh>
Thank how to connect?
<zmatt>
typically via ssh... I would normally also expect there to be a web interface though I personally don't use that
<Mahesh>
Ok
Guest77 has joined #beagle
Mahesh has quit [Quit: Client closed]
Guest77 has quit [Quit: Client closed]
Mahesh has joined #beagle
Mahesh has quit [Client Quit]
vagrantc has joined #beagle
brook_ has quit [Ping timeout: 272 seconds]
dinuxbg has joined #beagle
Shadyman has joined #beagle
brook has joined #beagle
<set_>
Well, I got back to the BBBlue and "flying."
<set_>
Notta so far! But...I will keep trying this time. I can feel a wind a brewing. Zoom!
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #beagle
<set_>
GenTooMan: Hello. How are the am335x boards treating you these days?