This is a first cut at a TINI FAQ. Contributions are welcome - send me an email.

Tony.

• Linux (Redhat 6.0)
• Windows

Description	TINI DB9 Female	PC/Workstation DB9 Male	TINI RJ11 (1)	TINI SIMM 68 pin connector (2)
Receive Data	2	2	2	17
Transmit Data	3	3	5	18
DTR	4	4	3	23
Signal Ground	5	5	4	1

Notes:

1. To determine the RJ-11 pin numbers, look into the FEMALE connector with the release tab UP and the pins along the bottom. Number them from RIGHT to LEFT, 1 through 6.
   Another way to look at it is this is to look at the end of the MALE connector on the cable, with the release tab UP and number the pins from LEFT to RIGHT, 1 through 6
2. Applies to the Rev E TINI Socket.

Adding Memory to the TINI Board

>We'll try to post a couple
>of different URLs to RAMs that you safely add to to the TINI boards
>unpopulated site.

The devices on the boards presently are Hitachi HM628512BLTT5 . The
following devices also appear suitable:

Mitsubishi M5M5408BTP-55L.
http://www.mitsubishichips.com/data/datasheets/memory/mempdf/ds/d99024.pdf

Samsung KM684000CLT-5L.
http://www.usa.samsungsemi.com/products/prodspec/powersram/684000c.pdf

Don Loomis
6 Oct 1999
(extracted from an email on the mailing list tini@dalsemi.com)

Voltage and Temperature

As for the comments about temperatures of the parts:

Most of the components should be cool to the touch. The '390 CPU, however, will be quite warm. This device is running at nearly 40 MHz and dissipating a lot of power in a very small package. The temp rise is normal. On the Socket board, the regulator may be warm, but should not be hot to the touch.

If D7 (the big Transorb device on the Rev E Socket board) is hot, there is a problem! That device should not dissipate any power unless it is clamping to protect the TINI board from overvoltage.

Chris Fox
26 Oct 1999
(extracted from an email on the mailing list tini@dalsemi.com)

1-Wire (MicroLAN)

• DalSemi 1-Wire Net Compatibility Table - I believe that this table shows those 1-wire devices that cannot be on a MicroLAN
• Circuit Cellar - Dallas 1-Wire - All on One Part 1 / Part 2
• Point Six 1-Wire products

• An introduction is available.
• Circuit Celler CAN Resources
• Devices supporting CAN. Mostly controllers.

The pin numbers used on your connector might not match these, so be careful. What I call pin #1 is like this:

Look into the FEMALE connector with the release tab UP and the pins along the bottom. Number them from RIGHT to LEFT, 1 through 6.

Another way to look at it is this:

Look at the end of the MALE connector on the cable, with the release tab UP and number the pins from LEFT to RIGHT, 1 through 6.

Here's the standard pin-out:

1) VCC (5 volts regulated)
2) Power Ground
3) One Wire Data
4) One Wire Ground
5) No Connect
6) V+ (unregulated DC)

Many of our devices provide the V+ (usually 12-20 VDC) and VCC (5 VDC) on the outer pins of the one wire connectors, but some do not. We also assume NO liability for what happens when you take excessive power from these outer pins or introduce excessive noise into them.

Chris Fox
17 Sep 1999
(extracted from an email on the mailing list tini@iButton.com)

EMI/EMC

Don Loomis
27 Oct 1999
(extracted from an email on the mailing list tini@iButton.com)

CAN Controller

Any pointers to additional Dallas documentation (Don ?) pertaining to the on board CAN controllers would be greatly appreciated.

Peter LePage

