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

Re: gcc and RISC OS

Mon Jan 14, 2013 7:55 pm

Ho - hum - works - but not as intended.... :|

My program runs but as it calls SWI OS_Memory it seems to do so before RISC OS has got itself fully sorted out.

Result = I2C operations corrupted so semi-legible but garbled text on LCD screen.

I tried putting a delay at the start the program, but it seems RISC OS very generously lets my program execute before fully implimenting other parts of itself that I wish to use.

Hmm... more thought needed - well, Shawty did warn me - any help appreciated...

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

Re: gcc and RISC OS

Mon Jan 14, 2013 8:29 pm

Ah - perhaps I can exploit the Pi's lack of a real time clock and use the TaskAlarm to run the control system some seconds after power-up...?

It seems to start at 06:07 am on 19th March 2202.

Maybe I could use a short script in the boot sequence to just reset the system time to 00:00:00 on 01 January 2000 and then use the Alarm to run my robots control system at 00:00:10 on the same day?

Bit Heath-Robinson, but maybe RISC OS will have zipped it's flys up, brushed its teeth and combed its hair by then?

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 Jan 14, 2013 8:52 pm

OS_Memory is in the core modules, so it should be loaded way before the boot sequence even starts...

well at least it always was when I used to develop on the system. :-S

however, that aside, rather than using "TaskAlarm" which is a perfectly valid way of doing it and will work, I'm wondering if we can use the OS scheduler instead...

SWI Numbers &3B and &3C are OS_CallAfter and OS_CallEvery, both take an argument in milliseconds (which like most platforms) means 1000 of them = 1 second of time.

Now, my thinking here is to implement a relocatable module, then in the RM's init code, set up a call to OS_CallAfter with an appropriate time. In the call back you can then use something like OS_TaskStart (I think that's what it called) to start your task as normal.

Failing that, you could write a relocatable module, and trap the "Desktop Welcome" service call which is generated when the "Welcome to Risc-Os" screen appears, the RM holding the calls for OS_Memory would almost certainly be running by then.

of course you could take the quick and easy way out, but I'm not sure how well it would work.

Wrap your program up as a proper risc-os application.

That is make a directory for it starting with a ! in the file name, then add all teh pre-req files that the OS expects to be there such as !boot, !run, !sprites, !sprites22 and !runimage (your main app)

Then set "!run" up (Which is just a regular Obey file) to FORCE loading of the correct relocatable module that contains the call to 'OS_Memory' at a time that's appropriate to your program.

Lastly however.....

Since your using GCC, you could just use 'UnixLib' and Malloc your memory without depending on risc-os.....
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 Jan 14, 2013 9:03 pm

Thanks again.

I understand all of the individual words you used but not all of what you said when put together in that order.

I was interested to read about how to wrap up an app and using the pling - which I may well do....

I shall try the quick and easy Task Alarm route first.

I will consider better ways of doing this later -thanks.

Focusing on system development atm.

I expect I will have to do things properly with OS calls at some point as I will need to tackle 'threading' *gulp* - those OS calls have given me a good starting point to research from - thanks again.

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 Jan 14, 2013 9:38 pm

You may very well gulp at the thought of Threading on risc os.......

Why?

Beacuse it has none.

Well at least not in the sense your used to.

It's certainly not pre-emtive, or even co-operitive, and it's definately not multicore. You can forget things like PTHreads and co they just won't work.

Risc-Os is inherently an event driven system and traditionaly time sliced (Much like the old main frame systems) way of doing things. It more or less just fly around in a loop, giving each task on the list it's turn. That task then raises events which are handled by Relocatable modules and / or wimp tasks.

RM's generally implement one of a number of different handler types, such as an event, SWI trap os callback message or something similar.

It's actually a testament to the ARM CPU when you actually look in detail at how the OS works, if the ARM wasn't as efficient at processing as it was then there is no way on this earth it would be able to keep up. Try doing what the ARM does with a traditional X86 design and it's going to cry :-)

Oh and now you know why memory pools for desktop gui programs are called "Wimp Slots" ;-)
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 Jan 14, 2013 10:02 pm

Gooey wimps eh?

No wories - I'm happy to forget things that I haven't learned yet - simple is good ;)

Perhaps I mean 'scheduling' rather than 'threading'

The options I have been considering are here: http://www.riosscheduler.org/

and here: http://www.riscosopen.org/wiki/document ... 0RTSupport

