question from a total newbie...

[mzimmers]

Hi, all -

I've decided to self-tutor in the area of embedded Linux. (I have embedded experience, and some Linux experience, but not together). I was thinking of getting a beaglebone for experimentation. I can't be more specific, because I don't know what I want to yet, other than learn some new skills.

 I have a few questions, if you please:

1. is the beaglebone platform a reasonable choice?

2. is there a particular model I should favor?

3. in the old days, we needed special devices (like flashers) for downloading programs. Do I need anything like this to use the board?

Thanks.

[William Hermans]

On Thu, Sep 29, 2016 at 11:39 AM, mzimmers <mzim...@gmail.com> wrote:

Hi, all -

I've decided to self-tutor in the area of embedded Linux. (I have embedded experience, and some Linux experience, but not together). I was thinking of getting a beaglebone for experimentation. I can't be more specific, because I don't know what I want to yet, other than learn some new skills.

 I have a few questions, if you please:

1. is the beaglebone platform a reasonable choice?

For what ? If you mean cost effective way to self teach embedded Linux. Then yes.
 

2. is there a particular model I should favor?

A what ?
 

3. in the old days, we needed special devices (like flashers) for downloading programs. Do I need anything like this to use the board?

No. You download or create a Linux image yourself. Copy it to sdcard, and either run that or use it to copy files to the eMMC.

The questions you're asking are subjective and rather broad. Which honestly most of what you're asking is something you're going to have to determine for yourself.

The beaglebone is much like the Raspberry Pi. In that it runs Linux, and is able to communicate with, and have an effect on devices connected externally. So either would work. However, where the beaglebone differs in the shear amount of I/O it's cable of. The hardware is far more open, and the beaglebone though it's amm335x processor has two PRU's( Programmable Real-time Unit ).

So where the Raspberry PI may have the advantage with "ease" of use in some cases. The beaglebone is far more flexible( in my opinion ). You can roll your own Linux image, thanks to Robert Nelson's eewiki guide, and customize to your heart content. The PRU's can handle a lot of Real-time tasks as well, without Linux getting in the way. So if you need something deterministic, the PRU's are probably what would be handling that task. All while communicating with Linux through . . . well most likely a set portion of memory in one way or another.

The Raspberry PI( rPI 3 in my own case ) is a pretty cool piece of technology to play with. But if you're serious about embedded Linux, with a very open hardware( and software ) model. Then the beaglebone is the place to be.

--
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/09888cf2-5402-432e-8f72-5c0d74662944%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

By the way the beaglebone comes with a pre-installed Linux demo image already on it. On the eMMC. So no sdcard is required, but is recommended.

[Graham]

The Beaglebone is a better choice than say, Raspberry Pi, since Linux is somewhat locked-down on the R Pi, which puts limits what you can do with it.

On the Beaglebone, there are multiple variations of Linux that are supported, and you are free to compile your own kernel variations and load and run them, also.

I would make sure you got something like a Rev C BeagleBone Black, with the 4G on board memory.  The earlier B and A versions only have 2GB on board memory.

To get going, you will also need a quality (2 Amp recommended) 5 Volt power supply to power through the "barrel connector." (Wall wart.)

example:   https://www.adafruit.com/products/276

A few uSD memory cards, preferably at least 8 GB in size, 

A method of writing those uSD cards (USB Adapter) from a host PC or Linux computer.

Example:  https://www.amazon.com/StarTech-com-External-Memory-Reader-FCREADMICRO3/dp/B00DFVZOCA/ref=sr_1_1

A USB to serial adapter cable, so you can directly access the command line on the Beaglebone from a PC or Linux host computer.

Example: https://www.adafruit.com/products/70   or    http://www.mouser.com/ProductDetail/FTDI/TTL-232R-3V3/

A book like:

Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux by Derek Molloy

or

BeagleBone Cookbook: Software and Hardware Problems and Solutions by Mark A. Yoder and Jason Kridner

--- Graham

=================================

[William Hermans]

On Thu, Sep 29, 2016 at 2:04 PM, Graham <gra...@flex-radio.com> wrote:

The Beaglebone is a better choice than say, Raspberry Pi, since Linux is somewhat locked-down on the R Pi, which puts limits what you can do with it.

This is mostly false. The images provided by the Raspberry PI foundation are rather "odd". However, just like with the beaglebone a user can create their own Linux images. Especially for the rPI2/3's. Since they are able to run armhf code like any other normal ARM system to date.

