[PASM] Puzzled about declaring constants

Cabbage

I'm having some odd problems with trying to define a 32 bit value that is derived from a list of bit-flags, each representing an IO pin that I want to drive as outputs.

So I tried "or"ing them together as shown below. This caused no compiler warnings and runs (kind of), but the end results are not what I was expecting. It seems that some pins are being set to outputs when they shouldn't be. This was causing a short between another microcontroller (an AVR) and the prop.

Anyway, it took me a couple of hours to narrow it down to this erroneously declared "OUTPUTS" value.

Then it struck me, I'm trying to OR a bunch of memory addresses together, not the values at those addresses! Randomly, the resulting bit pattern was actually similar enough to allow the circuit to work with some intermittent fault caused by a short circuit on P20, which was also being driven by the AVR.

SERIAL_RX           long  |< 31 'in
SERIAL_TX           long  |< 30 'out
SR595_SRCLK_PIN     long  |< 27 'out
SR595_RCLK_PIN      long  |< 26 'out
LED_PIN             long  |< 25 'out
SR595_SER_PIN       long  |< 24 'out
LCD_RS_PIN          long  |< 23 'out
LCD_RW_PIN          long  |< 22 'out
LCD_En_PIN          long  |< 21 'out
ATTINY85_OK         long  |< 20 'in
SR165_PLn           long  |< 19 'out
SR165_CP            long  |< 18 'out
SR165_Q7            long  |< 17 'in

'does work...
OUTPUTS         long  %01001111_11101100_00000000_00000000 

'does not work...
OUTPUTS         long     SERIAL_TX or SR595_SRCLK_PIN or {..blah blah..} SR165_CP

So my question is, what is the correct way to use and declare constant 32 bit values and perform boolean math operations on them in PASM?

I don't really want to have to maintain the ugly-looking "%01001111_11101100_00000000_00000000" value because it'd be prone to human error.

Electrodude

or in Spin is logical OR, like || in C, but not short-circuiting. It returns -1 (true) if either operand is non-zero, and otherwise 0 (false). In this case, you want |, plain bitwise OR.

Christof Eb.

Hi,
I do not work with the SPIN2 environment, but in an example I found:

CON     _clkfreq    = 250_000_000   'system clock frequency

        gtzl_base   = 16        'must be a multiple of 8

I think, this CON section gives information to the compiler.
In the DAT section longs will be placed into HUB RAM.

Cabbage

@Electrodude

Just tried |, which compiles and runs but does not function correctly.
I think it's because I'm declaring things in COG ram and trying to build a composite value using math.

To use a C language analogy, I reckon I'm not dereferencing the pointers. e.g.:
unsigned long OUTPUTS = (ptra | ptrb | ptrc);
//as opposed to:
unsigned long OUTPUTS = (*ptra | *ptrb | *ptrc);

| did give different results to or though as you mentioned.

Electrodude

@Cabbage said:
@Electrodude

Just tried |, which compiles and runs but does not function correctly.
I think it's because I'm declaring things in COG ram and trying to build a composite value using math.

To use a C language analogy, I reckon I'm not dereferencing the pointers. e.g.:
unsigned long OUTPUTS = (ptra | ptrb | ptrc);
//as opposed to:
unsigned long OUTPUTS = (*ptra | *ptrb | *ptrc);

| did give different results to or though as you mentioned.

Yes, you need to declare each bit in a CON section and then | those together - otherwise, you'll be doing arithmetic on assembler addresses. Stuff declared in a CON section is like stuff declared with #define in C - it assigns a value to a symbol for the compiler, but doesn't actually produce any compiled output itself. You can freely use CON constants in a DAT section, as can be seen in many examples.

Cabbage

@Electrodude

Cool, I'll do that then. Thank you for the help.