Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #731 > unrolled thread

DEVICEFS Serial Driver RPC examples

Back to article view | Back to comp.sys.acorn.programmer

Contents

  DEVICEFS Serial Driver RPC examples cferris@freeRemoveuk.com.invalid - 2011-09-17 11:39 +0100
    Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-18 13:32 +1200
      Re: DEVICEFS Serial Driver RPC examples druck <news@druck.org.uk> - 2011-09-18 08:12 +0100
        Re: DEVICEFS Serial Driver RPC examples cferris@freeRemoveuk.com.invalid - 2011-09-18 09:34 +0100
        Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-19 02:50 +1200
          Re: DEVICEFS Serial Driver RPC examples cferris@freeRemoveuk.com.invalid - 2011-09-18 17:46 +0100
            Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-19 08:34 +1200
              Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-19 09:08 +1200
                Re: DEVICEFS Serial Driver RPC examples "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-09-18 23:15 +0200
                  Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-21 14:14 +1200
              Re: DEVICEFS Serial Driver RPC examples cferris@freeRemoveuk.com.invalid - 2011-09-18 22:42 +0100
                Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-19 10:57 +1200
                Re: DEVICEFS Serial Driver RPC examples Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-19 18:37 +0200
                  Re: DEVICEFS Serial Driver RPC examples Thomas Milius <Thomas-Milius@t-online.de> - 2011-09-20 19:49 +0200
                    Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-21 11:34 +1200
                      Re: DEVICEFS Serial Driver RPC examples Thomas Milius <Thomas-Milius@t-online.de> - 2011-09-23 20:55 +0200
                        Re: DEVICEFS Serial Driver RPC examples Ron <beeb@woosh.co.nz> - 2011-09-24 19:16 +1200

#731 — DEVICEFS Serial Driver RPC examples

Are there any examples of using the DEVICEFS with the RPC Serial port?

ie OPENIN and OPENOUT with devices#

Thanks
--                                                               
Colin Ferris Cornwall UK

[toc] | [next] | [standalone]

#732

In message <d698181452.cferris@cferris.freeuk.com>
          cferris@freeRemoveuk.com.invalid wrote:

> Are there any examples of using the DEVICEFS with the RPC Serial port?
> 
> ie OPENIN and OPENOUT with devices#
> 
> Thanks
> --                                                               
> Colin Ferris Cornwall UK

I downloaded 
http://www.xat.nl/riscos/sw/bd/rev10a.zip
There is a BASIC file called Example.

I got a Syntax error on my Iyonix.
Changing this definition

DEFFnd(A%,B%,C%,D%)
   CALL driver TO A%     
=A%

I changed second line to   
CALL driver,A%
and it seems to run, but not sure if it's 100% correct.

The question is, does "Serial:" then use the reportedly
installed driver, or how else would you stream the data?
  
Sorry, I haven't experimented with it yet.

Ron M.

[toc] | [prev] | [next] | [standalone]

#733

On 18/09/2011 02:32, Ron wrote:
> I got a Syntax error on my Iyonix.
> Changing this definition
>
> DEFFnd(A%,B%,C%,D%)
>     CALL driver TO A%
> =A%
>
> I changed second line to
> CALL driver,A%
> and it seems to run, but not sure if it's 100% correct.

The original code was attempting to return the value of register R0 from 
the driver code via A%, using some non standard syntax which may be 
available on other variants of BASIC. You've changed it to pass the 
value of A% in register R0 *to* the driver code.

The way to do it which will work on all versions of BASIC is:-

   A% = USR(driver)

The values in A% to H% will automatically be copied in to registers R0 
to R7 and passed to the driver. A% will be updated with the value to R0 
on exit from the driver.

---druck

[toc] | [prev] | [next] | [standalone]

#734

In message <j545kg$vk3$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 18/09/2011 02:32, Ron wrote:
[snip]
 
>    A% = USR(driver)
> 
> The values in A% to H% will automatically be copied in to registers R0 
> to R7 and passed to the driver. A% will be updated with the value to R0 
> on exit from the driver.
> 

Thanks for info - but am trying to use the DEVICEFS system - with the
RPC to start with - if that works - try and make a 'Serial Driver' that
other programs can use.

If this works - make a 'Serial Driver' for the 'Iyonix/Beagle' - that
can use the 'FTDI' module (which used DEVICEFS) to send to a 'USB to
RS232' converter.


For the RPC  someone wrote:-
*******
in%  = OPENIN "devices#baud19200;sleep:$.Serial"

