when 128k is not enough


Closed Thread
Page 1 of 3 123 LastLast
Results 1 to 40 of 82
  1. #1
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838

    Default when 128k is not enough

    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

  2. #2
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    or if placing 2 cpus on the board , what signaling was used , would spi bus be better interface with interrupt handling ?

  3. #3
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  4. #4


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  5. #5
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    I like to use PBP, another PIC and I2C at 115,200.

    Robert

  6. #6
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

  7. #7
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  8. #8
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  9. #9
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  10. #10
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,166


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

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

  11. #11
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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 ?

  12. #12
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  13. #13


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  14. #14
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  15. #15
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.
    Last edited by Demon; - 12th December 2014 at 04:59.

  16. #16
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  17. #17


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

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

    George

  18. #18
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  19. #19


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  20. #20
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

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

  21. #21
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  22. #22


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  23. #23
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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
    Attached Images Attached Images  

  24. #24
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  25. #25
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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 ??
    Last edited by richard; - 13th December 2014 at 12:41.

  26. #26
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  27. #27
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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)

  28. #28
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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 ?

  29. #29
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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 )

  30. #30
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  31. #31
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

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

  32. #32
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

  33. #33


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  34. #34
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  35. #35
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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

  36. #36
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

  37. #37
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    947


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

  38. #38
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

  39. #39
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    Quote Originally Posted by richard View Post
    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

  40. #40
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: when 128k is not enough

    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.

Similar Threads

  1. Saving space - close to 128k
    By longpole001 in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 26th October 2014, 07:16
  2. writecode at upper half of 128K parts?
    By Tomasm in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 22nd November 2004, 20:02

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts