Cant input or output greater than 9 bits

Chris B · 2009-11-07 10:32

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 · 2009-11-07 11:19

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 · 2009-11-07 11:46

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 · 2009-11-07 12:09

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 · 2009-11-07 17:47

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.

[b]con[/b]
  [b]_clkmode[/b] = [b]xtal1[/b] + [b]pll16x[/b]
  [b]_xinfreq[/b] = 5_000_000
  
[b]pub[/b] DIP_Led
  [b]cognew[/b] (@Read, 0)

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

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

Ale · 2009-11-07 18:01

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 · 2009-11-07 19:54

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 · 2009-11-08 08:26

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 · 2009-11-08 10:35

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 · 2009-11-08 11:39

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 · 2009-11-08 12:24

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.

Cant input or output greater than 9 bits

Comments