heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Paralle data entry

Fri Feb 01, 2013 8:56 pm

Advice needed please: can the RPi (under RISC OS and BASIC) cater for parallel data entry ( eg by designating 8 GPIO lines as a parallel port) ? I have an application where I want to read a 24-bit counter as fast as possible, as often as possible. I currently use a commercial PIC-based micro running BASIC, and this works well, reading a single byte in 90 microseconds using just three instructions (selectchip, read data, deselect). On the RPi, I gather than RISC OS - BASIC would be faster than Linux-Python, but the BASIC interpreter appears to lack I/O facilities. What have I missed ? (My apologies if this is a stupid question).

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

Re: Paralle data entry

Sat Feb 02, 2013 2:42 am

There is a GPIO module for BBC BASIC on RISC OS available through !PacMan as well as a manual for it separately available through !PackMan.

Also make sure that your voltages are correct when using the GPIO pins, there is nothing protecting the SOC from an error in a hardware configuration.

Though it is definitely possible, I have written a module to print to my Parallel Port OkiData Laser Printer and it works great (both input and output), and it should work well with just about anything.
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: Paralle data entry

Sun Feb 03, 2013 3:05 am

heuristicjohn wrote: On the RPi, I gather than RISC OS - BASIC would be faster than Linux-Python, but the BASIC interpreter appears to lack I/O facilities. What have I missed ? .
BBC BASIC does provide some commands (like VDU) that does address hardware (via RISC OS), but as it is easy to add new hardware at any time to account for this in BASIC would be difficult as you'd need to keep adding new commands to BASIC for each new piece of hardware. Also not everyone would have that hardware so you'd have BASIC polluted with rarely used I/O commands - and as each command has to be interpreted this would hit performance.

BBC BASIC instead provides a general purpose command (SYS) that allows you to invoke functions in the OS or added to the OS by "lumps" of code called Relocatable Modules. The modules also provide a "human friendly" name for these commands and these can be invoked by name using SYS.

