Accessing mapped GPIO in gcc?

I’ve been trying to work out how to control the GPIO pins on my Pi3 using gcc and OSLib.
Getting a memory window from osmemory_map_in_permanent_io(…) returns a sane looking 0xf9200000 for the base address. I’m pretty sure that’s right for a Pi3.
Trouble is the program segfaults if I try to do anything with it. That doesn’t surprise me at all. How do I actually work with that address range in C in RISC OS?
If it were asm accesses would probably need to be within SWI “OS_EnterOS” and SWI “OS_LeaveOS”. Should I be doing the equivalent, which I’m not sure how to yet or something else?

I want to avoid assembler even if it isn’t the most efficient route. I just want to put together something that I can base a library off that I can use for my own projects.

You are probably needing to access the I/O in SVC mode. That’s what the OS_EnterOS is for.
As an alternative, does your library allow you to pass flags? If so you could try requesting USR mode access? https://www.riscosopen.org/wiki/documentation/show/OS_Memory%2013%20Flags

If you do decide to use OS_EnterOS/OS_LeaveOS, doing it from assembler is pretty much the only way. If you were to try using them from C then things would go wrong pretty quickly due to the switch from the USR stack to the SVC stack.

Rick Murray: My library as in the one that I am using (OSLib) or what I intend to write? If you mean mine, it’s still just a standalone program where I’m working on getting basic hardware I/O to work. OSLib has “os_enter_os” and “os_leave_os” documented as SWIs for “OS.h”. Trouble is I can’t work out how to use them.
I’ll have to look into what you linked there. Or rather try to work out how OSLib interacts. In flags I used “osmemory_IO_ACCESS”. I have no idea how to set the other flags. Do I just logical OR other stuff for the flags? It looks like I could possibly set the memory window for USR access. I don’t know if it’s a good idea or not, but other than messing with GPIO I can’t see it causing much harm.

Jeffrey Lee: Assembler is about the only way that i could potentially get to work at this point because I haven’t worked out how to use things with no params listed in the OSLib SWIs part of the StrongHelp manual. I tried as a function with no params, as a constant in swi(), swi() and kernel_swi(). It didn’t recognise them in any form. An explanation or example somewhere would have gone a long way.
I was curious how it would get away with the switch of stacks too. I haven’t looked at the source of the library for os_enter/exitos so I just assumed someone far more knowledgeable than me worked it out.

My library as in the one that I am using (OSLib) or what I intend to write?

OSLib.

OSLib has “os_enter_os” and “os_leave_os” documented as SWIs for “OS.h”. Trouble is I can’t work out how to use them.

They will be veneers for the appropriate SWIs. Basically:

   EnterOS
   do stuff
   LeaveOS

However note the following points carefully:

• C dumps a lot of stuff on “the stack”. The stack is pointed to by R13. When you switch to SVC mode, this changes R13 to be a pointer to the SVC stack. As such, any attempts to call or exit functions will be pushing/pulling values from the wrong stack. It will go bang.
• R14 is… Complicated. C handles it correctly when you use the -zM switch to build a module. Such issues are “unexpected” in an application, so you’ll need to deal with this yourself, should the need arise.

What this means is you cannot just stay in SVC mode.

Or rather try to work out how OSLib interacts. In flags I used “osmemory_IO_ACCESS”. I have no idea how to set the other flags. Do I just logical OR other stuff for the flags?

I cannot answer, I don’t use OSLib.

It looks like I could possibly set the memory window for USR access. I don’t know if it’s a good idea or not, but other than messing with GPIO I can’t see it causing much harm.

Generally things like that stay in SVC mode to try to protect the system from errant accesses. I don’t recall the specifics, but I think when I tried directly playing with the GPIO on my Pi (1), the SWI actually mapped in an entire megabyte, and just returned to me the offset to what it is that I was interested in. With this in mind, it is possible that requesting to map in the GPIO in USR mode might expose some other things.

Assembler is about the only way that i could potentially get to work at this point because I haven’t worked out how to use things with no params listed in the OSLib SWIs part of the StrongHelp manual. I tried as a function with no params, as a constant in swi(), swi() and kernel_swi(). It didn’t recognise them in any form.

? I’m not sure what the question is, exactly.