Unfortunately, I cannot give you a good solid solution to your support question today. However, I do have two suggestions that I think will help you in the not too distant future. As you have already determined, the CAN controllers in the DS80C390 are very complex. In fact, they are way too complex to completely describe in the limited space of a data sheet. Therefore, we are in the process of writing a "User's Guide" for this new processor. Since the CAN controllers are the most complex peripherals in the processor, we are writing this section of the User's Guide first. As soon as it has been signed-off, we will post it on the Dallas web site. You can expect this information to be available before the end of November. The other suggestion is that we are working with Keil Software in Dallas to provide software support for this new processor. They have committed to support the DS80C390, including CAN library modules for their 8051 C compiler. The latest date I have from them on support of the CAN controllers is sometime this December. If you wanted to call them for an update, this might encourage them to move a bit faster. Their phone number in Dallas is 972-735-8052. Right now, this is the best we have to offer.

Frank Taylor
28 Oct 1999
(extracted from an email on the mailing list tini@iButton.com)

Blue Dot Adapter

Is there any way to detect which blue dot is an ibutton insert in? No.

iBFirst() is to find the "first" ibutton on the 1-wire bus. But it is not to check whether there is an ibutton insert into the, say, "first" blue dot.

In fact, is there any ordering/naming for the two blue dots on the blue dot adapter? No.

It seems to me that no matter which blue dot I use, iBFirst() will always find the ibutton for me.

What I want to do is that if I insert an ibutton into one blue dot, then I do something, if I insert an ibutton into another blue dot, then I do something else.

So is it possible to do it?

Both blue dot's are on the same 1-wire. It doesn't matter which 1 you use. If you want multiple 1-wire nets you might want to look into building something using an addressable switch (DS2406).

Interesting. Why do they include 2 blue dots, rather than simply make the receptor smaller?

Dallas Semi makes a variety of iButton receptors, and third party companies have made a very wide variety of them. The most common ones are for use in access control environments. Some have clever LED indicator arrangements, and some are designed to be very weather-resistant.

The latest advances in the iButtons include a ridge around the top that helps the iButton "touch and hold" in a receptor, like a snap. More and more applications require the iButton to remain securely in the reader. The dual Blue Dot is popular because you can have an authorization iButton locked in place and still have a reader port for touching additional iButtons when needed.

30 Oct 1999
(extracted from an email on the mailing list tini@iButton.com)

A couple of people have had problems loading the firmware 
(tini.hex, tiniapi.hex), and slush (slush.hex).

In the software download:

	ftp://ftp.dalsemi.com/pub/tini/tinibeta01.tar.gz

there is a file:

	RUNNING_THE_DEMO.txt

It's not obvious from the name, but it has a good writeup on
how to reload the firmware in section:

	II. Loading the API hex files

The files are all in the appropriate directories:

	tinibeta1/firmware/tini.hex
	tinibeta1/firmware/tiniapi.hex
	tinibeta1/examples/slush/Slush.hex

It's probably worth having a quick read through all of 
the .txt files.

Don Loomis
27 Oct 1999
(extracted from an email on the mailing list tini@dalsemi.com)

Uploading a hex file WITHOUT JavaKit

There's no protocol nor handshake. JavaKit merely sends ASCII codes with 6 spaces on top of each line. I've discovered this by protocol analyzer. I made a JavaKit replacement for Macintosh for my own use and this can upload HEX file just like JavaKit using this method.

On Linux I am using seyon and a simple sed-script for uploading the files. Note: the "^M" (introduces by DOS/WIN) at the end of the lines are essential - so one should not convert the hex-files to UNIX format.

BTW: Lines starting with 6 blanks remind me of my first programs in FORTRAN IV (back in '79) on punched cards. Do they use a IBM card-reader for uploading to the TINI board? ;-))

Actually, the 6 spaces are to slow down the write. JavaKit analyzes the hex file it sends out to see if it is writing to one of the flash ROM banks. If so, 115200 is too fast for the loader to write to flash, so the spaces slow down the send enough to give the loader time to finish its last write. (If you load a hex file in say bank 18 - not in flash - JavaKit does not send out the pad of 6 spaces.) You can, however, open the port outside of JavaKit at a slower speed, say 19200, and not have to send the leading spaces at all.

Also, you are correct about the ^M. The loader expects a carriage return (/r in Java world) after every hex file line, and a /r/n after every loader command I believe.

Johann Schumann, Stephen Hess, et al.
27 Oct 1999
(extracted from an email on the mailing list tini@dalsemi.com)

Using the .startup file

I've had a play with the .startup file.

The first thing to do is to enter the command:

	genlog -e

This creates a file:

	/etc/.log

with interesting messages each time TINI is rebooted.

Next I created a new /etc/.startup file:

# 
setenv FTPServer active
setenv TelnetServer active
setenv SerialServer active
#
#Add user calls to setenv here:
initializeNetwork
#
#Add other user additions here:
java TINIWebServer.tini &


then I rebooted my TINI.

It automatically started TINIWebServer at boot time. Cool!

As far as I can gather, lines in the .startup file are executed as 
slush commands.

I don't understand the 'initializeNetwork' line as this is not a command.

'setenv' is a command. Type the command with no arguments to see a list
of environment variables.


5 Nov 1999
(extracted from an email on the mailing list tini@dalsemi.com)

• java JavaKit -advanced
• java -classpath tini.jar JavaKit -advanced

Usage: java JavaKit <-options>
Where options include:
-port		Specifies the COM port to auto open.
-macro		Specifies a macro file to auto load.
		Pass multiple files separated by commas.
-baud		Specifies the baud rate to use (default is 115200.)
-padSize	Specifies the size of the pad string when
		writing to flash ROM (default is 6.)
-exitAfterRun	Specifies that JavaKit should exit after running the
		macro file specified with "-macro".
-promptString	Specifies the remote system's prompt.
		Default: ">".  You must wrap string in quotation marks.
-questionString	Specifies what ends each query from the remote system.
		Default: "? ".  You must wrap string in quotation marks.
-bankSize	Specifies the size of each memory bank.
		Default: 64000
-ROMSize	Specifies the total size of the Flash ROM.
		Default: 512000
-log		Generates a log file called JavaKit.log.
-advanced	Show advanced options.

On a superficial level, it takes all of your .class files and converts them into a single .tini file which may then be executed on TINI. My guess is that it is kind of like a linker that preprocesses a bunch of class files into a memory image in order to offload that processing from TINI. My other guess is that the tini.db file is kind of like a .lib file, i.e. it provides information to TINIConverter on how to link to the system APIs.

These are just educated guesses, though.

And from Don:

The convertor does most (but certainly not all) of it's work on the constant pool. Many UTF8s are removed. The UTF8s that are removed completely are the fully qualified names that are used for dynamic class loading, bytecode verification and in some cases debug. The UTF8s that are needed to create String objects (via an ldc or ldc_w) are stored in a separate table. This leaves a constant pool that consists of entirely 5 byte entries (a type byte and a 4 byte value). longs and doubles span 2 entries. This means that given a constant pool index I can point to any value in the constant pool (which happens a bunch) with a multiply, and add of the data pointer.

Also in all of the revs up to and including alpha6 many of the java VM opcodes were not supported so the convertor would also remap the opcodes to allow the bytecode interpreter to have a smaller jump table. This is no longer the case in beta since all opcodes are supported. However in all releases the convertor goes through the bytecode streams of all of the methods and renumbers the constant pool indices. The size of the bytecode streams is completely unchanged (most of the size reduction comes from the work on the constant pool).

This is very incomplete but it should at least provide a rough idea of what it's doing. The advantages of the convertor were accurately described by John Wilson. The main disadvantage currently is that much information required to support the class Class and java.lang.reflect package is lost. The trick is to put that information back without significantly growing the resulting binaries and without big restructuring of the bytecode interpreter. I think we've discovered how to do this and hopefully in the 2nd beta we'll be able to add this support.

Finally, we have a crude text document that describes the structure of a .tini file in detail. We'll try to clean that up and make it available shortly after the 1.0 release.

David MacMahon and Don Loomis
27/28 Oct 1999
(extracted from an email on the mailing list tini@dalsemi.com)