I made a Youtube video on SPI -- Feedback welcome! - Page 1
Forum section: electronics / general

author: clifford
author_rank: Regular Contributor
timestamp: September 22, 2013, 08:26:04 pm
content: Hello everyone,I made a Youtube video on SPI and SPI Modes. It's my first video, so I'm basically trying out the format and want figure out what works.http://youtu.be/WP9UBbigj3EI'd appreciate your feedback.

author: free_electron
author_rank: Super Contributor
timestamp: September 22, 2013, 09:41:38 pm
content: Pretty good for a base overview of SPI. well doneA couple of things though:- SPI does have a standard. It is owned by Motorola ( now ON semiconductor). It is a 'standard' just like I2C is a standard. It is not ratified by a commitee (neither is i2c).- SPI is a trademark of On semi. just like I2C is a trademark of NXPone important thing you did not mention : there is no fixed packet length ( unlike in i2c where everything happens on 8 bit boundaries)

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 22, 2013, 09:44:12 pm
content: Nice video.

author: clifford
author_rank: Regular Contributor
timestamp: September 22, 2013, 10:24:07 pm
content: Quote from: free_electron on September 22, 2013, 09:41:38 pmyou are right, of course.I've also crossposted your comment on the subredit so it can be found from the video easily.

author: clifford
author_rank: Regular Contributor
timestamp: September 23, 2013, 12:37:06 am
content: Quote from: wilfred on September 22, 2013, 11:57:08 pmThanks! I really appreciate it.Quote from: wilfred on September 22, 2013, 11:57:08 pmI'll experiment with different settings before making my next video. thanks for the advice.Quote from: wilfred on September 22, 2013, 11:57:08 pmI made them in Inkscape. It was not too much trouble for this small diagram. I just painted the one for SPI mode 0 and made the others from modified copies of the first one.I a paper or other document I would usually use the tikz-timing LaTex package. That, of course, only helps if you happen to use TeX already for typesetting..Quote from: wilfred on September 22, 2013, 11:57:08 pmYes. I noticed this when cutting the video. I will try to be more careful in choosing the timebase on the oscilloscope next time.I spend a lot of time getting the multi-camera setup to work, btw.It's still not working perfectly though.

author: BravoV
author_rank: Super Contributor
timestamp: September 23, 2013, 12:47:27 am
content: Good video, especially considering thats your first one !Thanks and keep them coming !

author: robrenz
author_rank: Super Contributor
timestamp: September 23, 2013, 01:14:24 am
content: Nice video

author: FrankBuss
author_rank: Unknown
timestamp: September 23, 2013, 07:16:37 am
content: Quote from: free_electron on September 22, 2013, 09:41:38 pmTheWikipedia articlesays that only the I2C logo is registered, not the name I2C, and patents on I2C have now lapsed. And I can't find anything about the SPI trademark, do you have a reference? The Wikipedia article says it was named by Motorola (now Freescale).

author: EEVblog
author_rank: Unknown
timestamp: September 23, 2013, 07:24:44 am
content: Nice work, great first video!Just a few small things to keep note of when doing videos.Use manual exposure were possible, and as was mentioned, turn it up a bit for full white. Auto exposure which change the brightness of the image a bit when you move your hand in the frame.Did I detect a slow shutter speed on the oscilloscope part?The screen capture was a bit blury. Capture using a fixed 1280x720 window size so the edit software doesn't do any rescaling. And the 1280x720 gives a much better readable result than full HD 1920x1080. A lot of people make this mistake and capture in full HD or just any size that fits the program window.Video compression seems a bit high. Fine for a podcast/iPhone version, but you want the best quality for Youtube. You can notice this with moving images.Unless you want to show scope control operation, will the entire video frame with the DSO window.

author: clifford
author_rank: Regular Contributor
timestamp: September 23, 2013, 09:36:43 am
content: Quote from: EEVblog on September 23, 2013, 07:24:44 amYes. I still need to find the right render options.Quote from: EEVblog on September 23, 2013, 07:24:44 amThe scope is recorded using a webcam with fixed focal length (Logitech C310). If I push it closer, the scope will just go out of focus. I could only crop the image in editing. Maybe I'll do that next time for the picture in picture, where the image is rescaled anyways.

author: PA0PBZ
author_rank: Super Contributor
timestamp: September 23, 2013, 06:11:41 pm
content: Very nice done, I learned something again today!Including why you did not get the expected result from 0xf0 + SPI_MODE, the answer is in spi.h:#define SPI_MODE0 0x00#define SPI_MODE1 0x04#define SPI_MODE2 0x08#define SPI_MODE3 0x0C

author: jancumps
author_rank: Unknown
timestamp: September 23, 2013, 07:09:31 pm
content: I liked the video very much.I did have a strange sound effect when listening with headphones, a kind of phasing effect.

author: Thor-Arne
author_rank: Unknown
timestamp: September 23, 2013, 07:18:35 pm
content: Nice video

author: jancumps
author_rank: Unknown
timestamp: September 24, 2013, 09:02:58 pm
content: Quote from: PA0PBZ on September 23, 2013, 06:11:41 pmTo help my ageing brain:do you mean that clifford is expecting a hex 0 -> 4 when he actually gets a 0 -> C , or am I missing something obvious here?

author: Unknown
author_rank: Unknown
timestamp: September 24, 2013, 10:39:06 pm
content: Nice video but I was a bit confused in a couple of places, I think at 21:27 you say enter serial mode MODE 1 but then enter 0 on the terminal which was a bit confusing.Also the second transfer call you make always showed 0xFF on the scope was it meant to show the value of 0xF0 + SPI_MODE ?Quote from: jancumps on September 24, 2013, 09:02:58 pmI've never actually used SPI but I think the first scope example the byte sent is 0xF0 + 0x00 , which comes out like 1111 0000, then the next example 0xF0 + 0x04 which comes out like 1111 0100 etc but the second byte 0xFF from each scope capture is always the same1111 1111, because the bit of code always returns 0xFF.0000 0000, because the bit of code always returns 0x00Code:miso_data = SPI.transfer(miso_data);

author: clifford
author_rank: Regular Contributor
timestamp: September 25, 2013, 04:39:38 am
content: Quote from: jucole on September 24, 2013, 10:39:06 pmNo. In the 2nd transfer the byte received during the 1st transfer is sent:Code:miso_data = SPI.transfer(0xf0 + spi_mode);miso_data = SPI.transfer(miso_data);In the test setup the miso line was connected to ground. So the master always receives zero bits and therefore miso_data is always 0x00.

author: jancumps
author_rank: Unknown
timestamp: September 25, 2013, 04:53:50 am
content: Ah yes, I get it now.

author: Unknown
author_rank: Unknown
timestamp: September 25, 2013, 07:06:21 am
content: Quote from: clifford on September 25, 2013, 04:39:38 amok, I see; I must say though - it's a good tutorial and I hope you do some more!I now know SPI kungfu!

author: usLEDsupply
author_rank: Newbie
timestamp: October 07, 2013, 02:07:56 am
content: Great job on the video i learned a lot:-)I also liked the part showing the code.I wish i would have seen that a few years ago (it would have saved a lot of time figuring out how it worked)i hope you do some more videos

author: konatsu
author_rank: Newbie
timestamp: October 07, 2013, 07:32:31 am
content: Nice video