RTS and DTR

[YahooArchive]

DTR is used for RESET on the ARMmite
RTS selects BASIC vs C booting when RESET

Normal mode--
When the PC is idle the board will run a BASIC program

Legacy mode--
When the PC is idle, the board will be held in reset
You must start the legacy program (Hyperterm or equiv) to get the
board to run (or BASICtools with the control set for legacy)

MatLab mode--
like legacy mode, the board will be held in reset until Matlab opens
the serial port.

this info is also in the Help Files, Hardware Section

You can use TclTerm instead of Hyperterm, the easiest way is to use
the FreeWrap shell to launch Tcl programs

http://downloads.sourceforge.net/freewr ... rror=voxel

Download this, rename it to freewish or something other than freewrap
and associate it with *.tcl files.

[YahooArchive]

>from the help line
>I am using the Armite for usb communications. When plugged into the >usb I
cannot communicate to the unit running a rxd0 and txd0 program >until I press
the reset button on the unit then it takes off >running. I tried all different
things with the rts and dtr lines >with no luck. I have also tried normal,
legacy and metlab modes. >What am I missing so on plug in it will run the
program and allow >communications?

There is too much software in the way to have this do what you want. The USB
driver goes out and IDs the device, calls in drivers and establishes
connections. All this toggles the RTS and DTR lines a number of times, and
sometimes its deaf and sometimes not, so the PC and board are completely out of
sync. This also varies between systems, drivers and probably what Bill G had
for breakfast.

Unfortunately its not like an old RS-232 link where you just connect it up and
go.

But there are solutions, beyond disconnecting the control lines. Assuming there
is a program on the PC thats capturing this data, it can go out and detect a new
device and connect to it. It can also force a reset. Its going to depend on a
lot of factors, including when you disconnect the board it will close the serial
connection, even though your program may not be informed of that until it
attempts a write.

As for normal/legacy/matlab your choice here is probably best to leave it in
normal mode, at least a reset will start your program, that is not the case for
legacy or matlab.

Another option for the ARMmite PRO is to use an FTDI cable so the serial
connection always exists as far as the PC is concerned, then connecting the
board up should go smoothly.

[YahooArchive]

Problem with that tho, is that a windows app is still dependant on the USB OS
drivers to enumerate the usb port and id it.

My problems have been the opposite, how to get the app to know when the device
has been disconnected or turned off.

This causes the following problem. Power on device, windows ids and assigns
port. App connects to port, and system talks. Device disconnects or is
reset/powwered off.

