problem with makfile

[jbush]

I'm having a really hard time executing a makefile for the Cambridge University baking pi lesson 1. In a directory, I have dir template, containing (dir (build), dir source, containing ( main.s,), kernel.ld, MakeFile, and LICENCE ). I am using Windows 7 , I have downloaded GNU toolchain & using the gcc command prompt. in the dir with all the mentioned files and typed in "make," and get-- "'make' is not recognized as an internal or external command, operable program or batch file.". In the lesson one text it simply says "Open a terminal on your machine and type “"make"”".
I am using the gcc-arm-none-eabi-4_8-2013q4-20131204-win32 toolchain.
Any help would be appreciated. Thanks!

Posts: 1
Joined: Tue Mar 25, 2014 1:48 pm

[Tarcas]

sudo apt-get install build-essential
I believe this package contains make, among other useful tools for compiling your own programs.

Edit: Sorry, missed the part where you said you were doing this on Windows 7.

[topguy]

"sudo apt-get" is probably not going to work on a Windows 7 machine....

I don't know what "gcc command prompt" is but I guess you will need a windows version of "make" somewhere.
http://gnuwin32.sourceforge.net/packages/make.htm

And you'll probably have to edit the makefile to point to where your compiler is located.

[MrEngman]

I'm having a really hard time executing a makefile for the Cambridge University baking pi lesson 1.

I am using Windows 7 , I have downloaded GNU toolchain & using the gcc command prompt.

Are you trying to run make on your Windows 7 machine?

That will not work. Surely you need to install the programs on your Raspberry Pi.


MrEngman

[DeeJay]

Are you trying to run make on your Windows 7 machine?

That will not work. Surely you need to install the programs on your Raspberry Pi.


MrEngman

The tutorial that @jbush referenced contains instructions for installing a cross-compilation tool chain on either Windows or MacOS.

https://www.cl.cam.ac.uk/projects/raspb ... s.html#gnu

That said, my assumption would be that the toolchain has not been installed correctly.

[jbush]

I am trying to do the Cambridge University Baking pi lesson 1.
As Rpi o/s does not allow a machine code program to access the GPIO pins directly, this lesson shows how to create a bare bones o/s to allow the GPIO access. this is done on another machine, the lesson provides a template to download,which contains a dir "source" where you insert your code program i.e. "main.s", a dir "build" a makefile, a license. Then you you download the necessary GNU toolchain for the machine you are using, go into the parent dir of the dir "source" and type "make". ( this is where i have the problem)
This should run the makefile, create the new kernel image, and compile the source code, "main.s".
You then clone the Rpi onto an 8 gb sd card, and insert it into the machine you are using i.e for me, windows 7, then rename the original kernel on the Rpi sd card and place the new kernel image in beside it. The idea is you still have the original sd card and the other which allows the access you require.
My problem is I cant get the makefile to run, I need assistance and advice from someone who has done this.

[stevepdp]

Jbush, I've just filled a warning against you for reposting this topic in multiple locations.

This thread is as far as I'm aware the only one remaining. We'll keep this one open since it has replies.

Thanks

[DeeJay]

JBush: I think you have to issue the 'make' command within the MinGW environment created by clicking on the MSYS icon on your desktop. That in turn means that the template files and your newly created main.s source file have to be in the home directory that MSYS is using within your Windows system.

This is what it looks like for me -

Code: Select all

David@ADLER ~
$ ls
LICENSE  Makefile  kernel.ld  source

David@ADLER ~
$ ls source
main.s

David@ADLER ~
$ make 
mkdir build
arm-none-eabi-as -I source/ source/main.s -o build/main.o
arm-none-eabi-ld --no-undefined build/main.o -Map kernel.map -o build/output.elf -T kernel.ld
arm-none-eabi-objcopy build/output.elf -O binary kernel.img 
arm-none-eabi-objdump -d build/output.elf > kernel.list

David@ADLER ~

[Richard-TX]

I am trying to do the Cambridge University Baking pi lesson 1.
As Rpi o/s does not allow a machine code program to access the GPIO pins directly, this lesson shows how to create a bare bones o/s to allow the GPIO access.

