when 128k is not enough

[longpole001]

Hi guys ,
well the project i am doing has now reached a point where i need to go to the next chip size , but there is not one that is supported by PBP

the easiest way seem , just add another chip and use the serial port to interface the 2 cpus' then start building software interface moduals for each of the hardware which is on each cpu

since i really only need more code space , another 128k would be nice ,

but its expected that 40% overhead of duplicated code would need to reside in the 2nd cpu for interface services.

how have others gotten around this problem , when you know the project exceeds 128k
i already have a lot of tables , off board serial flash etc , and only what cant be put in serial flash is on the program space

has any one gone down the path of converting pbp to mikrobasic that the compiler supports larger chips ?

cheers

Sheldon

[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.

[longpole001]

i would love to migrate , to another platform but the amount of work /time required its just not a road i want to go down , i need to finish this project , and i am very close for stage i want to be at ,

i need to add few other features , which will exceed 128k ( its currently at 110k ) and adding another chip appears to be the easiest way to use my existing coding/ knowlage and with what is written so far for the support code i have .


hendrich i am doing block diagram as its has quite a few moduals you would imagine

adding a 2nd chip although its pain , as the interface support to access and use hardware on both cpus and the common interface varables then transfer to the other cpu as needed , notification via status word for use between cpus for interrupt control notification ,etc etc

it is bit scarry at this point on the amount of extra work needed , to gain about 40k of program space , but that far less than learning a new scripting langage and new plateform i think.

ill post a block diagram of the key hardware interfaces.

I am trying to get the code smaller ,but tring to find 40k is just not likely

cheers'

sheldon

[longpole001]

the project is event timer control system using rf gates


its hard to write each of the blocks here without describing in full all the software components and their functions

but as an overview the hardware has

2 x spi buses , rf devices sd card , 32m flash
software spi for rtc ( to be changed to IC2 on next update)

usb/ serial for updates/ terminal services / other support hardware / remote displays

sound / horn control modual
4x 4 matrix keyboard
option 1 - 240-x 64 GLCD
option 2 - 240x128 GLCD with touch screen ( to be done yet)
spi 32meg flash - holds fonts / banners . terminal strings/ event dephaplts , time records of events , system controls / update temp bootcode


the hardware is simple stuff really but coding wise it takes a space for all the options anf fuctions for the rf compontes and thier many options , and trying to make t work well woth only 64mhz is also a challenge.

without access to most of varables when using the hardware from the other cpu , alot duplication is needed as well addtional interface code from what i am thinking ,

i guess thats price you pay for the 128k limit and project thats getting to big

it real shame that pbp cant make use of the larger pics , even if it were just the code space

[Demon]

Is it possible to have two versions of the board, one for each LCD?

That would make for an easy "split line", and have common code for most of the logic (easier to maintain).

Robert

[Dave]

You keep talking about code duplication, Maybe you should look at turning some of it into subroutines and save some space?

[longpole001]

i have pulled out option 2 for the display , and the touchscreen interface and support at this point , , a cutdown version of the graphics lib , to just support 240x64 display , all to save space.

and that will be added back for that version of the unit

the code is always in subroutines and i have made a lot of common called routines for support in each modual

There is seperate program for the loading and coding of the serial flash for the all fonts / strings / graphic symbols / event dephalts / menus system configuration / events menus /options / record data ,
only fonts that need to be in the main code area are.

the fact is the project has gotton bigger/ features added as it progressed , but the cpu space is limited

regardless of those type of code changes and they are on going , i wont be able to find a lot more space without removing features , or get a lot better at coding what is needed , ( always plays its part)

a new board will be designed , as this one was the prototype , and although i will use it as the first version for product testing / feedback , a lot of features will need to be shelved till i have more code space to allow for them ,

but in the end i need to have those features and some future expansion options ,

so i am looking at those now , as any new board would need to have those options , and thus the thought of adding a 2nd cpu

how to do it ???

when i say duplication of code its more to do with overhead when moving say the matrix keyboard over to the 2nd cpu, but the graphics modull / support is on cpu 1

most menus/ rf selection etc are displayed based on key pressed so code " if key x then do a lot of shit in cpu1 and use those varables in cpu1 , "
so moving the code that gets the key value is of little size moved to cpu2 , a small space saving on cpu1

but the all the varables , subroutines for hardware it calls as result need to be then sent as requests to cpu1 ,

so i cant really move all the keyboard menu statements / actions as they relate to hardware/ variables in cpu1 without a very large change on both cpu1 code for most of it would need to be copied over to cpu2 in the form of requests to cpu1.

and thats just moving the keyboard , i am looking at the other hardware items , but i most cases it not an easy task to isolate them as other parts of code do use them , and any parts that are moved to cpu 2 need to be coded to the cpu1 and 2 interface varables , which in tern duplicates the variables on both cpu's , which is no real space improvement ;(

This how i thinking of it at the moment ?

[Demon]

I think you're trying to hold a desk together with a single screw.

I'd delegate; one PIC to manage the RF peripherals, one for both LCDs, and so on.

A USB master PIC would poll each slave in turn, managing the exchange of data.

I was a mainframe programmer in COBOL. PC programmers make fun of such an archaic language but it taught me to think modular. It makes for more hardware, sometimes duplication, but it makes robust systems.

Robert

[towlerg]

I agree with Demon, try to look at the whole as a bunch of functions and locate the function on the CPU best placed to deal with a particular piece of hardware, for instance move the LCD handler and fonts etc. to a supernumerary cpu attached to the LCD's. As you are going to have 2 ? CPU's suggest SPI (a good deal quicker than I2C) slave /master. You'll need to establish some protocol, like first byte is command (in this case data to LCD), second byte is length of data, data n bytes (inevitably this will get more complex). You'll also need a mechanism to allow data to go the other way.

Actually the more I think about this, the more positive this could be. While leveraging your existing programming skills, you'll inevitably you'll get a performance hike, with all the humdrum stuff removed (to the other CPU) debugging becomes easier, if the second CPU is a separate board it makes it easier to add functions and a whole bunch of other stuff I haven't thought off.

I know the old corporate nonsense about challenges and opportunities but I think in this case viewing the situation positively could result in all sorts of benefits.

I wish you the best in your project, it sound really interesting. If possible post your progress, I for one am keen to hear where this story goes!

George

[longpole001]

ok if i am going to break out to 2 or more cpus's

then perhaps breakup into hardware voltage use
cpu1 128K 18F 64PIN 64MHZ 5v - 18F67K22
xtl based 10ppm
cpu clock calibration control
GLCD 1 = 240 X 64 5V UNIT
GLCD 2 = 240X 128 5V UNIT

GLCD SUPPORT SERVICES -
gldc bightness control PWM / back lighting

KEY MATRIX 4 X4 / SUPPORT / KEY MENUS SYSTEM MENUS / EVENT MENUS SUPPORT
touch screen interface / support / CALIBRATIONS
cpu clock calibration

SERIAL PORT 1 - USB TTL MODUAL / USB CHANGER pwr CCT / VOLTAGE MONITOR / alarm SERVICES / USB UPDATE BOOT CODE SUPPORT / REMOTE DISPLAY RF DONGLE SUPPORT / DEBUG - 5V UNIT

RTC - software iC2 - 5V UNIT / modual 1/100th SUPPORT / ELAPSED TIMER MODUAL SUPPORT /

RGB Led for onboard status/ monitor (heartbeat) both cpus.
SPI bus 1 - level converters used - FLASH 32Mb (3V3 / FLASH SUPPORT / FONTS / SYMBOLS / BANNERS / common STRINGS / ALL MENUS / TEMP BOOT CODE STORAGE / REMOTE DISPLAY STRINGS/ OTHER DATA tables AS NEEDED
SPI bus 1 - ( same bus as flash ) SD CARD ( 3v3) / CARD SERVICES/ FILE SUPPORT CONVERTED TO NOT USE LONGS
( COMMON BUFFERS FOR BOTH DEVICES )
spi bus 2 - cpu2 interface ( level converters used ) / INTERFACE CODE / BUFFERS / INTERRUPT SERVICES CONTROL WORDS / STATUS WORDS AND PROTOCOLS

spare serial + port 3 pins

CPU2 128K 64MHZ 18F67K22 3V3

RF MODUAL 3V3 / SUPPORT SERVICES / ALL, RELATED RF ATIVITIES FOR GATES/ AND SUPPORT RF TRAFFIC DEVICES / HAND CONTROLLERS ID DATA / SYSTEMS / PROPRIETARY ENCRYPTED ENCODED PROTOCOL

EVENTS HORN CONTROL / SOUND CHIP modual 3V3 / flash - EVENT TRIGGERING AND GATES control / options settings / monitoring services

ALL EVENT RELATED DATA / EVENT GATE CONTROL / ELAPSED TIMER INTERFACE SERVICES / EVENT LOOKUP FIND ROUTINES / Floating point for distance speed caculations ( use longs )

SPI BUS 1 - 2ND FLASH CHIP 32mb - / EVENTS RECORDS DATA / boot code temp use

Spi bus 2 - cpu2 interface ( level converters used ) / INTERFACE CODE / BUFFERS / INTERRUPT SERVICES CONTROL WORDS / STATUS WORDS AND PROTOCOLS


Shared services modual

coding for bootloader programing for cpu1 , cpu2 , flash 1


well thats a staring point anyway

[Demon]

Unless you move to next-gen PICs, this is a huge step towards a much more reliable system; easier to write, debug, support and expand.

Awesome project. Looking forward to seeing your demo video.

Robert
:)

Edit: I know it's gnawing at your guts, that it feels like a step back, another delay towards your goal.

It's the opposite, it's an investment. I was a system's analyst, from the high level down to the code. You'll be happy later when things go sideways or you add more features. :)

