Thanks! The C#/Mono MCS 3.2.8 (with mcs -optimize+ -platform:arm) is a factor of 2.47, which is approximately the same as Node.js. However, it may be possible to further optimize the build. Also, the performance of Node.js on the BeagleBone is exceptional — I’m not sure how it was optimized so well. No significant reason for leaving it out (other than page space) — I would also like to have covered Haskell, Lua and Ruby! Kind regards, Derek.

==============
Partial code:
.
.
if ((myOutputHandle = fopen(GPIOValue, "rb+")) == NULL)
{
  return 1;
}
strcpy(setValue, "0");            // output = 0
fwrite(&setValue, sizeof(char), 1, myOutputHandle);
fclose(myOutputHandle);
//// >>>> until now ok, the led is off
if ((myOutputHandle = fopen("/sys/class/gpio/unexport", "ab")) == NULL) 
{
  return 1;
}
//// >>>> until now ok, the led is still off
strcpy(setValue, GPIOString);
fwrite(&setValue, sizeof(char), 2, myOutputHandle);
fclose(myOutputHandle);
//// >>>> the led goes high.

Hi Robert, Unfortunately I keep losing the executable bits and I don’t know why — I think it is possibly the GitHub Windows client, but I cannot be certain. I will fix that. Thanks, Derek.

Thanks. Yes it should be +AggressiveOpts — adding it to the list of errata, Derek.

Thanks Brett — I appreciate your support! Yes, I would have loved to spend more time on the PRU-ICSS but I had agreed 430 pages and was well over that! I’ll continue to add more content to the chapter web page as I develop it (I’ll have to look at real-time DAC soon), but I’ll have to be honest, I hadn’t considered using the PRU-ICSS quite the way that you have suggested. I can see certainly see the use for controlling PWM, but with the complexity of the AM335x and the (quite) limited set of instructions available on the PRU-ICSS it is going to be hard work! I’ll have to have a look into it though. Another book is off the cards for the moment (on any topic) until I catch up with myself. I wrote this book late at night after I settled my kids in bed and it was hard keeping up with everything in work the next day. I’ll keep adding content to the chapter web pages as I develop it — maybe it will all end up in Revision 2! Kind regards, Derek.

Hi Evert, No, they are actually equivalent. When you create a pointer, the dereference type of the pointer defines what a +1 is in terms of bytes. For example, on the BBB if you define int *p; the compiler uses the dereference type size (e.g., 4 bytes in this case) to manipulate the pointer. If you declare char *p; then the pointer will only move by one byte on a ++ or +1 manipulation. You can see this in a short code example:

#include < iostream >
using namespace std;

int main(){
	int numbers[3] = {100,200,300};
	int *p = &numbers[0];
	cout << "[0]The address of p is " << p << " and the dereferenced value is: " << *p << endl;
	p++;
	cout << "[1]The address of p is " << p << " and the dereferenced value is: " << *p << endl;
	p=p+1;
	cout << "[2]The address of p is " << p << " and the dereferenced value is: " << *p << endl;
	return 0;
}

Which gives the output when executed:

 
[0]The address of p is 0x7fffdeeccf10 and the dereferenced value is: 100
[1]The address of p is 0x7fffdeeccf14 and the dereferenced value is: 200
[2]The address of p is 0x7fffdeeccf18 and the dereferenced value is: 300

You can see that the pointer moved by 4 bytes after each pointer operation. Hope that helps! Derek.