WP 34S USB flash adaptor arrived



#27

The PCBs have arrived.
The first picture shows the PCB that replaces the original one in the HP flash cable. This converts the cable to USB so it can be directly pluged into the PCs USB port.

Next is my original design for the integrated USB adaptor using a mini USB connector. The pictures show the preparation of the calculator and the PCB glued in place. This version also includes the handling of a lithium ion battery that is charged via the USB port.

Sorry for the poor solder quality. I ran out of solder and had to use the horrible lead free stuff, because I wanted to get it up an running....

I also have made a version using a micro USB connector, requiring less modifications to the calculator housing. I am still wating for the connectors to arrive.

There is also a basic version without the lithium ion battery handling:

I have a few spare PCBs and parts for now. So if anyone is interested, please let me know. If there turns out to be a real interest in this, I can also have more made, but would rather wait and include other things like the LED for the printing port and SPI memory.

Cheers,
Harald


#28

Harald, this is great news! Wonderful. Amazing things coming along for the WP-34S.

The cables I have been mailing out (and I have mailed alot - 6 more today) will NOT be around forever.

When the ones I have now are gone, they are gone. Period. So we need future alternatives and this is a great step. Bravo!


#29

Thanks for the kind words!

I have been talking to Eric about this as well. He was looking into getting the connectors to plug into the calculator. But since he hasn't got back to me, I assume he had no luck. This would render the cable conversion PCB pretty much useless, unless someone wanted to convert a cable he got already got from you.


#30

That's correct. I haven't found anything yet and I am not optimistic that I will be able to find anything.

Eric


#31

Quote:
That's correct. I haven't found anything yet and I am not optimistic that I will be able to find anything.

Eric


It is a lot like an old Garmin GPS connector. The pfranc plug guy has made a lot of custom connectors (injection molds and pins) and may have something...

#32

Gene,

Please check your LinkedIn Inmail... I have been trying to contact you for a cable without much success.

Jeff


#33

Hey Jeff.

Email me at my name, no spaces, then 143

at hotmail

#34

Quote:
I have a few spare PCBs and parts for now. So if anyone is interested, please let me know. If there turns out to be a real interest in this, I can also have more made, but would rather wait and include other things like the LED for the printing port and SPI memory.

I'd definitely be interested in some for my hoard of 34S's. I can wait for the all inclusive version of course.

The LED for printing is a given at this stage. The SPI memory is still very uncertain. Until we know it will actually work and be fast enough to be useful, it will stay that way.

A single PCB with all the extras will be a great boon.


- Pauli


#35

Which one would be most interesting from your point of view?
The "basic" version without the lithium ion handling and an added IR diode for the printer?

I am not too keen on marketing the lithium ion versions as I don't want to be resposible for things going wrong with the battery....(although I have no reason to belive something would go wrong)

Maybe it is time to start a poll: Who would like to see what?

Cheers, Harald


PS: here is a picture of the completed WP 34S. I am hoping the micro USB version will look a little nicer. Hopefully cutting into the battery door can be avoided.


#36

Definite on the IR diode.

Definite on the USB connector.

Definite on the SPI memory (if it turns out workable, if not ignore).

I don't mind either way about the lithium ion battery handling, not until I put one into a device that is :-)


The 30b hardware has some A2D interfaces padded out -- these could be exposed too. If the SPI doesn't work, there are some GPIO pins freed up too. Would there be overwhelming interest in these? Assume that these are exposed raw and without any safety features to prevent CPU cooking.


- Pauli


#37

I'd be interested in using the A2D pins if they could be made available.

#38

How does one expose the A2D pins i.e. is the chip soldered or directly wire bonded to the circuit board?


#39

Quote:
How does one expose the A2D pins i.e. is the chip soldered or directly wire bonded to the circuit board?

There is an unpopulated pad on the circuit board that contains four A2D lines. Find the technical specs for the CPU (AT91SAM7L128). These four are built into the chip.


- Pauli

#40

I'm with Pauli: USB, LED, memory. And I would need more than one for experimenting. :-)

With SPI memory it will certainly be V4.


#41

Quote:
With SPI memory it will certainly be V4.

If not the 43S. It all depends on far we go....


- Pauli


#42

Quote:


If not the 43S. It all depends on far we go....

- Pauli


And I was dreaming that the 43s would be on a completely other hardware...

#43

Quote:

And I was dreaming that the 43s would be on a completely other hardware...


Could be as well. Not decided yet. So far it's only the 43S (TM). :-)

#44