On return of power, Windows tried to assign SAME USB port ID, but App is holding
it open, SO ID FAILS (note it doesn't goto the next port id!). App and device
never see each other again.

So usb is more a pain in the neck than anything else, for end user support
anyway. I can deal with it fine, but I doubt grandpa or grandma will like it
very much.

Solutions are appreciated, btw Bruce I too am using tcl as my userland app
support. If it could detect the usb drop that would be cool.

Later,
JoeR

[YahooArchive]

Possible help.

Tcl -> FTDI Driver interface.
http://www.patthoyts.tk/tclftd2xx.html

I'll have to check this code out when I get home.

[YahooArchive]

> Possible help.
>
> Tcl -> FTDI Driver interface.
> http://www.patthoyts.tk/tclftd2xx.html

haven't looked at that yet

> > My problems have been the opposite, how to get the app to know when the
device has been disconnected or turned off.

some quick experiments in Tcl --

This statement would detect the port has gone away--

if {[catch {fconfigure $ser_port -ttycontrol {RTS 1}}]} {puts "yikes"}

Where ser_port was assigned the filename on the open COM port. Though you would
have to be polling this in the Tcl. Other NOP types of fconfigure might work
too.

As for detecting the serial port has been restored, you can just try to open it
in Tcl. If it is potentially a different card, so a different port, you would
have to look at the registry (TclTerm does this to find the available serial
ports).

[YahooArchive]

Solution:

Even with the sparkfun basic breakout (not the arduino one, but the other simple
4 pin one, you still have to hookup all six pins.

DTR -> RESn
RX -> Tx
TX -> Rx
VCC -> V+
CTS -> Cn
Gnd -> GND

And then it will work.
I was under the impression we did not need DTR/CTS.

I can now load C programs. Sweet!

[YahooArchive]

> Even with the sparkfun basic breakout (not the arduino one, but the other
simple 4 pin one, you still have to hookup all six pins.
>
> DTR -> RESn
> RX -> Tx
> TX -> Rx
> VCC -> V+
> RTS -> Cn
> Gnd -> GND
>
> And then it will work.
> I was under the impression we did not need DTR/CTS.

C programs require booting into the ISP, as well as your program so that
requires Cn and RESn to be controlled.

But I have updated the MakeItC utility so you can use either the SparkFun
Arduino USB board or the FTDI cable which only control reset, either with DTR or
RTS. BUT you will have to INSTALL a JUMPER on loadC, during download, and the
program will prompt you for that.

When you choose an ARMmite PRO it will ask you whether you are using a Coridium
USB dongle or not.

this new utility can be download from the Support page.

www.coridium.us/files/setupC.exe

[YahooArchive]

>The problem we noticed is that on powerup the basic program hangs up and does
not execute. Many times pressing the reset button starts the program. However,
when hooked up to the USB and using Basic tolls to execute the program, the
program executes fine. Please Help

This has been covered before, the ARMmite uses DTR and RTS lines for control,
which means you don't need to push buttons when loading and running programs
from the tools. Very useful. The downside is DTR and RTS control the ARMmite
and when a PC boots up it toggles these lines somewhat arbitrarily and it gets
the ARMmite into a hung state.

A couple people have just cut the reset line when they finished their program,
this works but there should be a better way.

I put a C program in the files section that will reset the ARMmite, which would
start your program. This works fine from the command line. So it seems it
should be possible that use the Windows task scheduler to run this program on PC
startup (problem solved in theory).

Unfortunately there is still a missing piece of the puzzle, and I have to throw
in the towel for now. While it runs from the command line when I try to run it
from the task scheduler it doesn't run either.

Anyway this program and C source are in the files section ARMserial.zip. It
also contains an updated sample C program for opening a serial port to
communicate with an ARMmite.

So if anybody has Bill's IT guy's private line, or wants to figure it out let us
know...

[YahooArchive]

Gentlemen,

I assume that the PC can not be kept connected - that something simple like a
USB HUB won't help.

I am using the ARMmite in my BMW to control the idle speed, replacing the OEM
analog module. When I plug in my laptop, where I run a Liberty Basic program
that monitors and logs data that the ARMmite transmits, it stops the program. I
found that if I open the com port in Liberty Basic, close it, restart the
ARMmite with the reset button, and open the com port again, I can get keep
things moving.

I use a "Notice" dialog in Liberty Basic which pauses the PC's program until you
click the "OK" button while I push the ARMmite's reset button.

Open COMPort$ + ":19200,n,8,1,ds0,cs0,rs" for random as #KDIC
Close #KDIC
Notice "Reset KDIC, if the LED is not flashing."
Open COMPort$ + ":19200,n,8,1,ds0,cs0,rs" for random as #KDIC

Subsequent opens of the com port do not stop the ARMmite (as long as the USB
stays connected) so the "OK" can just be clicked.

While not very elegant, it is simple. Of course if your ARMmite is not storing
the collected data in flash memory, you will lose what ever it has gathered. If
the gathering only needs to work while the PC is connected, however, this might
help.

Ira

[YahooArchive]

> It looks like it may be possible to disable DTR in software using the
techniques outlined in EINT1.bas.
>

this will not do what you want, as DTR causes a reset which launch's NXP
generated and un-alterable code that looks at the state of the "boot" pin

-- see the prior post