Oscilloscope

[YahooArchive]

You are correct. That first sentence had a typo. Well, it was worth a shot. I
was unaware of a problem with the communications. That raises a red flag with
me. Is there a fix for that or specific things to avoid doing with it? I have
done surface mount rework before, so if there is a mod I can make, I'd like to
do that. I have the zoom scope and tools for such work. What is the mod? Thanks
very much for your help. Irv

[YahooArchive]

The issue of reset has been discussed at length in this forum, it is not a
communication problem.

The ARMmite has reset and boot method controlled from the USB port. This lets
you program the part without pushing buttons or shorting jumpers.

The issue comes about when you want to use the ARMmite powered independently
from the USB, and then connect the USB while its running.

Windows toggles the control lines on the USB when it connects up, which resets
the ARMmite. This is a function of both Windows and the FTDI drivers.

For uses where you want to be able to connect and disconnect to the USB without
disturbing the running program, those control lines need to be disconnected.
This is quite easy to do on the PRO board. It is not so easy to do on the
ARMmite (it requires either a pin to be lifted U2.2, or 1 trace cut between U2.2
and U3.6)

[YahooArchive]

If the sense of DTR is an issue with the program you are running you can invert
that using the MPROG utility from FTDI.

This is outlined in the help files at

http://www.coridium.us/ARMhelp/scr/HwUSB2.html

no cutting required.

As for blips on DTR, the only time I've seen them is when a program opens a USB
serial port, this might also occur if you are changing UART parameters in some
programs as they do it by closing and re-opening the port.

> Irv - It's ONLY a problem if you're using PC software that does not allow
control of DTR. I use 'Just Basic' as it's quite powerful and the price is right
(free!). But "OPEN COM.." seems to set DTR low - holding the ARMmite reset. And
there do seem to be spurious blips on DTR from time to time - probably a
windows/usb issue?
>
> The same problem exists if you want to use Liberty Basic programs, or
Hyperterminal.

[YahooArchive]

The idle state of DTR for a serial port in Windows is low
(RS-232 high), which is why we call that "Normal". For older programs that
don't allow control of DTR, they set it high (RS-232 low) when they open the
serial port. But then there's MatLAB that sets RTS low and DTR high,
incompatible with everybody.

Call Bill Gates and complain

Have you tried VB.net Express? It looks like it allows control of the DTR line.
And its free too.

[YahooArchive]

I am comfortable with cuts and jumps, but the software issues are gonna stop me,
for now. I have done 68HC11 assembly code but this is foreign to me and will
take some time to get going. I'd like to learn, but all I am looking for
currently is an analog scope program that will allow DC coupling. Sounds like
it's promising, but doesn't exist, currently. I did mess with VB some time back
and it had issues when I tried to use it to communicate via FTDI virtual com
port. I gave up on it. It was erratic. Worked fine for a while and then would
stop for no apparent reason. Thanks for looking into it, guys. If you ever hear
of a working analog scope application for the Armmite, please let me know.
Thanks. Irv

[YahooArchive]

I might suggest another tack to do something like this.

Excel is a good tool for generating graphs.

Importing data into Excel is pretty straight forward, in fact there's an example
of that in the files section.

But what you want to do is to have live data being captured into Excel.

This should be possible a number of different ways, including using VB.net to
read data coming in from the serial port.

[YahooArchive]

I do want a live updating display, like you see on an oscilloscope. I don't know
how to do that in Excel. I'll look in the files section for the example. Thanks.
Irv

[YahooArchive]

You don't need to change firmware to change the baud rate on UART0, just use the
BAUD0

[YahooArchive]

How to figure this out-

60 MHz CPU clock rate.

15 MHz Peripheral clock rate (if you couldn't find that in the doc's)
use the BASIC to read the value

@e01fc100
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

shows its divide by 4 -- 15 MHz rate, 3.11.2 in the User Manual

the UART baud rate generator description in the NXP User Manual, says the baud
clock has to be set to 16x baud rate.

that clock is based on 15 MHz peripheral clock

so the fastest rate is

15/16 Mb = 935 Kb
15/32 Mb = 468.75 Kb
15/48 Mb = 312.5 Kb
15/64 Mb = 234.375 Kb
15/80 Mb = 187.5 Kb
15/96 Mb = 156.25 Kb
...
15/128 = 117.1875 Kb (close enough to standard 115 Kb rate)
...

For the SuperPRO, the CPU clock is running at 100 MHz, and peripheral clock at
25

[YahooArchive]

in BASIC you enter 115000

and the routine plugs in the closest number

in C you enter the n (the divider) into setbaud(0, baudDiv)