HP Prime and wireless connectivity



#2

For compatibility with HP Classroom manager software :

http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1907

Edited: 23 Apr 2013, 1:28 a.m. after one or more responses were posted


#3

Wow! And you thought teachers had a problem with the short range IR I/O on the HP-48 series.

#4

Hello,

It is not WiFi. Nor bluetooth. Nor is it integrated into the internals of each device.

The issue with those protocols in a classroom setting is that they tend to be far too difficult to configure. You generally have to mess with passwords, network selection, pairing and other similar things. While people are used to this, having something like that in a classroom setting causes more problem then they are worth due to things needing configuration, students messing with settings and so on. More often then not, they end up wasting more time then any benefit they allow due to the higher complexity.

Rather, the wireless comes in small receivers that are plugged into the calculator. Basically it is a small box that is ~1x1x3cm with a micro USB connector on the long side. This automatically pairs with the PC dongle. No manual setup of any kind is needed.

This is the same technology used in the HP mice/keyboards that can connect many devices to the same small dongle.

As for being an issue with teachers, it actually is completely impossible for 2 calculator dongles to speak to each other. All communication is triggered from the PC end. Also, they are bright orange or some other color like that. :-)

In addition, the wireless modules can be used very effectively for classroom monitoring to show what everyone is doing, sharing of data, configuration of exam modes that restrict functionality, displaying screens from any unit in the room, sending small quizzes or polls to the classroom (think things like "how many items are in your pockets?" in order to gather quick data for statistics lessons), and similar activities.

HP Classroom Manager is a related piece of software that allows teachers to monitor classroom PCs, limit activities, and do all sorts of cool stuff.

TW


Edited: 22 Apr 2013, 4:39 p.m.


#5

Tim,

Thank you for the clarification and the link. The wireless capability you describe makes complete sense in the classroom environment. The HP Classroom Manager software looks incredibly useful for managing a roomful of students on computers.


I have to say, I have not been so excited about an HP Calculator model since 1991 when I bought my HP-48SX. A color touch screen, real HP keys and RPL. It has everything I could ask for. I am buying an HP Prime as soon as it is available.

Steve


#6

Quote:
A color touch screen, real HP keys and RPL.

No RPL programmability, however.


#7

Maybe next year in the HP Prime'.


#8

I think that would make it a Prime Prime. Hmmm...


#9

Maybe it'll be the HP Prime IIS ?
Or the HP'' (prime prime) aka "HP Quote"

#10

Quote:
No RPL programmability, however.





True... But I have to confess that the vast majority of the hundreds of RPL and RPN "programs" I have written over the last 35 years (Yikes!) have been little more than short keystroke macros recorded for convenience of repetitive calculations. If the programming of the Prime is just like the 38GII, it will probably work just as well for me.



I still use my HP-48SX weekly, primarily for exploratory calculations.

#11

Not quite for me.

I spent last night going through my 50g and 27 out of the 35 programs I have written can be expressed algebraically or as keystroke macros easy enough. They don't really have complicated logic in them.

In RPL, parameters come from the stack which allows small programs to be composed from the results of others with relative ease. Much as the UNIX operating system allows elegant composition, so does the 48-series. This is a big selling point for me. ALG-type machines don't actually have that elegant composition support.

Consider the canonical example of a resistor network with two 10K's in parallel and both in series with another 10K. Off the top of my head that's 15K. However, if I have two RPL progs (RPAR,RSER) which do the inevitable with the stack (off the top of my head: << INV SWAP INV + INV ->NUM >> / << + >> ).

To solve in RPL:

VAR 10 10 RPAR 10 RSER --> RESULT

To solve in ALG (39G style):

RSER(RPAR(10,10),10) --> RESULT

Not quite as elegant with respect to composition of programs. I did consider using unary functions with list parameters but typically that just results in a version of LISP evolving which ultimately is an incarnation of Greenspun's Tenth Rule.

Unless I'm doing it wrong?

Anyone care to persuade me? :)


#12

I agree

10 15 RPAR 20 RSER --> RESULT

is far better for me than

RSER(RPAR(10,15),20) --> RESULT

In algebraic, you can also do

RPAR(10,15)
RSER(Ans,20)--> Result
But if the 10_Ohm etc are the results of previous calculation it's far more easy in RPN/RPL without using variables

If I understand well what Tim wrote, the Prime will allow RPN notation in interactive usage but not in programmation.

So I suppose
10 15 RPAR 20 RSER
will be allowed

but RPAR and RSER will have to be defined in an algebraic program

If the language is an evolution of the 39Gii, it will be very readable et powerfull although verbose in my opinion when you want do write a program directly on the calc. On the contrary, RPL is very powerfull, extremly compact but not easily readable ( a kind of 'write once' language)

On the 39Gii

EXPORT RSER(a,b)
BEGIN
a+b;
END;

EXPORT RPAR(a,b)
BEGIN
1/(1/a+1/b);
END;

Note that the 'return' value is implicit


Edited: 23 Apr 2013, 5:30 a.m.


#13

Didn't think of using Ans - thanks for the tip. It makes it slightly bearable I suppose.

I'm just going through my (now rarely used) TI 85, TI nSpire CAS and Casio 9850GB and am writing the same programs and to be honest they are pretty much the same as the 39GII language. They all feel awkward now I've got used to RPL, particularly due to the verbosity and tetchiness of the interpreters. I might document all this somewhere if I get a few hours.

I think the Prime appears to be a convergence machine i.e. everything is converging on BASIC-like languages. RPL is definitely the "odd one out" here.

Agree about write-only. I had to think hard to work out a couple of my RPL programs.


#14

While the 39gii-style algebraic programming language appears to be the right choice for the educational market (and is well-executed with defined functions appearing as built-in), I agree that the sophistication and system integration of RPL (e.g., any object can be a variable, passing objects on the stack, writing programs on the command-line, integrated CAS, etc.) make it a great programming language, especially for modern scientists and engineers who use matrices for numerics and CAS for analysis. I hope HP upgrades the hardware on which RPL runs, as RPL is, IMHO, one of the greatest assets among HP calculators.


#15

Agreed, a million times.

What would be nice is RPL without the Saturn abstraction (I think I've mentioned this before). I imagine it would be rather nice if it ran on native ARM.

Perhaps a WP34s-type project for the HP50g wouldn't go amiss and perhaps a hardware-abstraction-layer that would allow it to run on any ARM based device with enough RAM (even the prime?).

Hmm. Tempting.


#16

Nice thing about a 50g repurposing project is, the hardware already exists, it's perfectly capable of being a fully-featured RPL calc (by virtue of... already being the most fully-featured RPL calc), and it's already labeled as a scientific machine (so key legends don't need to be changed).

The trick would be keeping the features constrained to something sane, while avoiding a decrease in functionality, I'd think. And, if possible, it might be best to see if the SysRPL code that's already in the 50g's OS could be open sourced (if not, then there's always having a script download the 2.15 firmware, and then "patch" it (which would actually be, take out the relevant SysRPL bits, and drop them into a new firmware), but that's a royal pain) to reduce development effort.

And, there would also be the concerns about changing hardware - as I understand, just changing framebuffer size can break a lot of stuff (but is that breaking things for UserRPL code, or just SysRPL and asm?) Really, it's 2013, you'd want a way to get resolution independence of some kind, even if it's the Acorn/Sony/Palm/Microsoft/Apple hokey pixel quadrupling scheme (although, that's kinda ugly (and by kinda ugly, I mean really ugly) for 131x80 plus annunciators - 393x240 on a 2.7" Sharp Memory LCD could work, but then you'd have to move annunciators to the left side, and they'd be tiny. The other thing is, switch to using an impossibly high resolution internal graphics representation, and just use scaling factors to get the real resolution of the screen. Problem is integer scaling to all sorts of disparate modes, and floating point scaling (especially on 1bpp displays) gets really ugly really quickly.

There is also, just maintaining UserRPL compatibility, and being SysRPL-like under the hood, but not actually compatible. For most users, I'd think that'd be fine? Floating point scale grobs to fit, and to hell with everything else?


#17

Interesting thoughts there.

Agree with resolution independence: that is one of the real problems with the whole HP-48 series by the looks. I think a terminal + termcap + threaded VDU driver approach would work quite well i.e. you have a series of capabilities that the core system can determine the fundamentals from such as screen size. The core system can issue text and 2d primitives as async commands and just forget about them and carry on processing (like WPF on Windows/OpenGL). As for text rendering, all you need is a nice hinting algorithm and a good renderer preferably with sub-pixel rendering (for LCDs) and it'll look pretty good.

If there's one thing I've learned over the last few years of writing software it is "keep your abstractions thin". I think I'd probably throw SysRPL out of the window and use a VM layer written in C which runs a bytecode (direct threaded) UserRPL implementation. As for backward compatibility, I'd say scrap it and start again. The last thing you want is to pull 20 years of crud into a new platform.

After spending a couple of hours disassembling the ARM SWI vector (ASM-> rocks) and dumping strings the 50g hardware itself seems to have at least a microkernel in there already. I couldn't find any markers for anything off the shelf (I know nSpire for example uses Mentor Nucleus as the core). I assume this is Kinpo provided and probably not of any use. I didn't delve too far in case I broke something as I need this unit in good shape!

I might buy another one and take it to bits properly and find out the SoC vendor and see if I can flash a hello world to it :)

Another thing for the enormous ideas list I have...


#18

The trick with subpixel rendering is the display. That now means you need color, and even greyscale anti-aliasing ala RISC OS or Windows 95 still, um, needs greyscale - which isn't practical on the 50g (yes, it can do it, but it looks horrible), and isn't even possible with things like the 2.7" Sharp Memory LCD. Certainly, anti-aliasing support is important, but depending on it is a no-go, I think.

The "ditch SysRPL, keep UserRPL" approach could certainly work well, and there's precedence for HP doing it (the 42S being the prime example - SysRPL under the hood, and no claims of being compatible with 41C synthetics or mcode, but nearly fully compatible with legal FOCAL code).

As far as the 50g's CPU, it's a Samsung S3C2410, as I understand, so docs should be quite easy to get for it.

Edited: 23 Apr 2013, 5:56 p.m.


#19

Had completely forgotten about RISC OS (I was a user of it from 1988 to about 1994). With hinting you can render fonts acceptably in 1bpp. If you have a Windows machine available, turn off ClearType and fire up Wordpad. Then tap out a sentence and scale the font up and down. If you cache the generated glyphs as well you can get respectable rendering performance on even miniscule hardware.

Have obtained S3C2410 datasheet. ARM920T with MMU - perhaps a COTS kernel is possible (FreeRTOS/NetBSD).


#20

And the Pebble watch actually does that caching at the compilation stage - compile a program or watchface for it that uses a custom TTF, and it actually uses FreeType to rasterize the font when the program is compiled, so the watch doesn't have to do much at all.

Not that something with the 50g's power would have any problem with rendering vector fonts, and that'd save ROM space for more fun stuff (mind you, I think a kernel like NetBSD is MASSIVE overkill and probably wouldn't fit at all, but something like FreeRTOS might work well).

In any case, my concern wasn't just font rendering, but scaling raster images that were drawn for less capable platforms (like the 50g) onto higher resolution displays.


Edited: 24 Apr 2013, 8:19 a.m.


#21

I am primarily being lazy as NetBSD evbarm already supports this line of SoCs whereas FreeRTOS doesn't, plus I've got a fair bit of experience writing kernel mode stuff on NetBSD and some ancient history with ARM (3) asm :) I reckon I can get the runtime overhead of NetBSD for code/data segs and runtime memory usage to a manageable level. Kernel defensively allocates a lot of RAM at start which is fairly easy to crank down. Also some careful compilation dependencies can get a working OS down to ~ 400k.

Does anyone know if the 50g has a JTAG port, even if it requires soldering (before I open one)?

I'll start with trying to get a hello world over serial first before attempting to think about fonts :)

Pile of bricked 50g's here I come :)


#22

Of course, the S3C2410 has off-board RAM, so it may be possible to upgrade that, too. (Not sure what part is being used.)


#23

Not sure I want that soldering job :)

