when 128k is not enough

[HenrikOlsson]

Richard,
I don't know much about C but can you explain what you mean by the the inherent blocking nature of basic in the context of comparing with C?
Yes, PAUSE blocks the CPU but doesn't Delayms() do the same?

Comparing different compilers and different languages is hard and is probably never going to be really fair. There's always more than one way to do certain things and I bet that if we try we can swing the result either way by just doing it differently. Using HIGH/LOW instead of direct ports access for example - that's a 100% performance increase right there. Yes, it's not 100% equal operationally but most of the time the user doesn't switch between inputs and outputs anyway. That's just one example.

Floats may be another. PBP doesn't have it natively so it can't win there. On the other hand, it's not often that you can't make do with 32bit integers and that's most likely going to beat floats from a performance and code space perspective anytime. Not as straight forward to use though.

I agree that the lack of "real" string handling procedures is a drawback for PBP. ArrayRead can be used to some extent though. Sometimes I really miss proper functions and local variables as well - especially as the projects grows. I can only imagine what Sheldons project is like to maintain, hitting 128k in size.

I don't know if there's a standard way that 'C' handles interrupts but I would imagine that it TOO must save and restore a bunch of system variables on entry/exit - just as is the case with DT-Ints.

/Henrik.

[towlerg]

I'm going to give up trying to get a pbp3 version up and running after ,3 days solid I have 2 C versions working

Thats really impressive porting all that code and debugging in such a short time. Might I ask why 2 versions? and what processor did you use?

You appear to have resolving your problem, you must be a happy man (albeit a tired one). Bravo!

George

[richard]

George
one version pic18f45k20 in mikroc the other arduino mega 2560 arduino C 1.55 ide . the arduino version works best and was the easiest to implement (but I had a head start by doing the pic first and solving
most of the issues )

reason insanity pig-headedness and because it was there

[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

[longpole001]

thats true , how ever i could ensure that certain code / process are run in the area , and the lower priority / execute time perhaps ???, but it would slow down the overall performace of those fuctions

but i dont think there is away to control the speed of the EMB apart from system clock rate and the amount of wait states for access

[tumbleweed]

but i dont think there is away to control the speed of the EMB apart from system clock rate and the amount of wait states for access

Correct.

how ever i could ensure that certain code / process are run in the area

If you're talking about dynamically changing the clock rate I have a hard time seeing how that would work. I'm not sure how you'd locate certain functions in the external memory space, but beyond that you'd have to watch out for what happens during interrupts. ISR's (and all the peripherals) would run at two different speeds depending on when the intr occurred. You'd almost have to disable interrupts when executing code out of the slower region.

[longpole001]

and i can see a way to only slow down the EMB operations without slowing down the system clock ???

[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

[longpole001]

one interesting thing i was thinking about in relation to i/o pin speed for 18f67k22 it allows the system clock at 64mhz full speed out on Reference clock output , signal is bit unclean and puting through a buffer helps a lot ,

microchips reponce for 16bit EMB operations would be the key

[Demon]

one interesting thing i was thinking about in relation to i/o pin speed for 18f67k22 it allows the system clock at 64mhz full speed out on Reference clock output ...

Good idea, except you'd end up with code that runs at 64MHz when it's on the PIC, and 25MHz when it's from the external source no?

Robert