All one needs to know is which files need to be where( text config files, and device tree files, etc ). But, one thing I have not seen yet is instructions for creating, compiling, and "installing" a boot loader for these systems. Presumably one could setup and use a "stock( rPI patched )uboot for this task.

The hard part would mostly be finding good solid information on how the hardware is to brought up at, and prior to boot. The graphics processor is also hard to find good solid information on. 

[William Hermans]

By the way, just for clarity. You do not need hard float for the kernel as far as I am aware. As it is my understanding that floating point math in the kernel is "forbidden". However, many userspace tools, apps, and perhaps the userspace side of any kernel module may need hard float.

[Graham Haddock]

Hi William:

For an expert, you are totally correct.

For a newbie, the Raspberry Pi images seem to be designed to limit how much tinkering you can do with Linux itself.

The tools and examples for modifying Linux itself are much better supported on the Beaglebone.

Both are good for blinking LEDs and simple embedded programming experiments.

--- Graham

==

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/memdbJws72M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrRAr_UiSPjcunOnizT_zRwu%2Boc5_y5qVedmMCPVXLA8g%40mail.gmail.com.

[William Hermans]

On Thu, Sep 29, 2016 at 2:25 PM, Graham Haddock <gra...@flexradio.com> wrote:

Hi William:

For an expert, you are totally correct.

I would argue the other way around. the rPI's have stuff like 'wiring', and are a lot like the Arduino's in many ways. Only running Linux. Me, I'm not a big fan of anything "Arduino" though . . .

For a newbie, the Raspberry Pi images seem to be designed to limit how much tinkering you can do with Linux itself.

There is a lot more information out there for doing many things. Specific to the Raspberry PI's versus the beaglebone. However, a lot of that information is universal. One only need understand the hardware, and the software which runs it.

The tools and examples for modifying Linux itself are much better supported on the Beaglebone.

They both use the same tools, or can.  User space tools, apps, compilers, etc.
 

Both are good for blinking LEDs and simple embedded programming experiments.

The rPI( at  least mine ) only has one LED.

Dont treat this as an rPI endorsement however. I much prefer the beaglebone in most cases, but the rPI, specifically the rPI's has many good points too.

[William Hermans]

Dont treat this as an rPI endorsement however. I much prefer the beaglebone in most cases, but the rPI, specifically the rPI's has many good points too.

Raspberry PI 3

[mzimmers]

Thanks for the detailed answers. Do I really need to use an SD card for transferring the kernel to the beaglebone? Seems kind of cumbersome, so if there's another way to do it, I'd appreciate hearing about it.

mz

[William Hermans]

Thanks for the detailed answers. Do I really need to use an SD card for transferring the kernel to the beaglebone? Seems kind of cumbersome, so if there's another way to do it, I'd appreciate hearing about it.

No you do not. You could create a *deb file, or other package manager file from your compiled sources. But that is by far more cumbersome. Robert does however make many kernel packages availible through APT for debian . . . so it's just an:

$ sudo apt-get install linux-image-<version> away.

On Thu, Sep 29, 2016 at 3:10 PM, mzimmers <mzim...@gmail.com> wrote:

Thanks for the detailed answers. Do I really need to use an SD card for transferring the kernel to the beaglebone? Seems kind of cumbersome, so if there's another way to do it, I'd appreciate hearing about it.

mz

--

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/757bc116-a375-480f-a77a-8f0542be33e1%40googlegroups.com.

[William Hermans]

mzimmers,

Do yourself a favore and get this book: https://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded-ebook/dp/B00QMIYWQM

It's probably not the best book for the experienced, or "Expert". But for someone new to this particular discipline. It'll be more information than you absorb in several months. It'll make an excellent reference. 

[Dennis Lee Bieber]

On Thu, 29 Sep 2016 14:12:56 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>The hard part would mostly be finding good solid information on how the
>hardware is to brought up at, and prior to boot. The graphics processor is
>also hard to find good solid information on.

Especially as the graphics processor performs the initial boot loading
of the RPI.

If one needs significant number crunching capability, the RPI-3 would
be the choice -- even with the 64-bit A53 quad-core crippled by using a
32-bit variant of Debian, compared to the 32-bit single-core BBB.* The
RPI-3 also has on board WiFi#

For GPIO, however, the BBB wins. Especially since, in a "real" embedded
application, the odds are good you can fit the code on the eMMC and not
need a slow $$$ SD card (save the SD card slot for data logging <G>).





