Content originally posted in LPCWare by edwinl@douglaswest.com on Tue Oct 28 12:52:00 MST 2014
Attached are the iOS Xcode5 debug logs for iPhone 4 verses iPod Touch 5G. The iPod and iPhone 5 yield similar errors so only iPod is attached.
•XcodeiPhone4DebugJoystick
•XcodeiPhone4DebugTemp
•XcodeiPodTouch5gDebugJoystick
•XcodeiPodTouch5gDebugTemp
•iPodTouch5gTemp.jpg
All tests performed on unmodified NXP Quick-Jack demo board (v3.0) and original source (v1.1). An extra debug at line 354 QuickJackApp.mm was added to display the received byte (ie: printf(“uartByteRx[%d]: 0x%x\n”, THIS.uartRecvNum, uartByte);). Both iPhone4 and iPod Touch 5G are running iOS 7.1.2.
Observations:
For the iPhone 4, all the functions of the Quick-Jack appear to work correctly (LED control, Joystick response, Temperature graph) and I do not see any ‘diff too long’ errors in reception during debug.
On the iPod and iPhone 5, the temperature graph can become unstable (ie: large swings in level). See attached photo of the iPod in Temperature mode. Both Temp and Joystick data reception is also showing ‘diff too long’ data errors.
Note1: I’ve also noticed that some byte patterns on the iPod yield the error and others do not. For example, the Joystick 0x1, 0x3, 0x5 byte do not show errors but 0x2, 0x4 do. It appears the errors are dependent on the bit pattern being transmitted.
Note2: Both the Joystick and Temperature demo functions are streaming data from board -> phone so they are ‘error’ tolerant. This means that although some of the data does not make it to the phone, it at least responds to the data that does make it. For the joystick, only a single byte is transported and is continuously sent while key is held. For temperature, a 4 byte pattern including the temp data is sent continuously while in the Temperature display mode. Erroneous data is more visible for the Temperature feature.