pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 2:10 am

Many thanks again David.

I think I have enough information to get started but I also think I have one last question - you said:
Next claim the centasecond timer, to do this call "OS_Claim" with hex &1C in R0, and the address of the routine that you wish to execute 100 times per second in R1, and an arbitratry value in R2.
If I write my application in C, I guess I will have one program instead of 2 and that the balancing part to be called every centisecond will be in a function. If this is correct, how can I get the address of that function to put in R1?

Apologies for asking so many questions and thanks in advance for any answers.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 2:29 am

pygmy_giant wrote:Many thanks again David.

I think I have enough information to get started but I also think I have one last question - you said:
Next claim the centasecond timer, to do this call "OS_Claim" with hex &1C in R0, and the address of the routine that you wish to execute 100 times per second in R1, and an arbitratry value in R2.
If I write my application in C, I guess I will have one program instead of 2 and that the balancing part to be called every centisecond will be in a function. If this is correct, how can I get the address of that function to put in R1?

Apologies for asking so many questions and thanks in advance for any answers.
In C to get the address of a function you use a function pointer, eg:

Code: Select all

void handlerfn(void);

int main(void)
{
  unsigned long PassAddr;  // Address of handler to pass is stored here.
  void (*HndlrAddr)(void);    // An unneeded intermediate veriable for clarity.
  /* Some code here */
  HndlrAddr = &Handlerfn;   // Unneeded intermediate assignment for clarity.
  PassAddr=(unsinged long)HndlrAddr;  // Assign the address of Handlerfn to PassAddr.
  /* more code */
  /* exit code */
}
And use the value stored in PassAddr. Of cource you coul just use a in place type cast in the system call, thus eliminating the need for any extra variables, though I think it is clearer and easier to read with the extra variables.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 2:41 am

and to make the system call you would use:

Code: Select all

_swi(0x1F,  0x1C, PassAddr, 0);  // SWI 0x1F is the OS Call "OS_Claim, and vector 0x1C is TickerV,
                                                 //TickerV is the vector called by the centasecond timer.
The 0 on the end is just a place holder, it is the value to put in R2, that would be passed to the routine in R12, in case you were using the same handler for more than one vector. Though be careful do not multitask unless you write your program as a module.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: gcc and RISC OS

Thu Feb 14, 2013 3:11 am

DavidS wrote:
To the best of my knowledge the HAL was added by PACE for set top boxes, and later removed by RISC OS Ltd. for the RISC OS Select versions, though the Castle versions retained the HAL, despite the solution providedin RISC Select being more in line with the way that RISC OS works.
I am not sure of the about the HAL being " later removed by RISC OS Ltd. for the RISC OS Select versions", in that RISC OS 4 (which predates Select) didn't have a HAL either and was produced by RISC OS Ltd. As far as I know (and I am open to correction here) ROL didn't use a HAL because they hadn't got one - and given that the hardware they were developing for had the required Acorn designed parts (IOMD/VIDC) it would have (arguably) not made sense to include a HAL even *if* they'd had one.

RISC OS Version 5 (The Castle/Tematic one was probably - as you say derived - from work for PACE) it did include a HAL in that Castle needed that to run RISC OS on what amounted to be "alien" hardware for their Tungsten/Iyonix machine. To do that in a timely fashion needed a HAL (remember RISC OS was built to run on an IOMD/VIDC equipped machine - and Iyonix contained neither and had a 32 bit (only) ARM, PCI and a NVidia video card to deal with as well).

The fact a 32 bit hardware abstracted version of RISC OS made it onto "non-traditional" hardware *first* is vindication of the approach. Having a working RISC OS that does use a HAL it would not make sense to (IMHO) for it to then be removed as it would break the OS and require a major re-write for (arguably) little benefit.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: gcc and RISC OS

Thu Feb 14, 2013 3:15 am

DavidS wrote:
pygmy_giant wrote:Many thanks again David.

I think I have enough information to get started but I also think I have one last question - you said:
Next claim the centasecond timer, to do this call "OS_Claim" with hex &1C in R0, and the address of the routine that you wish to execute 100 times per second in R1, and an arbitratry value in R2.
If I write my application in C, I guess I will have one program instead of 2 and that the balancing part to be called every centisecond will be in a function. If this is correct, how can I get the address of that function to put in R1?

Apologies for asking so many questions and thanks in advance for any answers.
In C to get the address of a function you use a function pointer, eg:

Code: Select all

void handlerfn(void);

int main(void)
{
  unsigned long PassAddr;  // Address of handler to pass is stored here.
  void (*HndlrAddr)(void);    // An unneeded intermediate veriable for clarity.
  /* Some code here */
  HndlrAddr = &Handlerfn;   // Unneeded intermediate assignment for clarity.
  PassAddr=(unsinged long)HndlrAddr;  // Assign the address of Handlerfn to PassAddr.
  /* more code */
  /* exit code */
}
And use the value stored in PassAddr. Of cource you coul just use a in place type cast in the system call, thus eliminating the need for any extra variables, though I think it is clearer and easier to read with the extra variables.
Thanks for that informative post David, much appreciated.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 3:39 am