out% = OPENOUT "devices#baud19200;sleep:$.Serial"
********

Where does the info - between the speech marks come from?

ie 'sleep'!!


Thanks
-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#735

In message <j545kg$vk3$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 18/09/2011 02:32, Ron wrote:
> > I got a Syntax error on my Iyonix.
> > Changing this definition
> >
> > DEFFnd(A%,B%,C%,D%)
> >     CALL driver TO A%
> > =A%
> >
> > I changed second line to
> > CALL driver,A%
> > and it seems to run, but not sure if it's 100% correct.
> 
> The original code was attempting to return the value of register R0 from 
> the driver code via A%, using some non standard syntax which may be 
> available on other variants of BASIC. You've changed it to pass the 
> value of A% in register R0 *to* the driver code.
> 
> The way to do it which will work on all versions of BASIC is:-
> 
>    A% = USR(driver)
> 
> The values in A% to H% will automatically be copied in to registers R0 
> to R7 and passed to the driver. A% will be updated with the value to R0 
> on exit from the driver.
> 
> ---druck

Thanks for getting me past that hurdle, I now have the 'Example'
program chatting between RPC's and the settings seem to remain in
existance for the use of serial: from the CLI after quitting.
For example, using 'Example' to set the speed to 115200 allows
me to pipecopy to serial: a text file to the other rpc which is
running !Connector in ASCII mode (also set at 115200)
I have yet to find wether all of the block driver is used by
serial: but so far everything has been rock solid using small
data flows.

The Iyonix and internal32 doesn't initialise with 'Example' 
It may be that the internal32 driver was written at a later date
and by a different person.

Ron M.  
  

 

[toc] | [prev] | [next] | [standalone]

#736

In message <516fb31452.beeb@ron1954.woosh.co.nz>
          Ron <beeb@woosh.co.nz> wrote:

> In message <j545kg$vk3$1@dont-email.me>
>           druck <news@druck.org.uk> wrote:
> 
> > On 18/09/2011 02:32, Ron wrote:
> > > I got a Syntax error on my Iyonix.
> > > Changing this definition
> > >
[snip]

> 
> The Iyonix and internal32 doesn't initialise with 'Example' 
> It may be that the internal32 driver was written at a later date and
> by a different person.
>

Perhaps you would like to have go with this code copied off ROOL.
  
*******
  REM Error handling
  in% = 0
  out% = 0
  REM ON ERROR PROCerror

  REM Flush some buffers
  *FX 7 8
  *FX 8 8

  REM Identify the hardware platform and open serial input and output streams
  SYS "OS_Byte", 129, 0, 255 TO , hw%
  IF hw% < &AA THEN
    REM Pre-Iyonix uses serial
    in%  = OPENIN"devices#baud19200;sleep:$.Serial" 
    out% = OPENOUT"devices#baud19200;sleep:$.Serial" 
  ELSE
    REM Iyonix uses serial1 - Iyonix has dual serial
    in%  = OPENIN"devices#baud19200;sleep:$.Serial1" 
    out% = OPENOUT"devices#baud19200;sleep:$.Serial1" 
  ENDIF

  REM Create a buffer
  DIM buf% 256

  REM Send something
  $(buf%) = "hello" 
  SYS "OS_GBPB", 2, out%, buf%, LEN $(buf%)

  REM Receive something (a byte)
  SYS "OS_GBPB", 4, in%, buf%, 1

  REM Or (untested) poll for input
  WHILE NOT EOF#in%
    PRINT GET$#in%
  ENDWHILE

  REM Close the streams
  CLOSE#in%
  CLOSE#out%
  QUIT

  DEF PROCerror
    ON ERROR OFF
    PRINT'REPORT$" at line ";ERL
    IF in% THEN CLOSE#in%
    IF out% THEN CLOSE#out%
    QUIT
  ENDPROC
********
  
-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#737

In message <2e14be1452.cferris@cferris.freeuk.com>
          cferris@freeRemoveuk.com.invalid wrote:

> In message <516fb31452.beeb@ron1954.woosh.co.nz>
>           Ron <beeb@woosh.co.nz> wrote:
> 
> > In message <j545kg$vk3$1@dont-email.me>
> >           druck <news@druck.org.uk> wrote:
> > 
> > > On 18/09/2011 02:32, Ron wrote:
> > > > I got a Syntax error on my Iyonix.
> > > > Changing this definition
> > > >
> [snip]
> 
> > 
> > The Iyonix and internal32 doesn't initialise with 'Example' 
> > It may be that the internal32 driver was written at a later date and
> > by a different person.
> >
> 
> Perhaps you would like to have go with this code copied off ROOL.
>   
> *******
<snip>