Kernel SWI is pretty simple…

   // in the definitions
   _kernel_swi_regs r;

   // then
   r.r[0] = value to put in R0;
   r.r[1] = value to put in R1;
   _kernel_swi(SWINUM, &r, &r);

Where SWINUM is a SWI number. Nothing more, nothing less.

I just assumed someone far more knowledgeable than me worked it out.

Generally, one should assume that application code will not work in SVC mode except for brief hops in and right back out again. For instance, at the top I said:

   EnterOS
   do stuff
   LeaveOS

That is the only way it’ll work.

If you have the DDE, that could be shortened down to:

   __asm
   {
      // assumes "address" is an unsigned long pointing to the I/O memory to read
      // assumes "myword" is an int or long to read data into
      SWI   0x16, {}, {}, {LR, PSR}   // OS_EnterOS
      LDR   myword, [address]
      // remember you can use offsets too, like:
      //    LDR   myword, [address, #12]  to read from (address+12)
      SWI   0x7C, {}, {}, {LR, PSR}   // OS_LeaveOS
   }

Disclaimer: I’m sitting outside in the sunshine writing this on the iPad. It may or may not work. ;-)

Assembler is about the only way that i could potentially get to work at this point because I haven’t worked out how to use things with no params listed in the OSLib SWIs part of the StrongHelp manual.

They’re just functions, so

os_enter_os()

Except that, as the OSLib manual notes, you can’t use os_enter_os() from APCS (for the reasons that have been discussed), meaning that this OSLib function’s not a lot of use.

have no idea how to set the other flags. Do I just logical OR other stuff for the flags?

No, you bitwise OR them. For example

osmemory_IO_BUFFERABLE | osmemory_IO_CACHEABLE | osmemory_IO_DOUBLY_MAPPED

I haven’t looked at the source of the library for os_enter/exitos

OSLib isn’t really a library in that sense: it’s just veneers around the SWIs. Beyond getting variables in to and out of registers, there’s no extra code there. That is, wimp_initialise() in C is the same as SYS "Wimp_Initialise" in BASIC.

Coding while sick and medicated is like driving while drunk, except nobody cares if you crash your program.
That being said, yes, bitwise OR absolutely. Don’t know where my head was at.

Rick Murray: It wouldn’t bother me if the SWI mapped a whole megabyte, even though it shouldn’t. I’d just map 0×3F000000 instead of 0×3F200000 and set a pointer to 0xF9200000 instead of 0xF9000000 to keep things simpler.
What actually would happen if it mapped a whole MB? I know in the Pi 2 and 3 the I/O is essentially in a 1MB memory hole at the top of addressable space. It means they lose 1MB of addressable RAM in the process which bugs me but I guess they had to build to a budget.

I kind of figured that the best I could hope for is a single read or write in SVC mode without causing havoc. Thing is I don’t trust gcc that much.

That’s a monumental effort for typing code on an iPad or any tablet really. SwiftKey on my TF700T decided it’d try autocorrecting my typing when I was writing some code for an Arduino this afternoon. I did not appreciate that.

I don’t have DDE, and probably never will. It’d be nice but I just don’t need it. If they’d kept the DDE Pascal up to date I probably would consider it.
Still the code is useful. Thanks! It’s pretty much what I was planning on doing in C in a single SVC mode switch.

Steve Fryatt: Thanks for the clarification. It’s wgat I was hoping. Just simple wrapper libraries without extra fiddling.

When I can work out which bits to pass for setting the window for USR mode, I’m going to try that. Needs a clearer head that I have right now though.

I’m not too worried about clobbering other IO. My code isn’t going to be controlling a nuclear reactor or a morphine pump. I usually write things to be pretty idiot(me) proof anyway. Pass things to the magic functions by value with checking on the max and min values etc. built in. If I want fast I/O I use a microcontroller. Pi I/O is not fast but it is useful, so I’d rather the marginal speed penalty for robust code.

Rick Murray: It wouldn’t bother me if the SWI mapped a whole megabyte, even though it shouldn’t. I’d just map 0×3F000000 instead of 0×3F200000 and set a pointer to 0xF9200000 instead of 0xF9000000 to keep things simpler.
What actually would happen if it mapped a whole MB? I know in the Pi 2 and 3 the I/O is essentially in a 1MB memory hole at the top of addressable space. It means they lose 1MB of addressable RAM in the process which bugs me but I guess they had to build to a budget.

OS_Memory 13 does (currently) map in in megabyte-aligned chunks, but it’s also smart enough to re-use an existing mapping if one is present (right address + size + access permissions). So on a typical system the logical address space you lose due to overly large IO areas isn’t that significant.

However it’s important not to make assumptions about any alignment/rounding that OS_Memory 13 performs – it could easily go up or down in future OS versions.

Coding while sick and medicated is like driving while drunk, except nobody cares if you crash your program.

Hmmm, the current network interconnection map at work is exactly what was on the whiteboard when I came into work after a bout of flu. The writing of the annotations was mine but I have no memory of doing it. According to my colleague I mumbled a lot while drawing it out.
Obviously the inner geek had no interference because it has worked rather well for years now.

Coding while sick and medicated is like driving while drunk, except nobody cares if you crash your program.

I tend to avoid medication if possible, just the odd paracetamol if necessary.
I find when I have something very wrong (like flu, not just a snotty nose), I write my best code. Fair enough, I might not entirely understand it when sanity resumes. ;-)

My attempt at writing a 6502 emulator from the ground up in VisualBasic (!) using only the Advanced User Guide to detail the opcodes? That could only have been the result of a very muddled head. One of the main reasons I’ve dropped the project is not that I rarely touch VB these days (which is true), but rather I devised some weirdo way of reading in the instructions from memory to get around the fact that VB really isn’t designed for something like that. Maybe some day I’ll try to work out WTF it actually does!

Rick Murray: It wouldn’t bother me if the SWI mapped a whole megabyte, even though it shouldn’t.

To answer both you and Jeffrey – as he mentions, how the memory mapping actually does what it does is not our concern. What I am doing is pointing out that the granularity of mapping is rather more than “just that port”, and by setting it to have USR mode access, you’re opening up potentially other¹ I/O and stuff to have the same access rights.

I know in the Pi 2 and 3 the I/O is essentially in a 1MB memory hole at the top of addressable space. It means they lose 1MB of addressable RAM in the process which bugs me but I guess they had to build to a budget.

Hmm… 1MiB on a machine with a theoretical 4GiB addressing range, and 1GiB actually installed.
I think I can live with that.

Oh, and you might want to browse this thread and note things such as: The RMA is a global resource, so it will still need to be a regular dynamic area, and will still need 256MiB-ish logical address space allocating to it even though it may only have 4-16MiB of pages mapped in.

I kind of figured that the best I could hope for is a single read or write in SVC mode without causing havoc. Thing is I don’t trust gcc that much.

You have an assembler with GCC, right? Simply write a routine to enter SVC mode, to the read (or write), then exit from SVC mode. It might be better to use MSR CPSR_c,#%10000 to return to USR32 instead of calling OS_LeaveOS.

That’s a monumental effort for typing code on an iPad or any tablet really.

Not so much. The iPad seems to have a learning function where it’ll wavy-line things it thinks are spelling errors (but it didn’t have suggestions for) but if you use them a few times, it’ll consider that you meant to do that.
The only thing I’ve not weaned it off of doing is inserting a ‘.’ if I press Space twice, but if I delete the ‘.’ and Space again, it’ll leave it alone.

Now. Android 5, on the other hand. Miserable. Miserable. Miserable. It can’t handle CamelCase words, like most SWIs, so you get either all caps, or normal word (initial cap if it thinks it needs it). iOS understands that RISC is followed by OS and both should be capitalised. Android tends to understand that risc is followed by os, but never even attempts to set the capitalisation. Plus the Android select-copy-paste is a miserable mess where you often end up selecting everything but the text you wanted to select.
Grrr-argh.

If they’d kept the DDE Pascal up to date I probably would consider it.

Wow. I thought I was the only one who remembered that!

I’m not too worried about clobbering other IO.

For your own use, no. But if you ever plan to share your program…

My code isn’t going to be controlling a nuclear reactor or a morphine pump.

Of course not. We here are all way overqualified for writing mission critical code.

I feel like I ought to add a smiley, but then I read The Register so I’m not sure the statement isn’t without some measure of truth.

If I want fast I/O I use a microcontroller.

Indeed. It can be useful to bolt an Arduino to the Pi, so it can handle the mission critical stuff (plus it has ADC), and let it regurgitate the information to the Pi in tidy predigested chunks.²

¹ Vague, as it’s been a long time since I looked at the sorry excuse that passes for a datasheet.

