when 128k is not enough

[HenrikOlsson]

Wow Richard, that post of yours was almost as hard to read as a C program :-)

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

Got it. Of course having it interrupt driven by default has drawbacks of its own. Is it high/low priority? Does it in turn block other interrupts? How much overhead does it add in term of interrupt processing etc etc. I suspect there are commands available that does not use interrupts so I do get your point.

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

Yes, but IMO that boils down to bad practice more that one anything else. As you say, there is no wrong way it's just different. Personally I tend to use statemachines quite a bit, either that or the main loop is pretty much a bunch of If ThisFlag then GOSUB xxx, if ThatFlag GOSUB yyy which pretty much turns it into the C style you describe (I think).

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

It must come from the fact that C uses local variable so the compiler always knows what variables are in scope and therefor what to variables it needs to save (?) (but how does it know when the interrupt fires at compile time....). On the other hand, doesn't that make for unpredicatble latency, ie one interrupt it needs to save 5 variables, next interrupt it needs to save 10? I'm asking, not arguing by the way ;-)

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 )

Definitely so! Handling strings IS limited in PBP, there's no doubt about that.

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

That it adds 8k doesn't surprise me one bit. What does surprise me is the fact that it's hardly noticable with Arduino C. Is it possible that it's hiding the size of library stuff? Arduino is based on GCC right?

/Henrik.

[Jerson]

Every compiler implementation is different. You may find some C compilers are better than others in using the available resources (read registers) to do a certain job. Others may be quite simple and un-optimized (think small-c). C or Basic makes no difference other than the implementation. It is the coder who needs to decide which to use and how.

Coming to implementation, some compilers keep tabs on which registers are used to pass values between the caller/callee, locally used in the routine and push/pop only those. Some other compilers may choose to simply save an entire register bank - no matter what the time cost.

I do not code arduino, but, I think they hide a lot of implementation from the user within their libraries. That makes it like PBP an excellent rapid app development (RAD) tool and so they have plenty of users. On the other hand, hiding the details means accepting the compiler authors view of the world. You either use it or roll your own/better code. PBP has a similar concept of hiding code behind its library of commands and also allowing you to roll your own.

As for interrupts, PBP does have simple polled interrupt handling that may be quite insufficient if you compare it with other compilers for the same platform. However, that is what it gives you; it also lets you mix assember with basic which is a major plus if you know how to asm.

In my personal opinion, string handling, re-entrant functions, variable scoping, native interrupt handling are the hurdles if you use PBP for large projects. The lack of string handling functions is definitely a handicap for many, but using some asm done by DT(RIP), you surely can overcome the limitations by writing your own functions.

[HenrikOlsson]

PBP has a similar concept of hiding code behind its library of commands and also allowing you to roll your own

But isn't that what EVERY compiler does, ie hide the low level code from the user so he/she can write the code at the higher level? And isn't the difference in whether or not that "hidden" code is acceassible or not to the end user?

For example all the assembly macros that makes up a PBP statement is accessible, you can view them to determine exactly how a specific task is being performed/generated by the compiler and/or if the authours view of the world agrees with yours. I'm pretty sure the Arduino IDE's libraries are open as well, while the compilers from MikroElektronika all comes with "closed" libraries - I stand to be corrected though.

As for interrupts, PBP does have simple polled interrupt handling that may be quite insufficient if you compare it with other compilers for the same platform.

Very much so. ON INTERRUPT pretty much sucks. But DT-INTS gives you a lot of power and I'm not sure what MeLabs could do to improve on what we already have there. The upside is that we have a lot options depending on the application at hand. Sometimes ON INTERRUPT might be all that's needed.

I think most of us agrees on the limited string handling capabilities. It's popped up quite often, perhaps MeLabs is listening and working silently in the background. There's not been much (any?) development (released) on PBP for years now.

[longpole001]

yep i forgot for moment about interrupts , the bottom line is what ever speed you can run the EMB , then thats the top speed of the whole pic from that point.


i might say adding EMB is not something you really want to do, unless you really really had to ,

for starters the chip is a 80 pin chip , its costing about $6 , for under 50 units plus then 16bit flash at 90ns , at about $2 each , plus interface glue logic , and add to opcb design , manufacture etc etc

also if you needed some of those 80 pins for microprossors i/o use and they are also used for the EMB interface some addtional interfacing is also required.

its clear you will reduce your speed down of the pic to 25mhz , perhaps 32mhz if your lucky ,( waiting on MIcrochip responce for 16 bit EMB spec )

so the 128k limit of 8 bits chips , from the options covered here in this thread , you are far far better to

A. Do Not Use PBP -
if you ever suspect or likely ever to expand a project and there a chance you need more that 128k of internal code space for the project, and want to use the chips 64mhz speed , . then drop any plans to use pbp from the start ,
as the there are very few ways you can go forward , and for the most part your project will be higher cost / effort than choosing another platform , even if you know pbp well ,
there is no upward way forward and there is not likely to be so for sometime.

B. if no other choice and you find your self at the 128k limit and you have used PBP , then you seem to have 2 options

1. You poor sole - its time to consider the longer road and learn C coding in the end it more transportable , port your code to another plateform and never look back but loose a lot of time on the project your on now

2. stick with PBP but add 2 or 3 CPUs , split the fuctions/ supported hardware over the cpus , however your not ever going to get a double / triple of extra space
the overheads are large depeding on the fuctions / interface code overheads on each cpu and that maintaing more cpu's coding make for lot more work , updating etc , your only stalling the above options but it may be enough
to get you over the line, and time to reconsider ever going down the PBP again for project that has the chance to get past 128k.


as said this sucks some days

will update when microchip gives a meaning full reply for Fmax on the EMB at 16bit interface
cheers sheldon

[Demon]

This is pretty much why I think modular from day #1 on a project. When you consider the low cost of PIC chips, I don't mind having a PIC that scans a keyboard, another slave outputs to a LCD and have a master send/receive data via USART at 115,200 using Darryl's interrupts. It's robust, proven and works over long cable lengths.

I used I/O expanders when I first started but it's not even worth it any more. Today, a PIC costs less, runs at 64MHz, has waaaay more pins, can use complicated I/O logic (charlie-plexing) and can still do any of the features available on that model PIC. Much more bang for the buck.

[richard]

Got it. Of course having it interrupt driven by default has drawbacks of its own. Is it high/low priority? Does it in turn block other interrupts? How much overhead does it add in term of interrupt processing etc etc. I suspect there are commands available that does not use interrupts so I do get your point.

for the arduino as soon as you issue the serial.begin() command the system takes control ,the user has no say in the buffer size (and I don't how big it is) and its behaviour when full or overrun is undefined .
it also has a millis() interrupt running every 1 millisecond and a micros() int running every 1 microsecond too presumably wether you want them or not. nothings perfect (a mans got to know his limitations )
and as jerson indicated the arduino ide does its best to completely hide the hardware from the user for better or worse . but I have to hand it to them their library code is pretty slick and the optimising capability of the complier is outstanding.
I have used pic chips for more than 20 years and I am very comfortable with their hardware modules and can nearly understand the data sheets . The pwm section alone of a atmega2560 is 25 pages and I find it quite difficult to come to grips with it the and terminology seems foreign to me . so when it comes down to a nut and bolts nitty gritty situation I keep bouncing back to known territory.

[longpole001]

MICROCHIP have confirmed that emb works at 64mhz at 16bit mode , recommends glue logic, and sram - see links

i have asked charles to confirm method would work as he is working on code using the 18f87k22 at the moment

regards

Sheldon

We have received some suggestions from another engineer for third party components. Obviously, anything suggested will need to be vetted by you for your application as Microchip can not support or verify third party products. However, here are the suggestions:

A lot matters on the choice of vcc
http://www.nxp.com/documents/data_sh...LVCH16373A.pdf - is a 3 v part
http://www.ti.com/lit/ds/symlink/sn74ahc16373.pdf is slower, but supports 5v
http://www.alliancememory.com/pdf/sr...c1026bv1.3.pdf 64Kx16, 5V
http://www.cypress.com/?docID=49420 256Kx16, 5V
http://www.alliancememory.com/pdf/sr..._8TIN_V1.4.pdf 256Kx16, 3V

[tumbleweed]

Thanks for the updated info. Interesting idea about using SRAM and serial flash for 0 wait states.

this method on surface may allow for the expansion of available ram to the PIC as well

It would, but you're limited to accessing it using TBLRD and TBLWR instructions, so it wouldn't function as "normal ram"

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

You'll likely have to have a bootloader anyway to read/write the serial flash, so you could just have the bootloader handle the whole hex file without having to manipulate it. Store the entire thing in serial flash, and then at power on read the data and either program the internal flash (for the first 128K) or copy it to the SRAM (for the rest). After doing that once, you wouldn't have to reprogram the internal flash unless things change.

[richard]

On the other hand, doesn't that make for unpredicatble latency, ie one interrupt it needs to save 5 variables, next interrupt it needs to save 10? I'm asking, not arguing by the way ;-)

turns out to be quite true but still near 3 times faster on average

mikroc latency for the previous example ranges from 16-21uS
pbp is not rock steady either there I a 1-2 uS variation