Close

SPI Problems

A project log for Driverless Mouse and Keyboard Sharing

Instantly share mouse and keyboard across computers on any platform.

frankstripodfrankstripod 06/26/2015 at 10:2815 Comments

I got some cheap perfboard and noticed how spoiled I was with the exact spacing on my mouse (2.54mm in both directions). None of my boards with pins fit, and I thought I was out of female headers. Then I found some baby 1x2 and 1x4 headers and decided to start a header farm.

The new sockets work fine.

I had this briefly working before, then when I set it up again, I got nothing. I thought I had blew up a board and totally missed the blue smoke. I checked everything with a meter a hundred times, and re-soldered everything three times. This is what I came up with.

This doesn't work:

This does:

I am thinking its interference in the shape of the SPI wires, even though the boards are so close to each other. (Blue=3.3V, Green=Ground.)

Am I wrong?

The differences:

Not working:

Does work:

(This makes more sense now that I see it on paper.)

This is very scary for me because I am just starting to play with KiCad, and would hate to order a board that had this problem.

Would a board with a ground plane and no “crossed wires” help so much that the shape wouldn't matter?

Are there board designs that are less SPI friendly than others?


I used LibreOffice Draw to map the pins and wires upside down.

Rotated diagram matches wiring pictures above:

I cut the VBUS jumper on the USB Host Shield that supplies power to the host connector, added a USB hub for power instead, and put in a 100uF cap, as recommended here:
http://pjrc.com/teensy/td_libs_USBHostShield.html
and here:
https://www.circuitsathome.com/usb-host-shield-hardware-manual

Teensy-LC

Even though the Stickvise comes in handy most of the time...

but I prefer to get the spacing right for pins here first.

Discussions

K.C. Lee wrote 06/27/2015 at 02:14 point

Looking at the wiring, there isn't any significant difference between the two.  Unless you are working in pico seconds.  If one of them works, then you have very marginal signal quality issues.  Have to have good solid ground paths and minimize current loops.
On my K22 part the default reset slew rate (I think was weak driver, fast ) gives the best signals quality.  The rise/fall time is 4ns and that mean I can get by with 4" of tracks that do not have terminations.  In my layout, I always make sure that there are ground return paths to all my signals. I talked a lot about those in my log.

Not a whole lot I can help here unless you have very specific questions.

  Are you sure? yes | no

frankstripod wrote 06/27/2015 at 02:24 point

I will have to re-read all of your projects again, because now I am sure I have missed a lot. Thank you!

  Are you sure? yes | no

K.C. Lee wrote 06/26/2015 at 23:32 point

try 822 pages of Reference Manual + 58 pages of datasheet - and that's for just one of the chips I use.  Some of my chips have multiple app notes too.  

  Are you sure? yes | no

frankstripod wrote 06/27/2015 at 01:13 point

If you don't mind helping, so that I know I'm looking in the right place; you did mean the Freescale chip datasheet like this: http://www.pjrc.com/teensy/K20P64M72SF1.pdf

It also has a 1377 page reference manual. 

http://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

Having another look at the MAX3421E datasheet again wouldn't hurt either.

  Are you sure? yes | no

K.C. Lee wrote 06/27/2015 at 01:29 point

Yes.  I have used the K22 chip and now using the KL16 chip.  Both are related to the teensy 3.1 and the LC but not the same family.  I have played with DMA controllers and SPI too.  https://hackaday.io/project/1347-fpga-computereval-board

I didn't bother with the MAX part in my project as I was going to use a OTG chip.  I don't do Arduino libraries however.  I ported RTOS to it.

The manual I read are: K22P48M50SF4.pdf  and I rename the other to K22 Sub-Family Reference Manual (48pins).pdf

Going to need KL16P64M48SF5.pdf,  KL16P80M48SF4RM.pdf for my new project.

  Are you sure? yes | no

K.C. Lee wrote 06/27/2015 at 02:16 point

The KL16 is for that project and it is sort of related to the KL26 in the LC - essentially minus the USB.

  Are you sure? yes | no

esot.eric wrote 06/26/2015 at 11:22 point

whoa, now that last pic is quite the header-farm.

You might be on to something, the cross-over of MOSI and MISO could be the problem, two fast signals, coupling... seems plausible. But, surprising with such short-distances. How fast are these things, anyhow? 

Cross-over with the clock would make some sense, but MOSI and MISO, yah'd think they'd both toggle at the same time and have time to settle before the "sample" edge of the clock came through.

I'm pretty certain if you don't cross-over and you have plenty of space between parallel traces (including parallel on opposite sides of a non-planed board), you'd be alright, but if you're doing high-speed stuff, you might be best-off keeping a ground trace inbetween.