AMcS wrote:I am not sure of the about the HAL being " later removed by RISC OS Ltd. for the RISC OS Select versions", in that RISC OS 4 (which predates Select) didn't have a HAL either and was produced by RISC OS Ltd. As far as I know (and I am open to correction here) ROL didn't use a HAL because they hadn't got one - and given that the hardware they were developing for had the required Acorn designed parts (IOMD/VIDC) it would have (arguably) not made sense to include a HAL even *if* they'd had one.
It very likely may have been removed before the release of ROL RISC OS 4, this I can not say for sure, the earliest ROL RISC OS that I have is RISC OS 4.02.
While I am sure that there are any number of sources of information out there on this topic:
To this I will point you to Justin Fletcher (Gerph):
Justin Fletcher wrote:

Hardware Abstraction

Other modules were far more obvious as replacements - CMOS (configuration data) access was in the Kernel, which meant that we ended up having direct hardware access in the Kernel - an unreasonable state of affairs. Pace had decided to go about this problem by providing what they called a 'HAL'. Essentially this meant "lift bits out of the kernel wholesale, not changing any APIs and just dump them in something that you can vector through". Unlike splitting things into module with proper RISC OS APIs and the like, this had the problem that the already quite poor internal interfaces that were 'abstracted' were left in this HAL where other hardware had to be shoehorned to work with. Maybe that's a bit uncharitable, but I have the completely diametric view that hardware functionality is a modular thing, and we have a well defined, and (relatively) well implemented system for doing so already in RISC OS. These components that provide hardware access are no different to those that come on Podules, so should not be treated as special. And, of course, many hardware things shouldn't sit 'under' the Kernel in a HAL, but should live above it.

This said, in order to know which modules need to be loaded (due to Unplug constraints) on start up, you need to have access to the configuration data. So... we need to know configuration in order to select modules for start up, but we also need to have modules in order to get at the configuration. Simple - a flag to indicate that some modules need to be initialised early. Not only does this address the issue of NVRAM configuration (and many other abstractions) but means that we can ensure that the PoduleManager is started early and remove the collusion that required it to be the second module. Other extension module providers would also have early initialisation here, were they to be present.
For more see:
http://gerph.org/riscos/ramble/modulari ... bstraction
AMcS wrote:Thanks for that informative post David, much appreciated.
I thought it common knowledge, I almost never use C, as I prefer assembly, this is just a standard part of the ANSI C programming Language, and the language definition is so small that I figure that any one that has made any estencive use of it would remember the entire core language by heart.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

sawdust
Posts: 40
Joined: Fri Jul 27, 2012 7:09 am

Re: gcc and RISC OS

Thu Feb 14, 2013 8:15 am

David,
The fork in the OS happened after RO4.02, which was a development of the OS Acorn had intended for Phoebe. Any changes in 4.xx after 4.02 did not make it into the RO5.xx code. Likewise any developments to the 5.xx branch did not feed back into 4.xx. So everything Justin writes about refers to changes in the ROL 4/6 branch not the PACE/Castle/ROOL 5 branch (which was the first to have a HAL).

ROL aiui took a different tack on hardware abstraction with their branch in not having a HAL but each platform requiring dedicated modules for all the differences in each platform they supported.(all two of them I think), While RO 5 uses the HAL approach which has enabled porting to five platforms so far (IOMD, Tungsten, OMAP3, OMAP4 and RPi).

Sawdust

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 1:38 pm

sawdust wrote:David,
The fork in the OS happened after RO4.02, which was a development of the OS Acorn had intended for Phoebe. Any changes in 4.xx after 4.02 did not make it into the RO5.xx code. Likewise any developments to the 5.xx branch did not feed back into 4.xx. So everything Justin writes about refers to changes in the ROL 4/6 branch not the PACE/Castle/ROOL 5 branch (which was the first to have a HAL).
I am aware of the branch being after that, though aparently there was some form of HAL that was removed by ROL, I had figured that this HAL must be the same as the one that ROOL extended.
ROL aiui took a different tack on hardware abstraction with their branch in not having a HAL but each platform requiring dedicated modules for all the differences in each platform they supported.(all two of them I think), While RO 5 uses the HAL approach which has enabled porting to five platforms so far (IOMD, Tungsten, OMAP3, OMAP4 and RPi).

Sawdust
And my point being the difference in stratagy in HW abstraction. The HAL does make sence for other OSes, though if the kernel knows nothing of the HW (except the core instruction set, and MMU), and the rest is provided by ROMModules loaded after the kernel this could actually simplify porting. I think that ROL just did not have the incentive to port to much other HW. Though they did port to a ARM9 Based computer, the A9Home.