basicaly I need two layers for control to flit between - a primary layer that adjusts the robots posture every 10ms and then another layer to do higher level things like mapping. I am guessing that I need a third 'layer' or overseeing control loop that starts by ensuring the balancing task is performed within 10ms and then resumes higher level functioning for however much of the 10ms is left before jumping back to the balancing task - can RISC OS adopt that role?

I guess I could just instead regularly poll the clock whilst doing higher level tasks to see if its time to jump to the balancing routine. But that's a bit annoying, so was wondeing if there is an elegant way of doing that. May end up using the technique you describe above?

No idea where to start, but have a few leads to follow up... any pointers appreciated.

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

Re: gcc and RISC OS

Mon Jan 14, 2013 10:31 pm

basicaly I need two layers for control to flit between - a primary layer that adjusts the robots posture every 10ms and then another layer to do higher level things like mapping. I am guessing that I need a third 'layer' or overseeing control loop that starts by ensuring the balancing task is performed within 10ms and then resumes higher level functioning for however much of the 10ms is left before jumping back to the balancing task - can RISC OS adopt that role?
You should be able to set up a timer inturupt to handle the 10ms task. Though you may have to directly set up the HW timer to handle 10ms as that is 10 times faster than the centasecond timer provided by RISC OS. Though once you have the timer set up for that, you can do everything else in a standard task, or a singletasking program if that is more appropriate,

Of couce the code that handles the 10ms timer will have to be quite fast to leave much time to do anything else.

Do you mind me asking why it has to be so fast and often? To maintin balance and regular movement I would think that you shoud be able to get away with 5 centaseconds (and then you could use the centasecond timer). If you are creating PWM servo control wave manually, you should be able to do this part with a timer setup correctly, completely independant of the task executing on RISC OS, except when you have to change the period to change the rate/dirrection of movement for the servo.
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 Jan 14, 2013 10:42 pm

Thanks - its for a 2 wheeled balancing robot - anecdotal evidence on this thread http://www.raspberrypi.org/phpBB3/viewt ... ot#p238464 suggest a 10ms frequency to be necessary. Most other people use an additional dedicated micro controller to do the ballancing, but I'm being bloody minded and trying to do it all on the Pi. I ditched desktop Linux because of its unpredictability and am currently attempting this on RISC OS because it has more focus.

If RISC OS is too slow I will try the bare metal route. If that fails I will get an aditional microcontroller like everyone else. I think it should be possible to both balance and think using just the Pi but most other people seem to disagree.

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 Jan 14, 2013 10:47 pm

Gotta agree with a lot of what David is saying here.

If you try to do that with the desktop environment running in the background / foreground (Which ever way you look at it) the performance of your program will suck.

Now there is one way you might want to consider.... but you ARE going to have to make your program into a proper "!appname" (Which is honestly NOT as hard as it might appear, you just have to follow the specifications)

once you have an application, and an obey file set to make sure that OS_Memory's module and anything else you need is loaded when your app is run, you need to do 2 things.

First, configure the system so that it doesn't boot the Risc OS desktop (I'm making the assumption here that cmos config still works even if not a real Archimedes) you do this by dropping to a command line (Press F12) and typing "*configure language 0"

Without the quotes

This will switch (Or should switch) the rom configured startup language from the desktop (Generally Language 12) to 0 (Not configured) , you might want to do a "*status" first just to see what it's set to should you want to put it back.

Restart Risc-OS and it should just drop you directly to a supervisor prompt. If not, then your !Boot sequence is over-riding things.

Rename !Boot to something else like !oldboot or similar

then create yourself a simple textfile in the root of your drive, name it !boot and set it's type to "obey", in this obey file put the command "*exec !appname" where !appname is your application.

This will boot the base OS, running just your app in a single tasking environment, and basically give it all the resources in the system to it's self. You won't however be able to do any fancy point & click wimp stuff. It'll all have to be console.
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 Jan 14, 2013 10:52 pm

Perfect - thanks :D

You make it sound easy :?

I will try that when the time comes and when I am feeling brave/lucky/foolish....
Last edited by pygmy_giant on Mon Jan 14, 2013 11:03 pm, edited 1 time in total.

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 Jan 14, 2013 10:59 pm

LOL.... that's cause it is easy, it just looks like it's not :-)

Plus you gotta remember I was using Risc-Os back in .....(Using the old grey cells) ... around about 1990 so that's over 20 years ago.

To be honest with you, I'm actually surprised just how much I remember!!!
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)