Yes, I tried this out when it was posted on CSAProgramming.
Between rpc and the iyonix it was a bit flakey and only worked in
one direction.
I removed !SerialDev from Resources and the code does not complain,
so this code does not use the block drivers.

I have used the following code with my Python serial Midifile player
successfully on my Iyonix.

Output Path :" "Devices#sleep;baud=38400;data=8;stop=1;noparity;
nohandshake:$.Serial1" "

I believe there are differences between the two Iyonix serial ports
and from memory, the above only works with Serial1 (port2).

The Iyonix uses an HAL layer, I notice the R05 release of !SerialDev
has an extra module called BlkDrv by Paul Reuver.

These are notes I have made rather than concrete knowledge.

Ron M.   





>   

[toc] | [prev] | [next] | [standalone]

#738

In message <7af3d21452.beeb@ron1954.woosh.co.nz>
          Ron <beeb@woosh.co.nz> wrote:

> In message <2e14be1452.cferris@cferris.freeuk.com>
>           cferris@freeRemoveuk.com.invalid wrote:
> 
> > In message <516fb31452.beeb@ron1954.woosh.co.nz>
> >           Ron <beeb@woosh.co.nz> wrote:
> > 
> > > In message <j545kg$vk3$1@dont-email.me>
> > >           druck <news@druck.org.uk> wrote:
> > > 
> > > > On 18/09/2011 02:32, Ron wrote:
> > > > > I got a Syntax error on my Iyonix.
> > > > > Changing this definition
> > > > >
> > [snip]
> > 
> > > 
> > > The Iyonix and internal32 doesn't initialise with 'Example' 
> > > It may be that the internal32 driver was written at a later date and
> > > by a different person.
> > >
> > 
> > Perhaps you would like to have go with this code copied off ROOL.
> >   
> > *******
> <snip>
> 
> Yes, I tried this out when it was posted on CSAProgramming.
> Between rpc and the iyonix it was a bit flakey and only worked in
> one direction.
> I removed !SerialDev from Resources and the code does not complain,
> so this code does not use the block drivers.
> 
> I have used the following code with my Python serial Midifile player
> successfully on my Iyonix.
> 
> Output Path :" "Devices#sleep;baud=38400;data=8;stop=1;noparity;
> nohandshake:$.Serial1" "
> 
> I believe there are differences between the two Iyonix serial ports
> and from memory, the above only works with Serial1 (port2).
> 
> The Iyonix uses an HAL layer, I notice the R05 release of !SerialDev
> has an extra module called BlkDrv by Paul Reuver.
> 
> These are notes I have made rather than concrete knowledge.
> 
> Ron M.   
> 
This morning, I have found that 'Example' is working on the
Iyonix with Internal32, and will chat with the RiscPC.
It does however get corrupted running it a second or third
time, but this can be corrected by double clicking the
BlkDrv module after which it initialises successfully again.

Ron M>   

[toc] | [prev] | [next] | [standalone]

#739

In article <7703d61452.beeb@ron1954.woosh.co.nz>,
   Ron <beeb@woosh.co.nz> wrote:

> This morning, 

OK, tonight here in the UK!

> I have found that 'Example' is working on the Iyonix with Internal32, and
> will chat with the RiscPC. It does however get corrupted running it a
> second or third time, but this can be corrected by double clicking the
> BlkDrv module after which it initialises successfully again.

Sounds like it needs a 'wrapper' to ensure functionality.
I seem to remember similar stuff establishing contact from an RPC to an
Amstrad Note... - whatever it was called.

But cannot your present need be served by serial networking (at a higher
level)?

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

[toc] | [prev] | [next] | [standalone]

#755

In message <5214d6b1ccUCEbin@tiscali.co.uk>
          "John Williams (News)" <UCEbin@tiscali.co.uk> wrote:

> In article <7703d61452.beeb@ron1954.woosh.co.nz>,
>    Ron <beeb@woosh.co.nz> wrote:
> 
> > This morning, 
> 
> OK, tonight here in the UK!
> 
> > I have found that 'Example' is working on the Iyonix with Internal32, and
> > will chat with the RiscPC. It does however get corrupted running it a
> > second or third time, but this can be corrected by double clicking the
> > BlkDrv module after which it initialises successfully again.
> 
> Sounds like it needs a 'wrapper' to ensure functionality.
> I seem to remember similar stuff establishing contact from an RPC to an
> Amstrad Note... - whatever it was called.
> 
Looking into this, it is caused by quitting the BASIC loop with the
Esc or Break keys, which leaves the serial port 'in use'
If  J%=FNd(DRIVER_CLOSEDOWN,0,0,0) is run before Esc or Break is used
there is no problem initialising the driver the second time.
Can one trap these keys from BASIC? Otherwise the loop would have to be
quit by some other unused key, maybe the End key, then issue the
DRIVER_CLOSEDOWN before END(of program).

