when 128k is not enough

[longpole001]

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

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

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]

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.

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

[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