Shop OBEX P1 Docs P2 Docs Learn Events
How to alter running code? — Parallax Forums

How to alter running code?

T ChapT Chap Posts: 4,223
edited 2009-05-26 19:07 in Propeller 1
If I have 4 possible hardware options that might be connected, but all may not be connected if the user chooses not to, is there a way to alter code to remove the IF statements that would attempt to poll the devices?

An example:

PUB Poll
Repeat 'poll devices for a response
if device 1
'something
if device 2
'something
if device 3
'something
if device 4
'something

whereas polling or attempting to poll all 4 would affect the speed and performance.

I am just curious if there is some software equivalent of commenting out the unwanted code, that can be set within the same program by the user. Something like:

PUB SetupDevices
If device1NotPresent
'set Poll to NOT read the device
If device2NotPresent
'set Poll to NOT read the device
If device3NotPresent
'set Poll to NOT read the device
If device4NotPresent
'set Poll to NOT read the device

The result would save the loop having to devote time to each IF. In a case where there are just a few like shown it is not a big deal, but when I have possibly 20 options to poll, the performance takes a hit with the multiple If statements.

Comments

  • AleAle Posts: 2,363
    edited 2009-05-25 16:53
    You just check another boolean variable to see if the polling should be done or not. While you can overwrite spin you will have to get the address of that piece of code and replace it for some jump or simiar... I'd check a variable as I said befoe, though

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92
  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-05-25 16:56
    You can use a CASE statement as a switch based on a variable that lives in a subroutine to check for the existence of the interface.
    If the parameter is a command line PARM then the CASE code uses parm in the CASE code. Ale's method works fine, also.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH

    Post Edited (James Michael Huselton) : 5/25/2009 5:01:25 PM GMT
  • jazzedjazzed Posts: 11,803
    edited 2009-05-25 18:40
    I assume you mean that this is a run-time situation where devices can dynamically disappear/reappear and not a situation where the configuration can be compiled.

    Given that, another way besides the good ones already mentioned would be to use an array of objects and indicies where each object has a method you can invoke depending on the device type. In the case of "missing hardware" the indexed object would be an "NullDevice" object where method does nothing or whatever. Of course that requires using the object boundary violation trick which means all objects must have the same set of methods (and some members loathe), but your code can be greatly simplified (more maintainable).

    I've included an example for you (a little more complicated than you need I guess). As you can see in the output below, object 1's function was dynamically altered during program execution. There is no chain of IF or other conditional constructs in the demo ... everything is controlled by repeat for loops and array manipulation.

    Starting Object Bounds Demo
    
    NullDevice is Object #0
    1 Normal TestDevice now open
    2 Special Test2Device now open
    3 Normal TestDevice now open
    
    Object Writes
    1 test
    2 hmmm....  test
    3 test
    
    Now Object 1 is NullDevice
    2 hmmm....  test
    3 test
    
    Object Bounds Demo Complete
    
    



    Hope this is helpful to you or someone else.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • T ChapT Chap Posts: 4,223
    edited 2009-05-25 19:21
    jazzed said...
    I assume you mean that this is a run-time situation where devices can dynamically disappear/reappear and not a situation where the configuration can be compiled.

    Jazzed, Thanks for that example to study. I am after something something similar. The end user does not have access to a compiler to turn off device scans, and the end user may choose what devices to connect, and these devices can be added later. That being the case, I want to have a menu where the user first manually configures by a menu driven method the actual devices are hooked up, and then the main repeat polling loop scans ONLY the devices that are present, without spending time determining (within each iteration) if the device is present. Using Case or IF to determine if a variable is present that stores the presence or absence of a device is the current method, but this still requires time to read the vars that precede each objects scan. In SPIN multiple layers of checks start affecting the repeat speed dramatically.

    In other words:

    Repeat
       If Device1Present   'byte var set earlier to 1 or 0
           If ReadDevice1 == True
             <something>
       If Device2Present
           If ReadDevice2 == True
             <something>
       ....
    
       IfDevice20Present
           If ReadDevice20 == True
              <something>
    
    
    



    But these layers of extra IFs add time to the loop and decreased reaction time to reading the present devices.

    To my understanding, either Case or IF requires similar time to look at every possible device state (to see if a variable was set to present or missing), meaning that you still have to allocate resources to ALL the possible connected devices, regardless of whether they are present or not. Your concept where the main program on boot checks for devices, and stores a value in an array of what is present or not is great, although in my case, I will have the 'user selected' devices get scanned on boot and a warning issued if the device(s) that should be detected are not.
  • jazzedjazzed Posts: 11,803
    edited 2009-05-25 21:32
    Specifying a set of devices helps to limit the scope of the problem ... so you're ahead of the game with that decision. A specification of what should be there as you mention can be helpful for debug. Having a "bootconfig" program that uses EEPROM or SDCARD files for persistent config information can be created pretty easily ... I've done it before. Hopefully the devices that "can be added later" are already known to your system. An open ended system is harder though doable as long as it doesn't outgrow your infrastructure. Any provision for updates or bug fixes can be appreciated. Are you using a PropOS or is your product completely embedded?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • T ChapT Chap Posts: 4,223
    edited 2009-05-25 23:28
    The devices are proprietary to the system (my own various boards), and the methods to incorporate or skip are specific to those devices (I2C and Serial). I have a system where the user can download an .eeprom revision, drop it onto a USB drive, if the file is a newer version than the current rev, it will copy the .eeprom to the boot eeprom, checksum it, reboot. I created what I call my own OS from scratch specific to the product. There is a spare eeprom that stores all prefs and are loaded on boot, so the user only sets up the devices present once, unless there is a change.
  • SSteveSSteve Posts: 808
    edited 2009-05-26 01:22
    Sorry this doesn't directly address your original request, but wouldn't this at least be a little faster?

    Repeat
       If Device1Present and ReadDevice1
             <something>
       If Device2Present and ReadDevice2
             <something>
       ....
    
       If Device20Present and ReadDevice20
              <something>
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    OS-X: because making Unix user-friendly was easier than debugging Windows

    links:
    My band's website
    Our album on the iTunes Music Store
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-05-26 06:11
    What does the interface to the devices look like? Does each device have it's own PASM driver?

    ReadDevice looks for me like you could possibly change the device driver to not wait for your SPIN-code call a read function to retrieve the value, but per default write the next value to a fixed buffer-adress. If the buffer of all the devices look the same (say it's one long for each device) that would be best. For each device that's physically present (or selected by the user) you use the next free long in an array of longs and you increase the number of devices. Then you only have a loop that iterates over all buffer-adresses to see if the driver put a value there. If the loop finds a value you need to branch to your <something> code with a case statement. The gain of speed in this case comes from looping over existing driver-buffers only and the lack of a ReadDevice code.
  • T ChapT Chap Posts: 4,223
    edited 2009-05-26 14:20
    That is a great suggestion mag. Probably not what you are saying precisely but here is what I take from it that will work fine;

    Con 
      Device1ID = 1
      Device2ID = 2
      '''Etc
    
    Byte addrbuf[noparse][[/noparse] 10 ]
    
    Pub init
        ''' Run user setup for first time,  or later for changes to set the address buffer values, store in eeprom2. 
    
       If devchk1 == yes
         Addrbuf[noparse][[/noparse] n ] := Device1ID
    
       If devchk2 == yes
        Addrbuf[noparse][[/noparse]n++ ] := Device2ID
    
      '''Do for all possible devices
    
    Pub devicepoll
        Repeat
          N := 0
          Repeat while addrbuf[noparse][[/noparse] n ] > 0
             Case addrbuf[noparse][[/noparse]n]
                    1 : readdevice1
                    2 : readdevice2
                    ''' Etc for all
             N++
    
    
    



    Oversimplified but the idea suggests that the repeat loop only spends time on devices that are present and not unneccessary IFs or Case statements querrying a list of variables.

    Thanks for the suggestions guys, very helpful!

    Post Edited (TChapman) : 5/26/2009 4:17:20 PM GMT
  • jazzedjazzed Posts: 11,803
    edited 2009-05-26 19:07
    Glad you found something you like. Looks like a nice approach for one feature. I suppose you will have other loops for all the other necessary device methods. Good luck with your project.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
Sign In or Register to comment.