On Mon, Jan 30, 2017 at 12:24 PM, 'woody stanford' via BeagleBoard < beagleboard@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 == -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CANN_KV7gXcLgOCpK%2B_gmZtxrLzLphTEOL_4HOQp7%3DHx33O9Jcw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