The decision to change to a 43S, I think, lies in the implementation of proper typed values or not. If we implement typed values, 43S becomes the natural step. If not, it will stay as the 34S.

All this hinges on the speed of the SPI memory. We'll almost certainly be relegating all library code to the SPI memory if not more. Having library code execute glacially slowly will abort this idea.


- Pauli

#45

Can you specify a memory chip you would like to use?


#46

Pauli has come up with this one: FM25V02-G (Link to Digikey) but we think more of a larger device which might aid in keeping the access simpler.


#47

Ok, sounds like I should wait until you are sure about what you want to use.

Cheers,
Harald

PS: I have installed an IR diode now - can't wait to get the printer tomorrow (it is still at my parents house) and see how it works...


#48

I made it happen but will be one of the last to try it on my device. Life is unfair.


#49

Marcus,

Are your LED's taking a long time to get to you for some reason. Can I help?

-Katie


#50

I'm still hoping for a few days. I just ordered them from a local supplier.


#51

According to Element 14 these IR LED's are made in Germany. Just drive to the plant and do a dumpster dive!

If not get them from Element 14, they should be able to ship them overnight to you for not much money.

#52

Do you have an old IR remote control you could steal the diode off? That could save you some time.

#53

Most of these devices are pinned out the same. The other one would likely be link to digikey. There is a 2Mbit (256kbyte) device as well but it seems like complete overkill.

Our address space is limited by the size of the program counter I chose and changing this would be painful (but by no means impossible). Thus, a 32kbyte device is close to the maximum we could address as programs/library. The above large (128kbyte) device would allow us to include some optimisations to avoid searching through RAM for labels (by including the destination address in the JMP instruction) and keeping a table of global labels.

Alternatively, the extra memory could be used for data, matrices or even 41-series extended memory like files.

The disadvantage of the larger memory device is the extra byte of address information required which will slow down accesses.


- Pauli

#54

Harald:

I would vote for that "basic" version (no Li-Ion handling) with an added IR diode!

Nice work!

Bruce.

#55

Same for me: basic + IR. I don't need the lithium-ion battery, however how difficult would it be to be able to power the WP-34S from the USB connector (as for the 50g)? For the cases when I know that it will run a program for a long time, it would be good to left it unattended without worrying about batteries.


#56

At the moment the battery gets supported when it drops below 2.7V. But with a few modifications it would be possible to power the calculator of the USB when it is plugged in and switch to battery if not.

Good idea!

#57

Very nice work Harald.

Options I would be interested in:

Micro USB: Yes
IR diode: Yes
Li-ION: No
Other I/O (e.g. SPI, GPIO): not at the moment
As the memory expansion is not defined yet, perhaps this could be a separate PCB at a later stage? In your photos it seems the PCB without the Li-Ion control is short enough to allow another PCB next to it?

Thanks,
-Bart

#58

Quote:
As the memory expansion is not defined yet, perhaps this could be a separate PCB at a later stage? In your photos it seems the PCB without the Li-Ion control is short enough to allow another PCB next to it?

Thanks,
-Bart


Yes, the basic version is not very large at all. The diode will add a bit to that, but I am not sure how to get it in mechanically yet.

I think I would simply make a new PCB adding the memory if and when that is reguired. That is easier than a seperat PCB.


#59

Quote:
I think I would simply make a new PCB adding the memory if and when that is reguired. That is easier than a seperat PCB.

Yes , it would probably better to have 1 PCB and just replace it.
#60

if carrying out case modifications for the USB connector and IR LED, how practical would it be to consider also machining out space to fit two AAA batteries for power? that way li-ion batteries would become a tad superfluous, as a couple of AAA cells would last for ages.

would two AAA cells fit within the exterior dimensions of the existing case?


cheers,
rob :-)


#61

It's probably much easier to add AAAA cells instead. You can normally salvage these from a 9V block.

#62

Nice job! It definitely needs a place for the IR emitter as the board position as you have it will interfere with mounting the diode as I have at to top end of the calculator.


#63

Yes, that is my next task. I would like to mount the diode on the PCB as well. But I am a bit concerned that assembly of the calculator might be too difficult with the micro USB sticking out on the left and the IR diode on the top.

The most popular solution seems to be the combination of USB interface, IR diode for printing and USB power while the calculator is plugged in. I think I will not go for the memory yet.

#64

Fantastic job. I'm in for a couple of copies of your final version.

Regards,
Bob


#65

Same for me.


#66

+1


#67

Likewise.


James

#68

I've like to get a USB interface board, but I think I'll stick with the stock coin cells. Can that be done?

