Skip to main content

Volunteer needed to port phoneME Advanced to Garnet OS / Palm OS 5.x

198 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hinkmond,
> Is pMEF's Green Thread model efficient enough for pMEA? I remember that I asked similiar question in J1. I don't know how many native functions has to be rewritten if adpot pMEF Green Thread, since there'll be no blocking native function supporting, but use SNI instead.
>
> BTW, does anyone knows other threading libraries available on PalmOS?
>

Hi Max,

I'm not that familiar with pMEF's Green Thread model. It might not be
enough, because pMEA (CDC) expects to map to native threads and
integrate with a system OS thread scheduler.

You might have to investigate future. But, as mentioned in Eric's
thread, the GNU Pth looks promising.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Hinkmond,
Yes, GNU Pth looks cool. But still have questions:
First, it depends on ANSI C. Here's a list of its required ANSI C header files:
/* mandatory system headers */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

Besides this, Pth is a non-preemptive Pthread implementation, I don't know if such a cooperative threading library can meet pMEA's requirement?

M@x

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hinkmond,
> Yes, GNU Pth looks cool. But still have questions:
> First, it depends on ANSI C. Here's a list of its required ANSI C header files:
> /* mandatory system headers */
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> Besides this, Pth is a non-preemptive Pthread implementation, I don't know if such a cooperative threading library can meet pMEA's requirement?
>

Ack! GNU Pth doesn't look that great with all those ANSI C dependencies
and no preemption. Maybe FC's suggestion of the Mobile Stream’s DevZone
web site SDK would be better?

http://tamspalm.tamoggemon.com/2007/03/14/mobile-stream-releases-updated...

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Hinkmond,
This SDK supports some unofficial APIs, but still very limited, only thread create/delay/delete are available. And I didn't find any synchronizing functions (e.g mutex).

M@x

ebresie
Offline
Joined: 2003-08-06
Points: 0

Just curious...are there other platforms that could benefit from implementation of a Green thread implementation?

From another perspective and I have not looked at their code much, but would anything from the OpenJDK be useful for this?