#24

Thank you Tim for your explanations. I've corrected my piece of news.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Prime Connectivity Kit Suggestion toml_12953 1 534 12-06-2013, 10:41 PM
Last Post: Michael de Estrada
  Gathering USB dumps for Connectivity Kit <-> 39gII communication... debrouxl 2 563 12-01-2013, 12:59 PM
Last Post: Marcus von Cube, Germany
  HP Prime Connectivity software in Virtualbox/wine Chris Pem10 2 522 11-22-2013, 02:20 PM
Last Post: Chris Pem10
  HP Prime - Connectivity kit purpose bluesun08 2 457 11-11-2013, 10:37 AM
Last Post: Michael de Estrada
  Connectivity Kit Les Koller 1 418 11-10-2013, 06:38 PM
Last Post: Michael de Estrada
  Hp PRIME - how to send a list to the connectivity Kit giancarlo 1 450 11-10-2013, 11:50 AM
Last Post: Tim Wessman
  Proper location for files on the PC for Connectivity Kit ,etc. Harold A Climer 8 1,044 10-23-2013, 02:43 AM
Last Post: Marcus von Cube, Germany
  HP Prime vs. 39gII Connectivity Kit Marcus von Cube, Germany 3 583 10-09-2013, 05:44 PM
Last Post: Marcus von Cube, Germany
  what can I do with the connectivity kit? bertopl 9 931 09-30-2013, 08:57 PM
Last Post: bertopl
  Fresh at this but excited: questions about 71B connectivity John Stewart 9 890 03-14-2013, 01:04 AM
Last Post: Michael Burr

Forum Jump: