Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lionel Debroux

Pages: 1 2 [3] 4 5 ... 143
31
News / Re: Put both Ndless and OS 3.6 in your TI-Nspire
« on: November 02, 2013, 05:02:01 am »
Quote
Also with the HP Prime now the Nspire will likely be of lesser interest to the community once the former goes mainstream, due to more power and TI f-ing up.
Clearly.

32
News / Re: Put both Ndless and OS 3.6 in your TI-Nspire
« on: November 02, 2013, 04:49:40 am »
Quote
But yeah, it is still good to see new ndless versions coming up :P
That's not a new version of Ndless :)

33
HP Calculators / Re: A solution to HP connectivity problems
« on: October 30, 2013, 05:20:12 pm »
I'm not making progress on the screenshots' CRC, but making progress on other areas:
* backup is now fully implemented (it already was earlier) and gets the CRC right (which is new). In the test program, there are silly charset conversion issues (with e.g. the theta variable, whose UTF-16 LE name is 0xB8 0x03), but I don't plan on addressing them in the test program: this job is better done by clients of the library with proper Unicode handling (with libicu, Qt, whatever);
* the procedure for sending files to the calculator is nailed, thanks to critor's dumps of the HP Connectivity Kit <-> calc interaction. Sending a first virtual packet without payload, then another virtual packet with data payload, doesn't seem to be necessary, as creating a file through the "Content" tab of the connectivity kit does create+fill the file in one fell swoop - therefore, I plan on implementing only the combined create+fill. critor's dumps also show that for computer -> calc transfers, the very first byte in the packet is getting incremented (0x00 -> 0xFE -> 0x00 -> ..., that also indirectly confirms the fact that packets starting with 0xFF are sort of "ready" acknowledgments, I'm ignoring them). That's unlike calc -> computer transfers, where the first byte stays 0.

