when 128k is not enough

[longpole001]

or if placing 2 cpus on the board , what signaling was used , would spi bus be better interface with interrupt handling ?

[richard]

if you need two cpu's I'd make one a raspberrypi , honestly multi gigabyte sd cards ,usb sticks, wifi ,Ethernet 512meg of ram and the elegant simplicity of python scripts and sql databases.
bang a pic on the side for lowdown nuts and bolts real time interfacing . join them together with rs232,spi,i2c what ever you like and bobs your uncle. multitasking (threading ) with python is just wonderful and have a look at pigpio by joan for some lowlevel stuff if you like (pretty amazing),but I still prefer bit-banging with a PIC.
why struggle when you can overkill it to death

[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

[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

[longpole001]

this is very interesting reading , cheers richard

[richard]

when I look at the hex dump both versions end at rom 00b8 so i'm not sure how to really compare the size

I'm wrong again was looking at wrong file . the pbp version is 341 words c version 181.
also the pbp version has a redundant for/next loop removing it saves 28 words
surprisingly the int latency has increased by 4uS by removing it ???

[longpole001]

yes splitting up into 2 cpus is no fun either , its a lot of work and cost either way, using EMb looks easier to implements if the codeing can be done ok , another issues is the amount of i/o ports the emb takes ,

the i/o ports cant really be used for anything else except the eMB bus, cos even if the ports / normal cpu i/o while not using the emb , any code that runs in the emb and requests hardware connected to pins that are emb bus wont work