pic16bit port on dspic33ep512mc202 with xc16 1.32

[pumelo]

Hellou forum

I'm trying to use the pic16port on a dspic33ep512mc202 with the latest xc16 1.32 compiler from microchip.

I had to do some modificatios to make it compile.
https://github.com/pumelo/micropython/tree/dspic33port

However there are still some issues left with compiling:
* I get a lot of warning of the form:
[code]
../../lib/mp-readline/readline.c: In function 'readline_process_char':
../../lib/mp-readline/readline.c:191:52: warning: Taking the address of 'compl_str' may require an extended pointer for this device
[/code]

* The compiler issues a warning: [code]psrd_psrd check summary: found 1 possible match[/code] this is a silicone errata which has to be worked around, however should not be present in the first place as the compiler is supposed to workaround it by itself.

Testing the produced code does not work as expected.

* The repl is there (good)
* small ints are fine but above some limit they do not work at all
* behaviour in general is strange, python variables some times just disappear ..

so clearly the produced build is bogus. Any idea how to fix this?

As the pic16port is quite old:
* have there been modifications to core micorpython which are expected to break pic16port?

[pumelo]

Here are a few examples of 'strange' behavior:
>>> print
<function>
>>> print('hellou')
Traceback (most recent call last):
File "<stdin>", in <module>
NameError: name not defined
>>> 2**32
4294967296
>>> 2*255875
''
>>> 2*10258
Ellipsis
>>>

So it is not related to 'big' numbers but somehow to multiplication?

>>> 2**32 +2**32
Traceback (most recent call last):
File "<stdin>", in <module>
NameError: name not defined
>>>

[pumelo]

I think the above problems originate from the esd (extended date space) on this device.
Actually, dspic with ram larger than 32kb have extended pointers which are 24bit not 16bit

http://microchipdeveloper.com/16bit:ext ... it-pic-mcu

My attempted would be to put the heap entirely into this extended data space, and keep everything else in the range below 32kB but as long as I see this requires to change all pointer declarations in gc.c and so on... =( and is also a big waste of space

Does anyone see an easier solution to this?

[Damien]

The pic16bit port was designed for and verified to run on the dsPIC33FJ256GP506, which has 256k of flash and 8k-16k of RAM. And it should still work correctly on this chip.

It should also work on other 16-bit dsPIC chips that have similar specs. But if you try with a chip that needs 24-bit pointers then it will probably give very strange errors like you are seeing. The reason is because it assumes that pointers are 16-bits wide and this is then how big a MicroPython object pointer is; anything beyond 16-bits will wrap around. Changing to use 24-bit pointers would require some effort and I myself can't really help in that direction.

[pumelo]

Actually be decreasing the allocated heap in main.c I managed to be able to use the compiler switch "small-data". This forces the compiler to allocate all symbols and the stack in the data range addressable with a standard pointer. Additionally I compiled with the debug switch.

However I get errors like the following:

>>> 112*112
assertion "tok == MP_TOKEN_ELLIPSIS" failed: file "../../py/emitbc.c", line 525, function: mp_emit_bc_load_const_tok

>>> 112233545
assertion "emit->stack_size == 0" failed: file "../../py/emitbc.c", line 406, function: mp_emit_bc_end_pass

>>> l = 15
assertion "exc_sp == exc_stack - 1" failed: file "../../py/vm.c", line 1095, function: mp_execute_bytecode

>>> gc.mem_free()
2840
assertion "exc_sp == exc_stack - 1" failed: file "../../py/vm.c", line 1095, function: mp_execute_bytecode

Any Ideas where or what to look for, to fix this?

BTW:

the psrd_psrd errate was a false positive. See here:
http://www.microchip.com/forums/m1016760.aspx

@damien
Thanks for your answer, very appreciated.

[pumelo]

Okay, I found one error when debugging however there is more:

struct _mp_exc_stack_t must be aligned by 4 otherwise pointer tagging will get evil... the compiler did only align by 2...

not sure how to properly make sure alignement if correct.

I tried with

typedef struct _mp_exc_stack_t {
const byte *handler;
// bit 0 is saved currently_in_except_block value
// bit 1 is whether the opcode was SETUP_WITH or SETUP_FINALLY
mp_obj_t *val_sp;
// Saved exception, valid if currently_in_except_block bit is 1
mp_obj_base_t *prev_exc;
} __attribute__((aligned(4))) mp_exc_stack_t;

but this did not get honourd by the compiler either =( so I just inserted anoter pointer in the mp_code_state_t struct to make the alignment which is buggy ....

I think by this i get rid of the assertation errors in vm.c however the ones in emitbc.c presist ...
anyone any ideas? might be alignment as well??

[pumelo]

Damien, sorry to bother you and for my ignorance.

MPLAP IDE of microchip has a simulation feature.
I used this simulation feature with your original unmodified code and target dsPIC33FJ256GP506 and the exact compiler you used (1.24).
I tried with several git tags of released versions down to 1.4
e.g.

Micro Python v1.4-23-g43ea73f on 2017-10-26; dsPICSK with dsPIC33
Type "help()" for more information.
>>> 12
12
assertion "exc_sp == exc_stack - 1" failed: file "../py/vm.c", line 1024, function: mp_execute_bytecode

MicroPython v1.9.1 on 2017-10-26; dsPICSK with dsPIC33
>>> 12
12
>>> 12+12
24
>>> import gc
>>> print('help')
assertion "emit->stack_size == 0" failed: file "../py/emitbc.c", line 406, function: mp_emit_bc_end_pass
MicroPython v1.9.1 on 2017-10-26; dsPICSK with dsPIC33
>>> 12**12 + 15 * 16
assertion "tok == MP_TOKEN_ELLIPSIS" failed: file "../py/emitbc.c", line 525, function: mp_emit_bc_load_const_tok

none of theme worked without issues in the simulator.

by saying "designed for and verified to run on the dsPIC33FJ256GP506" do you mean the above should be working (at least on the silicone) or am I testing something which you did not test and which is not intended to be working?

Actually this opens more questions than it solves:
-Is my build environment buggy (ubuntu in docker)
-Is the microchip simulator buggy

What I also do not understand is how mp should work on 16bit platform if pointer tagging is used on the last two bits see MP_TAGPTR macros in bc.h. Incremeting the pointer will clash with the second last bit, not?