Of SPI and such

[woody stanford]

I'm of the opinion that a lot of the terminology being used is being mixed, slurred, shifted in such a way to make basic concepts difficult to understand. I thought I would just talk about it.

What is SPI? You can use the terms UART and SPI interchangably. Bear with me on this...my point is cultural. SPI is ***serial***, asynchronous (in that it doesn't require a clock line, it uses timing purely) and 0V meaning zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V to represent one is acceptable.

This whole idea about SPI "throwing ioctl errors" is preposterous based on the previous. SPI is generated by a UART, a chip, a piece of hardware (that you can code a software UART not withstanding). SPI is the protocol that is the raw output of a UART.

I2C is understood to be (1) a protocol that uses a clock signal in conjunction with a data line, and (2) has something to do with being able to multiplex several "peripherals" at the same time with allusions to being the little brother of RS485. And no one really knows what CAN does, only that it is there and is comforting to know that you can connect as many things to your CPU as you could possibly conceive. It is a mystery lol. 

That we are being held hostage by electrical engineers and the whole microcontroller community does in no way change the fact that the BBB is a true UN*X host. Its just the way that it is.

Which leads to the inevitable question, why this ambiguity regarding the correct procedure to configure and utilize the P8 and P9 connectors. This is a TRIVIAL issue on a microcontroller. You just set the configuration registers such and communicate. Why this ambiguity on the BBB, whether real or perceived? I suppose that someone in authority at Beagleboard has to settle the issue for the prime path to success in using the P8/9 connectors. This ambiguity is killing me. Does libpruio do it? I don't know :)

My understanding of it is thus (and I'm sure its inaccurate and I beg someone to definitively explain it better so that I might understand), that it is a combination of a systems administration task combined with a programming task, that both must be done in order to unlock the potent connectivity powers of the BBB's P8 and P9 headers.That the crux of the issue is two fold, that I must add some lines to various configuration files so that it activates the ttyO1 thru ttyO6 "terminals" which allows civilized serial (and other communication like GPIO) to happen. My instincts tell me that this pertains intimately to the UN*X concept of a "stream", a concept of power and thus an element of our UN*X faith.

Is this so? And if not, how is it? Is my question to the minds greater than my own.

Thenwe use such programming concepts such as fopen() and open() to communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, universal connectivity.

Thoughts?

[Graham]

Woody:

SPI and Serial Data from a UART are very different.

SPI is synchronous with a supplied clock.  All that is sent on the data line is data.

Addressing is via a separate "Chip Select" line.

UARTs and their serial data are a legacy serial communications system from the teletype days.

There is no clock sent with UART.  It adds start and stop bits to frame the data as overhead, and requires that the independent clocks at the sending and receiving ends are within 5 percent of each other, or so. If you add a second stop bit (an option), then your independent send and receive clocks can be over ten percent apart. There is no explicit addressing. It is up to the receiver to figure out who the message is for.  The large permitted errors in clock frequency date from the time that quart crystals were extremely expensive, and therefore not a solution. The "clocks" were mechanical flyweight centrifugal regulators.

--- Graham

==

[woody stanford]

Hmmm. And I thought I was "old school".

http://www.mouser.com/ProductDetail/IQD/LFXTAL003185Bulk/?qs=sGAEpiMZZMsMyYRRhGMFNt26FzbIzMCTJO3fmLZxTac%3d

We all know what SPI is.

[woody stanford]

You are obviously knowledgeable, Graham, so we'll pose these questions to you then.

(1) Is serial (ie. UART) communication on a BBBW (Rev C) Angstrom "distro" (ie. stock) done with the ttyO1 to ttyO6 "terminals". Is this HOW it is done? Elaborate if you feel the need. (Hoping he's going to say yes to this so I can just use stdio.h and feel confident about it)

(2) What is THE accepted procedure(s) for enabling PWM/UART/TIMER/GPIOs on a BBB? Is it as they say by manipulating the uEnv.txt file, or would the pin-config utility be better, or am I mistaken here as well?

Not so critical but interested on your opinion:

(3) How do you feel about, at the board level, running a BBB's UART's TX to a bunch of RX's on (slave) MCU's, and then using a 1 byte "address" to figure which MCU the following byte(s) were for?

(4) Conversely, how do you feel about, again at the board level, running the MCU's UART TX's all to one bus wire and connecting that to the BBB's RX. Electrically and otherwise I mean? And then prefacing each transmit with a 1-byte "address" so the BBB knows which MCU the following byte(s) is comming from?

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:

[woody stanford]

Furthermore, how about putting a byte after the address byte with the length of the "frame" (and I use this term loosely) using the BBB as master (for collision avoidance, I mean) with each MCU only speaking when spoken too? Just thinking out loud lol.

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:

[Graham Haddock]

On Mon, Jan 30, 2017 at 12:24 PM, 'woody stanford' via BeagleBoard <beagl...@googlegroups.com> wrote:

You are obviously knowledgeable, Graham, so we'll pose these questions to you then.

(1) Is serial (ie. UART) communication on a BBBW (Rev C) Angstrom "distro" (ie. stock) done with the ttyO1 to ttyO6 "terminals". Is this HOW it is done? Elaborate if you feel the need. (Hoping he's going to say yes to this so I can just use stdio.h and feel confident about it)

Do you really mean Angstrom? If so, switch to one of the current Debian distros as fast as you can.

ttyO1 to ttyO6 are not "terminals."  A terminal client would use ttyOx to access the corresponding UART based serial ports.

The "stdio.h" equivalent for serial communications is "termios.h" .   I suggest you Google that and start reading. Look for things like "Programming with Termios".

(2) What is THE accepted procedure(s) for enabling PWM/UART/TIMER/GPIOs on a BBB? Is it as they say by manipulating the uEnv.txt file, or would the pin-config utility be better, or am I mistaken here as well?

There are many ways to enable an IO on the Beaglebone. Custom .dts/.dtb, Universal I/O, or use the pre-compiled overlays you access from uEnv.txt.

I usually find that for a serious application, I am just better off doing a custom .dts/.dtb for my application, so I am in control, and know everything that is going on.

If you only want to do one or two things for a simple application, the overlays work fine.

But, for instance, if you are using audio streaming from the McASP as part of your application, you have to start with a different base .dtb, that I am not sure has been tested for compatibility with all the overlays.

Not so critical but interested on your opinion:

(3) How do you feel about, at the board level, running a BBB's UART's TX to a bunch of RX's on (slave) MCU's, and then using a 1 byte "address" to figure which MCU the following byte(s) were for?

Lots of serial protocols do things like that.  If it is a closed system, and you are in control of both ends, should work fine.

 

(4) Conversely, how do you feel about, again at the board level, running the MCU's UART TX's all to one bus wire and connecting that to the BBB's RX. Electrically and otherwise I mean? And then prefacing each transmit with a 1-byte "address" so the BBB knows which MCU the following byte(s) is coming from?

 

See (3).  Sounds like you are re-inventing Ethernet.

The fun begins when you want status back from the slaves, and now you have to build a custom bus receive combiner that adds everything back together from the slaves.  And an overlay protocol that deals with bus collisions, if the slaves can autonomously speak without being polled.

--- Graham

==

[woody stanford]

Thank you for the quick and informative reply, Graham.

So ttyOx IS the UART abstraction that is used by UN*X typically? So I should just be able to fopen (speaking C) /dev/ttyO1 and have read write stream access to the TX and RX pins of UART1, assuming of course I've setup the "overlays" correctly? Is my question.

Sorry, just so used to being able to read from and write to COM1, that this process sounds so involved.

I have some PIC's that want to make serial love to my BBBW is all. And I'm not used to letting my PIC's down. I will have you know that my PIC16Fx's are pretty good "bitbangers" themselves.

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:

[Graham]

Simple answer, yes.  

As part of fopen, you need to flush and set up the buffers, and decide whether it is blocking or not, and check for initialization errors, but once you get the hang of that, it is not hard.

Being a "legacy" protocol, serial is very mature, and lots of good example code out there, that has not needed revision in the last 20 years. 

All of this dates to the dawn of UN*X.

The operator console on the very first UN*X machines were teletype (tty) machines or early electronic terminals that emulated teletype machine serial communications.

Your PICs will enjoy talking to ole Grand Dad.

--- Graham

==

[woody stanford]

The answer I was looking for. Thank you much Graham. A yes...this is good as now I have control of my BBB UARTS from C (and thus python, etc. etc.)

My next question might be an elaboration on how to access the GPIO/SPI/I2C/CAN/ADC however I have the magic key to BBB because I'm lazy and I can just break everything out to external MCU via UART. Clever huh?

My PIC's have bad ass multichannel 10-bit ADC, and I do the PWM in software which gives me absolutely perfect wave form control. I can even slow down my motors before stopping them at 20 Mhz on my PIC16Fx. I mean I'm not YouTube needing DMA-driven super streaming capability for my next round of financing. I'm just me.

I just want GPS, 9DOF accel/gyro with magnetometer calibration, RS485, MAX232, thermistor, pressure, stepper motor and industrial-strength servo motor control. I don't ask much. Not to mention ganged isolated MOSFET power handling and relay board capability. You know...the usual. :)

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:

[mickeyf]

If you want one 'thing' to talk to a bunch of 'things', or a bunch of 'things' to all talk to each other, you should read up on that mysterious CAN stuff. That is exactly what it was designed for.

[William Hermans]

No way in hell CANBUS is going to keep up with multi channel ADC samples at faster sample rates. If one needs fast, or super fast sampling, the only real option is going to be SPI.

So using the on die ADC last year I did a bit of a test to see how much data really would be written out to "disk" from reading from the ADC's for a constant 200ksps over . . . You know I do not remember the time frame, but it was for a total of 2M samples I think. 2M samples in text form came to a total of about 9M in size on disk, and I seem to recall 2.5M-3M per second. Averaged. CanBUS is 1Mbit/second max, which does not even come close. Somewhere around 24x too slow. But the point is, if you need a serious amount of ADC samples  sent out remotely, the only real option would be Ethernet. Which could be as simple as setting up an NFS mount on the beaglebone. e.g. the storage is remote, but the beagleobne writes to that storage as if it's local, and it's pretty fast. ~10M/s +

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/20778ea6-ca26-46b7-8911-fd120cfdfdd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

On Tue, Jan 31, 2017 at 8:08 PM, William Hermans <yyr...@gmail.com> wrote:

No way in hell CANBUS is going to keep up with multi channel ADC samples at faster sample rates. If one needs fast, or super fast sampling, the only real option is going to be SPI.

Sorry, I meant to say ethernet here. Was thinking about interfacing and "exit strategy" at the same time ;)

So using the on die ADC last year I did a bit of a test to see how much data really would be written out to "disk" from reading from the ADC's for a constant 200ksps over . . . You know I do not remember the time frame, but it was for a total of 2M samples I think. 2M samples in text form came to a total of about 9M in size on disk, and I seem to recall 2.5M-3M per second. Averaged. CanBUS is 1Mbit/second max, which does not even come close. Somewhere around 24x too slow. But the point is, if you need a serious amount of ADC samples  sent out remotely, the only real option would be Ethernet. Which could be as simple as setting up an NFS mount on the beaglebone. e.g. the storage is remote, but the beagleobne writes to that storage as if it's local, and it's pretty fast. ~10M/s +

Additionally, and this relates to my comment above. Technically, the all out fastest possibility here would be USB. I did manage to achieve ~20M / second writes a few years ago. Using an externally powered IDE<->USB enclosure. I also have an enclosure here with a much better controller, just have not had the time to replace the disk for a good test. The controller is of the USB 3.0 variant, and should show just how much the USB 2.0 bus on the Beaglebone can handle. *shrug*