> But cannot your present need be served by serial networking (at a higher
> level)?
> 
> John
> 
I have only looked at !PPPServe so far. Untested but I had to 
use Druck's BASIC correction for it also.
It was using something different again to load the driver.

Ron M
 

[toc] | [prev] | [next] | [standalone]

#740

In message <7af3d21452.beeb@ron1954.woosh.co.nz>
          Ron <beeb@woosh.co.nz> wrote:

> In message <2e14be1452.cferris@cferris.freeuk.com>
>           cferris@freeRemoveuk.com.invalid wrote:
> 
> > In message <516fb31452.beeb@ron1954.woosh.co.nz>
> >           Ron <beeb@woosh.co.nz> wrote:
> > 
> > > In message <j545kg$vk3$1@dont-email.me>
> > >           druck <news@druck.org.uk> wrote:
> > > 
> > > > On 18/09/2011 02:32, Ron wrote:
> > > > > I got a Syntax error on my Iyonix.
> > > > > Changing this definition
> > > > >
> > [snip]
> > 
> > > 
> > > The Iyonix and internal32 doesn't initialise with 'Example' 
> > > It may be that the internal32 driver was written at a later date and
> > > by a different person.
> > >
> > 
> > Perhaps you would like to have go with this code copied off ROOL.
> >   
> > *******
> <snip>
> 
> Yes, I tried this out when it was posted on CSAProgramming.
> Between rpc and the iyonix it was a bit flakey and only worked in
> one direction.
> I removed !SerialDev from Resources and the code does not complain,
> so this code does not use the block drivers.

That is correct - the !SerialDev is not used.

>  I have used the following code with my Python serial Midifile player
> successfully on my Iyonix.
> 
> Output Path :" "Devices#sleep;baud=38400;data=8;stop=1;noparity;
> nohandshake:$.Serial1" "

Where does the info about using 'Devices#sleep;' etc come from?
Some info about 'DeviceFS' is in the RO 3.1 manuals

Windows BBC BASIC seems to use this.
port% = OPENUP "COM1: baud=9600 parity=N data=8 stop=1"

> 
> I believe there are differences between the two Iyonix serial ports
> and from memory, the above only works with Serial1 (port2).

Considering that the 'RPC' uses 'Serial' then I presume that the
'Iyonix' uses 'Serial0' and 'Serial1' for ports 0 & 1.

> 
> The Iyonix uses an HAL layer, I notice the R05 release of !SerialDev
> has an extra module called BlkDrv by Paul Reuver.


It looks like the 'module' is used to drive the 2nd serial port with
the help of a serial block driver.
   
Thanks
-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#741

In message <832cd91452.cferris@cferris.freeuk.com>
          cferris@freeRemoveuk.com.invalid wrote:

> 
> Windows BBC BASIC seems to use this.
> port% = OPENUP "COM1: baud=9600 parity=N data=8 stop=1"
> 

Yes we may be able to use this style with Iyonix and later
hardware, but I think the problem with older hardware was 
that serial comms was unreliable until the Block drivers
were used. Particularly for use of a serial modem.

The above may work in RISCOS as
port% = OPENUP "Serial:"
if the appropriate bits of 'Example" have been run first.
while I know this works, I haven't exhaustively tested it.
I have noticed that the 115200 setting gets retained, and
there is no way to set this in CMOS, so it may be that
the block drivers are fully utilised by serial:  


> > 
> > The Iyonix uses an HAL layer, I notice the R05 release of !SerialDev
> > has an extra module called BlkDrv by Paul Reuver.
> 
> 
> It looks like the 'module' is used to drive the 2nd serial port with
> the help of a serial block driver.
>    

Thats interesting, maybe that is the one that the Beagleboard could
use, assuming it talks to HAL for the Serial Port.

I have read that FTDI and Prolific are the two main USB-Serial
adapters used.
While there is Serial hardware to use it is going to be easier.
GPS's and AIS receivers use serial communication but some are being
made with USB adapters for laptops with no serial port.
 
