Re: checking for a microphone
The description of the MultiConnector used on the T5 includes a microphone connection. It may be that all MultiConnector Palms support an external microphone. I don't know one way or the other about external microphone support, but it seems like it's worth an experiment. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T5 Serial Port drops data?
Martin Saxon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi everyone. I'm using the serial port on a T5 to talk to a data capture device, but it appears that if I try to send a data packet at the same time that data is arriving on the receive line, some of the received data gets dropped. ... What size receive buffer are you using? The default is 512 bytes. Since there is no hardware flow control on the T5, you need to allocate a large enough buffer to handle whatever amount could come in before you issue a SrmReceive. You can allocate a larger buffer with SrmSetReceiveBuffer. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
One undocumented feature that you should probably be interested in is the entry point for Arm native applications. Arm native applications have resources with names like ARMC, and do not have any CODE resources. In any case, it's the first instruction of the ARMC resource. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Despite the public documentation, Palm OS is a multi-tasking OS. The following undocumented calls are identified in some of the information that I gathered about YAHM: KALTaskCreate, KALTaskDelay, KALTaskDelete, KALTaskGetCurrentID, KALTaskGetInfo, KALTaskResume, KALTaskSuspend, KALTaskStart, KALTaskSwitching, KALTaskWait, KALTaskWaitClr, KALTaskWake, KALTaskExit, SysTaskCreate, SysTaskDelay, SysTaskDelayV40, SysTaskDelete. There is very little documentation from Microsoft about how to write a MSDOS TSR. Certainly not enough to write one. TSRs were developed by the developer community, not by Microsoft. The Microsoft attitude toward TSRs was primarily silence, with occasional warnings and disclaimers. Not unlike what we're seeing now with Palm. Not using undocumented facilities to detect viruses assumes that all viruses follow the same rules. Virus writers are not among the most pristine in their approach to rules. The idea that using only documented facilities will protect you from changes in future OS versions is naive. Witness the current problems with NVFS. Documented does not equate to stable, unchanging or even functional. Undocumented likewise does not equate to changeable or non-functional. It's like a log rolling contest, and only the alert and constantly involved have a chance at staying upright. The reason that SetTrapAddress is not available in OS/5 is that it doesn't make sense with an Arm device that is emulating a 68K. TRAP is a 68K instruction that transfers control from a 68K program to a 68K handler. In OS/5, the 68K TRAP instruction transfers control to an Arm handler. If you want to provide an alternate handler, then you need to intercept the call to the Arm handler and provide your own Arm handler. This is exactly what YAHM does. Palm is not going to tell you how to do this without some legal leverage on how you use the information. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Converting UTC time into local time in pre-OS 4.0
On systems where you can't get the time zone or daylight savings, the only time that exists is current local. The GPS data is still useful for correcting a time setting that is several minutes off. My approach would be to adjust the PDA time by up to 29 minutes to match the GPS minutes. It should be a mode setting, but I'd set the mode to automatic correction of several minutes. Anything more than 29 minutes should require a dialog with the user. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: ..2 running?
Steven Fisher [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there any way to check if the console is running? It doesn't have to be well supported -- this is just a little debugging utility I'm writing because DotDotTwo isn't doing what I want. :) You might try issuing a SrmOpen for the console. If it returns 0x0307 (already open), then either the console is running or something else left it open. If the SrmOpen succeeds, the console is not running (and a SrmClose would be appropriate). -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Software Copy Protection - One More Time!
There is a unique serial number on each SD card. That could be used as part of the installation verification for high value software. If you're really involved with high budget software, join the SD association and learn about how to utilize the SD security facilities. All of the system identifiers can be spoofed by a hack. System calls that ask for security information highlight the code involved in security. If you want to turn crackers into customers, how about the following game. Offer a prize for the first contestant to crack your security. In order to participate, a contestant has to either purchase a legitimate copy, or wait for someone else to win the prize. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to treat interruptions in Palm OS
You can set up the performance registers in a PNO. The fun starts with handling the interrupts produced by monitoring. There are no Palm documented ways of processing the interrupts. The interrupts come in on, I think, the same vector as the one for invalid opcode. You could take over the hardware interrupt vector (in the PNO), and provide your own handling. Or you could use PODS and write your own nub protocol handler. You're deep into undocumented territory here. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: pda for voice/language software
Roger Stringer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From: Rob Larson [EMAIL PROTECTED] Date: Fri, 27 Aug 2004 23:05:21 -0700 SNIP Be aware that OS/6 devices will be arriving in a month or two. For example Christmas electronics season requires product introduction in the September - October date range. Any later than that is a disaster. If they miss October, the next introduction is after the new year, in the February - March range. The T3 can potentially be upgraded to OS/6, But will PalmOne provide an OS upgrade for it ? They will if they want to push OS/6 to developers as fast as possible. The interesting question is what is going to happen to OS5.4. There aren't any current devices with it, which says that there will be new OS 5 devices. Otherwise, why even announce it? The tea leaves indicate that OS/5 will continue in the low end, Zire class machines. OS/6 will be introduced as the high end offering. It will be available on the T3 replacement machine, and probably offered as an upgrade for the T3. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: pda for voice/language software
You can use the POD debugger with the T3, but not with the 72. So, if you want to do some Arm debugging with breakpoints and such, the 72 doesn't qualify. Otherwise, they seem about the same to me. Be aware that OS/6 devices will be arriving in a month or two. If you're in this for the long haul, OS/6 seems more appropriate for such an application. Sorry to confuse the situation, but this is a major change. You need to evaluate whether you want a mature obsolete environment, or an early version of a richer new environment. The T3 can potentially be upgraded to OS/6, while the 72 is OS/5 for ever. Jennifer Fell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, This might not be an appropriate question for this forum. I am developing a language trasnlation software (with voice recognition and voice synthesis features in mind). I am going to order a palm device by a day or two. Based on a quick online research, I have decided to go for a Zire 72/Tungsten T3. From a developer's viewpoint, is there any suggestion/advice with that? Or any compatibility/feature related of issue that I should know? Thanks a lot. Regards, Jenni -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tungsten T3 Serial port problem
This problem is addressed by the SerialFix system extension. Go to www.handango.com and search for SerialFix. If a program works on other Palm devices, but output to the serial port fails on the T3, then it is worth trying SerialFix. The CTS required problem is definitely addressed by SerialFix. There are a few other problems that SerialFix corrects, and a few more that it can't solve. One problem that I'm working on right now is that RTS seems to get stuck on, despite setting the flags to disable it. I think I understand how to correct the problem, and the fix will be in SerialFix version 2.2. Contact me directly if you are interested in testing 2.2. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Does PalmOS 5 use the ARM's Memory Protection Facilities?
Yes. OS/5 devices use memory mapping, and Sony devices run applications in user mode. While memory mapping could be used to prevent coprocessor register access, it is not. PNOlets can access system registers, even on the user mode devices. The game is that many of the devices remap the registers to different addresses than the chip manufacturer specifies. There are a number of queries in the archives about where are the system registers on device x. Several mappings that I know of are that the Tungsten/T uses identity mapping (registers are exactly where TI says they are), and the Tungsten/T3 moves registers at 4xxx to 9xxx. The TI watchdog timer on the Zire 71 is at FFFEC800. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: about palm's future
I have a Clie TJ37 that died after one month. Before it completely died, the WiFi was suitable only for a developer - I'd never deploy such a device for real work. I don't know about the Zire 72, but Sony is certainly capable of delivering poor quality hardware. Next thing I get to find out is how long it takes to fix it. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: FrmDoDialog Eats Events
The FrmDoDialog is issued as a result of a notification. The notification comes from another application, with its own event loop. FrmDoDialog was very attractive since it has it's own event loop to control its form. And, in fact, it usually works. The problem occurs when the other application has events still in the queue, specifically frmLoadEvent and frmOpenEvent. FrmDoDialog processes these other events, and gets hopelessly confused. I get the impression that OS/6 will handle this situation ok. But with all applications sharing the same event queue in OS/5, FrmDoDialog eats some events that one would expect to be directed to other forms. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: FrmDoDialog Eats Events
That document is quite useful in utilizing FrmDoDialog. It would be even more useful if it covered the issue of pending events and event discarding by the function. There are many problems described in the archives that may very well be caused by FrmDoDialog event discards. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
FrmDoDialog Eats Events
I have a situation where a FrmGotoForm for form A has been issued, and the frmLoadEvent has not been processed yet. An error is detected, and results in a FrmDoDialog for form B to report the error. It turns out that the FrmDoDialog event handler consumes the frmLoadEvent, which means that form A is never drawn. The solution that I'm trying is to do a FrmSetEventHandler for the FrmDoDialog form (B). This event handler returns false for all events known to apply to form B (nil, penUp, penDown, penMove winEnter, winExit, ctlEnter, ctlSelect). For the frmLoadEvent, it is recorded and the event handler returns true. After the FrmDoDialog returns (and form B is no longer active), the frmLoadEvent is requeued. My question is what other events could be passed to the FrmDoDialog event handler? Should I record all unrecognized events and requeue them after the dialog is complete? It would seem that frmLoadEvent is just the event that is causing trouble, but there could be others that also should not just be thrown away. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: FrmDoDialog Eats Events
Thanks Matt. That would certainly be my preference, but I don't control that code. There's more discussion of FrmDoDialog in the archives than I've got the time to review. But a recurrent theme seems to be that using it stops other things from working. This is a case of it consuming an event that had nothing to do with the current active form. The frmLoadFormEvent can be detected, and requeued after the dialog is completed. There may be other events that need to be delayed until after the dialog. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Serial comm differences between Simulator and real device
The first thing I'd be suspicious of is the cable to the Palm. Some vendors provide a different serial connector for the new (Tungsten Zire 71) devices than for older devices. The specification is the same, but there seems to be a small difference on the real devices that leads to poor connections between connectors designed for old devices and actual new devices. The best connectors have a tab that runs a ways up the back of the T3 in order to stabilize everything. Try several different cables and see if there is any difference among them. The new devices require a proper ID resistor in the serial connector. Cables with the wrong ID (Y cables in particular) can work with old Palms, but go wonky with a T3. The sensor device may be sensitive to the timing of signals sent to it. This is what handshaking is supposed to take care of, but some devices are just deaf some of the time. They are dependent upon the sender leaving some time between characters, or between command sequences. The T3 is a very fast device, and it may be overrunning the performance of the sensor. While the PC is fast, it has many other things going on, and thus may not actually drive the serial connection at the highest speed. I've had reports that my SerialFix extension corrected data integrity to serial devices. The only way I can figure that this could be true is that there must be some buffer management problems in the standard serial handler code. If the program works on other Palm devices, but not on the T3, then it is worth trying the SerialFix extension. It is available at http://www.handango.com/PlatformProductDetail.jsp?productId=64193 SerialFix bypasses the requirement for CTS or cable ID handshake signals. This allows usage of three wire serial connections and cables that do not provide the proper device ID, such as Y cables. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Serial comm differences between Simulator and real device
Isn't serial port work fun?!! You can't use a debugger, since the debugger uses the serial port. Note that if you use a serial debugger connection, the serial port is tied up until you reset the device. Same deal if your program opens the serial port and exits without closing it. A soft reset usually clears up serial port tieups. I've been known to do a hard reset every few days to get out of persistent glitches. Don't keep anything important on your testing device, or at least keep a current hotsync. The best you can do is to check every return code, and issue progress messages as the code proceeds. If there is any error on the serial port, all further communications can be locked up until you clear the error. The OS/5 devices seem to be much more picky about this than the earlier ones. Use SrmClearErr on any hint that there is a problem. And don't use SrmSetWakeupHandler - it doesn't work. The company that provides the Portabella program that you mentioned sells a variety of serial port widgets. They probably offer a RS232 adapter with LED readouts of the various signals. Another device that you might consider is an opto-isolator. It can be used to clean up any non-standard signal levels that the sensor (or the Palm) is producing. You could use a third device to monitor the communications. Another PC or Palm could be tapped into the connection. An oscilloscope is ok for check signal presence and levels, but I'd hate to decode a long message from a scope trace. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Inline assembly support in pacc for PNOlet (PODS v1.0alpha)
Is there any documentation about how to use PAASM? I tried converting some GAS code to it, and it's clearly a different language. Is PAASM a subset of ADS assembler? Is there an ADR/ADRL type function available? How about any primitives that could be used to provide similar function? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Calling Arm code slow?
There is a YAHM OS/5 hack that disables the cacheflush. Get it at http://yahm.palmoid.com/nocacheflush.zip -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: POSE error message- reading from low memory
Chances are very high that POSE caught a bug in the program that the real machine ignores. It's obviously ok to read that location on a real OS/4 device. But since the data is garbage (at least as far as your program is concerned), I'd question what decision your program is making based on garbage. Half the bits in random data are right... so a program can certainly make the right decision for the wrong reason. Happens all the time. Check the buffer allocation for the insert field. It's probably not set, or worse yet, just a leftover value from the previous use of that memory. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Dynamically creating controls
Ok, I took a look at the code (it's about 2 years old), and here's what it seems to be doing... The design is that there is a blank form on which buttons are added with CtlNewControl. The actual data describing the form is in a database, and the user can add/delete/change/move buttons and specify the labels. There is no form resource that describes the screen image - it is all dynamically created with CtlNewControl as part of handling a frmLoadEvent. A corruption sometimes occurs that destroys the label of at least one control currently on the screen. It's not the control that was just added - it's one that was already correctly displayed. I think that what happens is that adding a new control requires that the entire form structure be recreated. The bug is that in some cases a label does not get properly copied from the old structure to the new one. The corruption seemed to occur when the 18th or so button was added. Examination of the control block structure all looked ok, except that things had moved around, and the label data was bad. This was OS 3.5, so the source code is available, and the control blocks are real (not shadowed like in OS 5). The fix is to scan the labels for all controls in the active form every time a control is added or deleted. Do a CtlGetLabel for each control. CtlGetLabel returns a pointer to the label. It is compared with StrCompare to the database info, and rewritten with StrCopy if it doesn't agree. The key is that using CtlNewControl can trigger damage to another control. There's nothing wrong with how CtlNewControl is called, or with the other controls currently active. The damage (in my case) can be corrected by rewriting the label data. Note also that the maximum length of the label data is defined as part of the CtlNewControl. To use a label that is longer than the original definition, you have to delete the old control and define a new one with enough space. Palm recommends Glue... I find that chewing gum is also useful... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Dynamically creating controls
Ben, I have what appears to be a solution, at least for the way I use dynamic controls. After adding/deleting a control, the entire form is redrawn. As part of the redraw, all labels are read, and compared to the database. Sometimes this comparison fails, in which case the label is rewritten from the database. The reason for reading the label, rather than just rewriting it, is to limit the fixup to only those cases where there actually is a corruption. As best I can tell, the actual space allocated for each control is ok. Only the contents of the label field is corrupted, and rewriting it fixes the problem. Most of the work on this problem was done with a IIIC, running 3.5. Seems to work with everything since then, although I couldn't tell you if the fixup is triggered on other versions of the OS. Does my experience ring true, or is there corruption that just hasn't shown up? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tungsteen E device
Very interesting. There are entries for the Tungsten/E2 and Zire 31. OS/6 maybe? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T3 Serial
It's a bug in the T3 serial driver. Contact me offline for a beta copy of SerialFix that handles the T3 problem. It will be up on Handango shortly, but I'd be interested in some more testers. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: simultaneous serial port / IR port usage
The Zire 71 and Tungsten/T3 have separate serial and IR ports. The Tungsten/T IR and console share the same serial hardware. Watch out for the non-support of raw IR on the Zire 71. I don't know about the Sonys, but they're worth checking out. Some people have had to modify their 68k serial code to work with OS/5, even though the specifications are the same. Wakeup handler support in OS/5 doesn't work in 68k mode, although it might with Arm native code. risc [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] we have developed an application that requires the use of both the serial port and the IR simultaneously. This was available on the m125 and m130, and worked quite well on these units, but these are no longer available even in refurbished form in any quantity. Do any of the new devices even have 2 physical serial ports, the way the m125 and m130 did? For that matter, do any of the new devices even have the serial port at all in any form? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Raw IR on Tungsten T3 Update
There are no public documents that I know of that specify things like which uart is connected to the IR port. Those of us who need this information just spend a lot of time experimenting with devices to find out how they're configured. For example, the IR port can be identified by issuing a SrmOpen to the IR port, and checking which hardware port is activated. If changing the baud rate via the Serial Manager changes one uart, then you've found it. More commonly nothing changes... keith cameron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OK thanks Rob I can probably get things working without resorting to directly accessing the UART or reprogramming it but just out of interest do you have a reference/URL that gives details of the T3 hardware and/or sftware architecture? Keith Rob Larson wrote: The Intel documentation is available at www.intel.com. I don't have the specific page, but the document you're looking for is Intel PXA255 Processor Developer's Manual, order number 278693-001. The hardware registers on the T3 are remapped from 0x4000 to 0x9000. So the STUART register that Intel documents at 0x4070 probably shows up at 0x9070. I say probably because I haven't verified that the IR port is there, but it's the first place I would look. keith cameron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there documentation somewhere accesible that gives the T3 architecture and address map so that I can get direct access to the UART? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Raw IR on Tungsten T3 Update
The Uart is generally programmed to hold input in the FIFO queue until 4 or 5 character times have past without any input. Thus the time to receive 1 character is the time for that character, plus 4 additional character times. The details vary with the chip manufacturer (TI OMAP, Intel, Motorola, Sony). The T3 uses an Intel PXA255 chip, and you can read about the Character Timeout Interrupt in section 17.4.2.1.2 of the Intel PXA255 Processor Developer's Manual. The delay for TI OMAP devices is 4 words plus 12 bits, or 2 bits more than 5 characters. The purpose for using character timeouts is to reduce the interrupt load. Instead of an interrupt per character, the device is programmed to interrupt, for example, after 8 characters are received, or when no additional characters are received for 4 character times. Less overhead, but you get delays that can be significant at lower baud rates. The standard Palm setups can be overridden with a PNOLet that reprograms the Uart. The details vary according to chip manufacturer, which Uart is being used, virtual address relocation, and initialization by the standard code for the device. The Uart can be programmed to interrupt immediately upon receipt of a character, without using the timeout function. keith cameron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I am gradually getting things to work, mainly by puting delays in the reponses from the data logger which is a bit anoying. I'm testing at 9600 baud but need to move to at least 38400 later. The logger was supposed to already have a 20 milli second delay from which I deduced the 25 milliseconds this turned out to be less than 2 milliseconds so the total delay was around 7 milliseconds. The logger now has 20 milliseconds delay and thing seem to work. I will try and determine how much delay is needed at the different baud rate. Any advice on this would be appreciated. What is the five charactyer timeout? Keith Rob Larson said This sounds like the receive function is being terminated by the five character timeout. At 2400 baud, this would be about the 25 milliseconds that you're observing. At 56000 baud this delay would only be about 1 millisecond. Keith - is the connection running at about 2400 baud? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Raw IR on Tungsten T3 Update
The Intel documentation is available at www.intel.com. I don't have the specific page, but the document you're looking for is Intel PXA255 Processor Developer's Manual, order number 278693-001. The hardware registers on the T3 are remapped from 0x4000 to 0x9000. So the STUART register that Intel documents at 0x4070 probably shows up at 0x9070. I say probably because I haven't verified that the IR port is there, but it's the first place I would look. keith cameron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there documentation somewhere accesible that gives the T3 architecture and address map so that I can get direct access to the UART? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Raw IR on Tungsten T3
This sounds like the receive function is being terminated by the five character timeout. At 2400 baud, this would be about the 25 milliseconds that you're observing. At 56000 baud this delay would only be about 1 millisecond. Keith - is the connection running at about 2400 baud? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: OS 5.x Serial Baud Rates
The problem with serial port support on the Tungsten/T bothered me enough that I developed the SerialFix product. It is a system extension for OS/5 that enables use of the full range of baud rates. The problem is that the serial port driver shipped with the Tungsten/T only honors specific rates. SerialFix intercepts the SrmOpen requests, and reprograms the serial port hardware for the requested baud rate. The only difference for application programs is that requests for unusual baud rates (such as 31250) are honored, as opposed to the standard system response of failing such requests. Go to http://www.handango.com and search for SerialFix. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T/2 Voice Memo button
I've never seen any documentation about how to use the Voice Memo button, but it behaves like another hard key. While the hard keys produce key events 0x0204, 0x0205, 0x0206, and 0x0207, the Voice Memo key produces 0x0214. The Voice Memo key only appears in conjunction with the 5-way navigator, so perhaps that would be an adequate test. I'm not sure about the Tungsten/W - does it have the key? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Chip-specific optimizations?
I think you're showing your experience with x86 programming. It is true that low level optimization on a 486 is different from a Pentium which is different from a Pentium II ...etc. As far as I know, all the 68k chips used in Palm devices execute instructions in the same number of cycles. The differences in speed are a function of the clock rate and the memory configuration. If you really must have the highest speed display access, you can write custom code for each display hardware. Other than that, any optimization you do should apply equally to all platforms. With OS/5, this game really changes. Optimization will require writing native Arm code. And the various Arm processors (TI, Intel, Motorola) execute instructions at different rates, even after adjusting for clock speed. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: running program from removeable media stays in ram?
When your app is started from a card, there is a sysAppLaunchCmdCardLaunch launch code before the normal launch. You can record that fact in feature memory, for use next time the app starts up. As part of the reset, there is a sysAppLaunchCmdSystemReset launch code when the system restarts. So the ram copy of the program can know that it is not supposed to be running. Now the problem is how does it delete itself. Best I can come up with is that you SysUIAppSwitch to a helper application with a launch code parameter block specifying the delete me request. Maybe there is some other way for a program to delete itself? Mark Lussier [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I notice, if a PRC is run from removeable storage, and while running, a soft reset occurs, that application is left in RAM. The same is true if the application itself programatically soft resets the Palm. Does anyone have a solution so as the PRC is removed? Particularly in the case where the program itself does a soft reset. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Determining idle time
I assume you noticed sysNotifyIdleTimeEvent to mark the start of idle. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: No overwrite when launching off Card
Yep, does that to me too. My mapping of what happens on my Tungsten/T is that if you launch from the card and the same app already exists on the handheld, then it launches the handheld copy. If you launch from the card and a handheld copy does not exist, then it is copied over to the handheld and run from there. If the card launched copy terminates normally, then it is deleted from the handheld. If, however, the handheld resets (something that happens a lot on my TT...), then the handheld copy remains. The solution is to either copy from the card to the handheld every time you put a new version on the card, or to delete the handheld copy every time. I've spent a lot of time wondering why a change I just put in didn't seem to be there, usually because it wasn't - I was running the old copy from the handheld instead of the new copy I intended. Andrew Waites [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In my testing if I copy an app from Palm to card then launch off the card there is no prompting..it runs the existing app on the Palm. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Documentation on forward compatibility
Regulatory types like documentation. You have already applied several techniques to your design process that were intended to assure the requested level of functionality. You claim to use only documented APIs, do not depend upon OS internal structures, and have tested a wide variety of actual hardware. The first thing you should do for the regulatory people is to write down this list of things you've already done. Next you should make a list of things that could go wrong, both things you control and, more importantly, things you do not control. As a technical problem, you can only be held accountable for your own efforts. If you wish to act as an insurance business, you can accept the responsibility for what others (like Palm) do, even though you have no control over their actions. The highest quality software that I've seen was written by one individual/group, and studied by another. The function of the second pass over the code was solely to audit it. Done right, this is a valuable process for everyone. Done wrong, it can be a nit picking argument over the spelling of comments, indentation style, and other aspects of a program that do not relate to the externally visible function. Another technique I've seen used effectively is what I call grooming. Code is revised to improve coherency, without necessarily changing the actual results. I'm much more impressed by the results of code audits than by the results of black box testing. The quality of the code needs to be matched to the quality requirements of its application. Code that controls medical life support devices clearly needs more attention than game or entertainment software. You need to understand the value system of those imposing the regulations. Are they trying to assure a level of quality, or simply on an ego trip to demonstrate their ability to control you? If they really want quality, demonstrate that you consider them a valuable part of your team. If they're just SOBs, flood them with details that they will have to wade through. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Resource types
So the only use for aalt, amdc and amdi resources are for native arm applications? Any particular places where I might get these for my Tungsten? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Serial comm delays in OS 5
A SrmReceive with a byte count of one and a minimal timeout should immediately return with the first byte of the two byte buffer. If there is no data available, then SrmReceive should wait for the timeout period and then return with a timeout error code. Any data in excess of the SrmReceive request should be left in the uart or the OS buffer. I say should since you have the code I am just talking theory here. There are three places the byte travels through on its route to your buffer. First the uart receives it and places it in the receive FIFO buffer. The FIFO buffer can hold up to 64 bytes, and can be programmed to interrupt on one, 8, 16, 56, or 60 characters present (see OMAP documentation for uart3, FCR register, FX_FIFO_TRIG field). The uart certainly has the capability of buffering 8 characters before ever notifying the cpu that anything has happened. The operating system reads data from the FIFO when the uart interrupts, or it could also do it in response to a SrmReceiveCheck (which should look at the LSR register bit RX_FIFO_E (flags at least one data character in the RX_FIFO)). The OS can either store the character in its own buffer or in yours. If you don't tell the OS where to store the data, then it must use the OS buffer. Finally you issue a SrmReceive, and the character is transferred to the buffer specified with the SrmReceive. Lots of places to get lost here, but the number 8 screams that the data must be stuck in the FIFO buffer. The reason OS/5 behaves differently than earlier OSes is that OS/5 on the Tungsten/T uses the TI OMAP processor. Earlier OSes all run on Motorola 68k cpus, which use an entirely different uart. New code, new bugs. I agree that your code should work, but this looks like a bug in the serial support for the Tungsten/T. Trying SrmReceive would be an attempt to exercise different code that might not exercise the assumed bug. You might also try the code on a Sony NX or NZ machine - the uart is different and so the device driver must also be different. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Serial comm delays in OS 5
My guess is that the Uart is buffering the characters in its FIFO. Instead of the SrmReceiveCheck for a large number of characters, you might try a SrmReceive for a single character with a timeout of zero (or if zero doesn't work, try one). -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PalmOS 5.0 Compatibility
Add Rule 22 (as in Catch 22). An older program may work in OS/5 if it: 1. Doesn't provoke bugs in OS/5. 2. Doesn't depend upon older bugs that were fixed in OS/5. 3. Doesn't use obsolete functions. 4. Doesn't use direct access to OS created data structures. 5. Doesn't use system globals. The obsolete function game caught me on several points. I have a calculator that uses the really ancient floating point library. Works fine with everything up to OS/5. When it didn't work, I tried to debug the problem. Eventually I found the documentation (in 6 point type (or was it 3 point...) that said that the original floating point interface was not supported in OS/5. This program didn't do any manipulation of OS internal data structures or any of the supposed nasty things we're not supposed to use. It's only fault was that it was never updated to the newer way of doing floating point calculations. I guess I'm getting rather tired of the implication that if we developers had just lead a more pure existence and not violated so many interface guidelines, then everything would just work like it should have been designed. The only reason the glue library exists is that there were no proper ways to get many tasks done. The glue library was a last minute attempt to provide blessed ways of doing things that previously could only be done in hacker fashion. Many of the useful things that were done pre-OS/5 cannot be done in OS/5 by any blessed technique. If you doubt this, please tell me the official policy on how to install a hack. Hacks were never blessed, and have now been officially condemned. Not that that ever stopped real palm programmers... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Opinions on Expectation of problems with a known invalid global data access.
The 68k really doesn't care about reading the wrong address, although you could get an alignment fault by reading from an odd (as opposed to even) address. I can't think of any I/O ports that will object to a random read, although you could maybe clear some condition that hadn't been serviced yet. It's scary how many programs work for the wrong reasons. I've traced a lot of programs that make all sorts of stupid decisions, but in the end seem to work ok. Any significant program has many bugs in it, but only a few worth the effort to ferret out. High reliability systems pay much more attention to being fault tolerant than to being fault free. Besides, half the random bits in the world are correct... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: NR70 and baud rates
What I've currently got working is code that runs the Tungsten IR port at about 40,000 baud. The IR port is just another serial port, so the issues of setting the baud rate are exactly the same. I've also got some test code that overrides the SrmOpen baud rate on a 68k to a separately calculated baud rate. This is all developmental code, but it sounds like someone else besides me might be interested in something like a utility library. The hardware is certainly capable of non-standard baud rates on both the serial connector and the IR port. Mike - from what you have said about your 10,400 baud data connection, I'm wondering if you really want 8 bit characters (plus a start and a stop bit) from the serial connection. It sounds like you are trying to sample a pulse stream, and are just using the 8 bit setup because it is what's available. Tell me more about the characteristics of the data stream - there is more that can be done than simply setting the baud rate. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: NR70 and baud rates
The 68k produces baud rates at very specific multipliers of the clock frequency. The closest a 66 Mhz machine can get to 10400 baud is 10363. The next step is 10794. The closest to 31250 is 31402, with the next closest 30932. The Tungsten/T hardware is capable of 10416 and 31250 (exactly!). Of course the crystals in real devices probably vary by a few percent. I don't understand why they wire in specific rates beyond what the hardware is capable of. Seems like more code, arguments over which rates to include, etc. Much simpler to just do a divide and round to the closest available value. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS 5.2, tungsten/sony?
Ben Combee [EMAIL PROTECTED] wrote in message news:110199@palm-dev-forum... There isn't a way for normal software developers to have completely ARM-native applications on current Palm OS devices. Arm native applications require some sort of system call structure like the Trap instruction interface on 68k. It looks like the current native applications are static linked into the entire OS. Am I missing something (like a SWI interface)? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS 5.2, tungsten/sony?
OS 5.2 is just a developer release for use with the simulator. One of the very interesting fixes noted in 5.2 is Fatal error could occur when 68K callback (serial manager window handler, procedure alarm, attention manager, notification) is launched while native ARM application is being run. This would seem to imply that there is already support for native ARM applications in OS 5.0. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Does Palm OS5 support 31250 Baud?
The short answer is no. You can only request baud rates of 300, 600, 1200, 9600, 11440, 19200, 38400, or 65280. Any other request will be rejected as a bad parm. Actually, I'd be surprised if any of them actually worked. The long answer is yes. The serial port on the Tungsten/T runs at 75/n, where n is the value of a divisor set into a uart register. The value 75/24 is exactly 31250. Setting this value is a job for a low level armlet routine, but it could be done. Maybe OS 5.1+ could be upgraded to accept such a value. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Does Palm OS5 support 31250 Baud?
Try asking for 300 baud. I think it will give you 31250! -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Dynamic Forms getting corrupted
I have a similar problem with dynamically created controls. Upon redrawing a form with maybe 10 dynamically created controls, one of the control labels was getting trashed. Apparently when the OS shuffles the form data around (say, one of the controls is deleted), it can fail to copy the label data to its new location. Everything is properly allocated, except the label is trash. My solution was to run through the database, comparing the intended label to the current control label. When they don't compare, I reset the label to the one in the database. If everything works properly, then there is no fixup. Ugly, but not doing it is even more so. As I recall, form titles have a fixed maximum length. Whatever length you use when the title is first declared becomes the maximum length that will work. You can set any length title you want, but if it exceeds the available space, it just trashes the next control in the form. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Cold boot on Tungsten/T doesn't reset everything
I've gotten my /T into a knot that cold boot doesn't reset. Used to be that I could go to console mode, import some files, start debugging mode, crash, reset, and restart debugging mode. Now, even if I don't run my crashing software, I have to cold boot every time to get to debugging mode. I'm using PalmDebugger V3.6d7 and a serial cradle. I've tried to run the battery down to nothing, but that doesn't change anything. I'm about to try opening the case to disconnect the battery for a while in hopes that lack of power will reset whatever the problem is. I suppose I could send it in for warranty repair, but if the problem is my software, then it'll just happen again. Any advise (don't write buggy software?) would be appreciated. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Brightness vchr on Tungsten T
I don't know if it's related or just an additional fechur... If you call UIBrightnessAdjust(), the brightness slider is broken. The motion is jerky, the right 1/3 of the slider is corrupted, and the sensitive part of the slider is about 3/8 inch higher than it should be. Note that this is different code than the brightness slider invoked by the graffiti area selector. Maybe the simplest fix is to direct UIBrightnessAdjust to the graffiti invoked code (since it works already). Over in UIPickColor, the title line is corrupted. My wild guess is that the relevant code in UIControls.c was never converted to Arm native. Endian errors strike again... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Os5 or Os4
OS/5 is a major change from OS/4. One of the broken parts of OS/5 is debugging on the actual device. There is no emulator for the Tungsten/T or any other OS/5 device. OS/5 debugging on the simulator is debugging with similar but different code than actually runs on the device. OS/5 is the bleeding edge of Palm development. If you are a developer who has to be sure your code works on the real device, then you have no choice but to use OS/5. But even if you must use OS/5, I recommend that you develop in the OS/4 environment, first with the emulator and occasionally on a real device. After the code is working on OS/4, confirm that it works on OS/5 devices. Be sure to read everything you can about OS/5 compatible coding techniques. As long as you don't go mucking in OS tables, your code should work the same in OS/4 and OS/5. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tungsten-CW for debugging
Ben - So what will happen with CW V8 debugger? Does it sometimes just stop a little further on in the code than expected, or does it get totally confused? Your mention of overlaying code with the TRAP #0 leads me to a related question. How do you gain access to code segment? I had to remove the HwrEnableDataWrites that I used with earlier OS to allow code segment writes. There is obviously some other way to achieve this in OS/5. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tungsten-CW for debugging
Looks like CW V9 is the only reasonable game in town. With older CW or PalmDebugger you need a serial cable with a universal connector. Do not use a Y cable with both USB and serial connectors. The Y cable works for hot sync, but really confuses any debugging traffic. If you have to reset the Tungsten, the Y cable serial connector causes it to hang. The serial (only) cable works fine. At the assembly level with PalmDebugger, there is a bizarre error such that the second instruction following a JSR or TRAP is skipped over by the debugger. The instruction is executed, but you can't single step into or breakpoint on it. So single stepping has these holes in the trace. What I've done for my own code is to add assembler NOP instructions in the skipped areas so I don't have to think about the invisible areas. For code you don't control, just be aware of what is happening and do lots of disassembly after skipping over a JSR/BSR/TRAP. At the C/C++ level with CW before V9, I'll bet it just blows on past any breakpoints that happen to end up on the second machine instruction past a JSR/BSR/TRAP. As Ben says, the problem is in the debugger nub on the Tungsten. The effect will show up with CW debugger, PalmDebugger, GDB, or any other debugger that communicates with the Tungsten debugger nub. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm Debugger on Tunsten/T
The problem with starting up PalmDebugger on the Tungsten/T is an issue with the serial/USB Y cable I am using. Reset works normally if I disconnect the Y cable before doing the reset, then reconnect the serial portion. USB debugging doesn't work, but at least I have a consistent serial debugging capability. The problem with MOVEM.W is still real. Took out another one... Tracing has a bizare problem. Given the sequence jsr foo move.w #1, d0 move.w #2, d1 move.w #3.d2 When you are stopped in the debugger at the JSR, step over the JSR with F10, it looks normal (new instruction is the move.w #1 Do another step with F10 and the debugger steps to the move.w #3 It does not stop and show the move.w #2, although register d1 will now contain 2 (the skipped instruction is executed, but not displayed by the debugger. The F10 over the jsr has left some residual status in the debugger that causes the next step to execute 2 instructions. ROM routine names are not displayed. Most show as ILLEGAL ADDRESS, or just _TD xxx. Obviously there are no routine names following the RTS instructions since the 68k is just a figment of our imagination... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Palm Debugger on Tunsten/T
I've had limited success in using Palm Debugger on Tungsten/T and I'm wondering if the problems are due to my particular hardware, or does everyone run into these. 1. USB debugging from Palm Debugger never connects. 2. Serial debugging connects only after doing a HotSync. Apparently HotSync sets some sort of status in the Palm and/or PC that is required for Palm Debugger to function. 3. After a crash that goes to the debugger, reset is flaky. Sometimes I have to hard reset the Tungsten several times before it comes up again. Then I HotSync everything back into the Tungsten via USB, switch to Serial HotSync again. Then quit Desktop restart Palm debugger in serial mode. 4. There is a bug in the 68k emulator on the Tungsten such that it cannot handle a MOVEM.W instruction. Works fine on a real 68k, but I had to replace the MOVEM.W with a MOVEM.L to get past that point in the code. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
