+ Reply to Thread
Results 1 to 9 of 9

Thread: 7135 Developers

  1. #1
    Registered User bhil's Avatar
    Join Date
    11-02-2003
    Location
    Middle of Nowhere, Canada
    Posts
    107

    7135 Developers

    For all the developers out there:

    I am creating this thread to give developers (both new and experienced) a chance to ask questions, discuss ideas, post tips, etc.

    The hope is, that with adequate usage, we will be able to show that there is enough interest to turn the single thread into a new 'Developer' forum section of the board. This forum would become to developers what the rest of the SPS site is to regular users, filling the gaping void that currently exists for Kyocera developers looking for resources online.

    Some simple rules to start:

    1. Please keep the posts in the thread related to development topics.
    2. The thread is being created for both new and experienced developers, so if someone asks a question that as an experienced developer seems absurdly simple to you, remember that they may be a first time programmer. Please don't ridicule them. Help them along so that they can grow, and maybe return the favor at a later date.
    3. If you are going to post code, please either keep it to reasonably short chunks or attach it as a zipped file.
    4. Remember the license agreement you agreed to when you downloaded the SDK, and adhere to it.
    5. It may seem obvious, but please do not post copyrighted work unless it is your own, and you are willing to freely share it with everyone.

    More rules will be added as they come necessary, but for now, let the knowledge flow!

  2. #2
    Registered User bhil's Avatar
    Join Date
    11-02-2003
    Location
    Middle of Nowhere, Canada
    Posts
    107

    Basic Development Tools

    I am going to start the thread off with a couple of fairly common questions pertaining to 7135 development that I have come across:

    1. Does anyone know of a 7135 ROM for the Plam Emulator to aid in development/debugging?

    2. Does anyone know of any extensions to be the basic API that allow for a person to control the external LCD?

  3. #3
    Registered User bhil's Avatar
    Join Date
    11-02-2003
    Location
    Middle of Nowhere, Canada
    Posts
    107

    Recognizing the 7135

    Another common questions I have seen from people starting out is:
    How do I use the Kyocera recommended PDQCoreLibGetVersion to recognize the 7135?
    Here is the basic method I use:
    Code:
    UInt32 romVersion;
    UInt16 coreRefNum;
    Err err=0;
    err = SysLibFind(PDQCoreLibName,&coreRefNum);
    if (!err)
    {
      PDQCoreLibGetVersion(coreRefNum, &romVersion);
      romVersion = sysGetROMVerMajor(romVersion);
      if(romVersion != KWC7135Version1)
      {
        FrmAlert (RomIncompatibleAlert);
        return sysErrRomIncompatible;
      }
    }
    else
    {
      FrmAlert (RomIncompatibleAlert);
      return sysErrRomIncompatible;
    }
    return errNone;

  4. #4
    Fully Converged rlwhitt's Avatar
    Join Date
    11-05-2002
    Posts
    821

    Re: Basic Development Tools

    Great start bhil!

    1. This is one of the things that HandSpring is doing so much better than KYO. You can go to their site and download a Palm Simulator version that has all the HS special libraries in it. Of course attempting Dial does nothing (well, it crashes!), but at least you can see if you are accessing the correct API access points. I know it'd be hard to make a ROM that did anything useful since you could not actually make or get calls and SMS, but it'd be GREAT if the end of call signalling could be simulated - I find that to be one of the most challenging aspects of targeting the 6035/7135, since the signalling issues can be pretty complicated and all the testing is live.

    It would be possible of course to write a standalone simulator that could be set up to call a given creator id with specified signals and parameters. If I were starting out today with this sort of thing, I'd probably write such an animal, but would not be so motivated today. Perhaps we can leave that as an idea for some intrepid new explorer here to tackle? I might consider it if nobody else steps forward, for this kind of thing is certainly needed.

    2. There MUST be a way to do this from the Palm side, since the self test app does it. There's a thread that was posted last week about how to get this app to run, and it does indeed write text to the LCD. I doubt we'd ever get KYO to share that bit of info, but if anyone was sufficiently curious, it might be possible to search the ROM to see what library code is there that looks like might be responsible for this - but then you'd still have to divine how to use it.

    Both interesting topics!

    Originally posted by bhil
    I am going to start the thread off with a couple of fairly common questions pertaining to 7135 development that I have come across:

    1. Does anyone know of a 7135 ROM for the Plam Emulator to aid in development/debugging?

    2. Does anyone know of any extensions to be the basic API that allow for a person to control the external LCD?

  5. #5
    Fully Converged rlwhitt's Avatar
    Join Date
    11-05-2002
    Posts
    821
    Another way to identify what device you are running on, in case you need to write an app that runs on more than one brand of device (KYO, Handspring, Samsung, etc) is to use the FtrGet() function to get the manufacturer and model number codes. Each Palm OS licensee is required to return a unique number for both of these values. There is a handy table here that appears to be pretty current and complete:

    http://www.mobilegeographics.com/dev/devices.php

    An example snippet to identify KYO models:

    Code:
    UInt32 companyID, deviceID;
    Err err;
    Boolean isKYO = false;
    Boolean is7135 = false;
    
    err = FtrGet(sysFtrCreator, sysFtrNumOEMCompanyID,
                        &companyID);
    if (! err) {
      if (companyID == 'qcom' ||  companyID == 'kwc.') {
        // it's some sort of phone we're interested in
        isKYO = true;
        err = FtrGet(sysFtrCreator, sysFtrNumOEMDeviceID,
                            &deviceID);
        if (! err && deviceID == '7135')
          is7135 = true;    
      }
    }
    Obviously, you can make this test as complete as you need it to identify all the different devices you need to work with.

    If you're not (yet) familiar with C code, one thing that may look odd above are things like 'qcom' and '7135'. These are NOT strings as the would be the case in many languages, but are integers. In this case 4 byte integers. Some things (notably Creator IDs) in Palm programming look like this, so it's something to be familiar with.

    One word of warning on both the methods given so far to identifty devices. Neither will work for you if you testing on POSE (the Emulator). So, you'd have to "fake" it if you need to get past the test.

  6. #6
    Registered User bhil's Avatar
    Join Date
    11-02-2003
    Location
    Middle of Nowhere, Canada
    Posts
    107
    Originally posted by rlwhitt
    If you're not (yet) familiar with C code, one thing that may look odd above are things like 'qcom' and '7135'. These are NOT strings as the would be the case in many languages, but are integers. In this case 4 byte integers. Some things (notably Creator IDs) in Palm programming look like this, so it's something to be familiar with.
    Excellent tip! I knew about using the FtrGet function to determine the device, and had used them, but my C is pretty rusty (I've been doing Java for the last 5 years), so when I saw the quoted words, my mind immediately thought of them as strings. You can compare the results as strings (I did it) but it is nowhere near as clean and efficient of a solution as what you show. There are definitely going to be a few people that benefit from this.
    :clap

  7. #7
    Registered User bhil's Avatar
    Join Date
    11-02-2003
    Location
    Middle of Nowhere, Canada
    Posts
    107
    Well, here's Kyocera's official response to the LCD API, and ROM availablility:


    Thank you for contacting Kyocera Wireless. I understand that you are looking for SDK information on your Kyocera 7135 SmartPhone.

    There are currently no plans to release a newer version of the SDK for the 7135 SmartPhone.

    Due to contractual restrictions of the included copyrighted programs, the ROM image of the 7135 SmartPhone cannot be made availble.


    I guess we are on our own.

  8. #8
    Registered User
    Join Date
    08-27-2003
    Posts
    150

    Re: Re: Basic Development Tools

    Originally posted by rlwhitt
    ... It would be possible of course to write a standalone simulator that could be set up to call a given creator id with specified signals and parameters. If I were starting out today with this sort of thing, I'd probably write such an animal, but would not be so motivated today. Perhaps we can leave that as an idea for some intrepid new explorer here to tackle? I might consider it if nobody else steps forward, for this kind of thing is certainly needed. ...
    Well, I'm already halfway there. I wrote such an when I began developing Bebopper but never put together a generic interface to select which signal and which application. The current version only sends a single signal and is recompiled whenever I change what I'm testing.

  9. #9
    Fully Converged rlwhitt's Avatar
    Join Date
    11-05-2002
    Posts
    821

    Re: Re: Re: Basic Development Tools

    Just in case anyone wants to bite, to be really slick, this would:

    1. Be able to input creator ID - in letter form.
    2. PickList of possible signals
    3. Once a signal is selected, be able to enter values for the various components of the data strcture that will be sent.
    4. Be able to save all this as an instance record in a database to be able to edit/replay later. Since many things that happen (during the course of a call, for example) happen in sequences of several events (phone mode changes, call begin, call end, etc), it would be quite handy to be able to quickly call them all up without having to re-enter everything.

    Originally posted by PalmNut
    Well, I'm already halfway there. I wrote such an when I began developing Bebopper but never put together a generic interface to select which signal and which application. The current version only sends a single signal and is recompiled whenever I change what I'm testing.

Posting Permissions

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