For GPIO a third party module (like Tank's) adds functionality to access and control the GPIO pins. Once this module is loaded then BBC BASIC can be used to invoke it (using the aforementioned SYS command).

And finally if you need to you can resort to the Assembler built into BBC BASIC to get the I/O task done.

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: Paralle data entry

Sun Feb 03, 2013 11:12 am

Many thanks for helpful replies. I downloaded the GPIO manual (had to run !PackMan update for it to appear on the list). A brief look suggested you can set individual IO pins but I did not see references to GPIO.set(PIO,OUT) and GPIO.output(PIO,x) which have been mentioned elsewhere. Sadly, when I resumed today the manual was unavailable (error SDFS::RISCOSpi.$Apps.Misc.!StrongHlp.!Run not found) so I have to sort this out before resuming.
I have been an admirer of BBC BASIC for many years, but do feel that I/O is a weak point, when compared with other BASIC versions I use. However, I have the Bruce Smith book on Assembly Language, so this might be an option.
I intend to run my 74HC logic chips at 3.3V, so no level problems.

tank
Posts: 64
Joined: Thu Dec 15, 2011 5:51 pm

Re: Paralle data entry

Sun Feb 03, 2013 12:11 pm

heuristicjohn wrote:Advice needed please: can the RPi (under RISC OS and BASIC) cater for parallel data entry ( eg by designating 8 GPIO lines as a parallel port) ? I have an application where I want to read a 24-bit counter as fast as possible, as often as possible. I currently use a commercial PIC-based micro running BASIC, and this works well, reading a single byte in 90 microseconds using just three instructions (selectchip, read data, deselect). On the RPi, I gather than RISC OS - BASIC would be faster than Linux-Python, but the BASIC interpreter appears to lack I/O facilities. What have I missed ? (My apologies if this is a stupid question).
The commands you mention, I believe, are part of Linux-Python.
The "equivalent" using the GPIO module with BASIC would be SYS "GPIO_WriteMode" ,pinnumber,mode where pinnumber is the GPIO pin you wish to change and mode is 0 for input, 1 for output or upto 7 for the other modes available for that pin.
To then set the pin high or low, if it is setup as an output, use SYS "GPIO_WriteData" ,pinnumber,data where data is 0 for low and 1 for high.
To read the pin use SYS "GPIO_ReadData" ,pinnumber,value where value will be 0 or 1 from the pin input.
You cannot create a "parallel port" as such, but you can read/write the 8 lines as separate values.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Paralle data entry

Sun Feb 03, 2013 1:33 pm

tank wrote:
heuristicjohn wrote:Advice needed please: can the RPi (under RISC OS and BASIC) cater for parallel data entry ( eg by designating 8 GPIO lines as a parallel port) ?
You cannot create a "parallel port" as such, but you can read/write the 8 lines as separate values.
Tank was very kind in helping me understand the GP ports, so I hesitate to tread on his toes, but the parallel port configuration you request was one I also wanted. So, I wrote a specialised module that only works with the Pi and cannot do the generalised GPIO of Tank's module.
MCPIO (http://kappa.me.uk/Modules/swMCPIOMod020.zip) is specifically designed for the MCPIO23017 IIC chip on the Ciseco SliceOfPIO, among others. This chip provides two 8-bit ports, but the Ciseco board also brings out 8 GPIO pins as a single port, so the module deals with this in the same way. As a consequence, you could use the module just for the GPIO pins, which has a further small advantage in having lower overheads, being specifically for the Pi.
I wrote a desktop demonstration program for MCPIO, but it requires the presence of the MCPIO chip, so at the moment it would not be much use to you. If you would like me to modify it, please let me know.

tank
Posts: 64
Joined: Thu Dec 15, 2011 5:51 pm

Re: Paralle data entry

Sun Feb 03, 2013 2:10 pm

Steve Drain wrote:
tank wrote:
heuristicjohn wrote:Advice needed please: can the RPi (under RISC OS and BASIC) cater for parallel data entry ( eg by designating 8 GPIO lines as a parallel port) ?
You cannot create a "parallel port" as such, but you can read/write the 8 lines as separate values.
Tank was very kind in helping me understand the GP ports, so I hesitate to tread on his toes, but the parallel port configuration you request was one I also wanted. So, I wrote a specialised module that only works with the Pi and cannot do the generalised GPIO of Tank's module.
MCPIO (http://kappa.me.uk/Modules/swMCPIOMod020.zip) is specifically designed for the MCPIO23017 IIC chip on the Ciseco SliceOfPIO, among others. This chip provides two 8-bit ports, but the Ciseco board also brings out 8 GPIO pins as a single port, so the module deals with this in the same way. As a consequence, you could use the module just for the GPIO pins, which has a further small advantage in having lower overheads, being specifically for the Pi.
I wrote a desktop demonstration program for MCPIO, but it requires the presence of the MCPIO chip, so at the moment it would not be much use to you. If you would like me to modify it, please let me know.
Don't worry about that Steve, my toes are hardened !!
Just to say, a "Parallel Port" is a very different beast to 8 GPIO lines. ;)
I think for you to create a similar 8 bit wide port on the ordinary GPIO pins would mean you would need most of the decode logic used in the GPIO module as well.
Strangely the OMAP3 GPIO's lend themselves better to grouping pins as the control registers are laid out in a better order than the Pi's, which is why I included the 32bit wide SWI's for them.

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

Re: Paralle data entry

Sun Feb 03, 2013 7:45 pm

tank wrote:You cannot create a "parallel port" as such, but you can read/write the 8 lines as separate values.
I haven't yet looked in detail at GPIO so what I am suggesting may be absurd (if so apologies in advance!) - or there may be better ways of doing it...

Would it be possible to add a SWI to "simulate" a byte read/write from the callers perspective? That when requested to "read" a byte the module simply does 8 bit sequential reads - and shifts and ORRs the single bit values into a single register that gets returned to the caller (obviously for writes it would have the single byte decomposed into single bits each written individually to an I/O pin).

From the point of view of the caller it is an abstraction - and allows them to simplify their code (other than reads and writes taking longer than normal the caller wouldn't be aware of the difference).

tank
Posts: 64
Joined: Thu Dec 15, 2011 5:51 pm

Re: Paralle data entry

Sun Feb 03, 2013 8:09 pm

AMcS wrote:
tank wrote:You cannot create a "parallel port" as such, but you can read/write the 8 lines as separate values.
I haven't yet looked in detail at GPIO so what I am suggesting may be absurd (if so apologies in advance!) - or there may be better ways of doing it...

Would it be possible to add a SWI to "simulate" a byte read/write from the callers perspective? That when requested to "read" a byte the module simply does 8 bit sequential reads - and shifts and ORRs the single bit values into a single register that gets returned to the caller (obviously for writes it would have the single byte decomposed into single bits each written individually to an I/O pin).

From the point of view of the caller it is an abstraction - and allows them to simplify their code (other than reads and writes taking longer than normal the caller wouldn't be aware of the difference).
It's not absurd at all, in fact I have already done this in the I2C support code in the module (similar to what Steve Drain has done in his module).
The only reason I have not is because I have not needed it myself (selfish mode on).
It would be quite a slow call as it would, as you say need to build/decompose the result.
Strangely I do something similar in my PCB test program base I use with a Beagleboard at work...

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Paralle data entry

Sun Feb 03, 2013 8:56 pm

The IIC ports are written and read as bytes - that's pretty straightforward.

The GPIO pin numbers are not sequential and the port addressing system is 'awkard', shall we say. As Tank suggests, you need to build the port from individual pins, but I do not think it is slow. With suitably designed tables, I have loops of 4 instructions to read and write, iterated 8 times.

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

Re: Paralle data entry

Sun Feb 03, 2013 10:00 pm

@Steve & Tank: Thanks for the replies guys.
tank wrote:It would be quite a slow call as it would, as you say need to build/decompose the result.
Still if the user just makes a single SWI call (rather than having to do multiples of that setting up a "pin" on each call - then it might overall still be faster than the user having to do so).
Steve wrote:The IIC ports are written and read as bytes - that's pretty straightforward
That's useful, I can see there are many devices that could be useful on that then - for example a date/time NVRAM device (such as the one in the Iyonix).
Steve wrote:The GPIO pin numbers are not sequential and the port addressing system is 'awkard'
Does seem to be that way alright - what you seemed to have done is a "lookup" to handle that - again that hides from the consumer of your module the underlying complexity.

I'll do a bit more reading into the GPIO stuff (don't have anything I can hoike up to it yet - and having just got a PI I don't want to blow it up with 5V in the wrong part - if you get my drift ... :)

Thanks again lads.

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: Paralle data entry

Thu Feb 07, 2013 3:02 pm

Following up guidance provided, I have written a simple BASIC program which reads 8 GPIO inputs and performs a weighted addition, simulating a normal parallel port. Good news: it works - bad news, it takes 450 microseconds per read. (Ten times faster would be nice). Moving eight data bits from one memory location to another - how hard can that be ? Must try assembly language as next step (or giant leap, in my case).

Incidentally, isn't the !GPIOconfig window a nice feature - you can see your IO pin setup, and even turns LEDs on and off with mouse clicks.

Thanks for advice. I found the 'RISCOS and GPIO for dummies' topic especially helpful (naturally).
(and who kicked the L out of the title !!)

Sandgrounder
Posts: 31
Joined: Fri Jul 20, 2012 3:22 pm

Re: Paralle data entry

Thu Feb 07, 2013 11:23 pm

DavidS wrote: ...... ...... I have written a module to print to my Parallel Port OkiData Laser Printer and it works great .
Is the module available?

And, more importantly, I assume your Parallel Port OkiData Laser Printer takes straight ASCII text and prints it. I see from the OKI website, that some of their new printers take Epson FX printer codes. Does that mean that they will also print pure ASCII text from a BBC Basic program?

(I have been searching for such a printer since my old one died.)

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: Paralle data entry

Mon Feb 18, 2013 12:18 am

I currently use a commercial PIC-based micro running BASIC, and this works well, reading a single byte in 90 microseconds using just three instructions (selectchip, read data, deselect
Following up guidance provided, I have written a simple BASIC program which reads 8 GPIO inputs and performs a weighted addition, simulating a normal parallel port. Good news: it works - bad news, it takes 450 microseconds per read.
Having now delved into the (excellent) Bruce Smith book on assembly language, I have rewritten the program using assembly language calls where appropriate, and find that it now runs ten times faster. Transferring a 24 bit number by reading three bytes in succession now takes under 100 microseconds (the time for each read varies, presumably depending on what else the processor is doing). This is three times faster than my (more expensive) PIC-based micro, so I am a happy bunny.

I find I have to call the !GPIOConfig utility before running the BASIC program. Presumably this may be called from within the program by a suitable command, but I can't find this. Advice please ?

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

Re: Paralle data entry

Mon Feb 18, 2013 1:12 am

Sandgrounder wrote:
DavidS wrote: ...... ...... I have written a module to print to my Parallel Port OkiData Laser Printer and it works great .
Is the module available?

And, more importantly, I assume your Parallel Port OkiData Laser Printer takes straight ASCII text and prints it. I see from the OKI website, that some of their new printers take Epson FX printer codes. Does that mean that they will also print pure ASCII text from a BBC Basic program?

(I have been searching for such a printer since my old one died.)
No the module is not available (yet), no one had asked for it before.

Yes you can send raw ASCII to it if you wish, and yes it does support Epson codes.
I also supports a basterdized subset of PostScript for graphics (and this is why I still use this printer :-) ).
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

tank
Posts: 64
Joined: Thu Dec 15, 2011 5:51 pm

Re: Paralle data entry

Mon Feb 18, 2013 6:37 am

heuristicjohn, I have added (untested as yet) multiple bit read/write SWI's for the Pi part of the GPIO module.
If you wish to test it, please email me webmaster@tankstage.co.uk !

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

Re: Paralle data entry

Wed Feb 20, 2013 3:33 pm

I find I have to call the !GPIOConfig utility before running the BASIC program. Presumably this may be called from within the program by a suitable command
Run it in the !Boot or !Run file. Or shell it out as a command (OSCLI in BBCBasic)

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: Paralle data entry

Sat Feb 23, 2013 12:58 pm

It turns out that parallel data entry on the RPi is not a problem. Using information gleaned from the various forums, I have written program in BASIC, BASIC+ assembly, and using direct register access, and find that read times for one byte are about 300, 30 and 15 microseconds respectively. The fastest method is to read the BCM2835 pin level register directly. The register does contain all the right bits, but not necessarily in the right order - however, to move each bit needs just three instructions - AND to read, MOV...LSR to shift, and ORR to drop into the output byte. The attached demo program may be of interest (if only as an example of how not to do it. Pin numbers are embedded in the code, which makes it faster but less flexible), An output line is raised during each byte read, for chip selection. Bytes are left shifted before being stored, so successive bytes can be concatenated (I love that word). I do feel that providing examples (good or bad) is far more useful than vague suggestions, hence this submission.

Code: Select all

REM >qadport
REM program to demonstrate parallel port read
REM John Willis  22-02-2013
MODE MODE: OFF
ON ERROR ON:REPORT:PRINT " at line "; ERL :END
PRINT "start of program .."
PROCassemble
:
REM define pins for input, output
REM THIS PROGRAM REQUIRES Mk 2 board, as some pin numbers embedded
DIM gpi%(7)
DIM gpo%(2)
gpi%() = 17,18,27,22,23,24,25,4
gpo%()= 7,8,9
:
REM now set 8 pins as GPIO, set as inputs, set to 0
FOR x% = 0 TO 7
    g%= gpi%(x%)
    SYS "GPIO_WriteMode",g%, 0
    SYS "GPIO_WriteData",g%, 0
NEXT x%
:
REM NOW set pins 7,8,9, as GPIO, outputs, 0 (for flags)
FOR x% = 0 TO 2
    g% = gpo%(x%)
    SYS "GPIO_WriteMode", g%, 1
    SYS "GPIO_WriteData", g%, 0
NEXT x%
:
REM define memory location
SYS "OS_Memory",13,&20200000,&100 TO ,,,membase%
:
REPEAT
   REM set answer to 0
   A% = 0
   CALL storeans%
   :
   REM move bits from reg to ans%  (only 2 in this demo)
   F% = membase% + &34 : G% = 7
   CALL readbits%
   :
   CALL fetchans%
   PRINT " data = " ; ~USR fetchans%
   tnow% = TIME:REPEAT:UNTIL TIME> tnow% + 100
UNTIL FALSE
END

DEF PROCassemble
FOR pass = 0 TO 3 STEP 3
   DIM anslocn (50)
   DIM storeans% (100)
   P% = storeans%
      [
      OPT pass
      ADR R2, anslocn
      STR R0,[R2]
      MOV R15, R14
      ]
   DIM fetchans% (100)
   P% = fetchans%
      [
      OPT pass
      ADR R2, anslocn
      LDR R0, [R2]
      MOV R0,R0,LSR #8
      MOV R15, R14
      ]
   DIM readbits% (200)
   P% = readbits%
      [
      OPT pass
      MOV R0, R6
      MOV R1, #1
      SWI "GPIO_WriteData"
      .loadreg
      SWI "OS_EnterOS"
      LDR R3, [R5]
      SWI "OS_LeaveOS"
      .getprevans
      ADR R2, anslocn
      LDR R0, [R2]
      AND R7, R3, # &20000
      MOV R7, R7, LSR #10
      ORR R0, R0, R7
      .digit7
      AND R7, R3, # &40000
      MOV R7, R7, LSR #12
      ORR R0, R0, R7
      .digit6
      :
      MOV R0, R0, LSL #8
      ADR R2, anslocn
      STR R0, [R2]
      :
      MOV R0, R6
      MOV R1, #0
      SWI "GPIO_WriteData"
      MOV R15, R14
      ]
   NEXT pass
ENDPROC

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: Paralle data entry

Thu Mar 07, 2013 3:31 pm

Query: are there any hidden pitfalls in writing directly to I/O registers ? All the information is in the BCM2835 handbook pages 90-97, and the only system calls required appear to be one to set memory location, and two to move from User to Supervisor mode and back, when accessing the registers. This seems more straightforward that other approaches.

The attached program uses this approach, first to set up the GPIO lines, and second to loop around reading groups of three bytes from the 8 input lines. (The program is intended to read data from three separate counter chips, selected by the 3 output lines, and combine the results into a 24 bit number).
Time to read three bytes is about 30 usec. There are small random delays, but these do not appear to affect program operation. Time to read one byte is under 2 usec.

Code: Select all

REM >3byteread
REM program to read 3 bytes from parallel port
REM John Willis  04-03-13  
MODE MODE: OFF
ON ERROR ON:REPORT:PRINT " at line "; ERL :END
PRINT "start of program .."
PROCassemble
:
REM define pins for input, output
REM for Mk I board change pin 27 to 21
DIM gpi%(7)
DIM gpo%(2)
gpi%() = 17,18,27,22,23,24,25,4
gpo%()= 7,8,9
:
REM define memory location     *****************
SYS "OS_Memory",13,&20200000,&100 TO ,,,membase%
:
REM now set 8 pins to GPIO, input
FOR x% = 0 TO 7
    A% = membase% : B% = gpi%(x%) DIV 10 : C% = gpi%(x%) MOD 10 : D% = 0
    CALL setpinmode%
NEXT

REM NOW set 3 pins to GPIO, output
FOR x% = 0 TO 2
    A% = membase% : B% = gpo%(x%) DIV 10 : C% = gpo%(x%) MOD 10 : D% = 1
    CALL setpinmode%
NEXT
:
REM store input pin numbers
   A% = gpi%(7) : B% = gpi%(6)
   C% = gpi%(5) : D% = gpi%(4)
   E% = gpi%(3) : F% = gpi%(2)
   G% = gpi%(1) : H% = gpi%(0)
CALL storepins%
:
REM gpo%(1) and (2) outputs to chip selector:
REM  01 read chip 1, 11 read chip 2, 10 read chip 3, 00 clear
:
REM  main read program - reads 3 bytes, prints ans
REPEAT
   A% = membase% : B% = 1<<gpo%(0) : C% = 1<<gpo%(1) : D% = &1C
   CALL setup%
   A% = membase% : B% = 1<<gpo%(0) : C% = 1<<gpo%(2) : D% = &1C
   CALL readbits%
   A% = membase% : B% = 1<<gpo%(0) : C% = 1<<gpo%(1) : D% = &28
   CALL readbits%
   A% = membase% : B% = 1<<gpo%(0) : C% = 1<<gpo%(2) : D% = &28
   CALL readbits%
   A% = membase% : B% = 1<<gpo%(0)
   CALL clearup%
   :
   PRINT " data = " ; ~USR fetchans%
   tnow% = TIME:REPEAT:UNTIL TIME> tnow% + 100
UNTIL FALSE
END

DEF PROCassemble
   DIM pinnum% (50)
FOR pass = 0 TO 3 STEP 3
   DIM setup% (100)
   DIM anslocn% (50)
   P% = setup%
      [
      OPT pass
      ADR R7, anslocn%
      MOV R6, #0
      STR R6, [R7]      REM set ans to 0
      SWI "OS_EnterOS"
      STR R2, [R0, R3]     REM set flag 1 HI
      SWI "OS_LeaveOS"
      MOV R15, R14
      ]
   DIM fetchans%  (100)
   DIM pinstore%  300
   P% = fetchans%
      [
      OPT pass
      ADR R2, anslocn%
      LDR R0, [R2]
      MOV R0, R0, LSR #8
      MOV R15, R14
      ]
   DIM readbits% (300)
   P% = readbits%
      [
      OPT pass
      SWI "OS_EnterOS"
      STR R1, [R0, #&1C]   REM set flag 0 HI
      LDR R9, [R0, #&34]   REM read pin level reg into R9
      SWI "OS_LeaveOS"
      :
      ADR R7, anslocn%        REM fetch prev answer
      LDR R11, [R7]
      :
      ADR R7, pinstore%
      :
      MOV R6, #7              REM count down from ans bit 7 to bit 0
      .start
      MOV R5, R6
      MOV R5, R5, LSL #2      REM set indexed address where pin no. held
      LDR R4, [R7,R5]         REM load pin no. (say 17, ms bit)

      MOV R10, #1
      MOV R10, R10, LSL R4    REM move #1 to posn 17
      AND R10, R10, R9        REM read input bit here
      MOV R10, R10, LSR R4    REM move bit back to posn 0
      MOV R10, R10, LSL R6    REM move bit to ans ms bit posn
      ORR R11, R11, R10       REM write bit into answer byte
      SUBS R6, R6, #1         REM decrement index
      BPL start
      :
      MOV R11, R11, LSL #8    REM shift complete ans 8 bits to L
      ADR R10, anslocn%       REM save answer
      STR R11, [R10]
      SWI "OS_EnterOS"
      STR R1, [R0, #&28]      REM set flag 0 LO
      STR R2, [R0, R3]        REM set flag 1 or 2
      SWI "OS_LeaveOS"
      MOV R15, R14
      ]
   DIM storepins% (100)
   P% = storepins%
      [
      OPT pass
      ADR R9, pinstore%
      STR R0, [R9, #0]
      STR R1, [R9, #4]
      STR R2, [R9, #8]
      STR R3, [R9, #12]
      STR R4, [R9, #16]
      STR R5, [R9, #20]
      STR R6, [R9, #24]
      STR R7, [R9, #28]
      MOV R15,R14
      ]
    DIM setpinmode% 200
    P% = setpinmode%
       [
       OPT pass
       MOV R1, R1, LSL #2
       ADD R1, R1, R0     REM address of fn select reg decade
       ADD R2, R2, R2, LSL #1   REM R2 x 3 is req left shift
       MOV R3, R3, LSL R2    REM these bits to be added to reg
       MOV R4,#7
       MOV R4, R4, LSL R2  REM holds 111 mask to clear bits
       SWI "OS_EnterOS"
       LDR R5, [R1]        REM load contents of fn reg
       BIC R5, R5, R4      REM delete masked bits
       ORR R5, R5, R3      REM insert new bits, leave rest
       STR R5, [R1]
       SWI "OS_LeaveOS"
       MOV R0, R4
       MOV R15, R14
       ]
   DIM clearup% 100
   P% = clearup%
      [
      OPT pass
      SWI "OS_EnterOS"
      STR  R1, [R0, #&1C]      REM set gpo%(0) HI
      MOV R6, #100
      .delay
      SUBS R6, R6, #1
      BPL delay
      STR  R1, [R0, #&28]     REM set gpo%(0) LO
      SWI "OS_LeaveOS"
      MOV R15,R14
      ]
   NEXT pass
ENDPROC

atto
Posts: 3
Joined: Tue May 07, 2013 7:11 pm

Re: Parallel data entry

Tue May 07, 2013 9:47 pm

Thanks very much for that source ... So about 100kBytes/s seems to be the limit, right. Well, that would mean that it takes 3 seconds to capture an image with 640x480 pixels and 1 byte per pixel ... Hmmm ... Great for many things, but ...

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

Re: Parallel data entry

Wed May 08, 2013 9:29 pm

atto wrote:Thanks very much for that source ... So about 100kBytes/s seems to be the limit, right. Well, that would mean that it takes 3 seconds to capture an image with 640x480 pixels and 1 byte per pixel ... Hmmm ... Great for many things, but ...
The discussion was in connection to converting a serial to parallel stream (e.g., for implementing a parallel port) in software. So 100KBytes per sec (for a parallel port) would be "ok". If you were using an external device to convert from Serial straight to Parallel the performance would be much better as you could dispense with the bit shifting in software (one poster elsewhere managed to toggle a single GPIO at 19MHz - GPIO) so, in theory, transfer rates could be considerably better than 100KBytes/sec.

Return to “RISCOS”