* I've recently run the HINT benchmark for (data/index) float/int,
double/int, double/longlong, longlong/int, and longlong/longlong
(strangely, the RPI-3 double precision runs showed better performance than
a Zynq ZCU102 [A53 quad-core] using bare-board executables -- but the Zynq
excelled at longlong modes). Took all night on the RPI-3 as hitting the
1.5GB swapfile on SD card was a brick wall <G>; the Zynq had no swap so its
tests just ended when out of heap space -- BBB/RPI-3 both had OS kill the
process if I had no swap.

#Since my main computer was spending the day in a CHKDSK operation, I had
the RPI-3 connected to my upstairs TV with Logitech keyboard/mouse, and SSH
into the BBB connected downstair to the router.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[William Hermans]

One more thing, sorry . . . multi-tasking. . .

As Graham mentioned above. You'll probably want to start off with a Beaglebone black RevC. But my motivation in recommending this would be slightly different. I've been using an A5A for over 3.5 years, and in the last 1.5 years have been mostly using an Element14 RevC. It's been pretty solid, but I personally do not specifically need the 4G eMMC. You mileage may vary.

But the only reason why I bring this up is that the Beaglebone  Green Wireless has been having driver issues with the wifi module. So unless you can deal with the "headache" of largely trouble shooting these issues yourself. I'd stick with the black until you feel competent.

I've also have had hands on with around ~30 Beaglebone green recently for a customer. As far as I can tell they're every bit as good a Beaglebone black too. But, I've been seeing posts on the groups here of people having issues with creating images that work on both . . . again your mileage may vary.

[William Hermans]

If one needs significant number crunching capability, the RPI-3 would
be the choice -- even with the 64-bit A53 quad-core crippled by using a
32-bit variant of Debian, compared to the 32-bit single-core BBB.* The
RPI-3 also has on board WiFi#

I wouldn't say crippled. The only real benefit to having a 64bit OS is to address more than 4G memory total. Since the rPI3 only has 1G ram . . . I'd say it's a moot point.

With that said, I've compiled Nodejs 4.6.2 on both platorms. The rPI3 takes less than half the time to compile rom the same sources, using the same compiler.

--
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/7m9rubpt6hbautks70jovr09jl60djvgov%404ax.com.

[Dennis Lee Bieber]

On Thu, 29 Sep 2016 15:10:28 -0700 (PDT), mzimmers
<mzim...@gmail.com> declaimed the following:

>Thanks for the detailed answers. Do I really need to use an SD card for
>transferring the kernel to the beaglebone? Seems kind of cumbersome, so if
>there's another way to do it, I'd appreciate hearing about it.
>

Typically one generates a complete OS system on the SD card, and
configure it to flash the entire eMMC with the entire OS.

If you can configure kernel images in a form that apt can handle, sftp
to the eMMC followed by apt on the image file might be a viable option.
I've not done anything like that (I've stayed with prebuilt OS images).

[William Hermans]

Not only that but if you make a mistake, and render the eMMC unbootable. How would you fix it without an sdcard ? Short answer is that you can't. But with an sdcard, you'd insert the "emergency" card, revert the changes you made, then power cycle the board ater removing the sdcard. viola! problem solved.

I would also highly recommend getting a 3v3 ttl USB serial cable. They don't have to be the FTDI $20 cabled. One like this: http://www.ebay.com/itm/like/231721779803?lpid=82&chn=ps&ul_noapp=true would work. Think we picked up 2 off ebay for less than $5 including shipping.

You just need make ABSOLUTELY SURE the serial side is 3v3 logic. Or you risk damaging the beaglebone's processor.

--
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/jmarub5b0i45c9u47n6km6egijvivsqekp%404ax.com.

[Graham]

mz:

You used the term "transferring the kernel" which set off a discussion.

I have been programming on the BBB for several years, and have not had to touch the kernel, which is part of the OS image.

Some people want to learn kernel programming. OK

.

In my case, for any application development I have done, stock kernels have worked fine, and you can load new application code into a running BBB many ways.

I use an SSH transfer over Ethernet from my host computer. For standalone applications, you don't have to stop or reboot the BBB.

The only requirement is that you stop any application or executable of the same name, so that Linux lets you overwrite it.

You will get as many opinions on tool chains as there programmers.

I generally do application/executable development in "C". Use Eclipse as the IDE, GCC cross compiler, running on a Linux desktop, or Linux on a VM running on a PC.

