Files published to GitHub

You can find the files for this project in GitHub: https://github.com/jake-b/Newton-Internal-WiFi

3D Printed Port Cover

Since the MP2x00 did not come with an internal modem (and one was never sold), each MessagePad came installed with a little plastic cover that fills the space where the RJ-11 jack would be.

This is the same cover where apple would place a "2100" sticker indicating that a MP2000 was upgraded to a 2100.

Due to an oversight, the WiFi card extended into the area where this plastic cover would sit.  (I'm not sure this could have been avoided, even if I had planned ahead)

Instead, I've designed a replacement cover that does not interfere.  For good measure, I added an embossed WiFi logo to indicate that the internal WiFi card is present.

I think it makes for a nice finished product.

The STL files for the port cover can be found here: https://github.com/jake-b/Newton-Internal-WiFi/tree/master/Port%20Cover

WiFi Board v1.1

I got the revised boards and finally found some time to assemble a board.  This board adds a logic inverter to fix the flow control, and removes some extra traces for an alternate reset circuit.

To assemble the board, I had a stencil made and used it to apply solder paste.  Then I placed the components using a very simple "pick and place" rig:

This jig was made from a piece of brass tube, a leur lock fitting, some tubing, and a 22ga blunt dispensing needle.   It was mounted in a cheap USB microscope holder (available on eBay or Amazon) and hooked to a vacuum pump that I already had.   There are many more complicated versions of this rig on the internet, but this simple setup worked fine for me.

Finally, I baked it in a toaster oven that I got for free at a garage sale, and a rocket scream reflow shield.

Everything works great.  I consider this project a success.  All thats left to do now is to 3D print a replacement for the plastic "plug" that covers the hole in the case.

Finally, a little application that uses the method mentioned in an earlier post to enable the board when the 'modem' port is opened:

Thermal Performance and Loose Ends

Thermal

Early designs used a linear regulator to supply 3.3v from the Newton's battery voltage.  It became pretty obvious that a linear regulator would get too hot, and so I changed it for a switching regulator.

I wanted to do a real world test.  The WiReach specs say that it can draw around 350mA peak during transmit.  I modified the Thumb sample code into a program that would output a continuous stream of ~25kB packets.  I taped a thermocouple to the regulator and ran the test for an hour or so.

The results were promising.  From room temperature, the regulator went from 77.4F to a high of 85.1F.  This satisfies me that in my normal use the board will not overheat.

A wise man once told me:

"People might be using such a Newton on a camp site close to Death Valley in August. Before you release such a circuit into the wild, you should put the assembly into the baking oven at 60 degrees centigrade and see what happens..."

Good advise, but I don't think I'll be performing that test.  I just can't imagine putting a Newton in a oven for any amount of time.

This test is anecdotal at best, I guess.  Was the WiReach module anywhere near its peak transmit power or current draw?  I don't know.  At 115200bps, I'm not sure that the Newton can saturate the WiFi module such that it would need to draw its maximum.

Physical

I found one other minor issue with the physical design.  I intentionally pushed the module as close to the edge of the Newton as possible-- into the space where a telephone jack would have been for an internal modem.  The module is large and getting it in just the right place and keeping the board within a 5cm square took some trial and error.  Also, I wanted the antenna area as close to the edge of the case as possible.

Well this made for one unintended consequence-- the "plug" that covers the hole likely won't fit, and it will interfere with the WiReach antenna connector and board.   It isn't the end of the world really -- I intend to 3D print a new plug with a little more clearance, and maybe an embossed WiFi logo so you can tell from the outside that there's a WiFi card installed.

An ugly fix

It is ugly, but it works:

I soldered leads to a 1-gate logic inverter.  This wasn't easy because the part is so small.  Then connect it to 3.3v, GND, and the RTS line coming out of the WiReach.  Then I cut the RTS trace on the bottom of the board.  I connected the output of the inverter to the input of the line driver IC.

Some Kapton tape holds it all in place.   It is a really terrible hack, but it works.  Hardware flow control works as expected, now.

I'm going to design a version 1.1 of the board that includes the inverter.  Also I can remove the extra GPIO/Reset stuff since the "power good/reset" circuit works.

WiFi Board For Newton: A Success?

I'm going to call this one a success.

There is an error in the hardware flow control circuit, but that's due to an error in the N2 Platform documentation.  I'll take responsibility because I should have more thoroughly prototyped (which I thought I had, but oh well)  I'm still planning on hacking an inverter onto the board to fix the issue.

Even so. I'm chalking this one up as a success.

A few last details:

The Antenna

I found a really small antenna.  I think its really for bluetooth devices, but it seems to work fine.  It is so small, I was able to tuck it in a small gap between the power connector and the interconnect port.

WiReach Configuration

You need to send a few specific commands to configure the WiReach module.  The most important is AT+iWANS=1  which tells the WiReach that the WiFi network is the WAN subnet.  Also you need to configure a username and password (which matches the PPP configuration on the Newton.)  AT+iRAU and AT+RAP are the commands you use to set the username and password.  And of course you'll need to connect to your network using:

AT+iWLSI=My_WiFi
AT+iWST0=4
AT+iWPP0=<WPA2 passphrase>

I use PT-100 to configure the module.  Then a Serial Internet configuration with a script.  The script is simple.  First, it pauses for a few seconds to give the module time to power on.  Second, it sends the at+iSPPP:0 command to start the PPP server.  Finally, it waits for the OK.

How Does it Work?

My goals when I started this were:

• The case had to close and everything had to be fully internal.  
• Find an antenna and antenna placement that would work without modifying the case or the shielding.
• Enough range to reach my router from my couch...
• Connecting my Newton to a WPA2 network.

In all, despite the flow control thing, I'm pretty happy with the end result.  The project meets my requirements.

I'm trying to decide if I want to do a v1.1 board with corrected flow control signals.

Subsystem Power Configuration for Fun and Profit

Up till now, I have been following Ekhart's template for enabling the serial signals: directly calling the ROM functions to toggle SerPortSel.  The only issue with this approach is that the OS also toggles these signals when a port is opened.  This means you have to configure the signals after the serial port is opened.

Wouldn't it be great if you could tell NewtonOS that you wanted SerPortSel to be "set to internal" when you open Serial0 or Serial3?

The trick is the functions TVotagerPlatform::SetSubsystemPower() and its twin TVotagerPlatform::GetSubsystemPower().  These functions involve a bitmask that tells the Newton which power rails a subsystem requires.  It is a 8-bit mask but is set/returned as a ULong.  By looking at the disassembly of TVoyagerPlatform::PowerOnSubsystem(), I have found the following flags:

#define kNeedsPowerOnSrc5v     0x01
#define kNeedsPowerOnSrc12v   0x02
#define kNeedsPowerOnIC5v     0x08
#define kNeedsPowerOnDMA       0x10
#define kSetPortSelectExternal 0x20

The constant names are my own invention.  The key one is kSetPortSelectExternal.  When this bit is set, the NewtonOS conigures the SerPortSel LOW, indicating an external device connected to the interconnect port.  When this bit is clear, it configures the SerPortSel HIGH, indicating that the internal serial slot will use the port.

These functions need an index or ID of the subsystem involved.  Again, looking at the disassembly, you find the relevant index.  There may be more, but the ones involving the serial port are:

#define kSerial0SubsystemIndex 1
#define kSerial3SubsystemIndex 3

Again, the constant names are invented.  So some simple pseudocode to tell NewtonOS "when you open 'mdem' set SerPortSel3 to HIGH" might be:

theVotagerPlatform->GetSubsystemPower(3, &flag);
flag &= ~0x20; // clear the bit, setting internal
theVotagerPlatform->SetSubsystemPower(3, flag);

When the serial port is opened in software, the NewtonOS reads the bitmask and enables the proper voltage supplies and sets the SerPortSel apporopriately.  When the port is closed, the GPIO line is returned to its default state.  Note for Serial0, the default state is "internal" (HIGH) until you open the port, as this disables the LTC1323 (used on the external port), probably to save power.

These settings are reset on reboot, which I think is probably for the best.  You could always have a Pacakge that sets the flags on boot.

Currently, this is what I consider the "right way" or at least the "best known way" to use the serial port select signal for the internal slot.  It is much better than manually toggling the signal with the SerialPortXLineDriverConfig functions.

I dislike hardware flow control

I can't ever seem to get the flow control lines right.   The current prototype only works with flow control disabled.

The N2 Platform docs says that the Serial3 signals are"ModemNotCTS" and "ModemNotRTS".  The WiReach docs also use inverted signals "nCTS" and "nRTS".  So I connected them up to each other thinking that they're all using the same signaling logic.

But I was wrong, and I think the n2 docs are too.  It seems that the Newton's CTS line is not inverted.  This can be verified with a  loopback.  When RX-TX are connected and RTS-CTS are connected, you will not get an echo when hardware flow control is enabled.

Similarly, if you connect CTS to GND, you won't get an echo.  If you connect CTS to 3v, you get the echo.

So this tells me that CTS is not inverted.  Per this site:

RTS and CTS are normally held high (TTL 1).  When high, no request (RTS) has been made, and no permission (CTS) has been granted.  When the PC is ready to send data, it brings TTL RTS low.  The MCU sees this.  When the MCU is ready to receive data, it brings TTL CTS low.  The PC sends data as long as TTL CTS is low, and stops when the MCU takes TTL CTS high.

The opposite seems to be happening no the Serial3 signal.

So what next? Well the board works fine without hardware flow control... but I'm going to try and "dead bug" a 1 gate inverter onto the board on the RTS line coming from the WiReach.  It won't be pretty, but it should work.

Serial Channel 2

The Newton's internal serial slot exposes 3 serial channels.   Serial 1 and Serial 3 are the most interesting, as they have a full set of signals and are selectable by the selection signals.

I was searching for a way to control SerPortSel3 within software.  When you open the serial port on the Newton, it sets SerPortSel3 LOW.  I had hoped there was a parameter you could pass to the endpoint that would keep SerPortSel3 high.  (See earlier posts)

I was searching the DDK headers and I found this (HALOptions.h)

#define kHWLocExternalSerial 'extr'

#define kHWLocBuiltInIR 'infr'

#define kHWLocBuiltInModem 'mdem'

#define kHWLocPCMCIASlot1 'slt1'

#define kHWLocPCMCIASlot2 'slt2'

#define kHWLocPCMCIAAnySlot 'slot'

#define kHWLocBuiltInExtra 'tblt'

kHWLocBuiltInExtra seemed promising.  I haven't seen it mentioned in any of the other docs.  So I whipped up a little package to enable it as a valid modem location:

InstallScript := func(partFrame,removeFrame)

   begin

AddArraySlot(GetGlobals().ModemLocations, {title: "Modem", id:"mdem"});

AddArraySlot(GetGlobals().ModemLocations, {title: "Extra", id:"tblt"});

   end;

I had hoped that 'tblt' would open Serial3 and set SerPortSel high.  This is not the case.  It turns out that kHWLocBuiltInExtra is actually Serial Channel 2.

The n2 platform documents say that SerialChannel2 is a "low speed channel for printer support".  I've also seen references that Serial2 is for keyboard.  Since Serial2 is not exposed on the external port, I don't think that it is used for the keyboard.

In all, kHWLocBuiltInExtra is one more piece of the internal serial slot puzzle.

It Works! (Sorta...)

It works! (Sorta) I finally got all the parts together to assemble the project. I started by populating the 3.3v regualtor section of the board, just to make sure it works. It did, a nice stable 3.29v.

I then proceeded to blow up the regulator somehow. I was trying to load it with a few ohms of load to simulate a 300mA draw... but that shouldn't destroy the thing. Maybe I connected something incorrectly or zapped it with static. Luckly, I had enough parts to try again. Again I populated the 3.3v regulator first, and checked the output. Again, a nice output voltage. This time I threw caution to the wind and just populated the rest of the board.

At first I thought the thing was not working. But then I tried disabling flow control, and moudle responded.

This means a few things:

•  Power regulation seems to work as expected
• The auto reset (which holds the module in reset until power-good) seems to work. 
• The buffer IC is forwarding the RX and TX lines between the Newton and the module properly. 
• My track record for screwing up hardware flow control may be unbroken. (Sadly)

Now there are a few things going on here, so maybe the hardware control isn't broken. 

First, when PT-100 connects, it turns off the SerPortSel3 signal. This powers down the module. PT-100 then reports a Buffer Under-run... I can then manually toggle SerPortSel3 and communicate with the module. I am wondering if the fact that the module is powered off during the process of opening the serial port does something to hardware flow control. Maybe it gets things in an inconsistent state. I am not sure.

I haven't tried using NIE yet, but I was able to connect to my WiFi network (WPA2) and ping my router using the AT+i command set.

Now if only I can figure out why hardware flow control doesn't work!  If someone wants to check my work, the relevant part of the circuit can be found below:

WiFi Update

Some updates on the project:

1. I was unhappy with the linear regulator's heat performance, so I changed to a switching module.  This increased the number of passive components a bit.  I found a nice module from TI that has an integrated inductor, so the whole thing still fits nicely.  The PCB layout is tricky for switching regulators, but I did my best to follow the guidelines in the data sheet, so I'm hopeful it will work as expected.
   
   Rather than making a separate breakout board to prototype the regulator, I just went ahead and ordered the PCBs for the whole project.  I'll reflow the regulator components first and test the circuit out before reflowing again to add the WiReach and additional components.
   
   
2. Mathias suggested a buffer to translate between 3.3v and 5v signals, but this is all 3.3v logic.  I did add a buffer for another reason-- the fact that the module is powered separately from the Newton means that the Newton can be pushing 3.3v logic signals when the module is powered off.  I checked with ConnectOne and the module is tolerant to this, but it wastes power and possibly causes problems with an inconsistent state on power-up.  By using a buffer, the logic signals are kept at the same voltage level as the module itself.  I chose a buffer that has "power off protection on inputs and outputs" which means the buffer can be at Vcc=0 and still tolerate signals coming from the Newton.¹
3. I have an idea for the reset circuit.  The power regulator has a "Power Good" output that holds to ground until the power regulation hits the target voltage.   The idea is to tie this to the WiReach module's reset pin.  This should hold the module in reset until the power regulator is fully online.  This only costs one extra pull-up resistor.
   
   In case this strategy doesn't work, I've got an alternate setup where the Newton's extra GPIO can trigger the reset.  The GPIO is looped through the buffer, again to keep the logic at the same voltage as the WiReach supply.  A solder jumper selects which reset circuit you wish to use.  The WiReach reset pin is an open-drain, and can be pulled low by the module.  I added a 200 ohm resistor inline to limit the current should the Newton be outputting a 3.3v signal while the module is pulling down its own reset signal.
4. Switched the test pads to just pads rather than thru-holes.  Moved them near the edge of the board so I can clip on with alligator clips to test.  Exposed the reset and MSEL signals as test pads on the back of the board as well.  These can be used to reset the module into rescue mode if necessary.
5. Some of the routing is a little odd but I tried to keep the jumpers on the bottom layer as short as possible.  This resulted in few extra vias.  I wanted to keep the ground plane as intact as possible.
6. I'm still paranoid about the hole locations and the physical design fitting properly, so I 3D printed another mockup to test the fit.  Seems to work well.  Hole placement is still iffy.  I'd love to know the real measurements.  Each time I tweak it a little, but never seem to be happy, so I'm finally just going with it.
   
   

So the board is off at ITEAD Studio being built, assuming it passes their error checks. update: it passed error checks and is being manufactured I also ordered two solder stencils from OSHStencils.  I also built a reflow toaster out of an old toaster oven I got for free from a garage sale.  All that's left is to get some solder paste.  I also want to build a little pick and place jig to help place the small components.

Hopefully this will all work in the end... and then there's still the antenna to figure out.
________

1. The data sheet for the On Semi MC74VHCT50A is vague on exactly what "Power Down Protection Provided on Inputs and Outputs" actually means.  I did a little testing on the bench, and found that when Vcc=0 the inputs and outputs seem to work like they are Hi-Z. (I'm not sure how to verify that they are definitively Hi-Z, but I can't measure any current flowing in or out when Vcc=0) It expect it to work for this application. ↩

SSL: An Exercise for the Reader

As a diversion, I tried to compiling an SSL library for the Newton.  I settled on CyaSSL, because it is designed for constrained devices.  For example, you can define macros that conditionally compile for devices that have NO_FILESYSTEM or NO_DEV_RANDOM.  That sounds a lot like the Newton.

Building

I got surprisingly far in compiling the library.  First you need to edit settings.h and add a section defining the compilation for the Newton, then pass this definition using "-D NEWTON" to the compiler:

    #ifdef NEWTON
        #define USER_MATH_LIB
        #define BIG_ENDIAN_ORDER
        #define SINGLE_THREADED
        #define NO_DEV_RANDOM
        #define NO_FILESYSTEM
        #define NO_STDIO_FILESYSTEM
        #define CYASSL_USER_IO
        #define NO_WRITEV
        #define SIZEOF_LONG        4
        #define SIZEOF_LONG_LONG   4
    #endif

One issue is that the Newton doesn't seem to support an 8-byte integer data type.  There is one configuration in settings.h where they #undef SIZE_OF_LONG_LONG. (I assume this is if you don't have a long long datatype) When I try this, it throws an #error, so I set both SIZEOF_LONG and SIZEOF_LONG_LONG to 4 and everything seems to compile.  (Note: There is a Int64 datatype in the C++ headers, but its just a struct with two longs.)