Ron M.

[toc] | [prev] | [next] | [standalone]

#743

On 18/09/2011 23:42, cferris@freeRemoveuk.com.invalid wrote:

> Where does the info about using 'Devices#sleep;' etc come from?

Confusingly, this information, if you pick apart the path, is something 
dealt with by FileSwitch - re. PRM 2-20 - because you are opening the 
device through the filing system (ie Device*FS*).


> Windows BBC BASIC seems to use this.
> port% = OPENUP "COM1: baud=9600 parity=N data=8 stop=1"

It's just different parsing. The RISC OS version is what FileSwitch is 
used to.


To be honest, I'm a SerialDev guy, after banging my head over the 
eccentricities of SerialOp and the difficulty in finding a list of 
useful options to the open call (as people ask - where is "sleep" 
documented?).


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#752

In message <4e776fd3$0$30787$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> 
> To be honest, I'm a SerialDev guy, after banging my head over the 
> eccentricities of SerialOp and the difficulty in finding a list of 
> useful options to the open call (as people ask - where is "sleep" 
> documented?).

Unfortunately the options are documented very rarely. It seems that around
1996 Acorn improved the serial port handling and DeviceFS for non blocking.
So the Blockdrivers are no longer necessary today except for older versions
of the RiscPC and yes to ensure operation of so much older Software based on
it. As everyone knows the last public documentation came out for 3.5 around
1994. This isn't including the non blocking features, the new tricky OS_ARGs
usage and so on. Afterwards Acorn disappeared and so it seems that all this
remained a secret. However since ROOL was so pleased to open the RISC OS
source you can retreive some very useful information about this area from
the source. I made the attempt to documentate a couple the features during my
FTDI driver project. Unfortunately it is working only with USB ROOL Stack
Version V0.49. Not before (technical impossible due to baug in the stack) and
until now not afterwards because the internal behaviour changed and I have to
adapt to driver but I didn't found time. To complete the trouble some USB 
stack version can't be killed and RMloaded again without crashing the machine
or only with luck and choosing the right destruction sequence of the modules.

Best Regards

Thomas Milius

[toc] | [prev] | [next] | [standalone]

#754

In message <578ccb1552.Thomas@thomas-milius.t-online.de>
          Thomas Milius <Thomas-Milius@t-online.de> wrote:

> In message <4e776fd3$0$30787$ba4acef3@reader.news.orange.fr>
>           Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> 
> > 
> > To be honest, I'm a SerialDev guy, after banging my head over the 
> > eccentricities of SerialOp and the difficulty in finding a list of 
> > useful options to the open call (as people ask - where is "sleep" 
> > documented?).
> 
> Unfortunately the options are documented very rarely. It seems that around
> 1996 Acorn improved the serial port handling and DeviceFS for non blocking.
> So the Blockdrivers are no longer necessary today except for older versions
> of the RiscPC and yes to ensure operation of so much older Software based on
> it. As everyone knows the last public documentation came out for 3.5 around
> 1994. This isn't including the non blocking features, the new tricky OS_ARGs
> usage and so on. Afterwards Acorn disappeared and so it seems that all this
> remained a secret. However since ROOL was so pleased to open the RISC OS
> source you can retreive some very useful information about this area from
> the source. I made the attempt to documentate a couple the features during my
> FTDI driver project. Unfortunately it is working only with USB ROOL Stack
> Version V0.49. Not before (technical impossible due to baug in the stack) and
> until now not afterwards because the internal behaviour changed and I have to
> adapt to driver but I didn't found time. To complete the trouble some USB 
> stack version can't be killed and RMloaded again without crashing the machine
> or only with luck and choosing the right destruction sequence of the modules.
> 
> Best Regards
> 
> Thomas Milius

1: Hi, I downloaded your FDTI module, but it wont load because of Headers
being incorrect. Looking at the start of the module, and the normal
list of headers looks corrupted? (Iyonix)

Sad to hear that the USB stack has been giving so much trouble,
I think others have also had trouble, the slow rate of development
since the Iyonix was released is an indicator what a tough ask it is.
Maybe everything should have been documented more so people 
can pick up on it, but other platforms have USB problems also,
I think we are lucky we have got a fair amount of mainstream 
devices supported.

2: Perhaps this is referring to sleep.
http://www.riscosopen.org/wiki/documentation/show/HAL%20Device%20descriptor

"Sleep