[longpole001]

hi robert

i will still progress on the current 1 cpu for the moment cos i have boards made / even if they are modified , for product testing the last 15k of code space should be enough to get the base requirements going so i can get a product feedback in jan ,

i will make use of the prototype boards for the product in its baseform , and after the feed back ill put that into the design of the 2nd pcb , which will use 2 cpus and break up the tasks as i see them at the moment .

it is a step backwards, in that if i had taken up pic design in C i would not have this as big an issue as i do now and change in platform would not be as painful and this would not be needed

but its been over 20 years since coding in C and i do like basic and PBP , but now i am seeing the many restrictions by the choice.

it is very sad that pbp can not support the larger chips even if it were for just to use the larger code space and use only 8bit fuctions ,
it at least allow some upgrade path using pbp past 128k.

It also seems likely that PBP will not progress in any functionality for some time , apart from adding a few more 8 bit chips in the next year or so ,
also given DT's passing has delayed any further release updates to PBP/ U2 programmer support etc for majority of this year.

Microchip in marketing wisdom have made that choice as well forcing you down the 16bit or 32 bit path just to get a bit more code space.

but this is where i am at so ill just have to make it work


i did not expect this to become as big as it has but to start again on new platform is not practicable given i just want to get it done


cheers

sheldon

[towlerg]