Next you need to define a GenerateSeed() function in random.c.  I just passed rand() from the CLibrary back.  The Newton doesn't have a /dev/random or a good source of entropy that I know of.  I just wanted to get things to compile.  Randomness is important for encryption. In practice, a better source of entropy might be needed.

int GenerateSeed(OS_Seed* os, byte* output, word32 sz)
{
    return rand();
}

Next you'll find a odd casting error in internal.c in GetHandShakeHeader:

File ":src:internal.c"; Line 3136 # Error: <function argument>: implicit cast of pointer loses 'const' qualifier

The c24to32 is an inline function, and the const qualifier was getting lost for a reason I don't understand.  I manually inlined the function in the one spot where there was a problem.

In internal.h there is a buffer structure that throws the following error:

File ":cyassl:internal.h"; Line 930 # Error: 'buffer::buffer' must be a function
File ":cyassl:internal.h"; Line 931 # Fatal error: Failure of internal consistency check
odd ctor type in struct 'buffer'

The issue appears to be that the compiler does not like the struct being named the same as one of the members.  I add an underscore to the struct name.  This doesn't really affect anything else because its in a typedef and future code uses the type:

typedef struct buffer_ {
    word32 length;
    byte*  buffer;
} buffer;

Next, you need to modify dh.c to use <fp.h> for the pow() and log() functions rather than math.h (which doesn't exist in the Newton C++ Toolkit)   There is a place in dh.c for you to place this code, and a macro (USER_MATH_LIB) in the settings.h file that conditionally compiles it in.

#ifndef USER_MATH_LIB
    #include <math.h>
    #define XPOW(x,y) pow((x),(y))
    #define XLOG(x)   log((x))
#else
    #include <fp.h>
    #define XPOW(x,y) pow((x),(y))
    #define XLOG(x)   log((x))
#endif

Finally, you need to compile the c files.  I snagged a list of the c files out of the make file (am__src_libcyassl_la_SOURCES_DIST) and made my own little makefile to call ARMCpp using the mpw tool. (mosrun would work too, but I already had an mpw makefile from another project.)  I took Demos.cp and Demos.exp from the NCT example code and modified them to call a few of the CyaSSL initialization functions.  (Otherwise the linker won't link in any of the CyaSSL stuff, since its not used anywhere) I tried to link with ARMLink...

...And... it links!  I was surprised, because I expected there to be some random assembly file or something with symbols that I missed.  The .sym file is around 386kB.  Seems like a reasonable size.

Things go wrong: Static globals

The next step in using C/C++ code in a Newton app is to make the .ntkc package using the AIFtoNTK tool... and this is where things go wrong:

### AIFtoNTK - error -  the file 'CyaSSL.sym' has a R/W global variables which is NOT supported in Newton packages.
#    You can use 'const' global variables & '*const' pointers.

Per the "NCT Programmer's Reference":

    Any global data that you reference in your C++ functions must be read-only data. You must reference this data with a constant pointer to constant data [...]
 
    You sometimes need to allocate memory for use in your C++ code that is like global data. Since you cannot use non-constant global data in your C++ code, you need to utilize a coordinated effort between your NewtonScript and C++ code to achieve this.

CyaSSL is pretty light on the static globals variables, but there are some sprinkled throughout.  Here are some that I found using a simple grep:

•     sniffer.c has a bunch, but I think this can be excluded
•     ssl.c has a mutex and a global random number generator object, and some related counters
•     io.c has errno as a global variable
•     des3.c has a few buffers and bytes, and a mutex
•     ecc.c has a cache of some sort.
•     memory.c uses globals to hold the malloc, free, and realloc functions.  These can be changed to static globals and #ifndef out the inside of CyaSSL_SetAllocators, since it won't be necessary.
•     there may be others that I didn't find.

Not all of these get linked in, they all might not not need to be fixed.  This is more retrofitting then I care to tackle.  I'm guessing that we'd need to MakeBinary() on the NewtonScript side and access these binaries using the NCT functions for accessing NewtonScript objects.

Newton Globals

I put together a little stub function that simulates a global variable by storing a pointer in a NewtonScript frame and passing that information back and forth between the C++ code.  The prototype looks something like this:

void* NewtonGlobal(RefArg sym, long size);

You give the global a unique name and pass it as a symbol.  If the symbol does not exist, a memory block of the given size is created, the pointer is stored in the NewtonScript frame and returned.  If it does exist already, then the pointer is retrieved and returned.

With this a very ugly preprocessor macro can be used to remove the static global:

static SessionRow SessionCache[SESSION_ROWS];

becomes

#define SessionCache ((SessionRow*)NewtonGlobal(SYM(SessionCache),sizeof(SessionRow)*SESSION_ROWS))

Ugly, but it should work.  I am able to compile, link, and package the CyaSSL library as a .ntkc file.  My "test" file tries and calls a few of the CyaSSL function so that the linker will find them in the dependency tree... but in practice there may be more static globals to tackle.

Other considerations

Besides the globals issue, there needs to be some glue code that allows NewtonScript to call CyaSSL and pass data back and forth.  NIE doesn't support the traditional concept of a "socket".  On the plus side, CyaSSL has an abstracted I/O architecture.  You can define functions for input and output instead of the default socket implementation.

Also, its quite likely that there are many more compiling & linking issues hidden.  When the library is used in practice, there will be more parts of the library in the dependency tree, and we may find new errors or static globals.

An Exercise for the Reader

I think that CyaSSL is a good choice for the Newton.  If you're interested in learning more about CyaSSL, here are some good starting points:

http://www.yassl.com/yaSSL/Docs-cyassl-porting-guide.html

http://yassl.com/yaSSL/Docs-cyassl-manual-5-portability.html

I don't know how many places these global variables might pop up in the CyaSSL code.  Also I'm not an expert on NewtonScript/NIE Endpoints and what well designed "glue" might look like.  Could it be done? Probably.  It is more work than I want to tackle with this little digression.

While I may dabble with this a little more, I don't think I'll see it through to completion.  I invite someone else to pick up the ball run with it. You can find me on NewtonTalk if you have any questions about what I have tried up till this point.  I'm happy to help out, but given the weird encryption export laws in the USA, I don't want to post any code directly.

Initial Design of Internal WiReach WiFi Board

I have been triangulating on a final PCB design for an internal WiReach card.  I am not an EE, so the design is hobbiest-grade at best.  Here is the thinking behind some of what you see in the picture above:

1.  Board size is less than 5cm x 5cm in order to print it at iTead Studio at a reasonable cost.  10 of them on 0.8mm board should be around $15.

2.  Hole locations were determined based on trial and error.  I have a 3D printer, so I printed 6 or so iterations of the board and then checked the fit and hole locations.  If someone has better dimensions for the location of the mounting points, please let me know.

Screw size seems to be #1-72.  Length is 3/8".  Flat head.  Phillips.  Shannon from NewtonTalk was selling an original SER-001 on eBay.  I have a SER-001 too, but I've lost the screws.  Shannon was nice enough to measure the screws for me, and confirm that the head diameter is ~0.136.  This seems consistant with McMaster part number 91771A168, but I would love to find an flat undercut version of this screw.  Unfortunately, it doesn't seem to be available in this length.  At least now I can get some screws for both my SER-001 and this project!

Eagle PCB tends to want to route things across the mounting holes as plated vias.  Since these holes will need to be countersunk, I didn't want to rely on these holes.  Drilling the countersink will break the plated thru hole.  Hence a couple of extra vias are nearby to make sure there isn't an issue.

3.  I trimed down one side of the board to give a little more clearance for the microphone and power switch wires.  This isn't strictly necessary, since the wires have their own recess in the stylus assembly.  Since I don't know how/where I'm going to route the antenna yet, but I figured a little extra room wouldn't hurt.

4.  I added a 500mA PTC Fuse, since the battery leads are unfused.  While there's not going to be any external connector to short out, I figured this was a safe play.

5.  I chose the Texas Instruments REG103 regulator, mainly because I was able to get a handful cheaply on eBay and it has a shutdown input.  Also its pretty low profile and won't interfere with mainboard components. The shutdown signal will will be driven by SerPortSel3.  SerPortSel3 is normally low, keeping the regulator off.  When toggled high in software the regulator will come online and power the WiReach.  This way, the module will only be powered when in use.  This regulator can handle 500mA.  At peak, the WiReach should only use 60% of this amount.

6.  The large copper planes on the top side are for battery power, ground and 3.3v.  The intent to help cool the regulator.  I'm not sure what the thermal characteristics will be in practice.  Power and ground traces are 30 mils wide, which is more than double what the online trace width calulators say you need for 500mA.

7.  Headers for debugging give access to the power lines on one side and the communication lines on the other.  In practice, I intend to tape over the pads so that there's no possibility of a short.  (I may go a little crazy with Kapton tape just to make sure the board doens't flex into something and cause a short to the mainboard.)

8.  The ground plane on the backside is only broken by a few signal jumpers where routing couldn't be done on the top side.

My next steps are to verify the connections one more time to make sure everything is correct, and then send the board off to be made.  In the interem, I'm going to build a reflow toaster oven.

WiReach Module Connection Test

All of this work on the internal serial slot is in support of my WiFi module project.  The goal is to build an internal interface to a ConnectOne WiReach module.  I like this module for a few reasons:

1. It supports modern wireless networking, such as WPA2.  There isn't any native way for the Newton to connect to a modern WiFi network, and likely there never will be.
2. It supports a PPP server.  This means that the module can appear to Newton Internet Enabler (NIE) as a PPP dialup server.  In effect, you can "dial up" to a wifi network.
3. It supports an AT command set for configuration-- so you can send a few commands from PT-100 or using the script utility in NIE to configure the module.  

I've done some testing today and found that it works really well.  A few caveats:

• The Newton's internal 3.3v regulator is not sufficient to run the module.  This was expected, but it does mean that any design will have to have a 3.3v regulator that runs off of the battery supply lines.  Luckily the internal serial slot does provide access directly to the battery.
• Hardware flow control seems to work.  I have a history of messing up the pinout, so I'l probably have a solder jumper that you can cut if you want to disable hardware flow control.
• There's a giant capacitor right where I would want the module to sit.  I think that that there is enough clearance in the area, but I'm starting to be concerned about how this will all fit.

My current thinking is to use the SerPortSel3 line to control the 3.3v regulator shutdown.  Serial3 is just as fast as Serial0 (even though the specs say that Ser3 is slower, this doesn't appear to be the case,  it works fine at 119200)  I wouldn't want the module running all the time, drawing power.  SerPortSel3 would work to turn on and off power to the module.  Since no one ever connects anything to Serial3 externally, I am thinking that I might skip a tri-state bus buffer. 

Posted to GitHub: Internal Serial Enabler

I have posted the source to "Internal Serial Enabler" - a small newton app that allows you to view and control a few of the signals of the internal serial slot on the MessagePad 2x00:

• gpSerPortSel - the serial port 0 selection signal.  When high, the internal serial driver is disabled, leaving Serial0 available for the internal slot.
• PortSelect - the serial port 3.  When high, Serial3 is available for the internal slot.  When low, Serial3 is dedicated for the external interconnect port.
• General Purpose I/O - Pin 26 can either be an input or output signal.  Using the app, you can select whether you want the app to be an input or an output.  If you select 'output', you can control the signal.

The application polls all three I/O signals and updates the user interface state every 1/2 second.  This will allow you to see when other applications or NewtonOS makes changes.  The gpSerPortSel pin does toggle on and off, enabling/disabling the driver.  This is likely for power saving.

Once again, I can't credit Eckhart Köppen enough for posting the source to Newton-Blunt-Support.  It is how I learned to call arbitrary ROM functions.

This application is intended for developers working on hardware for the internal serial slot.  If you are not such a person, do not install this application.   It should be harmless for a Newton with an empty internal serial slot.  Even still, you are toggling hardware signals with undocumented ROM functions... there is the potential to do hardware damage.

You can find the source and a pre-built package on GitHub here: https://github.com/jake-b/Newton-Internal-Serial-Enabler  I have released it under GPL v2.0 and as always, use it at your own risk!

General Purpose I/O Line

Pin 26 on the internal serial slot is listed as a "General Purpose I/O".  The Internal Serial Slot Developers Guide says that this pin can be configured as either an input or output.

The question is, how is this pin connected?  What GPIO or DIO pin is it connected to?

Well the answer seems to be GPIO #9.  Again a little tweaking of Eckhart's code lets you call the relevant functions and toggle the pin.

Also, you can configure the pin as an input, and things work as expected.  From a hardware design perspective, however, this pin will likely be an output (pulled to ground) until your software configures it as an input... so your hardware should be tolerant of the pin as both an input and an output.

One interesting note, is the N2 platform overview (p 1-29) document lists this GPIO as "Serial NOT CP Enable".   This doesn't seem accurate.   Also DIO #2 is listed as "Available for Configuration to the Slot".  DIO #2 is the output we use to configure SerPortSel3.  Perhaps there is a documentation error here and these signals are reversed.  Maybe these were reversed in the final hardware design and the documents were never updated.  Its a mystery.

I also updated my little app to support the GPIO pin for both input and output.  I'll post the code to Github soon.  Really this is intended for developer use, so it is not recommended that the average user install this application on their Newton.

Manually controlling the SerPortSel Pins

Eckhart Köppen, author of the Blunt, the Newton bluetooth stack, has posted code on GitHub for manually controlling the SerPortSel3 signal.  His code manually controls the proper DIO pins using functions in the Newton ROM.

While this method works great for Serial3, I wanted to also control Serial0.  So I started looking at the ROM.  I found two functions in the ROM explicitly for controlling these signals:

0x0026d050 SerialPort0LineDriverConfig__16TVoyagerPlatformFUcT1
0x0026d094 SerialPort3LineDriverConfig__16TVoyagerPlatformFUcT1

I took a look at the assembly for these functions and found them to be pretty simple.  The first parameter seems to be a boolean and the second a bitfield.  I'm not exactly sure what the second parameter does, but it changes the behavior of the function when it finds the 0x20 bit set.

From what I can tell, for the Port3 function, you can leave the second parameter as 0x0 and the first parameter is a bool that controls the signal.  For the Port0 function, the first parameter the logical inverse of the signal you want, and the second parameter should be 0x20.

• SerialPort0LineDriverConfig(0,0) // results in Port0Sel High 
• SerialPort0LineDriverConfig(1,0) // results in Port0Sel High 
• SerialPort0LineDriverConfig(0,0x20) // results Port0Sel High 
• SerialPort0LineDriverConfig(1,0x20) // results Port0Sel Low 

• SerialPort3LineDriverConfig(0,0) // results in  Port3Sel Low 
• SerialPort3LineDriverConfig(1,0) // results in Port3Sel High 
• SerialPort3LineDriverConfig(0,0x20) // results in Port3Sel Low 
• SerialPort3LineDriverConfig(1,0x20) // results in Port3Sel Low

Eckhart's code is an awesome blueprint for calling arbitrary memory locations, so it was easy to modify it to call these two functions.  Putting it all together, I whipped up this little Newton application:

Still a little more work to do, but good enough for development and testing.

Incidentally, when called with the correct parameters, the assembly behind SerialPort3LineDriverConfig is virtually identical to Eckhart's code.  The SerialPort0LineDriverConfig is very similar but uses as GPIO instead of DIO.

The SerPortSel Pins

The internal serial port of the Newton MessagePad 2x00 exposes the same ports as the external interconnect.  In order to prevent two devices (one internal, one external) from diving the port at the same time, there are "Serial Port Select Pins" for Serial Channel 0 and Serial Channel 3.

The "Internal Serial Slot Designer's Guide states:

Pin 1 PortSelect:
This is the control signal to select between a  peripheral in the internal Serial SLot and the Newton Interconnect Port.  When the signal is low, the Newton Interconnect POrt may drive the Serail Port 3 Signals.  When the signal is high, the Internal Serial Slot Peripheral may drive the Serial Port 3 Signals.

Pin 8 gpSerPortSel
This signal controls the LTC 1323 line driver for Serial Port 0 that drives the 26 pin Newton Interconnect Port.  When Low, the Newton Interconnect Port can drive Serial Port 0.  When high, the internal Serial Device can drive serial port 0 on the 32 pin connector.

The signals are most critical for Serial0, which has the LTC1323 driver on the main board which will attempt to drive the signal lines unless Pin 8 is high.  For Serial3, there are few (if any) devices that ever connected to the external interconnect port and used Serial3, so the potential for conflict is less.  Even still a "good citizen" will still honor these signals.  A bus driver buffer that can tristate these signals when not selected by these logic signals should probably be used.

One interesting wrinkle is an observation by Matthias Melcher:

Serial Port 0 uses gpSerPortSel on pin 8. When gpSerPortSel switches high, the card must respond with a low on DCD (5).

Basically, Matthias has found a sort of handshake where the Newton checks to see if a modem is present, and if the modem answers properly, it will leave the modem port selected.  I have not yet reproduced this, but I have seen a 5ms pulse when connecting to Serial0 on the Newton.  This pulse may be an interrogation.  I have yet try and respond on DCD to see if the port stays high (internal port selected).

The Internal Interconnect Port

I seem to have an odd, recurring interest in the internal serial port on the MP2x00.  A few years back I tried to make an internal bluetooth module.  It worked, but I never got the RF design correct so it didn't work well.

Now, I'd like to try for an internal WiFi module.  I'm more hopeful that I can get the antenna correct by using more off the shelf components and, worst case, an external antenna.

The internal port was originally designed for an internal modem that was never produced.  Luckily, some of the design documents were leaked and are now available.  The documents give you part of the picture, but there are omissions and errors that make the process a bit more of an exercise in reverse engineering.

I wanted a breakout board that would help prototype and test the behavior of some of the GPIO pins and such.  I came up with this:

The connector is a FTE-116-01-G-DV-ES.  It is easier to find without the -ES option, FTE-116-01-G-DV-P for example is available from Newark electronics.  The ES is just an end shroud, which while a nice thing, is not strictly necessary.  I think the pins are a little longer than the original JAE connector, so it sits a little high.  The case seems to close so I'm hopeful that it'll work for an internal card as well.

I had 20 of these boards made for $15.  You'll have to solder the connector on there yourself, but if you're playing around with this sort of thing, you probably know how to handle surface mount pins of this size.

Welcome

The Apple Newton is still one of my favorite gadgets.  Even now, almost 20 years later, my Newton MessagePad can do things that a modern iPad cannot.  Every six years or so I pull my Newton out of a drawer and it captures my interest.

I don't blog, but I needed a place to post some content and images.  Blogger seemed as good a place as any-- its free, and likely will be around as long as Google is.

I'm currently in one of my six year periods of fascination.  When I loose interest again and the Newton takes its place back in the drawer, this information posted here hopefully will still be available for archival purposes.