Linking with Assembler

[JohnHind]

Hi - Just read the dsPIC and PIC Pascal manual.

Is it possible to link code assembled with Microchip assembler with stub implementations in a Pascal Unit to create ones own library? I know I could use the built in assembler, but from other postings this is a bit incomplete and buggy at present. Also if you do this, how do you pick up passed parameters in the assembly code and return a value for a function? What registers do you need to safeguard?

[zristic]

For dsPIC we use stack frames and stack pointers. W14 holds the value of top of stack address. Parameters are pushed on the stack frame and each one can be accessed with indirect addressing [w14-OFFSET]. Local variables are above the stack pointer, so a local can be accessed with [w14+OFFSET]. If P1 is a parameter of the type word then you will access it as [W14-1], while L1 and L2 are a local vars and will be accessed as [w14+1] and [w14+2].

It is a bit complicated for beginners and we should write a guide of how to do it.

As for PIC just folow the naming convention and you cannot make a mistake. For example, the parameter P1 of the function Func1 form unit Unit1 has the assembly name "Unit1_Func1_Param_P1".

[JohnHind]

I think that's a no to the first part of the question - the compiler produces a linked .hex image and the .asm file is actually a disassemble of this which is not in a form that can be modified and assembled. There is no .obj file, so there is no way to link compiled Pascal with assembled assembler source using the Microchip linker?

Do you create your own library modules entirely using the embedded assembler?

[zristic]

Our object files have the extension .MCL and they are not compatible with microchip.

Assembly is compatible and you can use the .lst file info in order to link your asm from mikroPascal into mplab. The other way, mplab to mP will not work.

We tend to get authorization from microchip to use their object libraries, but apparently they are not willing to allow us do that, though they never officially denied it.

[LGR]

Maybe the question needs to be asked differently: How difficult would it be to provide for the interfacing of ASM or HEX code from outside of the mE environment? Specifically, the free DSP libraries from Microchip, but also possibly purchased libraries (such as voice recognition, acoustic echo cancellation, etc.). In both the PIC and dsPIC realms, this would be desirable, but with the dsPIC, it would be particularly desirable, because these libraries are so sophisticated, that it would be a lot of work to reinvent them.

[zristic]

Those libraries are someone's intellectual property. I guess this is why Microchip hesitates to give them for free. I understand that, but it is pitty that they are not availble out of MPLAB.

We will give our best to try to extract the code from the binaries Otherwise, there is a long work on writing them in mikroPascal/mikroC.

[LGR]

Those libraries are someone's intellectual property. I guess this is why Microchip hesitates to give them for free. I understand that, but it is pitty that they are not availble out of MPLAB.

We will give our best to try to extract the code from the binaries Otherwise, there is a long work on writing them in mikroPascal/mikroC.

I understood them to be free, but it wasn't completely clear. The thing about these libraries is that they need to be very tightly coded using the DSP hardware. It's not enough to have something that executes, it has to execute within certain timing specs. This implies a mix of Pascal and assembly. If you're lucky, you'll at least be able to see how to do some of these things in ASM.

The other thing about DSP libraries is that they handle streams of data in real time. The procedures only execute once, and without a good interrupt-driven executive, the procedures aren't worth much. Have you given any thought to a primitive RTOS, and some mechanism for piping streams of real-time data?