As you might guess, this first bit is going to be a downer for those who designed the proto boards available for the BeagleBone. Clearly the board was designed without ever trying to use it for anything requiring manual part placement or old fashioned dips. I agree that not too many people still use dip components, but I have many little storage trays full of them. So my project needs two serial ports, actually all 4 would be great, and thus I need to put two MAXRS232 16-pin dips and one 74LVC245, a 20 pin dip on one of the proto boards. For about two hours, I sat there with both the BB proto cape, and an Adafruits proto cape, only to agree that there is no way you can put the chips on the proto boards - the boards are just too small.
In my trying to work with the boards, I realized many little facts about the design that show, the mint tins are cute, but no place to be putting a system. I have seen where people are now aware of this problem, where one of the adjustments for a new revision was moving components that are too close to the mounting holes. I have read several forum discussions asking for "clones" due I think to this lack of space problem. Some of my other insights are things like stacking, the sockets should be on the bottom not the top. The SD socket and USB connector would be better on the front as well, so all external accessible items are on one end. One problem with the proto boards is the mounting holes, only two are usable, the front two are either not there, or interfere with holes on the main board. So my feeling is cute design, now lets get serious and produce one we can actually use. I suggest a 3.25" snap track version for industrial mounting and use.
I am not doing this article to prove you can't use the proto boards, just that your probably not going to use them as you would certainly like to. That is actually what happened to me. I said, look, my project needs at least one working serial port and a second for trouble shooting when the network doesn't come up. I could use the default console interface, but on principle decided against that. I did my testing using one Parallax 3.3v serial to usb device, and a no-name TTL (5V) to serial adapter. I looked at the space on the BB proto cape and realized I could put socket pins to hold the Parallax converter, and there was just enough room to glue down the TTL converter as well. When I ordered the adafruit proto board, I also ordered #757, a 4-bit level converter. My testing showed me that the TTL converter had a level problem on RX and thus using the "level converter" might solve that problem (3.3V vs 5V).
To make a long story short, you can look at a picture of the BB proto cape supporting the two serial converters from a link at the bottom of the page ( I will add a schemaic later - the picture shows my working diagram with corrections and all). Not one of my better jobs, but all things considered it works. There are a few things to watch for if using the BB proto cape. First off the P8/9 pins are not pulled onto the proto area. That means you must wrap some pretty fine wire around the base of the pins and give them a light soldering so they sink into the solder already there. Not much space to do this, but it does work, and with care you can thread wires through the forest of pins without problems. I checked and when the boards are joined with the main board, the pins are just a few millimeters longer than needed and thus you have a small gap between boards. The BB proto layout is really odd, as the rows support dip usage, but somewhere how dips work was missed. They have three holes hooked together for your dip pins to go in, but then the next dip location is hardwired to the same pins, so you can only use every other dip row. You end up with two rows of dips, instead of 4, with a maximum of 14 inline pins (28 pin dip max). For me, having just two pins per dip pin would work just fine and give me enough rows to handle my three chips.
There is a project associated with all this work and it goes something like this. We have been using SiLabs boards and chips for many years now and developed a specific version of Forth called Myforth. The main person behind this is Charley Shattuck and with Bob Nash's help, this 8051 Forth creates assembly instructions that run pretty fast and efficiently. Bob has numberous products he sells under the BOBZ logo and I even host his documents on this site. Over the years we found using MyForth to work very well, until serial ports started going away. Now we have about a 50/50% chance that a USB to serial adapter will work at all when talking to the SiLabs boards. We found the FTDI chips work almost always, but it is almost impossible to buy USB to serial converters and know for sure that your getting an FTDI chip. What often happens is you get home only to find your system doesn't support the converter, or worse yet it does support it but so poorly you can't use it.
There have been other problems with setting up MyForth, it needs "gforth", and not all Linux versions have it, or have the latest version with good serial I/O functions. Version 7 of gforth broke the serial I/O ready flags and thus broke MyForth. The latest versions in the source tree fix the problem, but you need to build from source code, and oh by the way, you need a running version of gforth to build gforth for the first time. We have seen as well, problems related to the version of the OS, linux is easier to explain to people, but some still try running it on Windows where the USB adapters can appear and then just dis-appear for no reason at all. So we noticed a number of problems that just make explaining and getting others to be successful at using MyForth less than promissing.
Bob came up with a possible solution that he calls an "interposer" system. The idea is to use a cheap system we can get for under $100 and has real hardware serial ports, and add a version of Linux that is clean and straight forward with gforth and Myforth installed so that everyone has the same system. All instructions, training, tools, and such now relate to one system and all the user has to do from any system of their choice is ssh or serially connect with the "interposer" and follow our guided instructions in the MyForth manual. We think this will make the experience considerably more positive and easy to document. To this end, I had been trying to find under $100 systems, but really wasn't getting too far, until Bob went to a "Make" convention and he saw the BeagleBone. Since then it has been a busy few months for me as I mastered the system and today got MyForth talking to a SiLabs board from the BeagleBone.
My CCII articles starting with 21 and through 23 pretty much cover what I learned and had to do to make BeagleBone running Arch work. I settled on using Arch Linux because it worked as I thought it should and because I think they are doing it the right way for embedded systems. Having worked on numerous ARM systems, the Arch setup appears to be standard, where as others want you to build it all from scrath. For embedded servers and what I think we want to do, you need real tools like ssh and not a compact version that just barely supports the standards. I want full BASH, real Perl, MySQL, Apache, and anything I might normally use on my workstation. "busybox" is a fine shell program for small systems, but I want the real things. Remember that we want normal users to have an experience pretty much the same as they might get on their regular workstation and I feel Arch will come pretty close to that for them. I really wanted Debian, but the current version is not ready yet - maybe Jan 2013(?).
Let me say this however about Arch, I tried to install it on a x86 machine with less than good results. The web pages did give me fixes for almost ever problem I found, but it really was way too much to get a working system. As to ranking, Arch comes in about 15th overall and is over 10 years old. To say they are doing something right is true, as I really do like their reduced amount of init programs and the simple setup files that once learned make things pretty easy. For the ARM user this makes installation and setup pretty straight forward, as we really only want command line access and tools, we are not after a full desktop setup. One problem with Arch is their packaging is done constantly - meaning that they have the latest tools all the time. Not quite bleading edge, but pretty much bleeding stable edge. That is good and bad. The good is we get changes on a regular bases, but the bad is we can sometimes get a bug that having waited wouldn't be there.
This problem of being too new, is why I don't have the images for Arch running gforth and MyForth ready for you today. My current system updated to Kernel 3.2.21 last week, only to have problems with the network not starting correctly. Now I saw in the git kernel log this problem listed for several commits, and I suspect it might even be fixed, but I have been busy doing other things and found a work around until I can update the kernel. So two things, running pacman -Syu will update an ARM kernel as boot is mounted and accessible, and two, if you seem to have problems with your network not coming up, just "restart" it by doing "sudo" or as "root" "/etc/rc.d/network restart" from a login console. If your on one of the serial port for console, you will also need to run my "pinmux" script from inside the "rc.d" directory by putting the script there and adding the line "pinmux" to "rc.config" in the DAEMONS list of commands to run at init time. I cover this in other articles and will review the articles later to be sure it make sense.
"gforth" is available on Debian, but not on Arch. We need the latest version of gforth for a working serial setup and thus we must use the latest source version. The problem is you need a running gforth to build gforth from scratch. The work around is to install the source on a working x86 system that already has gforth installed. Build gforth to make sure the version you have is good and then run "make dist", which will genrate a "tgz" file of the source tree. You can then take this source tree to another platform, such as our ARM Arch and run ".configure", "make", and "sudo make install" and you now have gforth loaded and ready to use. There are two ways to get gforth source, from the main svn repository or as I will put on the Arch system, from the git "gforth-mirror". I like git since it is slightly better than svn, and is getting more tools all the time. To get your own gforth repo do "git clone https://github.com/earl/gforth-mirror.git", you will of course need git on your system, but most have it these days, after all, the kernel uses git. For those wanting the version I used to build on Arch, here it is.
I have a public copy of our MyForth git repo on this server and you can clone it as well. Just do "git clone http://www.kiblerelectronics.com/myf/myforth.git". You can find some discussions on git by looking at ccii_18 and ccii_19, where I just noticed I need to do some updating. If you would like to test our MyForth on a SiLabs TB120 development board, first clone the Myforth repo, then cd to "myforth/silabs/docs" section and read the MyForth manual. There you will find the needed steps to setting up the TB120 boot loader (using the normal SiLabs MS Windows based tools), after which you can load myforth programs without the MS Windows or jtag tools.
In the case of Myforth on Arch you will need to do a few things first, make sure the inittab is not turning on uart2 ( do "ps -ef | grep tty" and make sure there is no /dev/ttyO2" listed). If it is running "agetty /dev/ttyO2", you will need to edit the "/etc/inittab" line and put a "#" in front of the line with "ttyO2" in it. To kill the current "agetty" do a "kill -9 $PID" (as root) where "$PID" is the process ID associated with the running agetty you found when you did "ps -ef" - the first row of numbers following the owners name "root". Next, go to the "myforth/silabs/code/TB120" directory (from docs do "cd ../code/TB120") of example code for the TB120 SiLabs board. From there we need to make sure that the serial interface is looking for "/dev/ttyO2" and not "/dev/ttyS0" or "/dev/ttyUSB0". We do that by editing "vi ../source/amr/serial-linux.fs" from the "myforth/silabs/code/TB120" directory. Change the line 'here ," /dev/ttyS0"' to 'here ," /dev/ttyO2"' (that is capital "O" not a zero!), save the changes and you can then do "./d" and follow instructions to download the "temperature" program to the TB120. By hitting return you will see the forth prompt and type "go" to start an endless loop of screens showing the temperature of the TB120's CPU as an HTML page. Go back to the MyForth manual for more information on how to use and what the "./d" and "./s" commands are all about.
At this point you should have a version of the interposer system running if you followed the steps and have the correct SiLabs board. If not, you can see that creating a specific linux system for a single task really isn't too hard if you can find all the data you need. I must say it did take considerable time to get and sort all the data into usable form that you can now find in my article 21, 22, and 23. The "a5" table is extremely useful for those trying to get a better grasp on pinmux and P8/9. I used Arch for our interposer, but any number of Linux distributions can be used that have versions for ARM/BeagleBone. There are several "build your own", as well as Ubuntu or Debian that are currently going through changes that may prevent them from working. I will be providing images for the boot section and ext4 section of Arch running with gforth and myforth.
Hope you have fun and keep me posted if you find needed changes, as I did this article quickly to provide help to get Charley and Bob up to speed. Expect changes soon and often.
I just re-read and edited the above and apoligize for all the problems that slipped in while rushing to get article 24 done. It really needed more than 4 hours of work, but I knew it would be almost a month before I could get back to it and I thought that Bob and Charley couldn't wait that long to know what I did to make it all work. Why the delay, well most was personal, but some is due to the Bone itself. Let me explain.
A major issue for me was support software or the PSP. Version 8 was due early July in the SDK 5.05 release. TI is supporting the BeagleBone design and provides the software drivers used in the kernel in their SDK. However the release date got pushed, my order for the serial cape got pushed, and so I felt a litle delay might let the kernel drivers catch up with my interests. If you read my comments on the problem using the physical layout, you know I was less than happy. I had several layouts and ideas, all of which need the Bone to have pins out the backside so it can be mounted such that the underside is down. When using snaptrack, the boards are "snapped" into the track and the backside is then hidden. I as well figured that keeping to a 3.25" size would require traces under the Bone when mounted. There just doesn't seem to be enough board space to get all the traces from P8/9 if you have to cut a hole in the supporting board to allow for the network socket.
When you start trying to work all this out it becomes clear, pins out the bottom are needed, not only for a backside mount, but for being able to mount the Bone anywhere in the stack of capes, not just the bottom of the stack. So I followed several threads where people where trying to find clones of the Bone. It became clear that an email to Clint Cooley, the President of CircuitCo (manufacturer of the Bone), asking about a possible variation to the Bone was needed. My idea was that during the board assembly step, simply replace the normal P8/9 headers with the ones used for the Proto Capes. No real changes, just make some boards with different socket style - all else the same. I explained all this in my email, only to get his request that I call him, which I did.
We talked for about an hour, I explained what my ideas and problems were, he covered his options and constraints and said he would get back to me after talking with others. It seems that both TI and the open forum limit just what he can and can not do as to the design of the Bone. This explains why they want you to contract with them to build boards to your design, as thus it frees CircuitCo from any infringements on the original project and design. And by the way, once changed, it is a "white" board and as such does not have the "BeagleBone" logo, and I suspect you can't even call it a "Bone". That last has me wondering how I sell a "Bone" clone if you can't call it a "Bone." So much for my ideas of building special capes to support a variation of the Bone.
I ended up thinking real hard about the whole issue and came up with a new concept - "BOD" - or "Board Of the Day". A "BOD" is a product that is the "hot" item with all the focus, articles, and tools showing how to do this or that. The main deal with "BODs", is every few months or years, some new board is the new "BOD". For me that asks the question - do I want a design based on the BOD or something less volatile. One of the reasons to use the Bone was the serial ports as they gave us some isolation from hardware I/O needs. If we make a design based on the P8/9 header pin layout, and they change the assignments, our design just got broken. CircuitCo's solution is to have them build boards for you and thus you control the product for as long as you need it. However that is a big commitment and one of the features of the Bone is getting as many as you need, as the demand warrants from your regular supplier. Need four or five, no problem, needs hundreds then order "white" boards.
I feel some of the reasons the Bone is the BOD is both the cost and being available in small quanties from normal suppliers. What I found however was that the cost may go up, in fact Arrow sells them for $106 right now. You might try searching on Arrow's web site for "CircuitCo" products and you will see some "white" boards - unfortunately I can't get any facts about what the "white" boards are actually. I suspect the Bone's popularity will drop greatly once it goes up to the non-introduction pricing - it will certainly break our under $100 reqirement. However for me the main thing this project did was prove that we can use any BOD that has serial ports and uses some form of standard Linux distribution. Other than building the serial cape, everything we did was standard Linux system building. Make the design using serial ports and instant isolation from the hardware features. Make your design based on certain pins in P8/9 and your locked in for better or worse.
---- more later and still waiting for PSP 8....