Why do you need to access the hardware directly? What is wrong with letting the Linux OS do it for you?

All you need to do is to export the pin, then setup direction and go. http://elinux.org/RPi_Low-level_periphe ... ing_system

Native C on linux can toggle a GPIO pin at 22 Mhz.

If you absolutely need to access the hardware directly here is an example of how to do it under wheezy. The only thing the OS is doing is providing a way to write the code in c. The actual access is direct to the hardware. http://elinux.org/RPi_Low-level_peripherals#C_2

Code: Select all

//
//  How to access GPIO registers from C-code on the Raspberry-Pi
//  Example program
//  15-January-2012
//  Dom and Gert
//  Revised: 15-Feb-2013


// Access from ARM Running Linux

#define BCM2708_PERI_BASE        0x20000000
#define GPIO_BASE                (BCM2708_PERI_BASE + 0x200000) /* GPIO controller */


#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>

#define PAGE_SIZE (4*1024)
#define BLOCK_SIZE (4*1024)

int  mem_fd;
void *gpio_map;

// I/O access
volatile unsigned *gpio;


// GPIO setup macros. Always use INP_GPIO(x) before using OUT_GPIO(x) or SET_GPIO_ALT(x,y)
#define INP_GPIO(g) *(gpio+((g)/10)) &= ~(7<<(((g)%10)*3))
#define OUT_GPIO(g) *(gpio+((g)/10)) |=  (1<<(((g)%10)*3))
#define SET_GPIO_ALT(g,a) *(gpio+(((g)/10))) |= (((a)<=3?(a)+4:(a)==4?3:2)<<(((g)%10)*3))

#define GPIO_SET *(gpio+7)  // sets   bits which are 1 ignores bits which are 0
#define GPIO_CLR *(gpio+10) // clears bits which are 1 ignores bits which are 0

void setup_io();

int main(int argc, char **argv)
{
  int g,rep;

  // Set up gpi pointer for direct register access
  setup_io();

  // Switch GPIO 7..11 to output mode

 /************************************************************************\
  * You are about to change the GPIO settings of your computer.          *
  * Mess this up and it will stop working!                               *
  * It might be a good idea to 'sync' before running this program        *
  * so at least you still have your code changes written to the SD-card! *
 \************************************************************************/

  // Set GPIO pins 7-11 to output
  for (g=7; g<=11; g++)
  {
    INP_GPIO(g); // must use INP_GPIO before we can use OUT_GPIO
    OUT_GPIO(g);
  }

  for (rep=0; rep<10; rep++)
  {
     for (g=7; g<=11; g++)
     {
       GPIO_SET = 1<<g;
       sleep(1);
     }
     for (g=7; g<=11; g++)
     {
       GPIO_CLR = 1<<g;
       sleep(1);
     }
  }

  return 0;

} // main