Might be worth looking into some of the related thread products as well (see http://www.gnu.org/software/pth/related.html )

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Just curious...are there other platforms that could benefit from implementation of a Green thread implementation?
>
> From another perspective and I have not looked at their code much, but would anything from the OpenJDK be useful for this?
>
> Might be worth looking into some of the related thread products as well (see http://www.gnu.org/software/pth/related.html )
>

Hi Eric,

I'm not sure it would be a huge benefit. Most mobile platforms for CDC,
such as embedded Linux, Windows Mobile, etc. have multithreading support.

I'm not that familiar with the latest OpenJDK use of Green threads, but
believe they use the term "Green threads" to mean something else.

The GNU Pth looks interesting though. That might be your best bet if
someone volunteers to investigate further.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

jslee06
Offline
Joined: 2008-06-21
Points: 0

"Pth is a very portable POSIX/ANSI-C based library for Unix platforms which provides non-preemptive priority-based scheduling for multiple threads of execution (aka ``multithreading'') inside event-driven applications. All threads run in the same address space of the server application, but each thread has it's own individual program-counter, run-time stack, signal mask and errno variable."

http://www.gnu.org/software/pth/

max_mu
Offline
Joined: 2006-11-15
Points: 0

I looks no official threading APIs of Palm OS 5 at all? I found some information that says multithreading is supported from Palm OS 5 Garnet, but no any threading APIs appear in documents. I've been searched on Palm's developer forum, but result is more discouraged:

http://www.mail-archive.com/palm-dev-forum@news.palmos.com/msg99314.html

Generally say, officially, multithreading is possible but undocumented and unsupported.
Please correct me if I'm wrong.

M@x

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I looks no official threading APIs of Palm OS 5 at all? I found some information that says multithreading is supported from Palm OS 5 Garnet, but no any threading APIs appear in documents. I've been searched on Palm's developer forum, but result is more discouraged:
>
> http://www.mail-archive.com/palm-dev-forum@news.palmos.com/msg99314.html
>
> Generally say, officially, multithreading is possible but undocumented and unsupported.
> Please correct me if I'm wrong.
>

If this is the case, this is a pretty big hurdle to get over in order to
port just the basic core of pMEA to PalmOS. Are you willing to create a
Green threads implementation (thread emulation in Java) for this
project? It won't be easy to do that and I don't know of any good
references for you to follow if you wanted to do that, but it seems like
it's the only choice now unless others on this list can suggest
something easier for the no official support of threads in PalmOS.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Terrence Barr - Senior Technologist and Ambassador

Or use phoneME Feature, which requires no threading support ...
if that is an option.

-- Terrence

Hinkmond Wong wrote:
> phonemeadvanced@mobileandembedded.org wrote:
>> I looks no official threading APIs of Palm OS 5 at all? I found some
>> information that says multithreading is supported from Palm OS 5
>> Garnet, but no any threading APIs appear in documents. I've been
>> searched on Palm's developer forum, but result is more discouraged:
>>
>> http://www.mail-archive.com/palm-dev-forum@news.palmos.com/msg99314.html
>>
>> Generally say, officially, multithreading is possible but undocumented
>> and unsupported.
>> Please correct me if I'm wrong.
>>
>
> If this is the case, this is a pretty big hurdle to get over in order to
> port just the basic core of pMEA to PalmOS. Are you willing to create a
> Green threads implementation (thread emulation in Java) for this
> project? It won't be easy to do that and I don't know of any good
> references for you to follow if you wanted to do that, but it seems like
> it's the only choice now unless others on this list can suggest
> something easier for the no official support of threads in PalmOS.
>
>
> Hinkmond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

--
Terrence Barr
Senior Technologist and Community Ambassador
Java Mobile & Embedded Community

Phone: +49 711 720 98185
Yahoo: terrencebarr, AIM: terrencebarr123
http://www.mobileandembedded.org
http://www.sun.com

Registered Office:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
[terrence_barr.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Hinkmond Wong

Terrence Barr - Senior Technologist and Ambassador wrote:
> Or use phoneME Feature, which requires no threading support ...
> if that is an option.

Good point. It's a whole different ball of wax, but another option. If
anyone is interested, this would have to go to our other forum group
(feature@phoneme.dev.java.net) with a separate thread.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

> Terrence Barr - Senior Technologist and Ambassador
> wrote:
> > Or use phoneME Feature, which requires no threading support ...
> > if that is an option.
>
> Good point. It's a whole different ball of wax, but another option. If
> anyone is interested, this would have to go to our other forum group
> (feature@phoneme.dev.java.net) with a separate thread.
>
> Hinkmond

I don't suppose anyone pursued porting Palm to phoneME Feature yet?

I've continued to try working to get pth ported to provide pthread capabilities, but there is a steep learning curve for Palm OS development, for Palm OS Library development, and just plane pthread learning curve. And time is in short supply regretfully..

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
>> Terrence Barr - Senior Technologist and Ambassador
>> wrote:
>>
>>> Or use phoneME Feature, which requires no threading support ...
>>> if that is an option.
>>>
>> Good point. It's a whole different ball of wax, but another option. If
>> anyone is interested, this would have to go to our other forum group
>> (feature@phoneme.dev.java.net) with a separate thread.
>>
>> Hinkmond
>>
>
> I don't suppose anyone pursued porting Palm to phoneME Feature yet?
>

Funnily enough, there's a current forum thread that just became active
again on that topic with Mauricio making some progress:

http://forums.java.net/jive/thread.jspa?messageID=300889&tstart=0

You might want to check with him on that forum thread.

Hinkmond

> I've continued to try working to get pth ported to provide pthread capabilities, but there is a steep learning curve for Palm OS development, for Palm OS Library development, and just plane pthread learning curve. And time is in short supply regretfully..
>
> Eric
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Hi Hinkmond,
What do you think if we give up porting on top of ANSI & POSIX layer, but port base on lower level PalmOS APIs instead? It seems that PalmSDK has only very limited ANSI & POSIX support, even FILE IO is not implemented.
Regarding to pthread, I don't think we can make it by rebuilding from arm-linux's GNU toolchain, because this pthread now has become a part of GNU C runtime and tightly bound to Linux/Unix OS, it'll be very hard to port to PalmOS. I think we have to decide now if we need to port Pthread or use PalmOS threading machanism.
What Pthread functions will be required for basic HelloWorld running? Porting basic functions like thread creating/stopping is not very hard. We can do a very limited Pthread porting at first, if needed, and make HelloWorld work without filesystem and much threading implementations.

M@x

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi Hinkmond,
> What do you think if we give up porting on top of ANSI & POSIX layer, but port base on lower level PalmOS APIs instead? It seems that PalmSDK has only very limited ANSI & POSIX support, even FILE IO is not implemented.
> Regarding to pthread, I don't think we can make it by rebuilding from arm-linux's GNU toolchain, because this pthread now has become a part of GNU C runtime and tightly bound to Linux/Unix OS, it'll be very hard to port to PalmOS. I think we have to decide now if we need to port Pthread or use PalmOS threading machanism.
> What Pthread functions will be required for basic HelloWorld running? Porting basic functions like thread creating/stopping is not very hard. We can do a very limited Pthread porting at first, if needed, and make HelloWorld work without filesystem and much threading implementations.
>

Hi Max,

Yes, after seeing the link that Eric gave:

http://dogbert.mse.cs.cmu.edu/charlatans/References/Tech_Doc/Palm_FAQ/ar...

it looks like using our already existing ANSI and POSIX porting layers
in pMEA to hook into PalmOS is harder than expected. No stdio and
pthreads is one thing (we could work around that), but no float.h, and
no File I/O makes a bad situation even worse since it compounds the need
for workarounds into many areas instead of just two. Ack!

HelloWorld might work OK without pthreads since I can imagine you trying
to hook into the PalmOS threading for now (using their basic
create/stop/etc as you pointed out). That would be a good experiment if
you could try that and report back how it works.

I say go ahead and try that along with using unix_stdio.h or StdIOPalm.h
instead of stdio.h and let us know how that goes. (Unfortunately, after
seeing the URL above that Eric found, it seems like there will be
several other missing *.h (such as errno.h, signal.h, etc.) files that
will prevent a good build that could run).

Let us know what you find out.

Thanks,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Hi Hinkmond,
Yes, I'm trying to port basic threading functions like create/stop, and will update once I got something. Just in case, however, I wanna know if anyone else is working on ANSI C workaround (i.e mapping headers)? I guess Eric may have got good progress on this, I don't wanna duplicate works if someone is working on same thing.

M@x

fcassia_at_gmail
Offline
Joined: 2004-10-11
Points: 0

See here:
ANSI C Standard Library for PocketC on the PalmOS
http://www.orbworks.com/pcpalm/resources.html

I wonder if this would be reusable for you guys:

Reusable Source Code

This is code specifically designed to be used within other applets.

Name Description Author
pclib the ANSI C Standard Library for PocketC on the PalmOS (or as close to it as is humanly possible). Thad Frogley

FC

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure if it's worth it at this point but found another possible ANSI C library that could potentially be ported.

Checkout: http://sourceware.org/newlib/

Eric

fcassia_at_gmail
Offline
Joined: 2004-10-11
Points: 0

Here's another one:

http://slawa.homeip.net/books/start.php/Palm/PalmOSCompanion/StandardIOA...

-----------------------------------------------------------------------------------------------------------------------------
Standard IO Applications

Palm OS® Programmer's Companion

Volume I

16 Standard IO Applications
Creating a Standard IO Application
Creating a Standard IO Provider Application
Summary of Standard IO

The Palm OS® supports command line (UNIX style) applications for debugging and special purposes such as communications utilities. This capability is not intended for general users, but for developers. This feature is not implemented in the Palm OS, but rather by additional C modules that you must link with your application.
NOTE: Don't confuse this standard IO functionality with the file streaming API. They are unrelated.

There are two parts necessary for a standard IO application:

* The standard IO application itself.

A standard IO application is not like a normal Palmâ„¢ application. It is executed by a command line and has minimal user interface. It can take character input from the stdin device (the keyboard) and write character output to the stdout window.
* The standard IO provider application.

A standard IO provider application is necessary to execute and see output from a standard IO application. The standard IO provider application is a normal Palm application that provides a field in which you can enter commands to execute standard IO applications. The field also serves as a stdout window where output from the executing application is written.

The details of creating these two different applications are described in the following sections.
Creating a Standard IO Application ^TOP^

To create a standard IO application, you must include the header file StdIOPalm.h. In addition to including this header, you must link the application with the module StdIOPalm.c. This module provides a PilotMain routine that extracts the command line arguments from the cmd and cmdPBP parameters and the glue code necessary for executing the appropriate callbacks supplied by the standard IO provider application.

You build the application normally, but give it a database type of sioDBType ('sdio') instead of 'appl'. In addition, it must be named "Cmd-cmdname" where cmdname is the name of the command used to execute the application. For example, the ping command would be placed in a database named "Cmd-ping".

In the Palm VIIâ„¢ handheld, the Network panel, whose log window is a standard IO provider application, has two standard IO commands built-in: info and finger. The ROM has two additional ones: ping and nettrace.

When compiling for the Palm Poweredâ„¢ handheld, the entry point must be named SioMain and must accept two parameters: argc and argv. Here's the simplest possible example of a standard IO application.

#include
Int16 SioMain(UInt16 argc, Char* argv[ ])
{
printf("Hello World\n");
}

Standard IO applications can use several input and output functions that mimic their similarly named UNIX counterparts. These are listed in the summary table at the end of this chapter.

Your standard IO application can accept input from stdin and write output to stdout. The stdin device corresponds to the text field in the standard IO provider application that is used for input and output. The stdout device corresponds to that same text field.
-----------------------------------------------------------------------------------------------------------------------------

FC

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Here's another one:
>
> http://slawa.homeip.net/books/start.php/Palm/PalmOSCompanion/StandardIOA...
>
> ...
> #include
> Int16 SioMain(UInt16 argc, Char* argv[ ])
> {
> printf("Hello World\n");
> }
>
>
> Standard IO applications can use several input and output functions that mimic their similarly named UNIX counterparts. These are listed in the summary table at the end of this chapter.
>
> Your standard IO application can accept input from stdin and write output to stdout. The stdin device corresponds to the text field in the standard IO provider application that is used for input and output. The stdout device corresponds to that same text field.
>

Thanks, FC! Good stuff! Eric, is there a way you can wrap SioMain()
around a normal main() (to make it invisible for our case on PalmOS, but
still work under their guidelines for StdIOPalm)?

Ex.

#include
Int16 SioMain(UInt16 argc, Char* argv[ ])
{
main(argc, argv);
}

static main(int argc, char* args[]) {
printf("Hello World\n");
// Our CVM_Main stuff will stay here...
}

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

As I am still trying to weary the innards of Palm Development, this has been a long time coming...

After finding an old version of StdIOPalm.c (I am trying to find something newer), I was able to build a basic Palm HelloWorld program (no VM built yet), which runs under the Preferences...Network...Option...View Log hidden terminal. This makes use of an SioMain based main.

I made a very basic port layer (a #define for main, int, and _int in place of SioMain, Int16, and UInt16, which may help minimize some of the porting.

So this turned into:

#include
/* The following is a quick port layer to translate from basic
*
* int main(int argc, char* argv)
*
* to equivalent Palm version
*
* Int16 SioMain(UInt16 argc, const Char* argv[])
*
* which uses SioMain.
*
* Since Palm version uses both UInt16 and Int16 instead of just int, I
* cludge together something with the assumption that _int is the Int16 as opposed
* to int which is the UInt16 version.
*
* This could be done better but it's a start.
* */
#define main(x, y) SioMain(x, y)
#define int UInt16
#define _int Int16
#define char const Char

_int main(int argc, char* argv[ ])
{
printf("Hello World\n");
return 0;
}

This may not seem like much, but at least I'm making some progress for my basic Palm development learning requirements.

On the thread front...

I almost have pth compiling and building for use with Palm, but to work with Palm version, still need to develop an additional inbetween layer.

Palm shared libraries require implementation of a open, close, sleep, and wake method used in Palm development, which allocates and frees memory using the Palms methods. The pth library specific stuff will also be used.

Next stop...making a sharable library using pth as the basics with a Palm shared library layer between it. Also make a basic test program to use the Palm pth as a test, then...port the phoneME thread portion..

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> As I am still trying to weary the innards of Palm Development, this has been a long time coming...
> ...
> Next stop...making a sharable library using pth as the basics with a Palm shared library layer between it. Also make a basic test program to use the Palm pth as a test, then...port the phoneME thread portion..
>

Hi Eric,

Good to hear you are making some progress. Hope you will be able to
work with pth OK. Please keep us in the loop and let us know if you run
into any problems we can try to help with...

Thanks,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

jslee06
Offline
Joined: 2008-06-21
Points: 0

I made a mistake relocating my arm-palmos files. prc-tools-arm rpm installs everything in
/usr/arm-palmos/ I'm kinda confused as to the relationship between prc-tools-arm .h files, the PalmOS SDK, and the missing glibc .h files for compiling the cvm target palmos-arm. Doesn't the palmos-arm compiler use only the C libraries that came with it and the PalmOS SDK? If that is the case and the PalmOS C programming functions do not include all ANSI C, we'd have to invent versions of the missing files if they need to be hooked into the PalmOS Native C functions.

CDC target operating system requirements from the Porting Guide section 2.1.2

â– Memory management.
â– Uniform address space (not segmented).
â– UNIX-like memory allocation functions.
â– ANSI Standard I/O.
â– POSIX thread management.
â– Easily ported to a POSIX thread library.
â– Alternate fast locking implementations available.
■Don’t need separate processes.
■Don’t need a large C stack per thread.
â– Monitor based.
â– Berkeley sockets.

- Jay (who has to learn the source, let alone use it)

ebresie
Offline
Joined: 2003-08-06
Points: 0

From "Palm OS Companion"

"IMPORTANT: The ANSI C libraries are not part of the Palm development platform. In many cases, you can perform the same function using a Palm OS API call as you can with a call to a ANSI C function. For example, the Palm OS provides a string manager that performs many of the string functions you’d expect to be able to perform in an ANSI C program. If you do use a standard C function, the code for the function is linked into your application and results in a bigger executable."

So to me this sounds as though even the missing stuff is possible, but it won't be the PalmOS optimized versions.

Looking some more, I noticed in cygwin that at /usr/include, I have the supposedly missing pthread.h and semaphore.h. This leads me to believe that for some reason the compiler is not seeing the necessary header files found here. Not being a gcc expert, how is the correct way for header "paths" to be specified?

Or is there an include _INCLUDE_PATH type variable that I need to include this in to specify the /usr/include is to be used? I thought I remember there being a gcc switch setting (like -I) that would allow this to be specified, but I'm not sure how to get this added properly. Anyone?

Eric

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> From "Palm OS Companion"
>
> "IMPORTANT: The ANSI C libraries are not part of the Palm development platform. In many cases, you can perform the same function using a Palm OS API call as you can with a call to a ANSI C function. For example, the Palm OS provides a string manager that performs many of the string functions you’d expect to be able to perform in an ANSI C program. If you do use a standard C function, the code for the function is linked into your application and results in a bigger executable."
>
> So to me this sounds as though even the missing stuff is possible, but it won't be the PalmOS optimized versions.
>
> Looking some more, I noticed in cygwin that at /usr/include, I have the supposedly missing pthread.h and semaphore.h. This leads me to believe that for some reason the compiler is not seeing the necessary header files found here. Not being a gcc expert, how is the correct way for header "paths" to be specified?
>
> Or is there an include _INCLUDE_PATH type variable that I need to include this in to specify the /usr/include is to be used? I thought I remember there being a gcc switch setting (like -I) that would allow this to be specified, but I'm not sure how to get this added properly. Anyone?
>

You have to be careful that you don't mix-up your host system
development tools with your target system development tools.

If you want to build a cygwin/x86 binary, then yes /usr/include is where
you would look since that is where *.h files are for building a
cygwin/x86 binary (for your host system). However, if you are using a
cross-compiler (to build on your host system for palmos/ARM for
instance), then there is a completely separate include subdir that is
used for just cross-compiling (such as /usr/local/palmos-arm/include,
this is just an example, I have no idea where it really goes). Your
cross-compiling tool (such as palmos-arm-gcc) is configured to look and
pull in by default *.h files only from your target area (such as
/usr/local/palmos-arm/include), not your host include area. Also, your
cross-linker will look for libraries in a place like
/usr/local/palmos-arm/lib. The cross-tools themselves like gcc and ld
are usually located in the toplevel location for that cross-tool like in
/usr/local/palmos-arm/bin.

So, looking in /usr/include is not what you want to do if you are
looking for include files that is used by your cross-compiler. Try
doing a "which palmos-gcc" command or whatever your cross-compiler gcc
is called to locate the bin of the cross-compiler, then go up and over
into the include directory. That should be where the cross-tool include
files are.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

jslee06
Offline
Joined: 2008-06-21
Points: 0

I found pthread.h in /usr/include which identifies itself as GNU C Library (glibc). I also found it in my crosstool builds /opt/crosstool/gcc-3.4.5-glibc-2.3.6/arm-xscale-linux-gnu/arm-xscale-linux-gnu/include/pthread.h

I was able to build linux-arm-generic with my crosstool derived arm-xscale compiler. I'm guessing I need to recompile the GNU C library for palmos-arm to go in /opt/palmos-arm/include and /opt/palmos-arm/lib...?

I think the unix/linux builds are misleading though. Garnet is only multithreaded for system programs and not applications so it doesn't look like genuine POSIX threads like in Linux is possible if the cvm has to be installed as an application. Judging by the behavior of the Websphere and Superwaba, it would have to run as an application and then sublaunch the midlets.

Can we map out Foundation Profile, version 1.1.2 to each java source file we need to go through and interface with whatever palmos functions then check them off as they are complete? Or can we cut requirements from the mk files so that the uncompliant Foundation Profile will only need the minimum necessary to run Hello World?

Foundation Profile, version 1.1.2

http://java.sun.com/javame/reference/apis/jsr219/

I haven't spend much time reading the CDC Porting Guide so my questions may seem redundant.

- Jay

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I found pthread.h in /usr/include which identifies itself as GNU C Library (glibc). I also found it in my crosstool builds /opt/crosstool/gcc-3.4.5-glibc-2.3.6/arm-xscale-linux-gnu/arm-xscale-linux-gnu/include/pthread.h
>
> I was able to build linux-arm-generic with my crosstool derived arm-xscale compiler. I'm guessing I need to recompile the GNU C library for palmos-arm to go in /opt/palmos-arm/include and /opt/palmos-arm/lib...?
>
> I think the unix/linux builds are misleading though. Garnet is only multithreaded for system programs and not applications so it doesn't look like genuine POSIX threads like in Linux is possible if the cvm has to be installed as an application. Judging by the behavior of the Websphere and Superwaba, it would have to run as an application and then sublaunch the midlets.
>
> Can we map out Foundation Profile, version 1.1.2 to each java source file we need to go through and interface with whatever palmos functions then check them off as they are complete? Or can we cut requirements from the mk files so that the uncompliant Foundation Profile will only need the minimum necessary to run Hello World?
>
> Foundation Profile, version 1.1.2
>
> http://java.sun.com/javame/reference/apis/jsr219/
>
> I haven't spend much time reading the CDC Porting Guide so my questions may seem redundant.
>

Hi Jay,

This is good info you found about crosstool. It doesn't look that great
that Garnet is not genuine POSIX threads, though. The problem with
dropping things out of the Makefiles is that it probably won't build if
you do that (too many interdependencies).

Do you know if you recompile the GNU C library for palmos-arm if that is
supposed to work or not? I thought I saw references on the Web that
side it won't work, since PalmOS cannot support everything that glibc
can do.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

If we find Palm equivalent header files, where do these changes go?

Which files need to be changed? In a makefile? defs_md.h? Do I search for every instance of stdio.h in every .c (and/or .h) and replace it with the palm equivalent?

There is a #define CVM_HDR_ANSI_STDIO_H that I find in the defs_md.h file which I suspect might be another candidate for changing.

I think as far as the stdio.h equivalent, there is the StdIOPalm.h or the unix_stdio.h that may be usable, but not sure where to do so?

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> If we find Palm equivalent header files, where do these changes go?
>
> Which files need to be changed? In a makefile? defs_md.h? Do I search for every instance of stdio.h in every .c (and/or .h) and replace it with the palm equivalent?
>
> There is a #define CVM_HDR_ANSI_STDIO_H that I find in the defs_md.h file which I suspect might be another candidate for changing.
>

This looks right to me, but Dean would have to confirm. Dean can Eric
use CVM_HDR_ANSI_STDIO_H to change the name of stdio.h everywhere for
the CVM?

> I think as far as the stdio.h equivalent, there is the StdIOPalm.h or the unix_stdio.h that may be usable, but not sure where to do so?
>

I think Dean might be able to best suggest what to do here also, if a
global replace in all the VM source code would be the better approach.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

xyzzy (Dean)

Hinkmond Wong wrote:
> phonemeadvanced@mobileandembedded.org wrote:
>> If we find Palm equivalent header files, where do these changes go?
>> Which files need to be changed? In a makefile? defs_md.h? Do I
>> search for every instance of stdio.h in every .c (and/or .h) and
>> replace it with the palm equivalent?
>>
>> There is a #define CVM_HDR_ANSI_STDIO_H that I find in the defs_md.h
>> file which I suspect might be another candidate for changing.
>>
>
> This looks right to me, but Dean would have to confirm. Dean can Eric
> use CVM_HDR_ANSI_STDIO_H to change the name of stdio.h everywhere for
> the CVM?

Sure.

>> I think as far as the stdio.h equivalent, there is the StdIOPalm.h or
>> the unix_stdio.h that may be usable, but not sure where to do so?
>
> I think Dean might be able to best suggest what to do here also, if a
> global replace in all the VM source code would be the better approach.
>

Yes, you can set CVM_HDR_ANSI_STDIO_H to one of those, but if something is
missing, it is better to use something like stdio_md.h that provides
the necessary features. For example, see the Symbian port.

dl

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

d_bleyl
Offline
Joined: 2003-07-15
Points: 0

The tapper-ware.net link is an awesome find! I hadn't heard about PEAL or PARM.

Here's a link to the Pila assembler tools:

http://www.schaeckermann.net/pila-user-manual.html

I'm not sure how much assembler is required for this project, hopefully little to none, but just in case.

Thanks!

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> The tapper-ware.net link is an awesome find! I hadn't heard about PEAL or PARM.
>
> Here's a link to the Pila assembler tools:
>
> http://www.schaeckermann.net/pila-user-manual.html
>
> I'm not sure how much assembler is required for this project, hopefully little to none, but just in case.
>

Thanks for all the good links. Remember, before jumping to thinking
about virtualization, graphics, or asking for PalmOS specific help, all
we want to do is build a simple headless Java VM that can do a simple
System.out.println("Hello World") in Java. That's it. It's difficult
enough in itself.

If you guys loose focus on that, you'll loose site of where we are right
now.

Eric, did you get a clean build yet? Did you find a *.h file location
for POSIX threads?

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

I haven't found any POSIX Thread porting on palmos so far, but Pthreads-w32 might be a alternative starting point. It's not hard to port, I had ported this to various platforms, such as OS20 and PSP.

http://sourceware.org/pthreads-win32/

Just 2 cents,
M@x

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure if this will be of any use, but found more info on the wxWidget port for Palm:

http://wiki.wxwidgets.org/Development:_wxPalm

And an interesting article on porting DLLs to Palm OS (slightly dated, but might be worth looking at):

http://www.ibm.com/developerworks/library/wi-palmdll/index.html?S_TACT=1...

jslee06
Offline
Joined: 2008-06-21
Points: 0

How to Port phoneME Advanced Software to Google Android, iPhone, OpenMoko, LiMO, and More

http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6304.pdf

jslee06
Offline
Joined: 2008-06-21
Points: 0

They added the slides and audio to the Hinkmond porting presentation.

http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-63...

ebresie
Offline
Joined: 2003-08-06
Points: 0

I finally found a little more on having a "Console" type application.

Check out: http://palmos.combee.net/blog/HiddenIOConsole.html

The sort answer (not really possible) is there appears to be a couple of relavnet Palm header file (StdIOPalm.h and StdIOPalmProvider.h) which allows some basic stdio.h type of handling.

Found an example of StdIOPalmProvider.c but still a little confusing to me at the moment. You can find this at: http://www.koders.com/c/fid6756F8DAD977813D8AFF9E7577DB31C851A63FE7.aspx...

The provider is basically an primative application that executes the commands and provides input and output to the "console" application. You have to make the database a sdio type instead of an app. You have to name it Cmd-.

There is also a Unix/unix_stdio.h we may want to investigate.

I still haven't been able to get this working yet, but figured I would post for others to learn as we go.

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I finally found a little more on having a "Console" type application.
>
> Check out: http://palmos.combee.net/blog/HiddenIOConsole.html
>
> The sort answer (not really possible) is there appears to be a couple of relavnet Palm header file (StdIOPalm.h and StdIOPalmProvider.h) which allows some basic stdio.h type of handling.
>
> Found an example of StdIOPalmProvider.c but still a little confusing to me at the moment. You can find this at: http://www.koders.com/c/fid6756F8DAD977813D8AFF9E7577DB31C851A63FE7.aspx...
>
> The provider is basically an primative application that executes the commands and provides input and output to the "console" application. You have to make the database a sdio type instead of an app. You have to name it Cmd-.
>
> There is also a Unix/unix_stdio.h we may want to investigate.
>

Yikes! This is going to be more complicated than I thought.

Let me ask anyone who knows PalmOS or ask you guys to forward this to a
PalmOS developer forum: If you wanted to write a simple C program (no
Java at all) that only did printf("Hello world!"); How would you
program that, compile it, and link it (how would you include stdio.h,
etc, etc)? And then, how would you run it (to actually see the text,
"Hello world!" display on your screen of your device)?

If you can find the answer to those questions, then we can treat the
Java VM as just another non-GUI PalmOS C program that you run from a
command line on your PalmOS device.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure if anything will come from it, but I posted on one of the news groups. See:

http://groups.google.com/group/comp.sys.palmtops/browse_thread/thread/e0...

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Not sure if anything will come from it, but I posted on one of the news groups. See:
>
> http://groups.google.com/group/comp.sys.palmtops/browse_thread/thread/e0...
>
>
Thanks, Eric! That was well worded.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

They provided a potentially helpful link. Check out:

http://dogbert.mse.cs.cmu.edu/charlatans/References/Tech_Doc/Palm_FAQ/ar...

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> They provided a potentially helpful link. Check out:
>
> http://dogbert.mse.cs.cmu.edu/charlatans/References/Tech_Doc/Palm_FAQ/ar...
>

Hi Eric,

Thanks for the link. That's a good reference for our purpose. Ack!
This is not going to be easy. Let's move over to Max's mail thread...

See:
http://forums.java.net/jive/thread.jspa?messageID=284100

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

I finally found a little more on having a "Console" type application.

Check out: http://palmos.combee.net/blog/HiddenIOConsole.html

The sort answer (not really possible) is there appears to be a couple of relavnet Palm header file (StdIOPalm.h and StdIOPalmProvider.h) which allows some basic stdio.h type of handling.

Found an example of StdIOPalmProvider.c but still a little confusing to me at the moment. You can find this at: http://www.koders.com/c/fid6756F8DAD977813D8AFF9E7577DB31C851A63FE7.aspx...

The provider is basically an primative application that executes the commands and provides input and output to the "console" application. You have to make the database a sdio type instead of an app. You have to name it Cmd-.

There is also a Unix/unix_stdio.h we may want to investigate.

I still haven't been able to get this working yet, but figured I would post for others to learn as we go.

Eric

ebresie
Offline
Joined: 2003-08-06
Points: 0

Minor update...On one of my machines, I was able to build and run the tests successfully for the VC8 version. I have updated the status page.

bsarkar
Offline
Joined: 2006-09-18
Points: 0

Hi Hinkmond!

I've installed the prc-tools under cygwin.

As for sdk, which one(s) should I download? The Access Developer Network (ADN) site lists several Access SDKs and Tools.

Biswajit

ebresie
Offline
Joined: 2003-08-06
Points: 0

You can get the Eclipse based development suite, called the Garnet OS Development Suite, that Access has which includes a version of the Palm SDK (I believe they include a version 5.4 version of the SDK).

There is a newer versions of the SDK/Headers at pdn.palm.com (which supports the new Centros). They also have a developers guide that you may want to get there to get some additional help on Palm development.

You will probably want to install the SDK in a /palmdev directory and/or mount whereever you installed it to the /palmdev.

Since you have installed cygwin, if you decide to make use of GODS, then you will need to do a custom installed and indicate you don't want to install the version included with the suite. They include an older version of cygwin.

After installing that, from within Cygwin, you will need to make sure and run palmprep which will set the default version of the gcc for the version included with the SDK you just installed.

Hope this is a good start for you.

Eric

bsarkar
Offline
Joined: 2006-09-18
Points: 0

> You can get the Eclipse based development suite,
> called the Garnet OS Development Suite, that Access
> has which includes a version of the Palm SDK (I
> believe they include a version 5.4 version of the
> SDK).
>

Hi Eric!

I don't have Eclipse on my machine. Is there any other SDK that I could download?

Biswajit

ebresie
Offline
Joined: 2003-08-06
Points: 0

The Garnet OS Development Suite has Eclipse packaged with it. It includes Eclipse, SDK, cygwin, prc-tools, etc. However, it is Windows based.

Access SDKs are available at:

http://www.accessdevnet.com/

Palm provided SDKs (including support for Centros) are available at:

http://pdnet.palm.com

Eric

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure if it will help but noticed another thread on the Feature forum which might be relevant on the thread front.

http://forums.java.net/jive/thread.jspa?messageID=293286

Eric

ebresie
Offline
Joined: 2003-08-06
Points: 0

> phonemeadvanced@mobileandembedded.org wrote:
> > I noticed there are some defs_personal_x11.mk and
> defs_personal_motif.mk which I assume are for X11 and
> MOTIF environments, which I suspect are not available
> for Palm presently, so I dropped these. I did notice
> the defs_personal_gtk.mk and defs_personal_qt.mk
> which seemed more likely candidates for use with
> Palm, but once again, I'm not sure if they have been
> ported to Palm either. I may need to have another
> items for whatever Palm UI framework we will end up
> using.
> >
>
> Yes, don't look at any parts of the build that used
> _basis or
> _personal. Those are the GUI parts that just won't
> build without a huge
> amount of work on Palm OS. The best approach is to
> stick with a
> headless CDC/Foundation Profile build
> (J2ME_CLASSLIB=foundation).

I am likely getting ahead of myself again, but I posted elsewhere (see http://www.1src.com/forums/showthread.php?t=145828 ) about possible UI related available libraries for Palm development and someone mentioned a port of SDL for the Palm (see https://sourceforge.net/project/showfiles.php?group_id=212180 ). Would SDL (see http://libsdl.org/ ) provide the necessary UI aspects needed for the GUI parts? Would a defs_personal_sdl.mk be worth developing?

Eric