Might I ask, what device are you currently using? and which device would you like to use?

George

[longpole001]

i am using 18f67k22 , like to use - anything bigger for code space and pbp ,

the device is holding together well with the code as it is running at 64mhz , but faster, bigger , more would be nice for some wiggle room , 2 or more cpus are the only option forward when using pbp and a chip that has 128k code space close to full

[towlerg]

I had a quick look, may be wrong but the only devices I could find with more that 128K were PIC24 and PIC32. If that is the case, don't even bother hinting to ME, it a whole new compiler.

George

[longpole001]

yep 8bit and 128k is the largest they make and pbp only supports 8 bit

[longpole001]

i asked charles on the possible support of the 16 bit , 32 bit in limited to access code space / or full usage ,


We've attempted to complete this on several occasions, but there have been setbacks. The most recent attempt was stalled in 2013 due to issues concerning the developer that we were using for the PC-side executable.

The project is bigger than an expansion of the current PBP. Some parts of the current compiler can be reused, but it's really a matter of creating a new compiler just for PIC24. The good news is that we've already completed most of the work. The issue is frequently discussed, but no development is happening right now.

In the past, I've shared my optimism for completion dates and such. Things didn't work out. I am still optimistic, but I'm reluctant to take a guess as to what the universe holds in store. It's been a tough year.
Charles Leo
microEngineering Labs, Inc.
http://melabs.com

[towlerg]

due to issues concerning the developer that we were using for the PC-side executable.
So what part of a compiler isn't PC-side?

Anyways, even if they released a new compiler tomorrow (which they clearly are not) you'd still have to port your code to a new compiler (would you base a commercial product on version 1.0.0.0 of a compiler?) and there are already several mature options , one you've already mentioned and Proton24 (which I see supports several 256k Flash PIC24 devices). It looks like you've got to bite the bullet one way or another.

As I said before, fascinated to hear your progress.

George

[richard]

587000 floating point records extracted from a 14 million record database plotted and displayed on a hdmi screen , converted and exported to a png file , time < 15 sec
raspberry pi -python
data is fed from wireless weather station every 48sec captured by a pic 12f1822 with rfm01 wireless module and uploaded to the pi via i2c
its a good combination.
its going to leave a pic24 for dead


ps the graph is interactive when viewed live on the pi

[longpole001]

looks like the way to go in the long term and need to tack real,look at it for project but its a lot of overkill for what i need - at the moment , given that i realy need a little more code space to top things off

also it add a large cost for the product which need to be made in the 50 units at a time
i will get one to play with though

[richard]

THE OTHER OPTION
arduino mega 2650 :- 256k flash 8k ram 4k eeprom ,the sainsmart clones <$20 delivered .
big bonus 16mhz mega is about 4 times faster at floats than a 64mhz pic18 and equal or better at most other tasks, plus the free compiler is outstanding , especially in its optimisation capabilities .
floats are pain free in comparison to the microchip float library. its almost as if atmel actually want you to use their products unlike others who want $1000 for a decent optimising compiler.
most of the free libraries I have tried are very good even the colour touch screen glcd lib (try to find a free one that works for a pic), there are bigger/faster models too including a 32bit version that looks to be using the same ide . got one of these (a mega)plugged into the pi too via rs232
ps debugging
wow for $25 got the atmel studio arduino suite plugin , source level debugging at last that actually works and without any fancy (expensive ) headers either

the arduino forum has about a 100 new posts a day compared too ??

[Ioannis]

Richard, what you post seems a lot interesting. But I 'd like a more detailed reasearch. For example, same kind of code in PBP and Arduino C like lanquage.

What size code produces each compiler?

I have a strong feeling that Arduino is not near in the same neighbour. So if Sheldon has problem with 128Kb in PBP, how would this code be efficient enough for the Arduino? I think it won't.

Have seen small programs that take many KB in Arduino that could be built with less than 1 or 2 in PBP.

The other side is that is very easy and worry free as you said. Meaning there is no such thing as free meal.

Ioannis

[richard]

ioannis , what you say is correct esp for core 10 and 14 chips who's architecture is not particularly c orientated . pbp is hard to beat for small efficient code on these chips.
but for floating point work and/or complicated string parsing on pic18's c comes into its own . I firmly believe in horses for courses and lets face it the difference in price between a pic12f1822 and a 18f45k20 is not that great. as I have said before why struggle unless you are going to make and/or sell heaps of units , most of my stuff these days is one off , plus If I can get the esp8266's to behave the IOT becomes a reality . the esp8266 prg is 8.67k compiled with c on a pic . I will port it to arduino and compare. so far I can't get it to function properly with pbp3 the inherently blocking behaviour of basic functions is making life hard for that idea ,but worth pursuing for the IOT revolution (if its not all hype)

[longpole001]

i do like the amtel / arm chips , pricing is good, many pre made boards with easy ways to incorporate into projects , but Arduino C seams like a road i will have to learn if i am to uses these chips/ although mickobasic may be an option as well ,
, but so far from whats been said , the compile size for something simple is high/ compared with PBP and it seems bloated for simple projects , larger ones , may be not as much ?

[richard]