² TMI? ;-)

As always I had part of a reply typed but never got to finish it. Just a quick one to let you all know I haven’t given up. Just have no time. I did however just try one of Bruce Smith’s GPIO examples on the Pi3 with an LED attached. It worked, after changing the IO base address of course. It’s good to have a basic sanity check.

I have to do a bit of digging to find a better example of asasm inline with GCC. The included example just didn’t have enough for me to work from.
Hopefully a better reply tomorrow!

Sorry. Another real short one.
Not the first time I’ve seen the following. Got it when I tried to OS_EnterOS via other means that I can’t recall.

/tmp/ccrxLNFE.s: Assembler messages:
/tmp/ccrxLNFE.s:108: Error: cannot represent SWI relocation in this object file format
/tmp/ccrxLNFE.s:109: Error: cannot represent SWI relocation in this object file format

This was caused by this rather awful looking two lines of inline asm

  __asm__ __volatile__ ("SWI\tOS_EnterOS\n\t"
                        "SWI\tOS_LeaveOS\n\t");

For some reason StrongED isn’t letting me put tabs in, so I had to use the escape character for it. It’s not choking on that anyway. Have I embarked on a fool’s errand here?

Also, while GCC seems to understand

 _kernel_swi(…)

 _kernel_swi_regs

Most likely you’re missing #include <kernel.h> and/or #include <swis.h>

swis.h contains the definitions for all the SWI numbers; they’re all #defines so the names will get replaced by numbers before the C compiler/inline assembler gets a proper look in. But by not including the file, the string is left in place, causing the inline assembler to think that it’s a symbol name. But symbol resolution generally involves help from the linker (e.g. resolving the values of external symbols), and the relocation format used for SWIs isn’t supported by whatever object format the inline assembler generates, so rather than getting a useful “SWI OS_EnterOS not found” error you get the rather cryptic “cannot represent SWI relocation” error.

kernel.h contains the definitions of all the _kernel_ functions and data types. Although I’m not sure why _kernel_swi wasn’t producing an error – possibly it’s also defined somewhere else, or maybe there’s a warning you’ve missed? C has the not-very-useful behaviour of issuing warnings for unknown functions rather than errors (on seeing a reference to an unknown function it generates a prototype on the fly, guessing at what the parameter and return types are, quite possibly getting them wrong. Perhaps this was useful 30+ years ago when you didn’t have enough RAM to arbitrarily load header files, but if that’s the motivation for the feature then it should have been outlawed by now)

That’s very helpful, thanks. I didn’t include “kernel.h” Truthfully I didn’t know about it. Finding documentation has been pretty hard. I’ll try it next chance I get. Right now my Pi3 is preoccupied trying to drag the Pi Zero’s SD up to date and install the gcc toolchain. I figure a second computer with a different generation SoC would be nice to help weed out any odd inconsistencies. Updating it is so slooooow though. I think the MicroSD I’m using for the Zero must be utter rubbish.

I’m still kind of sick. Whatever the bug is is more or less just making me dizzy and my mind kind of cloudy now.

Just wanted to say about the 6502 emulator written in VB, I wrote something years ago using a tiny imaginary subset of the 6502 instructions in QBASIC. It had an accompanying almost-assembler too.
I’m not big on medication either. Unless it’s to actually help me get better I usually don’t bother.

Next thing I’m going to try is the enter /leaveOS SWIs in an assembler file. Probably be easier just to copypaste the GCC examples for that one.
There was nothing actually wrong with the inline assembler I posted, right? I mean it was pointless, but it was just meant as a test to see if gcc tripped over.

For some reason StrongED isn’t letting me put tabs in,

To insert a tab character the action tied to the Tab key has to be ‘TrueTab’, in your case it probably wasn’t. The action performed by the Tab key can be changed, the options available are:

• Nearest : align caret with first non-empty line above or below
• Tabstops : move caret to next position in the tabstops definition
• TrueTab : insert a tab character, ie character code 0×09.

The infobar at the bottom of the window will show which action is currently set. You can change it by clicking on the infobar field or by using Ctrl-Tab.

As always, at least v2 of my reply. Thanks for the help, Fred! FOr some reason that one file had it’s tabs set weird. I probably grabbed the wrong mouse and clicked. The PC and Pi share the desk and one of the monitors.