Remember that most of the HW Support that we have with ROOL RISC OS came after it whas released as Shared Source. I am fairly sure that Castle never supported any HW other than the IYONIX PC, correct me if I am wrong.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Tide
Posts: 93
Joined: Wed Sep 14, 2011 11:21 am

Re: gcc and RISC OS

Thu Feb 14, 2013 5:31 pm

I am fairly sure that Castle never supported any HW other than the IYONIX PC, correct me if I am wrong.
Fair point. OTOH the A9 Home wasn't exactly a success and the OS remains partly unfinished with no hope for bug fixes now that ROL seems to have kicked the can. In a similar way Select for the Iyonix never happened either (which didn't stop ROL from talking Iyonix users into paying for a bag of hot air)

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 9:12 pm

Tide wrote:
I am fairly sure that Castle never supported any HW other than the IYONIX PC, correct me if I am wrong.
Fair point. OTOH the A9 Home wasn't exactly a success and the OS remains partly unfinished with no hope for bug fixes now that ROL seems to have kicked the can. In a similar way Select for the Iyonix never happened either (which didn't stop ROL from talking Iyonix users into paying for a bag of hot air)
This is true on both acounts, unfortunately. RISC OS Select had some nice features, though I have not heard of any activity from them in some time.

Now we have ROOL RISC OS 5.1x and it is shared source, with many portions now under a BSD License, we need to update it a bit. There are some things that are definitely behind the curve.

I still think that writing modules for the hardware interface would be easier to maintain than the current system of using the HAL. Of cource, if this update were made, there would need to be a HAL Emulation module for things that use the HAL directly (are there any other than for HW support???).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 10:34 pm

Following DavidS' instructions causes nothing to happen when the test program is run under a desktop environment. On exiting the program the desktop is replaced by a black screen with a movable blue pointer.....is this to be expected?

I think I will re-try by running the test program as an app on boot without loading the desktop to see if that makes a difference.....should it?

Perhaps a centisecond is too quick with the desktop running?

I will try without using OS_memory to BSCs for I2C incase it is a clash with that ....?

Re: function addresses - after a bit of head-scratching I cant find a reason not to just code:

Code: Select all

_swi(0x1F,  0x1C, &function_name, 0);
without setting up a pointer....?

would using _kernel_swi_regs make any difference?

As usual any help appreciated - I will dig about the net to see if I can find any more clues.....

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 10:50 pm

I will try without using OS_memory to BSCs for I2C incase it is a clash with that ....?
Nope. Removing any code using I2C and OS_memory actually causes more errors(!)

Rather than running but without the OS_claim executing, it does not run at all! I get the outline of the task window but without anything inside - not even the background - it is just a rectangle outline with the desktop showing through(!)

Clicking the mouse escape exits to a black screen with blue pointer again but this time it doesn't move - this suggests the program has generated an unobservable error and terminated straignt away - into paralysis.

Further thought neeed....will try without desktop....

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 11:06 pm

... or maybe its because I overclocked my Pi?

will remove the over clocking ....

... nope did not help ... will take a break and re-try with fresh eyes tomorrow ....

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: gcc and RISC OS

Thu Feb 14, 2013 11:11 pm

sawdust wrote: ROL aiui took a different tack on hardware abstraction with their branch in not having a HAL but each platform requiring dedicated modules for all the differences in each platform they supported.(all two of them I think), While RO 5 uses the HAL approach which has enabled porting to five platforms so far (IOMD, Tungsten, OMAP3, OMAP4 and RPi).
It's an approach that does seem to work.

I was trying to get onto the Iyonix site this evening to read up on the exact workings of the HAL - but the site seems either down or massively unresponsive (I managed to read a copy of the HAL page cached on Google). I sure hope the site (and content) doesn't disappear as it's a valuable resource.

The page was originally at http://www.iyonix.com/32bit/HAL.shtml, it gives a good overview into the design and it's philosophy.

UPDATE: The link seems to be Ok now (phew close call that !).
Last edited by AMcS on Thu Feb 14, 2013 11:19 pm, edited 1 time in total.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 11:12 pm

@pygmy_giant:
I had only used the pointer variable as an ilistration aid. Using:

Code: Select all

 _swi(0x1F,0x1c,&fn_name,0);
should work as expected.

I will try this in a minute to see if I had made an error in my instructions. Also what C compiler are you using, I have heard that GCC is no good for this, so you may wish to use the Norcroft C Compiler (version 5.70) as this may be part of the issue.

I usualy use Assembly for this stuff.

I will check this and tell you in a few minutes (maybe slightly more if I end up crashing RISC OS).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 11:26 pm

Thanks - I put my head between my knees and brace for impact (just in case).....

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 11:45 pm