Got any pics of the IR installed?


#69

Quote:
I've like to get a USB interface board, but I think I'll stick with the stock coin cells. Can that be done?

Yes, that is the "basic" version

Quote:
Got any pics of the IR installed?

No, not yet, I haven't made PCBs for that yet. I will post an update when I have them.

#70

Quote:

No, not yet, I haven't made PCBs for that yet. I will post an update when I have them.


I eagerly await the update. It shouldn't be too hard to shoehorn in a T1 LED and a resistor. It seems like a transistor is not necessary unless there's some power consumption consideration I'm not aware of. What's this SPI memory thing?

Given how thin the flying wires are, it may be more sensible to use pads instead of holes for attaching them to the board.


#71

Quote:
I eagerly await the update. It shouldn't be too hard to shoehorn in a T1 LED and a resistor.

Not, that is simple. The problem lies in the assempbly of the calculator. People would have to be very exact with the positioning of the hole for the LED. And also I am not sure how it will be possible to slide in the connector on one side and the led on the other at the same time when assembling the unit.

I have the feeling there will be a pad on the PCB to connect the LED. This will require a little more soldering and one extra wire, but a lot less hassle mechanically.

Quote:
It seems like a transistor is not necessary unless there's some power consumption consideration I'm not aware of. What's this SPI memory thing?

I agree, we don't need a transistor. The SPI memory is a nonvolatile memory expansion Pauli, Walter and Marcus are planing.
Quote:
Given how thin the flying wires are, it may be more sensible to use pads instead of holes for attaching them to the board.

I went for that option because it is more robust. I might switch to pads though, because they will make it possible to solder the wires to the pads after glueing the PCB in place (without burning the plastic behind it)
#72

Harald,

Are you using a separate (rectangular-ish) lithium-ion cell? Or did you modify the PCB traces to use the existing coin cell receptacles with a li-ion coin cell? I know they come in the CR2032 size, because my MCF51JM "Badge Board" runs on one. (The one they used keeps its charge for a long time with the board turned off, too.)

For my purposes, I vote:

USB: yes

Li-ion charging / regulation: yes

IR printing: yes

(In fact, I have 3 82240A printers and don't need them all.)

SPI memory: probably yes -- but not a big issue for me

Is IIC available? (Don't have the schematic in front of me...) There are lots of IIC EEPROM devices available that are easy to interface. 24LC64 is an 8-pin SO with 8k bytes, so it's probably too big physically and too small memory-wise, but I'm sure there are smaller faster cheaper roomier better ones. Maybe not as fast as SPI, but is that critical?

(Sorry, I use SO devices on my toys, because I can't hand solder the smaller stuff and haven't yet tried converting a toaster oven for reflow!)

It would be too cool if you could fit a MicroSD card socket on that board and use SPI for that. Yes, the FAT file system would use WAY too much precious flash....... but if the user program library(ies) went in IIC EEPROM or other non-volatile, that might free up 6 or 8 kB of flash, which should be enough for Chan's FatFS. Or is the 600-ish bytes of RAM needed for sector buffer and other variables the problem?

Dale


#73

The problem is that IR printing alone has eaten 1.5 KB of flash (minimum). We can use any space we can get and an external fast and reliable device could probably not only serve as library storage but for any program code or even data.

#74

I2C isn't exposed. The SPI pins are. Hence the desire to use SPI memory.

The speed difference will be critical. We'll be executing keystroke programs from this memory at the very least and we've no RAM available for buffering (well almost none), so we'll be reading on demand or at most prefetching a few instructions.

If the SPI memory is fast enough, we'll put registers there as well.


I'm looking at FRAM because it is fast, very low power and, at least at the sizes we'll be needing, not too expensive.


- Pauli

#75

Quote:
It would be too cool if you could fit a MicroSD card socket on that board and use SPI for that. Yes, the FAT file system would use WAY too much precious flash....... but if the user program library(ies) went in IIC EEPROM or other non-volatile, that might free up 6 or 8 kB of flash, which should be enough for Chan's FatFS. Or is the 600-ish bytes of RAM needed for sector buffer and other variables the problem?

There are pins to enable 2 or 3 SPI devices, so this might be possible. If SPI memory works out, we'll have circa 8kb of flash clear to support it and any other extensions -- FAT handing might fit in that. The sector buffer would be possible but not while executing a program.

A lot hinges on SPI memory being fast enough.


- Pauli


#76

The only way to find out is doing it. That's the way printing came to the WP 34S and many other features like on board flash writes. It's a shame that modern controllers cannot map external memory into the address space.


#77

Quote:
It's a shame that modern controllers cannot map external memory into the address space.

Many modern controllers can. It's a shame that the AT91SAM7L cannot.

#78

For FatFS, the compiled code size and RAM usage for various processors and options (read only or read-write, and other optional file library calls we may or may not want/need) is shown here. Of course, this doesn't include any application menus, etc., needed to actually DO something once you can read and write files. The team would also need to write the basic low-level block read and block write routines (simple blocks of SPI reads and write), and get the card detect and write protect status (two more discrete input pins needed), initialize the interface, stuff like that.

If you don't have too many files open at the same time (say, one or two), and if you can live without extra buffering, the TINY option gets you down below about 600 bytes of RAM usage.

FatFS can deal with FAT12, FAT16 and FAT32, so SDHC cards are no problem. I'm using it in an over-simplified MP3 player, reading files from the root directory only, in an 8-bit micro with 32k flash and 2k RAM. Most of the flash is actually filled with ridiculously-overcompressed MP3 "files" for the built-in sounds for card insert ("da-DINK"), card remove ("DE-dunk"), card error ("dunk-dunk-dunk") and a "click" sound for feedback on pushbutton presses, etc. Since I used the TINY option and the READ-ONLY option, the footprint is quite small. But I assume we'll want to write to the card to save user code, registers, etc.

Understood on only SPI, and a couple chip selects available. Fair enough. But the other issue might be power. Pullups on various lines are insignificant, but the card itself can pull a fair amount of current. Most are spec'ed at about 40 or 50 mA during write ops, but I think the limit in the SDCard Specification is 200 mA. That might actually be more of a problem than finding a place to shoehorn the code. I'm guessing that lithium ion cell power would be a "required option" if you want to have the SDCard option.

Dale


#79

Thanks for the link.

The extra couple of input pins could be a problem too.


- Pauli


#80

Pauli (and all),

I thought the additional pins might be an issue.

I tried to cover all the considerations I ran into in my project. A few last thoughts on SDCard implementation (based on my one hobby learning experience only) follow...

I've been working with regular size SDCards (again, easier to hand solder the socket to the PCB for these old eyes and hands...). For the full-size cards, you need to have the card detect input so you know when to initialize. And if you do any writes to the card, you need to have the write protect input, because it's a mechanical slider on the edge of the card, and you must respect it. (My project was read-only, but I pinned the write protect to an input anyway, just in case I wanted to do something else with the circuit.)

But as I think about it now, I'm pretty sure the MicroSD socket doesn't need a pin for write protect. I think it's done electronically (data on the card) rather than mechanically. So in addition to the SPI data in, data out, clock and slave select, I think you just need card detect. Maybe that helps.

Since my project was read-only, I only needed to develop disk_read(), disk_status() and disk_initialize(). If the whole SDCard thing is worth pursuing, I'd be more than happy to forward the source I developed for these --- but it's for the MC9S08QE32 and Freescale's SPI implementation. You're probably better off with the examples that come with FatFS for ARM code.

I had a couple hiccups with the READ_ONLY option on my compiler (Code Warrior), like a variable or two that were declared/initialized in code that was #ifdef'ed out. But I was using FatFS 0.6, and it's up to 0.9 now, so perhaps that's all fixed.

One last thought: when you create or modify a FAT file, you write a timestamp in the directory entry. If we'll be writing files to the card, we might also require having the clock crystal/capacitors and semi-reasonable timekeeping (if you want the file create/modify timestamps to make sense, that is). I didn't have to for my project, but this is one of the things that you have to provide in the disk_ioctl() code that you provide underneath FatFS. (And you have to provide disk_write(), of course.)

Hope this all helps....

Dale

p.s.: Apologies if this should have gone only to Pauli and not to everybody. But I always like learning the gory details from the postings here -- so I decided to err on the side of informing all.


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 1,004 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 552 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 796 12-04-2013, 11:14 AM
Last Post: Barry Mead
  Gathering USB dumps for Connectivity Kit <-> 39gII communication... debrouxl 2 608 12-01-2013, 12:59 PM
Last Post: Marcus von Cube, Germany
  WP 34S/43 ?'s Richard Berler 3 708 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 734 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 966 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 997 11-08-2013, 01:28 PM
Last Post: Nick_S
  PRIME: re-format the flash drive to recover the operating system Harold A Climer 2 590 11-06-2013, 12:22 AM
Last Post: Michael de Estrada
  m.dy in display of WP-34S Harold A Climer 3 615 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin

Forum Jump: