when 128k is not enough

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

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

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

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

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