Meeting follow up

[Debrant]

@gstro @jmickiewicz

Lets get the exact files, that failed upon integration, to Mike.

[gstro]

I got it working earlier today :+1:. Get this: we had the SCL and SDA lines crossed from the BBB. I think we were so convinced it was something more subtle and obfuscated we never bothered to confirm those connections :-1:. We must've checked every other connection at least a dozen times. Oh well, lesson learned.

I'm bummed that it meant missing the demo but glad it was an easy fix and we can move on. I'm gonna take some time to improve the daisy-chain and will meet with @jmickiewicz on Monday to smooth out more integration details. There may be a few surprises left so I'm not claiming victory just yet.

@Debrant, you and @dfrister are gonna test power and bring up the boards soon, right? Let us know when you think you're ready to put some code on there.

[erebuslabs]

:+1: Nice going!

Sorry that yesterday I didn't realize you were talking about hardware integration (my uC limitation comment probably seemed out of place). Regardless - glad you got that part figured out - and please do still send me a listing of the relevant files - I'd be happy to take a look.

[gstro]

Well, we thought it was a software issue too! But it turns out that we had some jumpers crossed from the BBB to our breadboards during prototyping and it was causing some strange behavior in the code -- including some false i2c start conditions -- so it was a bit misleading and wasn't obvious to us to double check the wires. We spent a good portion of our time looking through the code for errors that weren't there and never coming up with anything.

Now that the i2c is working (again), we'll finish up combining the daisy chain and i2c code and confirm there are no additional issues -- such as some hidden uC limitations as you suggested, we haven't completely ruled that out yet and I think it's a good point to investigate. I'll post a link to the combined files when that is done if you'd still like to take a look.

On a related note, the daisy chain code functions well when initiated after everything is already connected. But it can be a bit unreliable (~75% accurate) when "hot swapping," i.e. disconnecting and reconnecting. I created a (quick and dirty) handshake with the connecting lines to help prepare both sides for send and receive but despite a few revisions and staring at it for hours I still don't have a lot of confidence in it. I will be posting a new issue in the next few days with some diagrams detailing my implementation and I would appreciate your input, and everyone else's input too, once that's up.

[profroyk]

That's great news guys...I figured the problem had something to do w/ SCLK and getting the lines crossed would definitely affect the clock signal.

I will still plan to bring my logic analyzer for you to borrow to campus on Tuesday. I'm there by 3PM and leave for class around 6:15PM so if you still want to borrow the logic analyzer one of you should stop by my office FAB 20-04.

Roy

On Sun, Apr 12, 2015 at 4:31 PM, Greg notifications@github.com wrote:

Well, we thought it was a software issue too! But it turns out that we had some jumpers crossed from the BBB to our breadboards during prototyping and it was causing some strange behavior in the code -- including some false i2c start conditions -- so it was a bit misleading and wasn't obvious to us to double check the wires. We spent a good portion of our time looking through the code for errors that weren't there and never coming up with anything.

Now that the i2c is working (again), we'll finish up combining the daisy chain and i2c code and confirm there are no additional issues -- such as some hidden uC limitations as you suggested, we haven't completely ruled that out yet and I think it's a good point to investigate. I'll post a link to the combined files when that is done if you'd still like to take a look.

On a related note, the daisy chain code functions well when initiated after everything is already connected. But it can be a bit unreliable (~75% accurate) when "hot swapping," i.e. disconnecting and reconnecting. I created a (quick and dirty) handshake with the connecting lines to help prepare both sides for send and receive but despite a few revisions and staring at it for hours I still don't have a lot of confidence in it. I will be posting a new issue in the next few days with some diagrams detailing my implementation and I would appreciate your input, and everyone else's input too, once that's up.

— Reply to this email directly or view it on GitHub https://github.com/erebus-labs/blocks-o-code/issues/70#issuecomment-92151086 .

Roy Kravitz Westside Program Director Electrical and Computer Engineering Department Maseeh College of Engineering and Computer Science Portland State University

503-913-1678 (M) roy.kravitz@pdx.edu ece.pdx.edu

[jmickiewicz]

@profroyk I can take custody tomorrow between classes about 4pm, but I won't have time to do more than lock it in the LID to use weds.

[dfrister]

Logic analyzer is stored in the locker.