I have a hard time thinking these short-distances and data-rates would necessitate things like impedance/length-matching and whatnot, but I dunno. There are a number of "good practices" that'd probably help prevent stuff like that in cases like this, but those are hard to accomplish with point-to-point wiring.

Yahknow, another possibility... SPI has several different "Modes" which actually can seem compatible when wired-up, but might be *right at the edge* of functioning... E.G. if your "Master" is set-up to transition data on the rising-edge of the clock, and the "Slave" expects data to transition on the falling... it might still function in most-cases due to gate-transition-delays... check those SPI modes are matched!

Blue for + and Green for GND... I dunno man, I've only known one other person in the world who's done this... I think *that* is your problem ;) Red and Black, man, red and black!

  Are you sure? yes | no

esot.eric wrote 06/26/2015 at 13:15 point

This might be going too deep... I dunno about your setup, but I have found in some chip-documents the SPI *Configuration* [register-setting] Numbers don't match the de-facto/official SPI *Mode* Numbers... (which, as I recall, number from "SPI Mode 0" to "SPI Mode 3"). In fact, some of those *Configuration* numbers have actually been referred to, in those documents, as "SPI Mode", which makes everything *really* confusing. 

Right now I'm looking at the Atmega8515 datasheet, which shows two different timing-diagrams for two different options, then each of those diagrams show multiple other options... I think, in total, there are at least 8 different SPI configurations possible... several of those will work with each other if *everything* is ideal (matched wire-lengths, fast slew-rates, no noise/cross-talk), but aren't at all spec'd to work together and would fail if any of those ideals weren't met...

If you feel the urge to look into this, I *highly* recommend you check the timing-diagrams on both parts carefully, completely ignoring any "Mode" numbers. And, maybe use that Atmega8515 datasheet's timing-diagrams as a reference to just how many very slight differences might go un-seen if not shown side-by-side.

  Are you sure? yes | no

frankstripod wrote 06/26/2015 at 21:19 point

@esot.eric.wazhung, Fantastic information!!! I must keep this in mind for Kicad. Recap:
1. Never cross MOSI and MISO! (oops!)
2. Put a ground trace in between parallel data lines.
3. Get info on "good practices" for PCBs. Any suggestions?
4.Use Red and Black wires for Vcc & GND so Eric can see. Not just
whatever I had laying around. Good thing I didn't mix up the colors on the same lines, like the 36 Touch Sensor Matrix project, but I should color code stuff more if I expect to get any help at all.

Should the trace lengths for MOSI and MISO on a PCB be the same? What trace width should they be?

As for the software, everything is in Arduino, so the SIP magic is in the libraries. I would have to spend decades to duplicate the work that Paul Stoffregen and Oleg Mazurov put into the software to make this all work (a good reason not to buy ripoff boards.) I am hoping to redirect the output from the USB serial monitor to the slaves. I think someone out there could get all five slaves to connect on the different SPI modes (I think Teensy 3.1 supports 3?), but they wouldn't be playing around with a handful of Arduino boards. If I had the knowledge, I would design a board with one processor and four FTDI chips, but I am just scratching the surface here, and appreciate ANY help.


Thanks again for all your help SPI Master :)

  Are you sure? yes | no

esot.eric wrote 06/26/2015 at 22:08 point

Eh heh... having one of those moments...

I think you could get away with a pretty wonkey PCB design without trouble, as long as all the traces go where expected and nowhere else ;)

Is it possible the crossing-over-wire's insulation just melted?

Sorry for the bombardment of SPI-fears, they don't seem relevant in this case, if you're using libraries designed to work directly with the USB->SPI thing. 

I imagined a two-library setup: e.g. SPI_init(mode); USBshield_init(); as opposed to a single-package which is probably already configured for the right mode...

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

frankstripod wrote 06/26/2015 at 23:20 point

Datasheet, awesome idea! I actually did read the 67 page datasheet a while ago, but failed to get enough information from it, likely due to lack of formal training. I really should try to go through it again. Most of it assumes I have an oscilloscope :( 

  Are you sure? yes | no

frankstripod wrote 06/26/2015 at 23:27 point

As for the wires touching, there was more space between the wires vertically (think 3D). I will put up a picture of the old set up that didn't work at the end of this log.

  Are you sure? yes | no

esot.eric wrote 06/27/2015 at 01:03 point

I assume this was in response to a message that was deleted...?

  Are you sure? yes | no

frankstripod wrote 06/27/2015 at 01:45 point

Yes, but still applies. I need to read it again.

  Are you sure? yes | no