Parallax Forums

Parallax Forums

Parallax Forums > Public Forums > Propeller Chip > Cant input or output greater than 9 bits

Forum Quick Jump

[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

Chris B
Registered Member

Date Joined Nov 2006
Total Posts : 6

Posted 11/7/2009 2:32 AM (GMT -8)

Sorry for the newbie question,

I have an 8 way DIP switch connected to P0 through P7, I also have 8 LED's connected to P16 through P23. All I wish to do is read the DIP switch and display its current setting on the LED's.

I am failing at the first hurdle as I cant even set the DIRA up as when I try to "mov dira, %00000000111111110000000000000000" I get a compiler error telling me the source cannot be greater than $1FF.

My question then is how in assembler can I set the upper bits of DIRA, INA or OUTA when I can only use 9 bits in the source?

In spin I can just do "DIRA := %00000000111111110000000000000000"

Ale
Registered Member

Date Joined May 2007
Total Posts : 1267

Posted 11/7/2009 3:19 AM (GMT -8)

Literals are limited to 9 bits. But using a pointer to the value works for any literal:

mov A, pointer

pointer long $ff_ff_ff_00

Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Baggers
Registered Member

Date Joined Mar 2007
Total Posts : 1773

Posted 11/7/2009 3:46 AM (GMT -8)

Also, if you do want to put a literal value into DIRA, say for example you wanted 0-7 as outputs.

you could do :-

mov DIRA,#%11111111

the # signifying that you want to use a literal value and not a pointer to a value at a cog-ram address.

But as you want to set higher than bit 9, you have to use a pointer, as Ale demo'd

http://www.propgfx.co.uk/forum/ home of the PropGFX Lite

Drone
Registered Member

Date Joined Mar 2007
Total Posts : 359

Posted 11/7/2009 4:09 AM (GMT -8)

Hi Chris B,

Welcome to the Forum!

I'm typing this in real-time and only have a few minutes. PLEASE propeller PASM experts
correct my mistakes (likely many). This is a subject that should be EXPLICIT in the
Propeller Manual IMHO; with lots of examples.

It's implicit with the "mov dira..." line in your post you're programming in Propeller Assembler
(PASM). Please read the Propeller Manual section regarding "Literals Must Fit in 9 Bits". I excerpt
from the Propeller Manual V1.1 (have on-hand in this machine right now).

"Literals Must Fit in 9 Bits
The source operand is only 9 bits wide; it can hold a value from 0 to 511 ($000 to $1FF).
Keep this in mind when specifying literal values. If a value is too big to fit in 9 bits, it must
be stored in a register and accessed via the register's address. For example: (ed. read the Manual)"

If you set a literal value greater than $1FF then you need to specify an initialized register that
can hold a long. A res declaration cannot exceed $1FF in size if memory serves (may be wrong
here).

All (initialized) long declarations MUST be on lines in DAT area before any res declares.

Again, Chris B...

When you post a question like this, please post your source code as well. This forum a
little broken wrt source code posts, so there is a tool to reformat your source that may
post better (thanks again Phil). Here's the link (also available via the unofficial Propeller Wiki).

www.phipi.com/format/

Read and contribute to the Propeller Wiki here (start page):

propeller.wikispaces.com/

How is RES different from LONG? (from the Propeller Wiki)...
A Must Read regarding your question IMHO.

propeller.wikispaces.com/LONG+vs+RES

Chris B
Registered Member

Date Joined Nov 2006
Total Posts : 6

Posted 11/7/2009 9:47 AM (GMT -8)

Thanks all, if only you knew how stupid I feel. For reference here is the code I ended up with. I didn't realize the code would loop forever either.

con
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

pub DIP_Led
  cognew (@Read, 0)

dat
                        org     0
Read
              mov       dira,   DDRA                          'Configure data direction register
              mov       PORT,   ina                           'Read PORT
              and       PORT,   SWITCHES                      'Use mask to get switches
              shr       PORT,   #16                           'Shift switch positions down 16 bits
              mov       outa,   PORT                          'Output current DIP settings in P0 to P7


SWITCHES      long      %00000000111111110000000000000000     'Mask to isolate the switches after reading port (Bin uses %)
DDRA          long      $0000FFFF                             'Top 16 bits are input, bottom are output (Hex uses $)
PORT          res       1                                     'Reserve storage for one 32 bit long

Ale
Registered Member

Date Joined May 2007
Total Posts : 1267

Posted 11/7/2009 10:01 AM (GMT -8)

Well, you have to sort of end it, with a cogstop or with a jump to the jump address (jmp #$). Both give different results....

Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

MagIO2
Registered Member

Date Joined Mar 2009
Total Posts : 595

Posted 11/7/2009 11:54 AM (GMT -8)

If this is all your code you are lucky that it loops, because you don't have a

jmp #Read

in it. With other data at the end you might have bad luck doing thing the COG should better not do!

Remember the COG is always loaded with 496 longs. If you have other PASM sections behind that one or if you did some SPIN stuff which used some stack space, the memory behind your PASM code will have content. Anything can happen then.

So, make sure you stay within a loop in your code or stop the COG when you're done.

Chris B
Registered Member

Date Joined Nov 2006
Total Posts : 6

Posted 11/8/2009 12:26 AM (GMT -8)

Thanks MagIO2,

This is the beginning of a bigger project to control a camera and flash but it is me dipping my big toe into assembler. I agree completely about the

jmp #Read

I was very surprised it continued to loop as that is not what I wanted, Ale has already given me the answer but I am still not sure as to why it does it. As I said I have only just dipped a toe in. I am sure there will be a lot more head banging before I am finished.

MagIO2
Registered Member

Date Joined Mar 2009
Total Posts : 595

Posted 11/8/2009 2:35 AM (GMT -8)

If you don't have jumps, then the program counter is simply increased. If this snippet of code (this dat section) is at the end of your program all following HUB-RAM will contain zero. In PASM a zero is a NOP. So, the program counter runs to the end of COG-RAM and then jumps back to zero ( $1ff+$001 = $000 in 9 bit binary).

As I said you are lucky that nothing bad happens. If you would have some strings at the end of the dat section anything can happen. Setting input-pins to output in this COG is the worst, as it can destroy the IO-pins of the propeller. Overwriting HUB-RAM might have funny results as well - this could lead to problems in all other COGs.

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1577

Posted 11/8/2009 3:39 AM (GMT -8)

MagIO2 said...

As I said you are lucky that nothing bad happens. If you would have some strings at the end of the dat section anything can happen. Setting input-pins to output in this COG is the worst, as it can destroy the IO-pins of the propeller. Overwriting HUB-RAM might have funny results as well - this could lead to problems in all other COGs.

Actually, the spin bytecode follows the DAT section, so the cog would have been loaded with "random" data comprising the spin bytecode, then the stack space (given the small example presented). So I am extremely surprised it made it all the way through more than once. I've almost never seen a cog loop around past the registers at the end anyway!

If you always do what you always did, you always get what you always got.

MagIO2
Registered Member

Date Joined Mar 2009
Total Posts : 595

Posted 11/8/2009 4:24 AM (GMT -8)

Thanks BradC!

Thinking about it, it makes sense this way. SPIN code is byte-code which can end at any RAM adress. Putting the PASM code behind it means that you can loose up to 3 bytes.

Dat, SPIN, Vars, Stack seems to be the right order. Well ... maybe the one SPIN instruction COGNEW has an opcode that does not harm or it might be a NOP. Maybe I'll check that this evening, if nobody else did before. But the point is ANYTHING can happen.

[ << Previous Thread | Next Thread >> ]

Forum Information

Currently it is Friday, November 20, 2009 11:07 PM (GMT -8)
There are a total of 393,737 posts in 55,521 threads.
In the last 3 days there were 82 new threads and 701 reply posts. View Active Threads

Who's Online

This forum has 17687 registered members. Please welcome our newest member, mark09.
56 Guest(s), 4 Registered Member(s) are currently online. Details
OakGraphics, Phil Pilgrim (PhiPi), BradC, SRLM

Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009

Need Support? | Forum Help Manual