NigelJK
Posts: 65
Joined: Wed Sep 05, 2012 1:44 pm

Re: gcc and RISC OS

Tue Jan 15, 2013 5:31 pm

I would suggest that the task be a multitasking one or you may not ever get to the desktop, or even complete the boot up procedure correctly.

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

Re: gcc and RISC OS

Tue Jan 15, 2013 7:39 pm

@NigelJK - thats the whole point of suggesting single tasking the app, with a full desktop running in the background he may not be able to achive the very precise timings he needs to get to control his robot.

By doing it the single task way, he gets full control of the machine, but still has full support (More or Less) from Risc-OS.

This means he's about as close to doing this bare metal as he could possibly be, but without actually having to go fully bare metal.

Unlike many operating systems, Risc-OS does not require it's desktop to be running in order to fully functioning. In fact one of my real Acorn Archimedes (I had 3 in total) was configured to only ever boot straight into Basic.

Used to switch the machine on, and 30 seconds later be at a BBC Basic version 5 prompt ready to do single tasking development in Basic or using the built in assembler.

The WIMP environment is really only required if you want your application to use the windowing facilities presented by the system. Also don't be fooled by those that tell you you need the desktop to get access to all the colours and screen resolutions either.

OS_ColourTrans does a fantastic job of translating between colour modes & pallettes, and OS_Draw (The central engine behind the draw app) can be used perfectly well in a single tasking mode in BBC Basic.
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

Sat Jan 19, 2013 4:29 pm

Having fun experimenting.

So far under RISC OS I have written routines to display input from an alphanumeric keypad on an LCD screen and have set and read from a real time clock. I am however having a bit of trouble getting my servos to work and suspect errors in the I2C module data sheet as I have found others. Under Linux I also had access to gyro and accelerometer readings and was PWMing 2 DC motors - I have yet to translate those routines accross but it should not be too hard.

One (more) question though - is there a way to change GCCs compliance mode as I want to use other data types such as uint8_t ?

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

Re: gcc and RISC OS

Sat Jan 19, 2013 5:02 pm

Don't know if it's the same in the Risc-Os version (I would assume it is) but this any help?

http://gcc.gnu.org/onlinedocs/gcc/Standards.html
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)

User avatar
helpful
Posts: 57
Joined: Sun Oct 09, 2011 4:09 pm
Location: London
Contact: Website

Re: gcc and RISC OS

Sun Jan 20, 2013 6:05 pm

Err, all that stuff about not starting the desktop is completely unnecessary. If you run a program from the dekstop that doesn't call Wimp_Poll, then it has all the cpu power to itself. The desktop will not be "running in the background" it will be completely stopped. That's why RISC OS could be good for robotic control type applications as it is easy to get full control of the machine when required without sacrificing the nice GUI :-)

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

Re: gcc and RISC OS

Sun Jan 20, 2013 11:51 pm

Yes your correct, you effectively take over the wimp environment and become single tasking, but.....

What about service call handlers in your RM area? They still fire, and try to respond to things going on in the underlying OS.

All I'm trying to say is the less layers of abstraction you have to navigate the better it is, I mean what's the point in loading the desktop, just to suspend it in the background when you go into single tasking mode?

:-)
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)

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

Re: gcc and RISC OS

Mon Jan 21, 2013 2:58 am

Also if you want the WIMP, you can have it with out loading the desktop :) . I have done this in the past. Of cource if you put an Icon on the iconbar (thus causing it to apear) your Icon will be the only one (no desktop filer).
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

Wed Feb 13, 2013 8:26 pm

Hi again.

I have got my RISC OS Pi reading an accellerometer and gyroscope and keypad and writing to an LCD via I2C. I have previously successfully PWMed the 2 DC motors on my robot under Linux but have yet to try it under RISC OS as I don't want it to leap off the table and smash to pieces on the floor.

I would now like to have a go at setting up a timer interrupt to run a test program that simulates balancing.

One of my current test programs displays the accellerometer readings on the LCD screen in a loop until the D button on the keypad is pressed. I would like to adapt it so that instead of looping it will be called every 10ms by RISC OS.
David S said:
You should be able to set up a timer inturupt to handle the 10ms task. Though you may have to directly set up the HW timer to handle 10ms as that is 10 times faster than the centasecond timer provided by RISC OS. Though once you have the timer set up for that, you can do everything else in a standard task, or a singletasking program if that is more appropriate,