Eclipse has an option to automatically transfer an executable (SSH over Ethernet) into the target BBB as soon as it compiles.

Derek Molloy's book and his website videos tell you how to configure all of this.

--- Graham

---

On Thursday, September 29, 2016 at 7:13:30 PM UTC-5, William Hermans wrote:

Not only that but if you make a mistake, and render the eMMC unbootable. How would you fix it without an sdcard ? Short answer is that you can't. But with an sdcard, you'd insert the "emergency" card, revert the changes you made, then power cycle the board ater removing the sdcard. viola! problem solved.

I would also highly recommend getting a 3v3 ttl USB serial cable. They don't have to be the FTDI $20 cabled. One like this: http://www.ebay.com/itm/like/231721779803?lpid=82&chn=ps&ul_noapp=true would work. Think we picked up 2 off ebay for less than $5 including shipping.

You just need make ABSOLUTELY SURE the serial side is 3v3 logic. Or you risk damaging the beaglebone's processor.

On Thu, Sep 29, 2016 at 5:02 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

On Thu, 29 Sep 2016 15:10:28 -0700 (PDT), mzimmers
<mzim...@gmail.com> declaimed the following:

>Thanks for the detailed answers. Do I really need to use an SD card for
>transferring the kernel to the beaglebone? Seems kind of cumbersome, so if
>there's another way to do it, I'd appreciate hearing about it.
>
        Typically one generates a complete OS system on the SD card, and
configure it to flash the entire eMMC with the entire OS.

        If you can configure kernel images in a form that apt can handle, sftp
to the eMMC followed by apt on the image file might be a viable option.
I've not done anything like that (I've stayed with prebuilt OS images).
--
        Wulfraed                 Dennis Lee Bieber         AF6VN
    wlf...@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--
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...@googlegroups.com.

[mzimmers]

Thank you, Graham. I just ordered a starter kit and Mr. Molloy's book from Amazon. Come next Monday I'll have something to tinker with.

I appreciate everyone's input.

mz

[William Hermans]

Well, there seems to be a lot of confusion between toolchains, which no one really asked or said anything about( I made a passing remark ), Linux kernel, and Linux image. My own idea of what makes a Linux image is a complete "package" that contains bootloader(s), a Linux kernel, and a rootfs(root file system ), and assorted other files. In other words, anything / everything needed to run a complete boot-able image.

As far as compiling C from source. I do not recall the OP asking or that information.

--

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/b79ae34c-8f78-442e-a5bf-817b790de0c6%40googlegroups.com.

[William Hermans]

mz,

While the subject has been brought up. If you've had any experience with Linux development in the past. This experience would largely be the same. You do not need a cross compiler or 99.9% of what all is out there, and the chances you'll need a cross compiler toolchain, and IDE are near nil.

For instance, my own setup is a bit "complex" in setup, but makes my own daily development very simple. I started off with a seperate Debian system running Samba, and an NFS share specifically for the beaglebone. Like so:

william@beaglebone:~/dev$ df -h .
Filesystem                           Size  Used Avail Use% Mounted on
192.168.254.162:/home/william/share  136G   51G   79G  40% /home/william/dev

I then use Samba to share this same directory out to my main Windows development system. Where I simply edit code in either Sublime text, or Visual Studio Code. Any text editor that works for you will be fine. But the point of this whole setup is that I have a central place to store all my source, where my Windows development system can access those files as if they were local files(  because of Samba, and Windows " Map Network Drive").

Once finished, it's a simple matter of:

$ gcc -Wall source_file.c -o target_binary_name

Depending on how complex your source is, it may be better to use makefiles, but that's a subject I try to avoid myself . . . there are all kinds of build tools in this area.

Honestly, in three and a half years. Short of tinkering with compiling my own kernel. I've never had to cross compile anything. The above setup though is how one would avoid writing( through compile from source ) to the eMMC, or an sdcard. Which will help keep from prematurely destroying either. Another way, for small projects would be to setup a tmpfs ramdisk, 64M, or even 256M( yes I've personally used 256M occasionally ). You would just need to make sure to copy your changes, if needed to someplace safe. cp /path/* target, mv /path /target, or even setup a cron job to rsync the files to another location every few minutes . . . Again, the only limit here is your imagination.

[William Hermans]

. . .and the chances you'll need a cross compiler toolchain, and IDE are near nil.

For your own code. Unless you're one of *those* (them?!) code zombies who eat's sleeps and breathes caffine. Writing 5M lines of bug ridden code a day ;)