This call reads or sets a device‘s power-down state. If the second parameter is -1, then the current state is returned; otherwise the second parameter must be a value in the range 0-255 giving sleepiness (0 = full power, 255 = off) and the old sleepiness is returned. Note that the value returned does not have to match the last value programmed: for example, if a device cannot power down, it will always return 0."

So if a machine doesn't have a HAL and/or device that can't powerdown,
this parameter probably gets ignored (without error).


Ron M.



 

    


  

[toc] | [prev] | [next] | [standalone]

#756

In message <1f0deb1552.beeb@ron1954.woosh.co.nz>
          Ron <beeb@woosh.co.nz> wrote:

> In message <578ccb1552.Thomas@thomas-milius.t-online.de>
>           Thomas Milius <Thomas-Milius@t-online.de> wrote:
> 
> > In message <4e776fd3$0$30787$ba4acef3@reader.news.orange.fr>
> >           Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> > 
> > > 
> > > To be honest, I'm a SerialDev guy, after banging my head over the 
> > > eccentricities of SerialOp and the difficulty in finding a list of 
> > > useful options to the open call (as people ask - where is "sleep" 
> > > documented?).
> > 
> 
> 1: Hi, I downloaded your FDTI module, but it wont load because of Headers
> being incorrect. Looking at the start of the module, and the normal
> list of headers looks corrupted? (Iyonix)
> 

Thanks for the hint. I shall try to correct during the next weeks. However my
pocket computer is broken since a while so the time is missing to examine
things like this in the train on the way from/to my regular job. I am
spending all my energie in the moment to build a replacement based on BB xM
for this pocket computer.

> 2: Perhaps this is referring to sleep.
> http://www.riscosopen.org/wiki/documentation/show/HAL%20Device%20descriptor
> 

No this is a missunderstanding. Look into Castles USB documentation:

...

Two special fields have been added that are acted on by later versions of
DeviceFS. The same functionality is also available via an IOCTL call.

Value      IOCTL  Action
Nosleep    4      true/false. Any DeviceFS stream, if opened with the special
sleep/S           field entry 'sleep' will issue OS_UpCall 6 when it would
                  otherwise block thus allowing Taskwindows to continue
                  multitasking. Default nosleep. (Note.. in currently
                  available versions of DeviceFS, without this sleep
                  ability, the same effect can be achieved by polling the
                  buffer associated with the stream and only making such a
                  'blocking' call if there is data (or space as relevant)
                  in the buffer. If no data/space is available, then an
                  UpCall 6 can be issued. (See later for details of a
                  call to provide this information)
timeout/N  5      Time in cs This will cause the stream to issue a timeout
                  error if it sleeps for too long. The default is 0 meaning

...

Best Regards

Thomas Milius

[toc] | [prev] | [next] | [standalone]

#760

In message <8c055d1752.Thomas@thomas-milius.t-online.de>
          Thomas Milius <Thomas-Milius@t-online.de> wrote:
<snip>
> No this is a missunderstanding. Look into Castles USB documentation:
> 
> ...
> 
> Two special fields have been added that are acted on by later versions of
> DeviceFS. The same functionality is also available via an IOCTL call.
> 
> Value      IOCTL  Action
> Nosleep    4      true/false. Any DeviceFS stream, if opened with the special
> sleep/S           field entry 'sleep' will issue OS_UpCall 6 when it would
>                   otherwise block thus allowing Taskwindows to continue
>                   multitasking. Default nosleep. (Note.. in currently
>                   available versions of DeviceFS, without this sleep
>                   ability, the same effect can be achieved by polling the
>                   buffer associated with the stream and only making such a
>                   'blocking' call if there is data (or space as relevant)
>                   in the buffer. If no data/space is available, then an
>                   UpCall 6 can be issued. (See later for details of a
>                   call to provide this information)
> timeout/N  5      Time in cs This will cause the stream to issue a timeout
>                   error if it sleeps for too long. The default is 0 meaning
> 
> ...
> 
> Best Regards
> 
> Thomas Milius
> 
OK, thanks. I think that will help answer the OP's question.
After experimenting, the #Devices.... command is only successful 
on the Iyonix hardware port2 (Serial1)
I connected at 115200 and had 2 way chat with the RiscPC
My SA RO3.7 RiscPC will only work well/at all with the BlockDrivers
'Example', or !Connector in this connection.

The BlkDrv (Blockdriver) module gets loaded when the Internal32
driver setup is loaded. From Colin's observation, possibly to allow
the differently configured (in RO5) Serial1 to work with the
Blockdrivers in the same way as Serial0. -just a guess.
  
Ron M.

    

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web