Assembler compilation errors on dsPIC

[sdallo]

I'm having big problems to compile some ASM instructions wirh Positron 1.1.0.9, the reference manual is Microchip DS70157F document. The code I'm using was working on PIC18F and PicBasicPro compiler.

Code Select Expand

Asm
mov.b A0_1, WREG
addc.b A0_1, WREG
daw.b WREG
and.b WREG, #0x0F, W1
ior.b #0x30, W1
mov.b W1, A0_1
swap.b WREG
and.b #0x0F, WREG
ior.b #0x30, WREG
mov.b WREG, A0_0
;
EndAsm

Errors from compiler related to generated .asm file:

Code Select Expand

Assembler Error at Line [1641]  Invalid operands specified ('daw.b WREG').
Assembler Error at Line [1642]  Invalid operands specified ('and.b WREG,#0x0f,W1').
Assembler Error at Line [1644]  Invalid operands specified ('mov.b W1,A0_1').
Assembler Error at Line [1645]  Invalid operands specified ('swap.b WREG').
Assembler Error at Line [1646]  Invalid operands specified ('and.b #0x0f,WREG').
Assembler Error at Line [1647]  Invalid operands specified ('ior.b #0x30,WREG').
Hex file not Created

What I do to solve ?  Or there is a limitation of this compiler ?

Stefano

[RGV250]

Hi,
The only question I have is why do you want to do it in ASM on a BASIC forum, there is not much that cannot be done in BASIC with Positron.
The document you mention is for 16 bit and the device you say it was working on is 8 bit.

Bob

[John Drew]

I agree with Bob, the compiler produces very tight code.

Have you read the manual on how to include Assembler? It is possible.
John

[sdallo]

Thanks Bob & John,

the code showed is a little part of a whole firmware written in Positron16 BASIC (75-80%) for a dsPIC33FJ128MC706A, mostly stand-by routines as command parsing, diagnostics and calibrations; translated from previous code in PicBasicPro, the remaining part is a high speed acquisition code with a master interrupt ticks of 1 mS, this showed part of 8 bit just before sending result data to a serial port, data coming from CPLD is treated as 16 bits words, with internal data at 48 bits, dsPIC helps with more efficiency and speed.

Yes I have read the manual, but I suspect particular instructions (daw.b and swap) have problems to compile, no problems for many other instructions.

Stefano

[RGV250]

Hi,
I had a quick look at the datasheet for the device you are using, there are 15 working regs (WREG) so you would need to define which one you wish the compiler to use. Also I am not sure on the # or other things such as A0_1, some of which may be specific to PicBasicPro so I think you would need to go through the datasheet and the original programming language to convert it.
I still think it would be easier to do it in basic if you know what it actually does. The original code is from an 18 series so a dsPIC running at 40MIPS would be several times faster anyway.

Bob 

[top204]

The code I'm using was working on PIC18F and PicBasicPro compiler

The PICBASIC Pro compiler does not support PIC24 or dsPIC33 devices, so the code could not have worked on it! Also, the PIC18F and PIC24 and dsPIC33 devices are very, very different to each other. It is just the compiler that makes them seem the same in most respects. :-)

When assembler mnemonics are wrapped in Asm-EndAsm, they are sent directly to the ASM30 assembler, and the compiler has nothing to do with them. So any assembler errors or linker errors associated with them means that their Syntax or Semantics are wrong.

Remember, the PIC24 and dsPIC33 devices are 16-bit microcontrollers, and they have a limited mnemonic mechanism for 8-bit handling. Thus the instruction set documents need to be read with detail because of the differences in the mnemonics when operating with 8-bit or 16-bit variables or Wx SFRs.

There are quite a few mistakes within the assember code you have written that will not be accepted by the assmeber because they have semanic errors, more than syntax errors.

The code modifications below will get code assembling and linking, but the code you created actually needs a bit of a re-write to suit the dsPIC33 device a bit more, and to use W1 a bit more, so W0 is available for general purpose usage:

Asm
    Mov.b  A0_1, WREG
    Addc.b  A0_1, WREG
    Daw.b  W0
    Push.w  W0
    And.b  W0, #0x0F, W0
    Ior.b  #0x30, W0
    Mov.b  WREG, A0_1
    Pop.w  W0
    Swap.b  W0
    And.b  #0x0F, W0
    Ior.b  #0x30, W0
    Mov.b  WREG, A0_0
EndAsm

Notice, also, that the W0 SFR is pushed and popped to keep in intact, because some of the mnemonics between them can only work with the W0 SFR when operating with 8-bit variables (the .b after them), and some only when it is referenced as WREG. The PIC24 and dsPIC33 mnemonics had me scratching my head when I first created the compiler for them, because it had to work fully with 8-bit variables as well, and that is when the querks of the devices instruction set come into their own. But they do perform admirably with 8-bit variables, unlike most other 16-bit or 32-bit devices that insist on 16-bit or 32-bit variables to be used, even if they are only containing 8-bit values, and most other 16-bit and 32-bit microcontrollers do not actually have a mechanism for Bit type variables! So hats off to Microchip for them.

Please... Do some research before blaming the compiler for something it has no control over, and the code listing created is "very clearly" incorrect. Whenever assembler mnemonics are used within the high level code listing, it is up to the user to check if they are correct, because the compiler has very little to do with them and they are sent directly to the assembler, which will produce assembler errors or linker errors if the linker program sees RAM area errors in them that the assembler did not see.

[sdallo]

Hi Bob,
thank you for digging into my problem.

Also I am not sure on the # or other things such as A0_1, some of which may be specific to PicBasicPro

A0_0 and A0_1 are two array elements, declared as (Dim A0[32] As Byte).

Whole routibe convert a 40 bit binary dara in 13 ASCII bytes to be transmitted via serial port.
---

Hi Les,

thank you very much for the solution to my problem, I have only to learn from your explanations, the push.w and pop.w did the trick, I'm new to dsPIC assembler, obviously the original code developed on PIC18F46J50, 9 years ago, is different from this actual snippet that I have showed in my OP...

I absolutely no intention to blame your compiler, please accept my apologies, but this problem was worrying me a lot for respecting the deadline that I set, the first prototypes arrive shortly and I wanted to be ready for the initial tests.

I'm an a retired electronic eng, with heavy sight and hearing problems, this hard work is to complete the sale of my patent (hardware part of analog/RF circuit) in the coming months, I have always had to manage the firmware part by myself without any help.

Again, thank you for the solution !

Stefano

[top204]

No offence taken Stefano, and good luck with your sale.

The "real" RAM stack on the PIC24 and dsPIC33 devices and their versatile Push and Pop mnemonics are extremely useful and powerful. A "real" RAM stack is sadly missing on the 8-bit devices, even after all of these years where people have been asking for one to implemented inside them. :-(