I’m just going to dump a slightly cleaned up version of the mess I have here. This is the first one that doesn’t explode in flames. It also doesn’t light up the LED on GPIO21 :(
I removed a lot of commented out code, dead functions and swearing in comments. I’m pretty certain the math is bad at very least.
Just because there isn’t much there doesn’t mean there hasn’t been a lot of effort trying various methods. Once I can get the GPIO to respond to my code I’m going to write something properly.

#include <stdio.h>
#include "swis.h"
#include <stdlib.h>
#include <oslib/os.h>
#include <kernel.h>

//global vars. Bleh.
volatile unsigned long *p_GPIO;
volatile unsigned long *p_IO;
const byte *p_GPIO_phys_addr = (char *)0x3F200000 ; //Pi 2 and 3 GPIO base
//volatile byte *p_IO_phys_addr = (char *)0x3F000000 ; //Pi 2 and 3 IO base
int window_size = 0x100;

//---------------------------------------------------------------------------
void initGPIO()
//---------------------------------------------------------------------------
{

//_kernel_swi version.
_kernel_swi_regs reg;

//I don't like this line. Shouldn't it be '|'?
reg.r[0] = 13 + (1 << 17); // usr permission + osmemory_map_in_permanent_io?
//reg.r[1] = *p_GPIO_phys_addr; //PI 3 GPIO base address.
reg.r[1] = 0x3F200000;
reg.r[2] = 0x100; //memory window size to be mapped.
printf("reg 1= %p\n", reg.r[1]);
_kernel_swi(OS_Memory, &reg, &reg);
p_GPIO = reg.r[3];
printf("p_GPIO= %p\n", p_GPIO);
//Address looks good.

}

//---------------------------------------------------------------------------
void asmPinTest()
//---------------------------------------------------------------------------
{
  volatile unsigned long *m_p_GPIO; //going to set this up for GPIO base address.
  m_p_GPIO = p_GPIO; //hands off p_GPIO!
  volatile unsigned long *tmpGPIO; //only using this extra step for debugging.

  printf("Address mapped to RISC OS is: %p\n", p_GPIO);
  printf("GPIO base is: %p\n", m_p_GPIO);


  //let's try to light up GPIO21 in userspace.
  printf("Setting pin 21 to output\n");
  tmpGPIO = m_p_GPIO + 4;
  printf("IO Register address is: %p\n", tmpGPIO);
  printf("IO Register value before write is: %p\n", *tmpGPIO);

 //*(m_p_GPIO + 4) |= 1 << 3; //GPIO21 set to output
  *tmpGPIO |= 1 << 3; //GPIO21 set to output
  printf("IO Register value after write is: %p\n", *tmpGPIO);

  printf("Setting Pin 21 state to high\n");
  tmpGPIO = m_p_GPIO + 28;
  printf("IO Register address is: %p\n", tmpGPIO);
  printf("IO Register value before write is: %p\n", *tmpGPIO);
  *tmpGPIO |= 1 << 21;
  printf("IO Register value after write is: %p\n", *tmpGPIO);

  //*(m_p_GPIO + 28) |= 1 << 21; //make pin 21 high

}

//---------------------------------------------------------------------------
int main()
//---------------------------------------------------------------------------
{
  initGPIO(); //maps IO to memory.
  printf("GPIO probably mapped to logical memory!\n");

  printf("Calling test of GPIO\n");
  asmPinTest();
  printf("If you are reading this it means it didn't crash\n");




  return 0;

}

edit: Just spotted one thing. The byte offset to get to GPSEL2 should have been 8, not 4.

It looks like there are a couple of pointer-related pitfalls that you’ve fallen into.

Firstly:

//reg.r[1] = *p_GPIO_phys_addr; //PI 3 GPIO base address.
reg.r[1] = 0x3F200000;

*p_GPIO_phys_addr will be dereferencing the pointer, it would be the BASIC equivalent of !p_GPIO_phys_addr. Obviously this isn’t what you want, especially since p_GPIO_phys_addr is a physical address and there’s no way of directly using physical addresses in C (or most other programming languages).

If you change it to this then it will work, i.e. put the value 0×3F200000 into R1:

reg.r[1] = p_GPIO_phys_addr; //PI 3 GPIO base address.

However the compiler might throw a warning about a type mismatch (p_GPIO_phys_addr is a byte pointer but regs.r¹ will be an int). You can either ignore the warning, insert a type cast (e.g. regs.r[1] = (int) p_GPIO_phys_addr), or change p_GPIO_phys_addr so that it isn’t a pointer. Like I said, you can’t directly use physical addresses in C, so there’s no point declaring p_GPIO_phys_addr as a pointer – the usual convention is to use an unsigned int or equivalent type (e.g. paddr_t is a type defined on many unixy systems – not sure offhand if it’s available under GCC)

So the way I’d fix the warning would be:

const unsigned int p_GPIO_phys_addr = 0x3F200000

Secondly:

edit: Just spotted one thing. The byte offset to get to GPSEL2 should have been 8, not 4.

Yes, the byte offset should be 8. But when you add an offset to a C pointer, you don’t specify the offset in terms of bytes – you specify it in terms of the size of the type being pointed to. So if you have a pointer int *some_pointer then some_pointer + 4 will offset the pointer by 16 bytes, not 4 (it’s exactly the same as if you were to take the address of an array element, e.g. &some_pointer[4]). To get an offset of 4 bytes you’d need to use some_pointer + 1.

A lot of code I’ve seen for accessing memory-mapped IO in C tends to do it in one of two ways: define a struct which has the same memory layout as the hardware (pros: increased type safety, cons: easy to make mistakes in the struct definition and have everything offset incorrectly), or use #defines to define all the offsets and use wrapper functions/macros for the memory accesses (so you can e.g. use byte offsets in the #defines and the wrapper function will take care of any math or typecasts which are used to ensure it gets treated as a byte offset when it’s applied to the base pointer).

And finally a non-pointer thing:

//I don't like this line. Shouldn't it be '|'?
reg.r[0] = 13 + (1 << 17); // usr permission + osmemory_map_in_permanent_io?

| would work here, yes. But as long as the different parts of the expression aren’t trying to set the same bits it doesn’t matter which you use.

Ooh. You’ve spotted some things I haven’t. I only just saw your post but I’ll post a new version of what I’ve been working on. Chunks of dead commented code etc. have been stripped out for posting.

The goofed address dereferencing at the beginning was commented out for a reason. But what was it… It may have been something to do with using the OSLib call initially. Really I just stuck the magic number in to give me one less thing to worry about for the time.

I have to agree with you with using a struct or defines etc. with a wrapper. I know for a fact this code will not scale. It’s not meant to. The sole purpose is to initialize pin 21 and set it high. When I see that result I will take what has been learned and write something useful. It’s getting this bit to work that is the stumbling block for me.
There’s various hardware I’d like to interface via the GPIO controller but can’t until I can get it to sing for me.

Anyhow this is what I have.
e: Textile seems to be ignoring some of the markup. It’s still readable just looks a bit weird with italics, extra line spaces etc.

#include <stdio.h>
#include "swis.h"
#include <stdlib.h>
#include <oslib/os.h>
#include <kernel.h>

//global vars. Bleh.

volatile unsigned long *p_GPIO;

volatile unsigned long *p_IO;

const byte *p_GPIO_phys_addr = (char *)0×3F200000 ; //Pi 2 and 3 GPIO base

//volatile byte *p_IO_phys_addr = (char *)0×3F000000 ; //Pi 2 and 3 IO base

int window_size = 0×100;
//—————————————————————————————————————-

void initGPIO()

//—————————————————————————————————————-

{

//_kernel_swi version.

kernel_swi_regs reg;

reg.r0 = 13 + (1 << 17); // usr permission + osmemory_map_in_permanentio?

reg.r1 = 0×3F200000;

reg.r2 = 0×100; //memory window size to be mapped.

printf(“reg 1= %p\n”, reg.r1);

kernel_swi(OS_Memory, &reg, &reg);

p_GPIO = (volatile unsigned long *)reg.r3;

printf(“p_GPIO= %p\n”, pGPIO);

//Address looks good.

}
//—————————————————————————————————————-

void asmPinTest()

//—————————————————————————————————————-

{

  volatile unsigned long *m_p_GPIO; //going to set this up for GPIO base address.

  m_p_GPIO = p_GPIO; //hands off p_GPIO!

  volatile unsigned long *tmpGPIO; //only using this extra step for debugging

  unsigned long tmpReg = 0;
printf(“Address mapped to RISC OS is: %p\n”, p_GPIO);
printf(“GPIO base is: %p\n”, m_p_GPIO);
//let’s try to light up GPIO21 in userspace.
printf(“Setting pin 21 to output\n”);
tmpGPIO = m_p_GPIO + 8;
printf(“IO Register address is: %p\n”, tmpGPIO);
printf(“IO Register value before write is: %p\n”, *tmpGPIO);
*tmpGPIO &= (~(0b111<<3));
*tmpGPIO |= (1<<3);//set lsb of pin (output)
printf(“IO Register value after write is: %p\n”, *tmpGPIO);
printf(“Setting Pin 21 state to high\n”);
tmpGPIO = m_p_GPIO + 28;//base address for GPSET0
printf(“IO Register address is: %p\n”, tmpGPIO);
printf(“IO Register value before write is: %p\n”, *tmpGPIO);
//*tmpGPIO |= 1 << 21; //No. This just needs to write a 1 to bit 21.
//reading the register is useless.
*tmpGPIO = (1<<21);//set pin 21 to 1.
printf(“IO Register value after write is: %p\n”, *tmpGPIO);
}
//—————————————————————————————————————-

int main()

//—————————————————————————————————————-

{

  initGPIO(); //maps IO to memory.

  printf(“GPIO probably mapped to logical memory!\n”);

  printf(“Calling test of GPIO\n”);

  asmPinTest();

  printf(“If you are reading this it means it didn’t crash\n”);
return 0;
}

I had a bit of a mishap with building which has unintentionally given me some info. So far I’ve been using my pi 3 to work on this. Getting the GCC toolchain working on the Zero was a headache for some reason, so I cloned the Pi3’s SD on to one for the zero, tweaked the settings and booted it. Everything works fine (except setting to the wrong initial resolution again).
Here’s the accident. In the directory I’m working from I have an Obey file and a Make file. I was using the Obey file until I made the Makefile. They both generate a differently named executable. Without thinking I ran the Obey file and executed the file from the Makefile. The executable looked to the wrong address because I hadn’t changed it for the Zero in that version. The result was the exact same phenomenon I have observed on the 3 after making an address mistake. The “fake” GPIOSEL register is zeroed and written to correctly. The fake GPIOSET register accepts the write too.
On both the Zero and 3, when the IO is supposedly mapped correctly, the GPIOSEL register is not changed by the writes. I’m missing something here. I’m sure of it…

Apparently I was. I just saw it right now. I’m over the bug I caught and my head is clearer. Jeffrey, for some reason I wasn’t interpreting what you wrote correctly. My math is off for the registers. I’ll fiddle with it later.
A question. I used to know how to do this but don’t any more. How do I access memory like an array? Setting up IO register blocks as arrays would be much neater and safer for the way I’d like to use them.

e: Changed the offset to 32 bit words, ie divided the memory offsets by 4 that I was using, and it worked first go. I feel like such a dummy! Thanks for the help!

Only had minutes here and there to play with this. After tweaking my GPIO “Hello World” to let me enable PWM pins for sound on the Pi Zero I started to extend it a little to make it easier to use. I’m giving it Arduino style functions because they are pretty ubiquitous. Last night I knocked together pinMode(pin, mode) with bounds checking for pin# and support for INPUT, OUTPUT, and ALT0 – ALT5
Next up will be digitalWrite(pin, state) etc. etc.
It’s just something I’m doing for myself. Because it maps the GPIO as USR accessible, and doesn’t use a HAL, it’s not exactly standards compliant. It’s also still just a messy little program and not a library. Once the basics are written I’ll deal with that. My original intent for getting access to the GPIO pins somehow is to allow me to use all the different bits of hardware I have with RISC OS. Working out how to get to them was the piece of the puzzle which fell behind the lounge haha.

I’ve done a little more but it’s not entirely why I’m here. It’s because I learned something Pi3 specific.

http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3

It’s a thread about the UARTs on the Pi3. It answers a few questions for me.

*The main UART is connected to the Bluetooth chip.

*Pins 8 and 10 on the GPIO header are the Mini UART.

*The Mini UART is dependent on system clock speed.

Lucky I have USB to logic level serial modules with a couple of different chipsets and a USB to RS232 dongle I guess. At least SPI and I2C should still be fine.
On that, I’m having trouble finding an answer to a question about overlays on the Pi. Are the overlays that are stored in a subdirectory of the boot partition linux specific or something lower level? I’d assume they were Linux specific but I just thought I’d check.
One of my goals for my little project is to be able to talk to an SPI ENC28J60 Ethernet adapter I have. I noticed that there is support in Raspbian via an overlay to allow it to be recognised, but again I’m not sure where the line between firmware and software is on this strange beast.
At best I’d probably be looking at using a mangled version of the Arduino library for the adapter to display a page. I don’t have the skill or knowledge to write a driver module for it. Sorry!

e: I was just having a look at the datasheet for the BCM43438 module that stole my precious pins. It has a builtin ARM Cortex M3. The Pi 3 just keeps getting weirder.

It’s a thread about the UARTs on the Pi3. It answers a few questions for me.

*The main UART is connected to the Bluetooth chip.

*Pins 8 and 10 on the GPIO header are the Mini UART.

*The Mini UART is dependent on system clock speed.

However that’s not the full story. If you’re not using bluetooth you can change the pin mux settings and connect the main UART back up to the standard UART GPIO pins. That’s what RISC OS currently does.

On that, I’m having trouble finding an answer to a question about overlays on the Pi. Are the overlays that are stored in a subdirectory of the boot partition linux specific or something lower level? I’d assume they were Linux specific but I just thought I’d check.

They’re Linux specific. The firmware does process the files (it merges them together, and perhaps makes other tweaks dependent on config.txt settings) but AIUI the firmware doesn’t set up any of the hardware to match what’s specified in the device tree/overlays – it leaves all of that to the OS.

e: I was just having a look at the datasheet for the BCM43438 module that stole my precious pins. It has a builtin ARM Cortex M3. The Pi 3 just keeps getting weirder.

Having a microprocessor in bluetooth/wifi modules is pretty standard. I’m not sure how it is with USB dongles, but for on-board stuff the host OS generally has to upload a firmware blob to the chip which contains the code the microprocessor will run.

Oh good! I didn’t know the standard UART was set as active in RISC OS with the Pi 3. That’s going to be a big help.

I’m getting a bit confused about the overlays now. I guess there’s some low level stuff built into one of the files on the boot partition too, like changing the PWM audio pins. I had to use that dtoverlay line to get the audio to work on the Pi Zero. At least I believe I did. I might try commenting out the line then just changing the pin mode in RISC OS via the program I’m working on.

I wasn’t expecting such a fully formed CPU in the WiFi / BT chip. The datasheet did give a tiny glimmer of hope for the chip being usable at some point at least.

Truth be told I was hoping to be way further ahead on this project than I am. Finding a way to access the GPIO via GCC was a royal pain. I was hoping to enter something in the Raspberry Pie contest months ago for the chance to win a better supported Pi so I don’t need the program I’m writing to access GPIO hahaha! Never mind. I’ll just keep going anyway. An Arduino like interface that works with GCC in RISC OS might attract a few people that have been on the fence about trying RISC OS.

Truth be told I was hoping to be way further ahead on this project than I am.

That’s the problem with hardware that is “barely documented” at best. Your BT/WiFi will have its own SoC that will be running a proper operating system. Not like Linux, an RTOS of some sort.
I’m running into the same sort of problems with my IPCAM. It’s running a MIPS processor with some flash and some memory. It has USB (as the camera module is suspiciously five wires (4 USB plus shield). But most of this was worked out by opening up the camera, and by walking around /proc from a telnet login. Datasheet? You’ll be lucky. Programmer docs? Don’t make me laugh. All of this stuff is supposed to be a little black box that the supplied firmware (flash, binary blob, whatever) takes care of and don’t you dare peek.
It really ain’t like what it was in the eighties… :-(

There were still black boxes in the eighties, however they were easier to pry open. Metaphorically speaking.
As soon as I read “MIPS” my stomach knotted. It may sound weird but I find using things that have a MIPS RISC architecture unpleasant somehow. I don’t think it has anything to do with needing to learn how to program them in the various levels of assembler at uni. I’d rather take a fork to the eye than deal with TAL in MIPS again.
Even my older equipment I’ve had to resort to my CRO or a hastily slapped together uC based thing to work out what’s going on more than once.

I’m not sure I’m meant to have the datasheet for the module. Unless they didn’t update it to reflect it’s public release nature.