when 128k is not enough

[richard]

commands like hserin hserout block until they complete whereas in arduino c the equivalents serial.print() and serial.read() are both interrupt driven out of the box . of course pause eqv delay() is a blocker .
but the biggest difference is the architecture of coding style in c most have a main loop that executes as fast as possible calling functions on the way to see if they need servicing each function of course uses time from the main loop but only when needed (think of a token ring) . in basic most programmers make the code like a string doing functions sequentially . no one way is any better than the other except that one strategy may suit some tasks more easily . when it comes to interrupts c wins hands down sure its got to dump a heap of stuff into the stack and pop it off again but its much less than dt-ints doing a pbp style irq quite noticeably in fact , although often it doesn't matter
but what I was trying was three simultaneous async serial streams 2 ser outs one software one hardware and one hardware input all at 9600 baud , both hardware streams interrupt driven . if a chr was lost then things went wrong . in c no chr loss, pbp some loss , arduino mega no loss and baud rate jacked up to 115200 for the debug stream
you have to appreciate commands like serial.available() give you the number of byte in the serial buffer. serial.find("ok") returns true if serial buffer has ok in it . imitating those functions in pbp is not easy (don't forget the buffer is filling in the background as you search and if it overflows all can be lost )

floats are interesting in xc8 /hightec c for pic one float command adds nearly 8k to you pgm so workarounds are very worthwhile . / mikroc pretty much the same sourceboost c has a weird float library that takes multiple steps to achieve and adds up to about the 8k of the others anyway . yet on an arduino you'd hardly notice

[Ioannis]

commands like hserin hserout block until they complete whereas in arduino c the equivalents serial.print() and serial.read() are both interrupt driven out of the box

You have a good point Richard. Fortunatelly DT-INTS can help on this, though needs a little work from the programmer to make a ring buffer. Not out-of-the-box, but close.

Good thread this one.

Ioannis

[longpole001]

H1 guys ,

well further feedback from Microchip on the EMB of the 18f87k22 series , indicate that at 16bit which they do not state the the Fmax speed in the Datasheet , is that the device will run the EMB at 64mhz (16Mhz instruction rate internal)

Silicon C5 fixes the wait state Errata to allow for upto 3 wait states on the chips connected to it., however code running in the EMB would be slower than on the PIC as a result of the wait states

Microchip states that the expected chips would need if running at 0 wait states a total access time < 21ns ( electrical spec 167 ( address to data valid time in datasheet figure 31-7, table 31-11) ,including the glue logic

This can only be done by using the Sram 16bit ( most are 10ns ) , with glue logic at about ( 5ns max) , where the code would be loaded from serial Flash into Sram before running

this method on surface may allow for the expansion of available ram to the PIC as well , but i am waiting on confirmation of this and some other timing clarification on the above tables in the datasheet

The points highlighted in the thread indicate that the generated hex file would need be edited at the 128k code boundary , sub divided into 2 hex files manually, then loaded in to the PIC program area , then into external flash , then from external flash into the sram for use at startup .

It should be noted that Sram of speed and glue logic is not cheep , in fact its comparable to adding the same size PIC again

but it may be a way forward , more info still needed from microchip

regards

Sheldon