when 128k is not enough

[towlerg]

Longpole, the conversion to Mikro Basic might not be as easy as it sounds, mB is procedural like Proton24. Have you considered Proton24? Assuming that that there is an unsupported, appropriate 8 bit device with more ROM, have you tried manually editing the PPI etc.?


Richard, I think the idea is to migrate without re-writing all the code.

multitasking (threading ) with python is just wonderful

I guess that only applies if you know Python. If you don't it looks like Forth or something.

George

[Demon]

I like to use PBP, another PIC and I2C at 115,200.

Robert

[HenrikOlsson]

Sheldon,
Can you describe a little bit what this device and code consists of, what it's doing and so on? Perhaps a block diagram?
That will probably help others, including me, to come up with more relevant suggestions.

For example, does it have some kind of user interface, buttons, LCD or perhaps a console interface of some sort to speak to humans? If so, you could offload that to a secondary PIC and then have some less verbose Communication of those settings etc between the UI controller and the main controller.

You know that things like HSEROUT and ARRAYWRITE etc litterally EATS away codespace, something like 6bytes for each and every byte/characters. Using something like the "strings in codespace" routines discussed on this forum might be Another way (if you're not already doing that). And, if you're NOT doing any of that stuff what the heck ARE you doing that takes up 128k?

Again, it's not easy to come up with suggestions without any sort of background information. It's not like there's a magic compiler directive that just shrinks the code ;-)

With that said, at some point or another the limit IS of course reached.

/Henrik.

[richard]

updated files and arduino mega328 version too , there were some minor errors but the results are unaffected

arduino int latency 10.75uS code size 1794 bytes

[HenrikOlsson]

Hi Richard,
I started writing a reply based on the previous files you posted, in which I found what looked to me quite substantial differences but now you've changed them so I'm just going to ask instead.
Are all three versions functionally equivalent, ie. are they doing exactly the same thing?

It still looks to me as if there are functional differences between the C version and the PBP version - I'm only comparing the versions for PIC, haven't looked at the Arduino code. It's my understandning that the follwing two snippets should be functionally equivallent:
C-version:

while (1){
     if (d_mode)
     pins_on=va+vb;
     else
     pins_on=vc+vd  ;
    for (x=0;x<5;x++){
        latc =   latc | pins_on  ;
        delay_ms(200);
        latc =   latc & all_off ;
        delay_ms(200);
        }
    if (!d_mode)  shuffle();
       d_mode= !d_mode;
 }

PBP-version:

action:
  pins_on=a+b
  for x = 1 to 5
    latC =   latC | pins_on
    pause 200
    latC =   latC & all_off
     pause 200
   next x

   gosub shuffle
  
   goto action

In the C version there's a d_mode variable which you're checking, I don't see that in the PBP version - what am I missing. (I truly suck at reading C code!)
It won't have an impact on the Interrupt latency (at least not for PBP) but if we're comparing compiles size we're going to have to make the code as functionally equal as possible or the results won't say much, no matter which way it swings.

/Henrik.

[richard]

they are now . I had a few copy paste errors where the second delay fell off the c version and the pbp still had a unnecessary loop in it as well as the led initialising to 0 line misplaced into the loop .I just saw the leds flashing and assumed all was equal . the outcome is largely unaffected anyway . I was really just quantifying the interrupt latency for my own edification , I still don't think the code size comparison is valid a fairer test probably needs a few serout2's and a lcdout and a onwire or two to be meaningful .
the mikro c is now 193 bytes and the pbp 315 other than

[richard]

In the C version there's a d_mode variable which you're checking

your right of course
that's the way I eliminated the redundant loop in the c version
looks like I skipped that step for pbp

code size now 336 and functional equivalence restored
thanks for noticing that

*  Name    : UNTITLED.BAS                                      *
'*  Author  : [select VIEW...EDITOR OPTIONS]                    *
'*  Notice  : Copyright (c) 2014 [select VIEW...EDITOR OPTIONS] *
'*          : All Rights Reserved                               *
'*  Date    : 29/11/2014                                        *
'*  Version : 1.0                                               *
'*  Notes   :                                                   *
'*          :   pic12f1822                                                *
'****************************************************************
#CONFIG
cfg1 = _FOSC_INTOSC
cfg1&= _WDTE_ON
cfg1&= _PWRTE_OFF
cfg1&= _MCLRE_ON
cfg1&= _CP_OFF
cfg1&= _CPD_OFF
cfg1&= _BOREN_ON
cfg1&= _CLKOUTEN_OFF
cfg1&= _IESO_ON
cfg1&= _FCMEN_ON
  __CONFIG _CONFIG1, cfg1

cfg2 = _WRT_OFF
cfg2&= _PLLEN_OFF
cfg2&= _STVREN_ON
cfg2&= _BORV_19
cfg2&= _LVP_OFF
  __CONFIG _CONFIG2, cfg2

#ENDCONFIG
 
DEFINE OSC 8 

include "dt_ints-14.bas"
include "REENTERPBP.bas"
asm
INT_LIST macro
      INT_HANDLER  INT_INT, _TL, PBP,yes
      endm
      INT_CREATE
      INT_ENABLE INT_INT
ENDASM
    osccon=$70    '8 mhz
    anselA=0        'dig i/o 
    ANSELC=0
    TRISC= %11110000
    TRISA= %011111
    APFCON0.7=0
     OPTION_REG.6=0
  a  var  byte
  b  var  byte
  c  var  byte
  d  var  byte
  pin_mode var bit
  d_mode var bit
  x var byte
  all_off var byte
  
  pins_on var byte
  led var lata.5
 
  
  
  
  a=1        ;portC.0
  b=2         ;portC.1
  c=4         ;portC.2
  d=8         ;portC.3
  pin_mode=0
  d_mode=1
  all_off=~(a+b+c+d)
   led=0
  latC =   latC & all_off
  
 action:
  if d_mode then
  pins_on=a+b
  else
  pins_on=c+d
  endif
    
  for x = 1 to 5
  latC =   latC | pins_on
   
  

  pause 200

  latC =   latC & all_off
  
  pause 200

  next x
  if !d_mode  then  gosub shuffle
     d_mode= !d_mode
  goto action
  
   shuffle :
   pin_mode = not pin_mode
  if pin_mode then
  swap a,d
  swap b,c
  else
  swap b ,d
  swap c ,d
  endif
  return
  
TL:
 led=!led 
@ INT_RETURN

[Ioannis]

Richard,

since you do not have PBP variables in ISR, you can set this:

INT_HANDLER  INT_INT, _TL, PBP,yes

as this:

INT_HANDLER  INT_INT, _TL, ASM,yes

and see the difference.

Ioannis

[richard]

INT_HANDLER INT_INT, _TL, ASM,yes

int latency now same as or even slightly better than c around 16-20uS

but its not always an option

[HenrikOlsson]

No, as long as the C compiler also always handles all needed context saving (ie SFR and "system variables") automatically the fair comparison in this case is to have the handler defined as PBP.

I'm pretty sure that a big chunk of the 336 bytes is comming from DT-INTS and I think that part of the compiled/assembled code will be constant while (and I'm guessing) in the C version, due to the intelligent context switching (as the call it in the MikroC manual), as you add more code to the ISR and/or Main() it'll need to do more context saving/restoring and therefor needs more instructions (=more latency) and more RAM (of course).

I think that DT-INTS always saves everything, for good and bad - obviously.

As I stated earlier, comparing these things isn't easy and is never going to be exactly fair.

[longpole001]

this is very interesting reading , cheers richard