the esp8266 prg is 8.67k compiled with c on a pic . I will port it to arduino and compare
well I did it. for what it worth the two platforms seem comparable for C code anyways
on a pic18f45k20 my esp8266 simple server pgm in mikroc 8.7k using 1.4k ram , arduino mega 8.67k 1.6k ram .
pbp3 not yet working still trying although I can get a flaky version going with <3k flash and ram ? (i'm not going to add it up )

[Ioannis]

I am pretty sure PBP will consume less memory as long as no floats get in the way.

I am very intrested to see the results though.

Ioannis

[richard]

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 and flagging interest for the pbp3 version , with no inbuilt string searching routines my clunky attempts at a strtok(),strcmp() functions on circular buffers (three of them) over 256 bytes in size fed by and feeding interrupt routines is failing miserably ,its hard to compete with well honed C libraries . the task is daunting , at least for me . but I really don't think it would turn out to be much different size wise anyway .the inherent blocking nature of basic and the largish overheads in interrupting it don't help either. maybe you (ioannis or anybody) might like to propose a less daunting comparison to try (I think a simple blinky is not a realistic test its needs a bit more than that something that could use floats if they were available or workarounds if not).

[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]

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

[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.

[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

[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.

[richard]

Some files to ponder on . done on a pic16f1825 8 MHz , two led flashy blinky things with a pointless int_int

mikro c 181 rom words 11 bytes ram int latency 19 us
pbp 3 324 rom ram ? int latency over 58uS

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

[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

[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]

this is very interesting reading , cheers richard

[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

[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

[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.

[richard]

I have notice the c latency can be as low as 4us I first thought that was a glitch but it happens fairly often now that I'm looking , so the odds are that increased complexity in the isr will spread the range further.

there is a thing called chipkit-pi a pic 32(28 pin dip) clone of the arduino , its designed to plug directly into a raspberry pi and has a free ide based on the arduino ide . it has some limited arduino library compatability .
that's my next toy , perhaps thats the step up past 128k ,midrange c gets you nowhere extra in that regard

[longpole001]

this thread has been a bit hijacked although interssting

having alook at the 18f87k22) 80 pin chip , it tells of the eternal memory - section 8.5 addressing feature for both 8 and 16 bit mode , this option appears to be afar better one for accessing an 40- 128k of flash surely than changing horses ???????

[richard]

as the complexity increases I'm always expecting this result

[pedja089]

It's easy to add external memory, but how you would compile code for whole project, and then split code in 2 segments?
Only way I see this could work is to use only ASM, so you could manually enter address of each subrutine. But would MPASM allow you to assembly code larger than 128K?

[Demon]

this thread has been a bit hijacked although interssting

having alook at the 18f87k22) 80 pin chip , it tells of the eternal memory - section 8.5 addressing feature for both 8 and 16 bit mode , this option appears to be afar better one for accessing an 40- 128k of flash surely than changing horses ???????

When they mention external flash, do they mean an SD card?

Robert

[longpole001]

thats intersting question , i expect not , it seem to me more like adding an external flash chip is liuke adding eeprom , great but how o use it more than just storage

[tumbleweed]

When you use the external memory bus of the 87K22, you connect it up to a regular 16-bit parallel flash device and the operation is totally transparent to the program. Program code < 128K uses the internal flash, and addresses above that go to the external memory chip... up to 2M bytes

Assuming that the compiler doesn't have any internal program size limits, there's nothing special you have to do when writing your program... you just end up with a really big hex file.

There are some limits/things to note:

- external memory is slower, so you have to reduce the system clock. The only reference I've found in the 87K22 datasheet is a note that says"Fmax=25MHz in 8-bit external memory mode". Using a 16-bit wide memory may ease this a bit, but there's nothing in the data sheet to back that up.

- you'll likely have to have a bootloader that can program both the internal and external flash devices since the regular ICSP programming tools like the pickit won't work to program the external flash.

- likewise, you can't use the ICD debugging tools, and the MPLAB simulator doesn't support the EMI either.

- there's an errata w/the 87K22 for the EMB. The CE chip select pin won't be extended if you use wait states, so you have to make sure the flash is fast enough to run in a single cycle.

[longpole001]

The only reference I've found in the 87K22 datasheet is a note that says"Fmax=25MHz in 8-bit external memory mode". Using a 16-bit wide memory may ease this a bit, but there's nothing in the data sheet to back that up.




this would mean the whole chip has to run at 25mhz , assuming that you external mem/ addressing is used for compiled code by the sounds of things




Assuming that the compiler doesn't have any internal program size limits, there's nothing special you have to do when writing your program... you just end up with a really big hex file.


i am not so sure that it does , i have always though it was tied to the chip selected when compiles , as such the chip size limits would apply and give errors in the compile , not warnings and thus not compile ???

[towlerg]

i am not so sure that it does , i have always though it was tied to the chip selected when compiles , as such the chip size limits would apply and give errors in the compile , not warnings and thus not compile ???

I guess you'll need to edit BLOCK_SIZE in the device file.

George

[HenrikOlsson]

I'm not saying there isn't a way to make it work but I'm pretty sure PBP doesn't support it natively.
You'd need to somehow fool the compiler into thinking the device has more memory than it has (if that's even possible). Then the compiler and assembler generates a single .hex file which you'd need to split at the correct location, program the first half into the PIC itself and the second half into the external memory device using some other type of device programmer.

I don't know the format of the .hex file, if there's any sort of header and/or checksum or anything like that. If there is, then simply cutting the file into two most likely isn't going to work and some sort of software would need to be written to repackage the large hex into two with the correct format.

Again, I'm not saying it isn't possible and I look forward to hear about any experiments. All I'm saying is that I don't think it's going to be straight forward.

/Henrik.

[Demon]

I'd head over to the MeLabs forums for something so technical.

Robert

[HenrikOlsson]

I've just tried a couple of things....

In MicroCodeStudio I selected an 18F1220, which has 4k of FLASH.
I started to add code and compile untill I got close to 4k (I got to 4095 bytes).
At that point I expected to get an error message if trying to add more code but I didn't. Since I knew I was at the limit I added started to add @ NOP, one by one, each adding two bytes to the compiled/assembled size as shown in MCSP. Finally, at a reported size of 4107 bytes, it no longer seemed to get "any bigger". However, the compile and assemble process finnishes without errors and the actual .hex file keeps growing.

I then started MPLAB, selected a 18F1220 as the device and imported the .hex file. Needless to say, the last line displayed is at adress 4094
I then found this blog post (http://www.kanda.com/blog/microcontrollers/pic-microcontrollers/pic-hex-file-format/) which discusses the format of the actual .hex file.
What it tells me is that, as expected, it's not just a matter of simply splitting the file at the right location and I have no idea if the compiler/assembler process actually generates the correct adresses etc for calls outside of the chips "normal" memory.

In MPLINK helpfile there's a short section on how to set the linker up to build C and assembler Project for use with external memory. How that could be applied to PBP (if at all) is beyond me at this point.

I'd definitely drop MeLabs a line but considering you've already mentioned you're up against the 128k limit at their forum I would've expected them to suggest using external memory if at all possible.

/Henrik.

[longpole001]

ill have a check with melabs on this possible option to use extended flash , but the chip running at only 25mhz to support the extended memory hanging from it , would be a killer , as i do need the speed of 64mhz

but if charles can comment on this option when using pbp , would be good , as its not something that i think has been asked before ?

[longpole001]

re reading the datasheet , section 31-1 - note1 Fmax= 25Mhz in 8 bit External Memory mode - FOR VDD VALUES 1.8 TO 3V ,

so i would think that as long as VDD is higher than 3V then Fmax = 64Mhz

[longpole001]

also the CE for wait states on external memory bus has been fixed in C5 release of silicon

[longpole001]

APPLICATION NOTES ON EXTENDED MEMORY BUS
http://ww1.microchip.com/downloads/en/AppNotes/00869b.pdf

[tumbleweed]

I probably should have been clearer when I said there's nothing special you have to do when writing your program.
There was talk of having to use ASM and split the program into multiple sections, manually enter addreses, etc.

To enable MPASM to override the device size so you can use external memory you need to add a __MAXROM statement to the device .INC file, like so:


__MAXROM 0x1FFFFF ; 2Mbyte


I don't use PBP much anymore, so I just did that with an old 18F6680 (64K) program I had and built a 1.2MByte program using PBP 2.47


As you've all mentioned, the trick here is what to do with it once you're done. You have to get part of the hex file into internal memory, and the rest into the external flash chip. If you somehow want to program the devices using an external programmer, there are tools you can use to split the hex file into the needed segments. I'd recommend the hexmate utility that you can get for free w/some of the Microchip tools.
Personally, I think you'd be better off using a bootloader program running in the internal flash and just let the device itself program everything.


some other comments...

also the CE for wait states on external memory bus has been fixed in C5 release of silicon
Thanks for that. I didn't realize it had been fixed.


re reading the datasheet , section 31-1 - note1 Fmax= 25Mhz in 8 bit External Memory mode - FOR VDD VALUES 1.8 TO 3V ,
so i would think that as long as VDD is higher than 3V then Fmax = 64Mhz
I think you're mis-reading that statement. There's a period in that sentence that you've deleted.
In Figure 31-1 the note reads:

Note 1: FMAX = 25 MHz in 8-Bit External Memory mode.
For VDD values, 1.8V to 3V, FMAX = (VDD - 1.72)/0.02 MHz.
That puts a limit of 25MHz on FMAX when using 8-bit external mode. Period.

If you look later in the datasheet at Figure 31-6 it shows an external 8-bit bus cycle. At cycles Q3 and Q4 it shows fetching a byte from each of the byte-wide chips in a single Q period. At 64MHz, each OSC Qn is 16ns! That would be one fast flash chip!

Unfortunately, the datasheet doesn't show a fetch using a 16-bit device. App note AN869B shows a 16-bit fetch, and the timing is a lot more reasonable since it uses Q3 and Q4 together to fetch a single 16-bit value. If you combine that with a wait state (Figure 12) then you'd have a bus cycle of ~120ns, which would match up with the speed of most flash IC's.

The thing is you would still only have roughly a single cycle (16ns) to latch the multiplexed address info. I doubt that the PIC IO pins would actually be able to keep up with this speed. 25MHz would give a single Q time of 40ns, and a bus cycle of ~160ns. You could probably run a bit faster than this, say perhaps 32 or 40MHz before the IO pins quit working properly, but as I said there's nothing in the datasheet to guarantee that.


This is all pretty advanced stuff. You'd have to decide if it's worth all the bother or not. Of course, porting 120K of existing PBP code to something else is a lot of work too!

[pedja089]

I just did quick test.
Compiler doesn't mind compiling code larger than 128K. Actually, there is no way that compiler could know hex size, before assembling. So far so good.
But after assembling, assembler returned error that generated hex is too large. After adding __MAXROM 0x1FFFF to P18F67K22.inc, hex file is generated without any error.
I have done "secure" bootloader for PIC18F67K22, so when I need more memory, there is simple solution.
Thanks, tumbleweed!

[longpole001]

thanks for that ,
i been trolling the microchip site and this has been asked before using c , with various results , 2 threads i read eventualy gave it up.

16bit mode would be the only option to consider , and i have a raised a ticket with microchip to pin down timing on the 16bit option for the bus , but the timing you mention seems likely ( microchip also give an example - in C of setup for the addressing , but it was not of much help

but the underline factor is the speed drop of the cpu the 25mhz- or even say 32mhz to allow for the extended memory bus and that not really an option for this project. 64Mhz it works well and i really cant drop it back now , just running out of code space


so again its looks like either is porting the code/ learning new compiler / c probablyor Microbasic maybe but i dont hear good things so far / new hardware chips / probalby go ARM

OR

having 2 cpus / split off some of the hardware / then develop and complete interface for the cpus with interupt handing / some varable transfering / sub routines indexing interface so the one cpu can call each others routines and what at this point looks like a lot of duplicated code in both cpus and work

but it seems is the only way forward with PBP .

the code has taken most of this year to write / test , and even though porting would be alot easier than starting again , i really dont want to , it would take another 3-4 months to learn new script language and then port everything

EMB option looks so good an option over the above options if PBP can be made to use it well , but droping the cpu speed down to use the EMB is not really an option ,


this really sucks some days

cheers

Sheldon

[tumbleweed]

If Microchip gives you any good information, please post it here. I'd be very interested.

Sounds like you're between a rock and a hard place. Splitting a program up to run on two uC's doesn't necessarily make things easier, or save code space. It certainly doesn't make it more reliable, that's for sure. Quite the opposite.

If you're finding a lot of duplication of code then that's not a good sign. Try and split things up so that more of the work can be offloaded to the other cpu. If they have a lot of functionality/data to share things might not get any better.

Good luck!

[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

[longpole001]

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

[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

[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 accessCorrect.


how ever i could ensure that certain code / process are run in the areaIf 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]

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.

[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]

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_sheet/74LVC_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/sram/fa/as7c1026bv1.3.pdf 64Kx16, 5V
http://www.cypress.com/?docID=49420 256Kx16, 5V
http://www.alliancememory.com/pdf/sram/fa/as7c34098a_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 startupYou'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.

[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