As for transfer slowness: during the calc -> computer backup process [EDIT: made with the HP Connectivity Kit], the timestamps in critor's USB packet dumps show intervals of between 5 and 20 ms between each 64-byte packet, which mechanically limits the transfer rate to between ~3 KB/s and ~12 KB/s... but still, 8 minutes for 110 KB of data indicates a problem somewhere, as even at 3 KB/s, it should last less than 40s.
Does the Windows HID stack (whose reliability seems to be pitiful, as shown by the horrible behaviour when printing traces to the horrendously slow Windows terminal) lose packets so easily that calc -> computer backups cannot be made unconditionally at 5 ms interval ?
BTW, 3-12 KB/s is a very far cry from the transfer rate in firmware upgrade (MSD-like) mode (EDIT: using the "official" reflashing tool; libhpcalcs does not tackle that), whose speed is good, faster than that of the Nspire family, despite having more data to transfer :(
[EDIT: I do not have any measurements of the performance of libhpcalcs wrt. the official connectivity kit. If the calculator is the one setting the pace for calc -> computer transfers, which I believe due to my understanding of how USB interrupt mode works, there shouldn't be a difference, as the speed will be limited by the calculator for not overwhelming poor little Windows.]

The libhpcalcs + test_hpcalcs source code (written in C11) now exceeds 2500 SLOC, as counted by `sloccount`. The raw line count is above 4000 lines, as all main headers now have some documentation for all APIs and data structures, there are some comments... and the license blurb repeated at the beginning of all files takes its toll as well.

[EDITs for clarification.]

34
HP Calculators / Re: A solution to HP connectivity problems
« on: October 29, 2013, 05:02:10 pm »
So... the files seem to be nailed, but I'm still wrong for the screenshots in at least three ways...

(* as you indicated above, there's a trick for encoding the 16-bit images, so now, we know why they look like odd grayscale pictures. I didn't envision having libpng decompress the images, convert the data myself, then having libpng recompress the images, but it can be done);

* do the the colors for the paletted 4-bit color PNGs need the same kind of conversion as 16-bit grayscale PNGs ? The colors remain wrong, see
critor and others noted that this output looks like images with reversed blue and red colors. Interpreting 5551 as 565 probably wouldn't wreck the colors so much ?

* AFAICS in the test program, using the same CRC function for computing the screenshot data's CRC, and trying to match the result against the data at offset 6-7 (instead of 8-9 as in files), comes up empty, even when varying start and end (manually and programmatically). The best I could find was a match with reverse endianness, when computing between offset 8 and end of data, but that does not make sense.
In the short term, I can (and do) just ignore the CRC for screenshots, but it means that I am (and therefore, the code is) missing something.

35
HP Calculators / Re: A solution to HP connectivity problems
« on: October 29, 2013, 10:20:52 am »
Quote
// CCITT CRC-16 look-up table (X^16+X^12+X^5+1)
(this looks like a good place to look at: http://www.embeddedrelated.com/groups/msp430/show/29689.php)

Initialized the crc bytes to 0 at start (yeah - dumb, caught too late to mess with). Also, looks like it might be including the first byte, but using the "length" value which does not include the first 6. (so first 6 bytes are included and last 6 are not).
Works much better this way, thanks a lot :)
With the array and CRC computation function that you point:
Code: [Select]
static void crc16_block(const uint8_t * buffer, uint32_t len)
{
uint16_t crc = 0;
while (len--)
{
   crc = ccitt_crc16_table[(crc >> 8) ^ *buffer++] ^ (crc << 8);
}
printf("crc16 is %" PRIX16 "\n", crc);
}

the winning call is:
Code: [Select]
crc16_block(array2+1, 0x10);
crc16_block(array3+1, 0x10);
crc16_block(array4+1, 0x10);

Output:
Code: [Select]
crc16 is 9D57
crc16 is 68B
crc16 is 703F
(which shows that the CRC is written as little-endian)

I wonder why the brute-forcer didn't find it, even with 0x0000 as initial value for the CRC computation (I had already tested that instead of 0xFFFF), since it looked from 0 to 12 as start offset and 0 to 48 as end offset.

Anyhow, thanks a lot again ;)

36
HP Calculators / Re: A solution to HP connectivity problems
« on: October 29, 2013, 03:33:43 am »
Screenshotting and backup are supposed to be implemented reliably, besides the strange colors in the screenshots (but I'm not mangling the output). Printing logging output to a file instead of the horribly Windows terminal tremendously helps for reliability...
I'm not aware critor transferred back a file created by test_hpcalcs to the calculator using the HP Connectivity Kit.

What's holding further implementation of libhpcalcs / test_hpcalcs at this point, is the integrity checking value: 16-bit value in the header of packets, which varies with the variable name and the variable contents. I can't find how it is computed, even with a brute-forcing program, which I've posted at http://tiplanet.org/forum/viewtopic.php?p=151303#p151303 : the more eyes and brains, the better !
There seem to be such integrity checking values in the packets used for sending and receiving individual files, so I assume that these operations cannot work until we get this integrity-checking computation right.

37
HP Calculators / Re: Let's hack the HP Prime!
« on: October 29, 2013, 03:12:24 am »
For information, I pointed to this topic on MoHPC, and Tim Wessman indicated that the calculator is not running Windows CE.

38
News / Re: 1st mod of a TI-Nspire prototype into a TI-Nspire CAS
« on: October 26, 2013, 01:11:23 pm »
To work around the problem, you can download the latest beta build from http://ourl.ca/4010/360344 .

39
TI-Nspire / Re: nTxt - Nspire Text Editor
« on: October 26, 2013, 12:01:10 pm »
aeTIos: also, make sure you're using an up to date version of Ndless (but if nTxt uses the facility to request a minimum Ndless revision, it should refuse to run if yours is too old, anyway) :)

40
News / Re: Warning: OS 3.6 bricks TI-Nspire ClickPad DVT prototypes
« on: October 26, 2013, 07:45:39 am »
2.0.1188 probably did, but 3.0.1.1753 did at a far wider scale.

41
News / Re: 1st mod of a TI-Nspire prototype into a TI-Nspire CAS
« on: October 26, 2013, 01:58:15 am »
The files on ticalc.org are outdated, the latest release can be downloaded from http://sourceforge.net/projects/tilp/ .

42
HP Calculators / Re: A solution to HP connectivity problems
« on: October 26, 2013, 01:55:46 am »
Yesterday evening, critor confirmed that my latest changes produce a directly usable PNG file. The colors are still messed up, but I'm outputting verbatim the data part of the packets produced by the calculator (or so I think, at least :D).

43
HP Calculators / Re: A solution to HP connectivity problems
« on: October 25, 2013, 06:10:45 am »
Attached is an initial success for screenshot functionality through libhpcalcs on critor's Prime (thanks a lot for the many dumps and tests !), after manual edition of the PNG file to remove data which the lower layers of the code do not filter yet :)
Yup, the calculator's timestamp is broken. And the libhpcalcs code does not yet send or receive files to/from the calculator, which limits its practical usefulness, for now...

44
Other Calculators / Re: First xLIBC game ever: HP Prime Tunnel demake!
« on: October 25, 2013, 04:16:21 am »
Quote
You mean a 2D acceleration chip. :P
I'm not aware anybody has confirmed that this chip is actually used by the Prime's software.

45
Other Calculators / Re: Next Nspire release
« on: October 24, 2013, 01:27:42 am »
Quote
but for the time being I would advise against waiting for it, because it could take a few years before it comes out and even if it doesn't, it's most likely gonna cost outrageous prices.
Agreed. The most likely outcome is both "outrageously expensive" and "outrageously locked-down".

Pages: 1 2 [3] 4 5 ... 143