Of couce the code that handles the 10ms timer will have to be quite fast to leave much time to do anything else.
Well, 1 centasecond is 10ms (I think?) and the RPi's I2C works at 400kHz, so I am hoping to have at least some of that 10ms left over for higher functioning. I think my simulated balancing test program will be quick as intially it needs only:

1) read a value from an area of memory available to other programs
2) get x-axis accerometer reading via I2C
3) get x-axis gyroscope reading via I2C
4) dispay these 3 values on the LCD via I2C
5) add these 3 values and write the result to an area of memory available to other programs
6) end

I am hoping that I will also be able to run another test program in the background that passes values to and from this smaller frequently called 'balancing simulator'. This background program would represent a more abstract control system that might be concerned with non time critical tasks such as mapping the environment and setting the robots course.

I am not sure how to do this but I think I need to use a SWI to set this up. My question is - which SWIs should I use?

Think I need a HAL_interrupt API

http://www.riscosopen.org/wiki/document ... HAL%20APIs

I think this one?

http://www.riscosopen.org/wiki/document ... imer%20API

Any help much apprecitaed!

:)

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

Re: gcc and RISC OS

Wed Feb 13, 2013 11:04 pm

@pygmy_giant:
Using the HAL is not the best way to do these things. load your application as above, start the WIMP Module (not the full desktop) set your wimpmode, and hook the centasecond timer for the stuff that youneed to run every 10ms=1cs then do what is needed there while running the main application to do the non time dependant stuff. So long as done correctly and there is time left over you will have accomplished your goal. You will still want to do this without the desktop enviroment, as you want to have all the time to your self (or as much as possible [USB takes some, the Display manager takes some, etc..]). You make me ish that I had enough of the new USB stuff working correctly to upload to the CVS, the newer USB Stack is alot beter about managing time, and takes a lot less away from the rest of the system, though is still far from complete, and has some interesting bugs (some of which i wonder if are RPi specific :-( ).
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

Wed Feb 13, 2013 11:11 pm

Thanks for all your help and work on the stack.

There is no rush - the world can wait!

Best of luck squashing those bugs.

Think my next step will be to wrap my programs up into a pretty little apps with a bow on top and get RISC OS booting to commandline and auto running the background program - I will give this all further thought - expect more questions!

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

Re: gcc and RISC OS

Thu Feb 14, 2013 12:27 am

Well as much as I'd like to comment on using the HALL stuff, I can't... why?

It simply didn't exist when I was working on these things full time, so it's not something I know :-)

I'd listen to DavidS here as he seems to know what he's on about ...
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

Thu Feb 14, 2013 1:38 am

He does, doen't he - thanks for your advice also.

After appifying my code, and making RISCOS boot without desktop, how would I
start the WIMP Module (not the full desktop) set your wimpmode, and hook the centasecond timer for the stuff that youneed to run every 10ms=1cs
please?

Also how can I ensure that OS_memory is loaded?

Any help received with gratitude.

:)
Last edited by pygmy_giant on Thu Feb 14, 2013 2:00 am, 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 1:57 am

pygmy_giant wrote:He does, doen't he. After appifying my code, how do I
start the WIMP Module (not the full desktop) set your wimpmode, and hook the centasecond timer for the stuff that youneed to run every 10ms=1cs then do what is needed there while running the main application
?

Any help appreciated.

:)
actualy the wimp module should already be there :-) .

So the next thing is to write your application as a WIMP application (eg it calls "Wimp_Initialise" durin its initialization, and uses "Wimp_CloseDown" to exit), since you are single tasking you probably do not want to bother with Wimp_Poll unless you plan on including some extra user interaction (though it should not hurt).

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. Beings as you will be running on a reasonably clean system there should ve very little in the call chain, so this should work well for you.

In most situations it is best to avoid the HAL unless you are adding HW support to the HAL. This is because the HAL is not garentied to always be there, or for that matter not to change. Many of the RISC OS Select versions pretty much did away with the HAL, and there are a number of RISC OS users that argue that this should be done with the ROOL version as well, using a well structured set of modules to provide HW independance by moving all of the HW dependant stuff out of the kernel into these modules.
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:04 am

Shawty wrote:Well as much as I'd like to comment on using the HALL stuff, I can't... why?

It simply didn't exist when I was working on these things full time, so it's not something I know :-)

I'd listen to DavidS here as he seems to know what he's on about ...


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.
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

Return to “RISCOS”