after nearly 2 weeks of struggling my first LED blinking works under the following constitution:
-) Beaglebone black, Element14, rev.C
-) no OS → holding “boot” button, when powering
-) Code Composure Studio v6
-) Starterware (without BBB patch: http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html (DOES NOT WORK AT THE MOMENT)
-) XDS100v2 emulator
1.)
The maximum frequency for toggling the pin is 1.6 MHz,
but I need maximum speed.
In my understanding there is still a speed decrease as the system is running in emulation mode.
Correct?
2.)
From the build process of CCS I have got a .out file. What are the next steps to get the program running from the SD card?
Please be very precise - I have already heard of MOL, u-boot, GEL file,…,
but there does not seem to be a step-by-step tutorial.
3.) What are the next steps to get the program running from the eMMC?
You see, I want to do bare-metal C programming, without linux or any other OS,
as I must operate (pin toggling, computations,…) as fast as possible.
Starterware includes a bootloader that pulls a program from the SD card and loads it and runs it. As far as toggling the GPIO pins very fast, you're not going to get good results. This is an applications processor, not made for real time programming. That's why TI included 2 PRU units on the chip. If you want GPIO speed, that is the only way to go.
after nearly 2 weeks of struggling my first LED blinking works under the
following constitution:
-) Beaglebone black, Element14, rev.C
-) no OS --> holding "boot" button, when powering
-) Code Composure Studio v6
-) Starterware (without BBB patch:
1.)
The maximum frequency for toggling the pin is 1.6 MHz,
but I need maximum speed.
In my understanding there is still a speed decrease as the system is
running in *emulation *mode.
Correct?
I don't think emulation should slow you down if you are using hardware
breakpoints. The recommendations on using the PRUs would certainly result
in improved switching times, but I'm confident you could optimize your ARM
Cortex-A8 code quite a bit as well. Care to share your source and your
compilation options? Did you use "-O3" for example? Are you going through a
non-optimal library? Would you consider optimizing at the
cache/assembly/etc levels?
2.)
From the build process of CCS I have got a .out file.
*What are the next steps to get the program running from the SD card?*
Please be very precise - I have already heard of MOL, u-boot, GEL
file,....,
but there does not seem to be a step-by-step tutorial.
The StarterWare boot instructions as mentioned elsewhere should help. I
thought those instructions were fairly step-by-step. U-boot SPL (MLO) seems
like it would provide the most open and extensible examples. I suggest you
try writing the step-by-step.
3.)
*What are the next steps to get the program running from the eMMC?*
You see, I want to do bare-metal C programming, without linux or any other
OS,
as I must operate (pin toggling, computations,...) as fast as possible.
The eMMC looks just like an SD card to the processor. You simply need to
flash your code onto the eMMC the same way you would an SD card---except
that you can't remove it. You could boot over USB if you want to program
the eMMC without doing it from an existing system booted off of the eMMC or
SD ports. See GitHub - ungureanuvladvictor/BBBlfs: Flash your BeagleBone Black via USB.
thanks to the people who want to be helpful, but I really have to tell you that it is not easy to start (bare-metal programming)
with BBB.
Here are some of the troubles I ran into:
1.) Simple bare-metal from SD-card:
I installed the patch for starterware, when it was available for download again,
formatted a SD-card as descriped and put the new MLO file (which should work for BBB now) and the app file on it.
Inserted the SD-card into the BBB’s slot and booted by holding down the boot button while powering.
Nothing happens: No LEDs, no communication on the serial port.
2.) PRU programming:
I do understand that the main core is not intended for real-time programming,
so I try to do it on one of the PRUs, but XDS100v2 does not even connect to a PRU:
“The project … is not compatible with any CPU in the target configuration.”
3.) Emulation problems:
XDS100v2:
“Error connecting to the target: (Error -1266 @ 0x0)”.
Now one must figure out that he has to press Cancel (!) and wait about 8 seconds →
all of a sudden the emulator has got connection to the board and can execute the code.
4.) Documentation:
I spent 2 weeks on reading articles and documentations and most of the time I was a permanent
reader on forums. Often you find people who have exactly the same problems, but no solutions are
provided or the solution proposed did not work in my case.
I use CCS6 but what you find on the internet is for earlier versions, e.g., if you want to go through a tutorial
step-by-step, you are soon stuck, as you can’t find the settings in CCS6, which are shown for CCS5…
Are there people around, who are successfully doing bare-metal programming in C?
hi reinhardt. i know what u r going thru. i got a minimal standalone bare metal system up. see www.baremetal.tech
or github.com/ddlawrence
u made good progress, i hope u haven’t lost interest. i did it without ti tools whatsoever, so we have a fresh start.
get involved, i need help! we can subdue this beast and make the bbb into a hotrod.
hack on…dd
thanks to the people who want to be helpful, but I really have to tell you that it is not easy to start (bare-metal programming) with BBB. Here are some of the troubles I ran into:
There is a reason for this. The beaglebone is not meant to be used as a bare metal system. The processor is as Charles S has put it in the past. An application processor( Cortex A . . .) which will likely not perform better bare metal in many tasks versus using an OS. Sure, if you write your own event loop it will likely have less latency when compared to a stock Linux kernel. But that can largely be mitigated by taking stuff out of a working kernel that is not necessary for your purposes. As demonstrated by projects like Xenomai, etc.
So yes, you can run a BBB bare metal, but why you all are thinking this is a good idea is beyond me. If you’re learning, fine. I get that. But otherwise . . .
One thing to be aware of is the CortexA8 doesn’t perform very well if you don’t have Data and Instructions Cache enabled and you also have to have the MMU configured and enabled. For example, toggling a GPIO in Starterware with no Cache or MMU enabled, I get about 120KHz but if I enable both Cache and MMU, I get just over 12MHz.
Bare-metal is always going to out-perform linux and even an RTOS if done right. For beaglebone aka AM335x, start with Starterware. Over the past 3.5 years of working with beaglebone, I’ve developed a bare metal bootloader that enumerates eMMC over USB allowing you to drag and drop your MLO and app file directly. I have also written SD, USB device, usb host…etc drivers from scratch and benchmark this against similar functionality using linux (latest Debian) and my projects always get at least 2x the performance. For real-time stuff, linux just doesn’t suffice even when using PRUs. For instance, USB MSC with linux only gets ~8 MB/s for moving large files, I get ~18MB/s on average. Boot time is also insanely fast when done right with bare metal projects. I boot in ~2.2mS right now. I want to see Linux do that. However, like everyone is saying, its only worth bare-metal programming the beaglebone if you have the patience and time to do these projects. Otherwise, save frustration and use linux and get something working in hours instead of months.
Step1
Get the toggling working at desired speed using jtag this includes fully understanding what registers the gel file is programming by reading the TRM extensively.Make sure caches are enabled and code is optimized for speed.Without this the rest of the steps are pointless
No I don’t release my code to the public. Starterware has SD examples but they don’t work well. You could make improvements to it to make it work better.