We are busily working on several topics so the most recent updates to the SVN tree are most probably NOT WORKING! Revision 2830 is the latest to be trusted.
Pauli is redesigning the solver as a keystroke implementation (with some support from native code) to save space. I'm wasting the space gained with an attempt at IR printing. Stay tuned! :-)
Thanks for the warning.
I have been updating both of my units so frequently I live in fear of toasting the flash memory before its time.
I look forward to giving the machines a break while you fellows work your magic.
Les
Quote:
an attempt at IR printing.
I'm curious what will come next: BlueTooth, WLAN, ... ? ;-)
Quote:
I'm curious what will come next: BlueTooth, WLAN, ... ? ;-)
We'll probably add a DVD drive... ;-)
Marcus:
Wow; IR printing would be great! I hope your investigations go well!
Bruce.
I don't have the transmitter built yet but the pulses on my scope look promising. I'm using the pin marked RS232ON in the schematics which is connected to TIOA0, a timer output capable of driving 4mA. Moreover, the pin is routed to a pad where a transistor and a resistor can be soldered. (This was originally conceived to power a level converter chip.) This seems to be the ideal place to add an IR diode. The pulses are being generated by the timers 0 and 1 which are chained in a way that TC1 gates the clock of TC0 to generate a sequence of bursts of 7 pulses each. A single interrupt at a reasonable rate (32KHz/14, one half bit time) suffices to create a variable pattern of bursts. I have high hopes that the printer will be happy. :-)
Just a humble opinion:
As the HP IR printer has been discontinued long ago, and as it's not very frequent or easy to have one handy (or to buy one for that matter) and, even for those who have it already, it seems not easy to fix or maintain, and since it's output is rather limited for current standards, and...
If you really want to put some I/O (or at least the /O part of it) into the WP34S, would you consider a standard IR protocol like IRDA (serial IR), instead of the HP proprietary protocol, which is 25 years old, and has been implemented in only one product (printer, I mean).
Just my 0.10 AR$
Okay, we have a new solver. About half a kilobyte of flash saved for other purposes.
I managed to get Ridder's steps in as well as the others from the C solver (quadratic interpolation, secant method and bisection) which seems to assist with some functions, but not really hurt with others I've tried.
Of course, this means lots and lots of new solver bugs. Please let us know if any oddities are found.
Additionally, I've put the solver source code into a library file in case people want to try to improve it or submit bug fixes.
- Pauli
Edited: 21 Apr 2012, 12:53 a.m.
IRDA is too complicated in my opinion. And the pin I'm using is not connected to any UART device, either. I'll stick to the HP protocol for the time being.
Edit: IRDA would need an input making the necessary modifications even more complicated.
Edited: 21 Apr 2012, 5:24 a.m.
I've rebuild everything. It would be nice if someone would start testing the new code on both the device and the (classic) emulator. The Qt emulators aren't affected yet.
Please.
Better still debug the code for me ;-)
- Pauli
IR printing (HP82240) would be most useful! Hope it works.
TomC
And I've just got some new paper rolls for my HP82240B, so I'm ready to go! :-)
Where are the latest versions available? Latest files available for direct download from Sourceforge still have dates April 12 & 14.
Eduardo
Quote:
As the HP IR printer has been discontinued long ago, and as it's not very frequent or easy to have one handy (or to buy one for that matter) and, even for those who have it already, it seems not easy to fix or maintain, and since it's output is rather limited for current standards, and...
If you really need a portable printer there's probably a case
to be made for it. Otherwise except for experimentation or
nostalgia I don't quite see a practical motivation.
The problem I have with that protocol is the effective throughput
yielding about 78 bytes/sec which is abysmally slow. The error
correction is a little unconventional although that doesn't
affect the task here, for it to scale an a generally useful
interconnect more receivers are necessary. [Incidentally I've
seen some pretty sloppy timing generated (eg: substantial jitter)
from saturn devices where I had to resort to an averaging
data slicer to reliably recover the data stream.]
In any case without the ability of bidirectional communication,
unrecoverable error detection and recovery requires human intervention.
My approach would probably be to place an outboard US$3 IRDA
module driven by a US$1 uC to deal with the timing and protocol,
and conserve every possible byte of that scarce sam7 flash.
This would also scale to end users better from both mechanical
and retrofit complexity perspectives.
You need to go to the SVN tree. Directions are on the site.
OK, I'll try to figure it out. Thanks.
I agree! However, I will consider trying to buy an HP IR printer...
About the protocol throughput: I think that those 78 bytes per second were appropriate for a character-oriented, battery-powered thermal printer.
In addition to doing Ridder's steps if able, the new solver has an updated termination condition -- if the bounds surrounding the solution are with 5 ULP of each other, a final estimate is made and that is returned. If the bounds produce function values of opposite sign, the final estimate is guaranteed to be within the 5 ULP interval, otherwise, it is likely. This is better than the approximately equal bounds I'd used before I think.
The display mode is still used for the approximately equal to zero test, but this only really matters in FIX modes.
The maximum number of iterations has been increased, although this doesn't seem necessary all that often, quadratic interpolation and Ridder's method both converge very rapidly.
I'm also toying with forcing extra bisection steps instead of secant ones occasionally to bring Ridder's method more into play. Since it requires the interval mid-point function evaluation, it can only be applied after a bisection step.
- Pauli
I have kept up to 2864 on both my units so far and nothing has blown up yet!
Les
Pauli, when moving the statistical code to XROM as planned, will the inverse distribution estimates we have discussed here continue to be refined via their own dedicated Newton routines, as we see in the newton_qf() routine in stats.{c,h}, or can space and time be saved by using the calculators own solver? I just ask because the improvements have meant the TVM program finally works when computing an interest rate from other parameters instead of throwing a "no root found" error, so I thought it might be up to the job.
Les
At this stage I don't know. I'd likely start with the special Newton solver -- it takes advantage of the derivative (the pdf) of the cdf being solved and has a few adjustments to help avoid problems -- jump limiting, domain limiting. I also don't much like the approximate tests in the solver when I'm attempting to get full accuracy.
It would be possible to find out if the updated solver is up to the task or not -- write a user program that returns the cdf and solve that. Anyone care to give this a try?
- Pauli