Guest41 has joined #beagle
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<set_> Okay.
<set_> If I have two channels on my Oscilliscope, how would I test for SPI communication on the BBAI?
<set_> I can run a loopback test in the form of a clause so far.
<set_> It reports back what is supposed to be done but blah. Let me just throw in a do-while. Blah.
<set_> I caught it and w/out burning up the processor!
Guest41 has quit [Ping timeout: 256 seconds]
shoragan has quit [Ping timeout: 250 seconds]
shoragan has joined #beagle
<set_> @zmatt or GenTooMan, does this look correct for CS on a loopback test for /dev/spidev1.0 on the BBAI? https://imgur.com/a/19M22Yt
Shadyman has joined #beagle
<ds2> set_: you really need more context to determine if CS is correct - prehaps clock on another channel? otherwise, the best guess is you are looking at the end of a transaction
<ds2> CS is active low
<hnv> that is a bit of overshoot/ringing.. are the probes compensated?
<set_> Hmm.
<set_> I hope I did this already.
<set_> Off to compensate again. Blah.
<set_> I will go and look up a bit of info. first. I need to compensate correctly again and again (right). so, Molloy's software from his book shows some spidev usage in the form of a loopback test. All I did was add GND and CS on Channel 1 of the O-Scope.
<set_> I changed his software to use it continuously and then paused/stopped the reading so I can analyze it.
<set_> But...first things first. I will go and compensate again.
<hnv> Do you really need the BBAI for that?
<set_> Okay.
<set_> So, I am compensated now.
<set_> Well, the o-scope is compensated.
<set_> It was already done and in good standing still.
<set_> hnv: I do not need the AI for SPI. No.
<set_> The fellows on the forum or ladies/whomever really, anyway, they need some answers. I just wanted to let them know things are done and figuring things out is partially done too.
<set_> Yes. The probes are compensated.
<set_> ds2 lives!
<set_> Okay, I will try another channel.
<set_> and ds2. you are right from what I read. CS is active low but the source seems to make me think I can alter its state.
<set_> Actually, I will have to write the process that maps to -l in the source (I think).
<ds2> hmm?
<ds2> the driver should handle the /CS line
<set_> I say that b/c the system will not allow me to simply -l the CS line on the command line.
<set_> Oh.
<set_> Well, let me try again.
<set_> You are right.
<set_> I was trying -l.
<set_> For loopback. I think this is the normal routine it takes.
<set_> I performed the delay this time and I will show you the photo. Please hold.
<set_> Okay. It is the second photo down: https://imgur.com/a/19M22Yt
<set_> I slowed the process down for the Hz too.
<set_> So, there is a delay like w/ the driver and then my addition of slowing the Hz down.
<set_> I will try w/ the regular driver and get back to you.
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #beagle
<ds2> *shrug* that is just a rising edge. not meaningful without context. you really need to qualify it with at least one other line. About the only info from it is - if it toggles wien you run the command, it must be associated with SPI
<set_> Okay.
<ds2> it really doesn't have enough info to say is it MISO/MOSI/CLK/CS
<set_> Okay.
<set_> CS is the line but I will use the second Channel to show off CLK. P9.31 from /dev/spidev1.0 b/c of bone-buses is due!
<ds2> ideally, you would put a 4+ channel logic analyzer or scope on it but 2 at a time and working on the combos should give you enough clues
<set_> Right.
<set_> Right.
<set_> I got a bottom bargain on this thing. It works!
<set_> Just not w/ four channels.
<ds2> this is not only useful for learning - it is good for checking if SW and HW are in sync and verifying wiring
<set_> Nice and right...it is an all around useful tool.
<ds2> wouldn't worry about the number of channels - you could do some of this with a DMM if you know what to look for
<set_> Okay.
<ds2> but a VOM would be easier then a DMM though
<set_> I can do all combos and then take notes. No issue.
<set_> YOu say VOM, heh? What is that thing?
<ds2> think analog precursor to the DMM
<set_> Oh. VoltMeter?
<ds2> it has a moving needle that due to physics - averages the signal
<ds2> Volt-Ohm-Meter
<set_> Yep.
<set_> Oh!
<set_> Hmm. I am not familiar w/ them. So, the dial needle is testament to the average.
<set_> What would be gained from knowin' the average?
<ds2> well... the 4 signals have different duty cycles
<set_> Okay.
<set_> I am w/ you.
<ds2> you're backing out the duty cycle by looking at the average
<ds2> PWM in action :D
<set_> Right. Oh. So, the average of +/- on the dial shows a specific number and that number is the average?
<set_> I know on the O-Scope, the above and below signals in PWM are either positive or negative w/ respect to 0.00v.
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
russell-- has joined #beagle
russell-- has quit [Changing host]
<set_> Okay...I got a new photo and I think the CLK goes a bit awkward when the CS goes high.
<set_> Awkward = I am not desribing well what is actually taking place.
<set_> Anyway, if you are not bored yet: https://imgur.com/a/19M22Yt has three photos. The last file down is the the CLK and CS lines attached.
<hnv> Is CH2 grounded?
<hnv> i.e. connected to the same ground as CH1
<set_> Yes and no.
<set_> I have CH2 grounded to the BBAI on P9.2 while CH1 is grounded to P9.1.
<ds2> timing is a bit odd on that
<ds2> CS is yellow?
<ds2> or what you are calling CS?
<ds2> that does not seem right
<ds2> increase the per X division time
<set_> Maybe I used trigger.
<set_> Okay.
<set_> CS is yellow.
<set_> Blue is CLK.
<set_> Let me retry.
<ds2> CS should stay low while a xfer is in progress
<set_> I also used 100000 delay.
<set_> Sorry, 1000000 delay.
<set_> My lines were a bit off. Off to try. brb.
<set_> this is w/ CS high and delay at 10000.
<set_> Brb w/ the photo.
<set_> ds2: Should I perform the action w/out the CS w/ the -C call on the command line?
<set_> So, it seems when CS goes high due to my -C call on the command line, the CLK jumps a bit.
<set_> Then soon after, goes flat until a bit later.
<set_> Anyway, here is the command for the driver when I run the source: sudo ./spidev_test -C -d 10000
<set_> And...I reset all my variables to default on the o-scope to get this reading: https://imgur.com/cJ7ipxA
<set_> Anyway...time will tell what I can decipher. It is late now and I need to eat more! BRB or BBL, argh.
<set_> Also, late night ringer: https://imgur.com/a/C8I0eif must be some noise of some freq. getting caught up in the mix.
buzzmarshall has quit [Quit: Konversation terminated!]
<ds2> that is either not CS or something is wrong with it. it should be active when data is clocking
<zmatt> am I seeing correctly that these channels are set to 50 mV/div and 100 mV/div respectively?
<zmatt> and you're hoping to see anything other than noise?
indigaz has quit [Ping timeout: 245 seconds]
<zmatt> that previous pic is equally sus, showing a signal (or possibly a clock) but it's less than 0.1V in amplitude... do you have a short-circuit / drive-conflict going on or something?
<zmatt> and your CS seems to be configured active-high, which is very unusual
<ds2> if it was active high CS then why is it predominately high?
<ds2> if the 10x probe setting was wrong, the 50mv/div isn't bad
<zmatt> oh, wrong probe setting, right
<zmatt> and CS seems high during activity?
<zmatt> and he said something about configuring some huge delay, during which cs would be held active as well
<zmatt> so https://imgur.com/a/C8I0eif is fully consistent with active-high cs: idle period with CS high (delay at end of previous transfer), brief low between transfers, then high for the next transfer
<zmatt> and good call on the probe gain, if the scale is off by a factor of 10 then the blue signal is 3.3V, so that part makes sense too
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
ikarso has joined #beagle
rasenrhino has joined #beagle
rob_w has joined #beagle
rasenrhino has quit [Quit: Client closed]
rasenrhino has joined #beagle
florian has joined #beagle
rasenrhino has quit [Quit: Client closed]
set_ has quit [Remote host closed the connection]
Guest64 has joined #beagle
<Guest64> Hi
<Guest64> Request you to provide REACH & ROHS3 certificate of Beagleboard # 102110420
set_ has joined #beagle
<Guest64> Request you to provide REACH & ROHS3 certificate of Beagleboard # 102110420
<Guest64> Please sent these 3 certificates on prasad.Acharekar@TCS.com
<zmatt> Guest64: this is a user community chat
Shadyman has quit [Quit: Leaving.]
<zmatt> ask your distributor or the manufacturer (Seeed Technology)
Guest64 has quit [Quit: Client closed]
Guest64 has joined #beagle
Guest64 has quit [Client Quit]
argonautx has joined #beagle
rob_w has quit [Quit: Leaving]
rasenrhino has joined #beagle
<set_> I am shorting the MOSI/MISO pins for /dev/spidev1.0.
<set_> Did you guys think something was incorrect, i.e. ds2 and @zmatt?
<set_> I also put the single run in a loop, i.e. w/ while(1).
<set_> Anyway...here is another morning try: https://imgur.com/a/fsvI6tV along w/ window!
<set_> I will try w/ a SPI Cam or another SPI device to test soon.
<zmatt> set_: it looks like you configured the chip-select to be active-high instead of active-low, which is a bit unusual (though obviously doesn't matter if you're doing a loopback test)
<zmatt> what's your actual problem/question ?
<zmatt> looks like this is the data line being monitored and you're sending all-ones ?
<hnv> btw that scope doesn't detect the probe 1X/10X switch, so you need to set the scale in the menu accordingly
SJFriedl has quit [Quit: rebooting]
Aditya has joined #beagle
SJFriedl has joined #beagle
Aditya has quit [Ping timeout: 256 seconds]
Aditya has joined #beagle
vagrantc has joined #beagle
Aditya has quit [Quit: Client closed]
argonautx has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
ikarso has quit [Quit: Connection closed for inactivity]
<set_> No question and yes, hnv, you are right. I have a switch on the probe.
<set_> I have to set the probe and the MCU on the o-scope to handle 1x or 10x.
<set_> Molloy's book and source has a driver dedicated to spidev w/ a loopback test. In this test, one can use a -C option on the command line to "announce" a CS High instead of CS being as it were, i.e. active low.
<zmatt> okay, but why would you use that option?
<zmatt> I've never seen an spi device that used an active-high CS
<set_> I am just testing to see if it worked or not.
<zmatt> it evidently does
<set_> I have no reasoning to test w/ the -C option. Yes, it works.
<set_> So, SPI devices never use active high. Okay.
<set_> Now, I know.
<zmatt> I mean, who knows what kind of weird things exist :P but I've personally never encountered one
<set_> Aw.
<set_> Okay and that sounds right. Things are awkward at times w/ what exists.
<set_> Who knows what people will do?
<set_> !
<set_> Well, I will test later for the non -C option on the command line for the SPI on the AI.
<set_> It is getting interesting.
<set_> anyway...up, up, and Otay!
<set_> bbl
m-atoms has joined #beagle
rasenrhino has quit [Quit: Ping timeout (120 seconds)]
otisolsen70 has quit [Quit: Leaving]
<ds2> a device may not use CS (active high) but parts shortages/EE's may force SW to configure things as active high
<ds2> i.e. an inverting level translator
<zmatt> that seems really desperate though, since you'd also need to invert the data in software
<set_> Ooh la la. Zoinks.
<set_> The SPIDEV devices work! Now, my readings on the other hand will need some work.
<set_> What device do any of you persons recommend for displaying the use of SPI connectivity to the BBAI (to/from)?
<set_> I am asking b/c the people on the forums think two SPI devices are not enough for their instances or something. I am not sure exactly what they think.
<set_> I mean...
<set_> What are some examples of SPI modules to use, i.e. I found some from Molloy's book and an email popped up as soon as I asked, i.e. imu?
<set_> There is a long list of ideas, some bouncing, and relative conclusions (I think).
<set_> Anyway, so let me get this correct here: The CS line should go high b/c I am telling it to, which it does, and then the CLK should go low?
<set_> I need an update to the MCU on the board in this "fancy contraption." Brb.