//
// Set up a memory regions to access GPIO
//
void setup_io()
{
   /* open /dev/mem */
   if ((mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) {
      printf("can't open /dev/mem \n");
      exit(-1);
   }

   /* mmap GPIO */
   gpio_map = mmap(
      NULL,             //Any adddress in our space will do
      BLOCK_SIZE,       //Map length
      PROT_READ|PROT_WRITE,// Enable reading & writting to mapped memory
      MAP_SHARED,       //Shared with other processes
      mem_fd,           //File to map
      GPIO_BASE         //Offset to GPIO peripheral
   );

   close(mem_fd); //No need to keep mem_fd open after mmap

   if (gpio_map == MAP_FAILED) {
      printf("mmap error %d\n", (int)gpio_map);//errno also set!
      exit(-1);
   }

   // Always use volatile pointer!
   gpio = (volatile unsigned *)gpio_map;


} // setup_io

[jbush]

Jbush, I've just filled a warning against you for reposting this topic in multiple locations.

This thread is as far as I'm aware the only one remaining. We'll keep this one open since it has replies.

Thanks

Sorry I am a newbie and didn't realize that. I just wanted to put the problem in all the relevant subject areas to get as much response as possible.
Wont do that in future. thanks.

[jbush]

I am trying to do the Cambridge University Baking pi lesson 1.
As Rpi o/s does not allow a machine code program to access the GPIO pins directly, this lesson shows how to create a bare bones o/s to allow the GPIO access.

Why do you need to access the hardware directly? What is wrong with letting the Linux OS do it for you?

All you need to do is to export the pin, then setup direction and go. http://elinux.org/RPi_Low-level_periphe ... ing_system

Native C on linux can toggle a GPIO pin at 22 Mhz.

If you absolutely need to access the hardware directly here is an example of how to do it under wheezy. The only thing the OS is doing is providing a way to write the code in c. The actual access is direct to the hardware. http://elinux.org/RPi_Low-level_peripherals#C_2

Code: Select all

//
//  How to access GPIO registers from C-code on the Raspberry-Pi
//  Example program
//  15-January-2012
//  Dom and Gert
//  Revised: 15-Feb-2013


// Access from ARM Running Linux

#define BCM2708_PERI_BASE        0x20000000
#define GPIO_BASE                (BCM2708_PERI_BASE + 0x200000) /* GPIO controller */


#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>

#define PAGE_SIZE (4*1024)
#define BLOCK_SIZE (4*1024)

int  mem_fd;
void *gpio_map;

// I/O access
volatile unsigned *gpio;


// GPIO setup macros. Always use INP_GPIO(x) before using OUT_GPIO(x) or SET_GPIO_ALT(x,y)
#define INP_GPIO(g) *(gpio+((g)/10)) &= ~(7<<(((g)%10)*3))
#define OUT_GPIO(g) *(gpio+((g)/10)) |=  (1<<(((g)%10)*3))
#define SET_GPIO_ALT(g,a) *(gpio+(((g)/10))) |= (((a)<=3?(a)+4:(a)==4?3:2)<<(((g)%10)*3))

#define GPIO_SET *(gpio+7)  // sets   bits which are 1 ignores bits which are 0
#define GPIO_CLR *(gpio+10) // clears bits which are 1 ignores bits which are 0

void setup_io();

int main(int argc, char **argv)
{
  int g,rep;

  // Set up gpi pointer for direct register access
  setup_io();

  // Switch GPIO 7..11 to output mode

 /************************************************************************\
  * You are about to change the GPIO settings of your computer.          *
  * Mess this up and it will stop working!                               *
  * It might be a good idea to 'sync' before running this program        *
  * so at least you still have your code changes written to the SD-card! *
 \************************************************************************/

  // Set GPIO pins 7-11 to output
  for (g=7; g<=11; g++)
  {
    INP_GPIO(g); // must use INP_GPIO before we can use OUT_GPIO
    OUT_GPIO(g);
  }

  for (rep=0; rep<10; rep++)
  {
     for (g=7; g<=11; g++)
     {
       GPIO_SET = 1<<g;
       sleep(1);
     }
     for (g=7; g<=11; g++)
     {
       GPIO_CLR = 1<<g;
       sleep(1);
     }
  }

  return 0;

} // main


//
// Set up a memory regions to access GPIO
//
void setup_io()
{
   /* open /dev/mem */
   if ((mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) {
      printf("can't open /dev/mem \n");
      exit(-1);
   }

   /* mmap GPIO */
   gpio_map = mmap(
      NULL,             //Any adddress in our space will do
      BLOCK_SIZE,       //Map length
      PROT_READ|PROT_WRITE,// Enable reading & writting to mapped memory
      MAP_SHARED,       //Shared with other processes
      mem_fd,           //File to map
      GPIO_BASE         //Offset to GPIO peripheral
   );

   close(mem_fd); //No need to keep mem_fd open after mmap

   if (gpio_map == MAP_FAILED) {
      printf("mmap error %d\n", (int)gpio_map);//errno also set!
      exit(-1);
   }

   // Always use volatile pointer!
   gpio = (volatile unsigned *)gpio_map;


} // setup_io

thanks I may try the wheezy route, I am a newbie to wheezy but it look like it may be what I'm looking for to start my project.
I think I may have already touched on the other the other route, i.e virtual memory area to mirror the GPIO area, using mmap or libc, I tried a program from a book by Bruce Smith, but couldn't get it to work. Problem is I have a little experience of programing. thanks

[jbush]

JBush: I think you have to issue the 'make' command within the MinGW environment created by clicking on the MSYS icon on your desktop. That in turn means that the template files and your newly created main.s source file have to be in the home directory that MSYS is using within your Windows system.

This is what it looks like for me -

Code: Select all

David@ADLER ~
$ ls
LICENSE  Makefile  kernel.ld  source

David@ADLER ~
$ ls source
main.s

David@ADLER ~
$ make 
mkdir build
arm-none-eabi-as -I source/ source/main.s -o build/main.o
arm-none-eabi-ld --no-undefined build/main.o -Map kernel.map -o build/output.elf -T kernel.ld
arm-none-eabi-objcopy build/output.elf -O binary kernel.img 
arm-none-eabi-objdump -d build/output.elf > kernel.list

David@ADLER ~

hi
Are you doing that on a Linux machine or a windows ?

[DeeJay]

(Example deleted from this response.)

Are you doing that on a Linux machine or a windows ?

Windows7.


(But I agree with other responders: it might be worth re-visiting your motives for doing this. What do you hope to accomplish, or what do you hope to learn?)

[jbush]

my project is:-
To construct an X, Y plotter with parts from an Epson Printer, using the carriage and optical encoders from that printer.
and use the RPi as the controller.
My first task is to be able to count in the signal from the encoder accurately, The encoder strip is 310 mm long and has approx 3600 segments. This could give an accuracy of 310/3600 = 0.086 mm.
I have tried a python program using edge detect, incrementing a count for each edge detected but it could only catch a fraction of the signal.
I think this is because of the time i takes python to process the, (increment count, and if statement for each segment square wave signal). If I slowed the motor down the program detected more signal. But to get an accuracy of even 5 mm the carriage had to move at a snails pace ( maybe I'm wrong here any suggestion would be apprciated).
So i gave up on python.
I and am now looking at Raspbian, machine code which I believe is approx 30 times faster than python.
The problem is that you can write the source code and compile it, but it cant be run directly.
The options are as far as I know (and again I may be wrong), is to use virtual memory which I think is to "export the pin". and use mmap, or libc. (please correct me if I am wrong here).
I got a Raspbian program from a book by called " Raspberry Pi Assembly Language, Raspbian " by Bruce Smith, to allow access to the gpio, I wrote the source, but couldn't get it to compile and run, I think I spent hours trying but with no success.
Then I came across the Cambridge University Baking pi , How to create a kernel image of a bare bones o/s to allow GPIO access . This entails replacing the Kernel image of a cloned RPi SD card, o/s kernel image with your own .
I am having problems with running the makefile command "make" in windows 7, which makes the kernel image and compiles the source code "main.s". The main.s source is just a token simple program to light a led on the pi.
I'm finding downloading the correct GNU toolchain and running it on windows very difficult.

[DeeJay]

So i gave up on python.

That's probably sound. The authors notes for rpi.gpio (one of the main python gpio libraries) say -

Note that this module is unsuitable for real-time or timing critical applications. This is because you can not predict when Python will be busy garbage collecting. It also runs under the Linux kernel which is not suitable for real time applications - it is multitasking O/S and another process may be given priority over the CPU, causing jitter in your program. If you are after true real-time performance and predictability, buy yourself an Arduino http://www.arduino.cc !

I and am now looking at Raspbian, machine code which I believe is approx 30 times faster than python.
The problem is that you can write the source code and compile it, but it cant be run directly.

I don't understand that. Both rpi.gpio and wiringpi are written in C. It must be possible to run their compiled code.

Then I came across the Cambridge University Baking pi , How to create a kernel image of a bare bones o/s to allow GPIO access . This entails replacing the Kernel image of a cloned RPi SD card, o/s kernel image with your own .
I am having problems with running the makefile command "make" in windows 7, which makes the kernel image and compiles the source code "main.s". The main.s source is just a token simple program to light a led on the pi.
I'm finding downloading the correct GNU toolchain and running it on windows very difficult.

See http://www.cl.cam.ac.uk/projects/raspbe ... loads.html

The MinGW download gives you a MSYS icon once installed. Clicking on this gives a unix-like development environment for Windows. It is this MinGW environment that provides the support for the make command. The Yagarto download, once installed, gives a cross-compiler that turns C source into an ARM executable. This gets invoked by the makefile which is part of the OS template you are instructed to download.

SO: Template contains Makefile.
MinGW 'make' invokes that Makefile
the makefile rules invoke the Yagarto cross-compiler to generate Arm executables.


I've given an example previously of how this fits together. I did this only a couple of days ago, so you can be confident that the downloadable materials are the correct ones and will run on Win7.

[jbush]

Thanks.
When I first saw the program I thought it was done in Linux, but now I understand a Linux like environment is created in windows.
I think I have been downloading the wrong toolchain, I downloaded the GNUwin32 toolchain.
As soon as I have time I will download the minGW and try it.
thanks again.

[jbush]

Hi,
I have downloaded the MinGW installation manager.
It has more than a hundred different package options that can be installed.
MSYS has the same number of package options, problem is which packages to choose?
I ticked the options I think may be right, and installed but there is no MSYS icon to click.
What has installed is a "GNUwin32" directory with a sub directory "make" . Both contain a load of Pdf files and no .exe files.
Its a minefield.

[DeeJay]

The Baking Pi tutorial seems to try to make this as simple as possible.

On the downloads page here it says -

Please visit the YAGARTO website and download and install YAGARTO Tools and YAGARTO GNU ARM toolchain for Windows. MinGW can be downloaded from here. You may need to restart your computer for this to work (honestly).

That's exactly what I did. So I ended up with these 2 downloaded files -

Code: Select all

MSYS-1.0.10.exe
yagarto-bu-2.23.1_gcc-4.7.2-c-c++_nl-1.20.0_gdb-7.5.1_eabi_20121222.exe

Then I ran the 2 .exe installers.

[DeeJay]

So i gave up on python.
I and am now looking at Raspbian, machine code which I believe is approx 30 times faster than python.
The problem is that you can write the source code and compile it, but it cant be run directly.

Working directly on the RPi running Raspbian - NOT using a cross compiler on another system -

Code: Select all

pi@raspberrypi ~/hello $ cat hello.c
/* Hello World program */

#include<stdio.h>

main()
{
    printf("Hello World\n");


}
pi@raspberrypi ~/hello $ cc hello.c
pi@raspberrypi ~/hello $ ./a.out
Hello World
pi@raspberrypi ~/hello $

I think that demonstrates writing, and compiling a C source code program, which results machine code in the file a.out which can then be executed. Is that what you needed to acheive?

[jbush]

Hi Dee Jay
Re:- "I think that demonstrates writing, and compiling a C source code program, which results machine code in the file a.out which can then be executed. Is that what you needed to achieve?"
I'm sorry I may have misled you here, I meant that The GPIO area is protected space, ie it is possible to write and compile a program to access the GPIO area in Raspbian but it wont run directly the system wont allow it.
I don't know if native C has the same problem, I suspect it does or there would be no need for the baking pi project to create a Kernel o/s to access the GPIO area.

On the other subject:- "problems with makefile"
I went to the baking pi download page followed the link to the Yargato site , -- downloaded the yagarto-bu-2.23.1_gcc-4.7.2-c-c++_nl-1.20.0_gdb-7.5.1_eabi_20121222. exe , -- It was 36.7Mb, -- Ran it, -- it started the Yargato 4.7.2 setup wizard, -- Ticked the accept license box, -- it comes up with 5 option "select component to install " menu, -- ie. -- "Binutils-2.23.1", -- "Newlib-1.20.0", -- "GDB-7.5.1", -- "GCC-4,7,2", (which i thought was the correct one so i selected, only allowed to selec one option), -- Selected the install folder, "C:\yagarto-20121222", -- Selected the start menu folder "YAGARTO\YAGARTO", -- Pressed the install button, -- it installed the Yargato folder with a load of sub folders The "Bin" folder contained 20 .exe files one is "arm-none-eabi-gcc-4.7.2", when run flashes up a black command prompt screen which immediately disappears.
All 20 files are "arm-none-eabi-" with different prefixes all of them bring up a black command screen,
17 of them flash up and immediately disappear.
I don't know what to make of it.
Could it be because I'm running a 64 bit machine in 64 Bit windows???.
I'm afraid I'm rapidly losing heart with the pi, which is a pity because I like the idea of it.
Wouldn't it be great if the pi had two separate modes. A Micro-processor mode for multitasking. and a separate Micro-controller mode like the Ardueno.
It would allow you to create the program- compile it then switch mode to micro-controller to run it.
I think my next step may be to buy an Ardueno.

[Richard-TX]

I think you are over analyzing things. Get the c program to access the GPIO pins directly under Wheezy running first. Then if you find it lacking, then go for the bare metal programming. Baremetal programming is OK, but also realize that every bit of IO has to be programmed as well.

[jbush]

I agree it may be OK but also I agree with this from a previous comment:-

The authors notes for rpi.gpio (one of the main python gpio libraries) say -

Note that this module is unsuitable for real-time or timing critical applications. This is because you can not predict when Python will be busy garbage collecting. It also runs under the Linux kernel which is not suitable for real time applications - it is multitasking O/S and another process may be given priority over the CPU, causing jitter in your program. If you are after true real-time performance and predictability, buy yourself an Arduino.

There are things that I am beginning to realize about the RPi. and I have noticed a number of comments about it being a multitasking system not suitable for real time applications.
There is another consideration whether it be wheezy, python c. whatever.
The RPi like most multitasking systems use Dinamic Ram which has to be refreshed every 30 m/s, a priority interrupt , it stops what it is doing puts all the data onto a stack, then goes about refreshing the ram, unstack's then continues on it's way.
This has to be done every 30 m/s or the system will crash.
This is a problem for real time applications.
Now I suspect that the Arduino may have Static Ram which is more expensive but doesn't need refreshing and as it doesn't have a large Ram. -- This is from the Arduino webpage --- "Notice that there's not much SRAM available in the Uno. It's easy to use it all up by having lots of strings in your program. SRAM (static random access memory) is where the sketch creates and manipulates variables when it runs. " -- so it doesn't need to stop to refresh the Ram when running a program.

[jbush]

By the way I am not knocking the RPi I think its a great little machine and will still use it maybe in conjunction with the Arduino.
Do the hard work programing, web searching on the pi the run it on the Arduino.

[Tarcas]

There are things that I am beginning to realize about the RPi. and I have noticed a number of comments about it being a multitasking system not suitable for real time applications.

This is true. Linux is not a real-time OS. It is, however, still fast. Many people like to spew the warning without reminding new users of the actual definition of "real-time operating system." What this really means is that it cannot GUARANTEE a particular response time. While you can be "pretty sure" that it will get back to your thread within some number of miliseconds of when you expect it to, there is no guarantee, because as people have mentioned, it may have just started a garbage collection or RAM refresh routine which may take a little longer than normal. Or there may be another user process that is heavily using system resources, and isn't being "nice" about it. Alternately, something like an Arduino doesn't have the OS overhead that Linux has, so it might be able to make a guarantee like that (truthfully, I don't know. I'm not an Arduino expert.)

However, on the other hand, most applications that people claim require "real-time" processing, such as video processing or piloting a quadcopter, can actually handle late or missing data much better than the people complaining about "not a real-time OS" think. Now, if you're using Linux to directly control the precise timings of the spark plugs in an engine, that's a terrible idea. You need much finer precision for that. But for keeping a quad-copter stable in the air, no problem... If you drop some data or it comes in late, you'll just make up for it with the next update. If you miss a frame in processing a video, you just move on to the next frame, and no human watching will ever know the difference, so long as it's not happening continually. However, in either case you have to be able to handle the missing data in your software. If a developer is too lazy to build in proper data sanitization that can handle things like missing data, even a real-time OS won't keep everything perfect.

[jbush]

Hi I agree,
But my project ,-- an X, Y plotter requires accurate count of the output from the optical encoder and I don't see how I can get round that using the RPi.
If it were possible to count the encoder signal into a buffer maybe that would work. But I'm not sure how that could be done.
I have purchased a couple of SN74LV8154N counters and maybe count in the signal and transfer it to the RPi.
But have to figure out how to wire them up.