Ok it works fine, I tested it by incrementig a global variable in the function at 1 centasecond, and displayed the value of that function in the main control loop (it incremented faster than the control loop), though it does not work if the WIMP is present, so that part was my error. So do it with out the wimp.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Thu Feb 14, 2013 11:50 pm

I must add, it works fine with the WIMP running in assembly, I do not know why the trouble with the wimp in C???
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Thu Feb 14, 2013 11:56 pm

Thanks - reassuring - I will re-try without WIMP - failing that I will try with _kernel_swi_regs, failing that I will try declaring function as static or volatile or something, failing that I will try to get the Norcroft compiler, failing that I will learn assembly, failing that I will get a new hobby.

User avatar
Shawty
Posts: 59
Joined: Fri Nov 16, 2012 1:22 am
Location: North East UK
Contact: Website

Re: gcc and RISC OS

Fri Feb 15, 2013 12:51 am

Justin Fletcher wrote:


Hardware Abstraction

Other modules were far more obvious as replacements - CMOS (configuration data) access was in the Kernel, which meant that we ended up having direct hardware access in the Kernel - an unreasonable state of affairs. Pace had decided to go about this problem by providing what they called a 'HAL'. Essentially this meant "lift bits out of the kernel wholesale, not changing any APIs and just dump them in something that
Snip......

Now there's a name I remember :-)

Nice to know he's still around....

(For those younger members : He's an Original Acorn hack same as me :-) - Although I'll probs get shouted at for saying that...)
still crazy (Even since the days of my BBC Model B) BEST and only way to be ;-)

IM: @shawty_ds on twitter
if you remember the Acorn and BBC days then I was "!Shawty! of DSPD" (Author of the BBC B Sound Tracker suite, and the Dreamscape demo)

BleakHouse
Posts: 9
Joined: Mon Feb 18, 2013 12:12 am

Re: gcc and RISC OS

Mon Feb 18, 2013 12:23 am

This thread has gone many different places. It would be very helpful to me if someone could post some c code that reads and writes GPIOs. I can compile c.HelloWorld and have some code written under Raspbian that runs fine but I would like the OS to get out of the way. I think I'm in the right place.
I would be grateful for any help.

User avatar
Shawty
Posts: 59
Joined: Fri Nov 16, 2012 1:22 am
Location: North East UK
Contact: Website

Re: gcc and RISC OS

Mon Feb 18, 2013 10:38 am

@Bleakhouse,

I think you may not be in the correct place for "GPIO" code, it sounds to me (esp since you mention Raspbian) that you might just be looking for generic "C" code for the GPIO and not code specific to Risc-OS.

While I agree that this discussion has gone in many different directions, it was never originally about writing the GPIO, it was actually originally about the differences in getting GCC (The C compiler suite) to work reliably with the Risc-OS file system.

This over time has turned into a general performance guide about writing single tasking hardware code using Risc-OS as the base platform for doing so.

My advice to you, is to look in the "C programming" section of the forum, or if your wanting the OS out of the way completely, then look in the "Bare metal" programming area, there are plenty of code examples already pasted into the many discussions.

When I first started with my rPI I spent 4 or 5 weeks just reading through posts before I started participating in them, not only did I read posts related to what I was doing, but I read many others too and learned a whole heap of new things.

Discussion & reading is a great medium, never under estimate it's power. Iv'e been doing this coding lark for most of my life, and in just this thread alone Iv'e learned some new things.

If however, all you want is a quick copy & paste code fix, then I'm sure if you start a "Please give me code" discussion in the correct place , someone will "Give you some code"

regards
shawty
still crazy (Even since the days of my BBC Model B) BEST and only way to be ;-)

IM: @shawty_ds on twitter
if you remember the Acorn and BBC days then I was "!Shawty! of DSPD" (Author of the BBC B Sound Tracker suite, and the Dreamscape demo)

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Mon Feb 18, 2013 3:52 pm

@BleakHouse

The code I posted on this thread http://www.raspberrypi.org/phpBB3/viewt ... 2c#p229174 bypasses RISC OS for the purposes of using I2C.

I am currently working on adapting it to access GPIO for simpler control... cf the broadcom data sheet. I expect it literally requires only a few more lines of code to access the correct addresses rather than those relating to I2C. I too would be grateful for any help - failing that I will report back if I figure it out myself...

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: gcc and RISC OS

Mon Feb 18, 2013 4:11 pm

@pygmy_giant:
I had just relized that I do not if thatwould work the same in GCC, i compiled my test using Norcroft C.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: gcc and RISC OS

Mon Feb 18, 2013 4:28 pm

If you are referring to OS_Claim - I'll try it from GCC as soon as I get a spare SD card.....

....If you are referrig to the I2C code using OS_memory - it works just fine :)

Return to “RISCOS”