Simple multi-channel serial ADC (8-ch)?

[linnix]

That's what is needed. Now if this would be available for a smaller uC
such as the MSP430

If they use an open standard interface like Jtag, then it would be
possible. We tried with AVR, but the Jtag interface is not totally
open.

I believe it would certainly increase its market
penetration into areas that have gone without any uC so far. IOW not
chasing the competition but truly new markets.

IIRC from the Yahoo MSP430 forum there is a guy working on it but last
time he was still looking for someone who would take on the PC side
software.

It's hard to do that. We need to work on both sides at the same
time. For example, we are now trying to figure out the data transfer
protocol, and we need to program both Window and Linux.

The gdb protocol for reading is:

$ m <addr> , <count> # <checksum>
$ m <addr> , <data> # <checksum>
with + (ACK) and - (NAK)

We would need protocol extensions to write to buffer,
then a write flash command.

I don't want to spoil the broth here but, sorry, Linux isn't
really an option. If you take me as an example none of my clients uses
Linux. All Windows :-( .... ok, one MAC.

But they all use web servers, and many of them are Linux. As long as
they don't have to touch them, it would be fine. Think of it as a
Jtag programming server.

We don't want the client to mess with the Linux box as all. All the
user interfaces will be done on the Window side. The Linux box will
be running on read-only 64M Flash Drive. There is no user interface
to it, except for an RJ-45 for network and a USB cable for programming
the target.

I thought about a uC here after the discussion with Marte but will
forego it again this time. This board needs good radio silence most of
the time. The only way to achieve that within a few usec is to have an
external clock that is gated and then it'll all become quite esoteric.

No problem, you will need a uC eventually, for another project.

 

[Joerg]

Yes. How about a Lear Siegler ADM3?

Never used one of those. In my lab I had two Viewsonic but they went to
the recycler because their job had been taken over by PCs. One thing I
must say is that those terminals had tens of thousands of hours on them
yet never let me down.

 

[Joerg]

If they use an open standard interface like Jtag, then it would be
possible. We tried with AVR, but the Jtag interface is not totally
open.

AFAICT they don't, and actually migrated a bit away from JTAG with the
new F2xxx family. The old ones can usually be bootloaded quite well.

It's hard to do that. We need to work on both sides at the same
time. For example, we are now trying to figure out the data transfer
protocol, and we need to program both Window and Linux.

The gdb protocol for reading is:

$ m <addr> , <count> # <checksum>
$ m <addr> , <data> # <checksum>
with + (ACK) and - (NAK)

We would need protocol extensions to write to buffer,
then a write flash command.




But they all use web servers, and many of them are Linux. As long as
they don't have to touch them, it would be fine. Think of it as a
Jtag programming server.

We don't want the client to mess with the Linux box as all. All the
user interfaces will be done on the Window side. The Linux box will
be running on read-only 64M Flash Drive. There is no user interface
to it, except for an RJ-45 for network and a USB cable for programming
the target.

If that box is really small it would work.

No problem, you will need a uC eventually, for another project.

Yep, and one is coming. That one must have a uC because it'll have to
transmit data via wireless.

 

[linnix]

Yes but compare that to the mess that would occur if your customer
wanted a mod to your serial based stand alone A/D board (it would be a
HW mod)

There is no reason why you can't consider a CPU based A/D a piece of
unprogrammable hardware. Once you program it, put it on the board and
make no accommodations what-so- ever to reprogram it.

Tell that to the Honeywell Engineers who are recalling their products
built with flash based uC. Show me how to convince my customer who
would never consider "flash" permanent.

 

[linnix]

AFAICT they don't, and actually migrated a bit away from JTAG with the
new F2xxx family. The old ones can usually be bootloaded quite well.












If that box is really small it would work.

My target is a lunch box (in size), but there is no reason why you
can't use a PDA or cell phone (with usb). There are cell phones
running on Linux and internet connected.

 

[Joerg]

Yes but compare that to the mess that would occur if your customer
wanted a mod to your serial based stand alone A/D board (it would be a
HW mod)

There is no reason why you can't consider a CPU based A/D a piece of
unprogrammable hardware. Once you program it, put it on the board and
make no accommodations what-so- ever to reprogram it. The serial stand
alone A/D doesn't have that feature, and it appears it's acceptable to
your customer, so why add it.

Stand-alone ADC boards can be made quite versatile. It's all
controllable via registers and stuff. That can also be done with a uC
but the issues that tend to creep up there is noise from the uC itself.
On acquisition boards with uC we usually needed several iterations to
optimize sleep modes etc. Not required with a plain ADC board because
it's quiet the microsecond the SPI clock stops. But you are right, if
there was a hard bug it would be a re-design.

 

[Marte Schwarz]

Hi Jörg,

Hmm, that was the first question I fired off at the TI seminar. My
question was whether there is a simple Windows-based code dump routine
that would let non-programmers do a bootload. The answer was "nope". Later
I asked again but the answer didn't change :-(

You should look in NGs and Web around and ask by the sourgeforge folks. And
of course look the appnotes from TI. The salesmen often don't know the tools
in backstage. They know the Features they want to sell...

Also, nowadays one really wants to embrace the F2xxx family (usually
SBW-only) because older ones didn't even have a proper brown-out reset,

Wondering !?! A few years ago, long before the f2xxx was released, they
marks exact this feature: a propper brown-out circuit in their MSP430F1xy
and f4xy

It would be tough for me. Me and Windows frequently clash ;-)

go to the next university hang a sheet of paper out there with a promise of
a few dollars and you will get this job done very quickly.

If you run SPI the whole clock scheme is under system control. I can
request SPI to stop running after x microseconds no matter whether or not
some task is completed, then resume after y microseconds. Probably this
can also be handled by a uC as long as it is a fully static design.

may be you can deliver teh clock for µC this way external, without the usage
from internal fll.

Marte

 

[Joerg]

Hi Jörg,




You should look in NGs and Web around and ask by the sourgeforge folks. And
of course look the appnotes from TI. The salesmen often don't know the tools
in backstage. They know the Features they want to sell...

It wasn't the sales folks whom I asked

Wondering !?! A few years ago, long before the f2xxx was released, they
marks exact this feature: a propper brown-out circuit in their MSP430F1xy
and f4xy

I know, some of them do. But a lot of them don't and I never really
understood why not.

go to the next university hang a sheet of paper out there with a promise of
a few dollars and you will get this job done very quickly.

Sure. But this time I was able to do without ;-)

may be you can deliver teh clock for µC this way external, without the usage
from internal fll.

With a fully static design that works. The only thing you have to pay
attention to, usually, is the AD converter in there. Some concepts go
haywire if you take the clock away in the middle of the game. IIRC some
16bit SD converters then need three "dummy conversions" before you get a
good one.

 

[Joerg]

Tell that to the Honeywell Engineers who are recalling their products
built with flash based uC. Show me how to convince my customer who
would never consider "flash" permanent.

Was it caused by flash memory loss? If so, please let us know which uC
that was if you are at liberty to tell. Might avoid some black eyes.

 

[Marte Schwarz]

Hi Jörg,

It wasn't the sales folks whom I asked

Even cracks don't know all these very special things.

With a fully static design that works. The only thing you have to pay
attention to, usually, is the AD converter in there. Some concepts go
haywire if you take the clock away in the middle of the game. IIRC some
16bit SD converters then need three "dummy conversions" before you get a
good one.

Sure, you have allways to know what you do ;-) Several SD needs more than 3
Cycles to get valid results. SD converters are designed to convert streams
not single samples. Therefore they usually don't have a S&H or such things
and more often they have included filters...

Marte

 

[linnix]

Was it caused by flash memory loss? If so, please let us know which uC
that was if you are at liberty to tell. Might avoid some black eyes.

Flash is just my guess.
It was in the news for recalling a few hundred AT91SAM7S256. I
sometimes have strange results with AVR flash as well. I don't know
if they are built with the same process, or if it's just a certain
batch.

 

[[email protected]]

Tell that to the Honeywell Engineers who are recalling their products
built with flash based uC. Show me how to convince my customer who
would never consider "flash" permanent.- Hide quoted text -

- Show quoted text -

So you have customers that reject any flash based designs?

 

[Michael A. Terrell]

Never used one of those. In my lab I had two Viewsonic but they went to
the recycler because their job had been taken over by PCs. One thing I
must say is that those terminals had tens of thousands of hours on them
yet never let me down.

The ADM3 was a very early glass teletype. One of the first in the
"Low cost" category. They were built to last a lifetime. I think I
still have a complete unit, but I scrapped a lot of them for the nice LV
power transformers.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

 

[Joerg]

Hi Jörg,



Even cracks don't know all these very special things.

Well, suppose there was such a routine (which AFAIK there isn't) and the
top notch guys at a company would not know about a tool with so much
marketing power. Then it would be time for a huge organizational
structuring effort. Because it would mean that there is a company that
doesn't know where its assets are. I doubt that's the case with TI.

Sure, you have allways to know what you do ;-) Several SD needs more than 3
Cycles to get valid results. SD converters are designed to convert streams
not single samples. Therefore they usually don't have a S&H or such things
and more often they have included filters...

Which is why, I guess, parts like the MSP430F2013 wouldn't cut it in
this application.

 

[linnix]

So you have customers that reject any flash based designs?

No, they insist on being able to reprogram it in the field (at the
very least), as well as remotely probing the flash for
verifications. A local Window station monitors the remote targets'
flash and data memories,
that part of it is working fine. We are currently working on remotely
programming an ARM Cortex M3 using remote gdb server on the targets.

We are still trying to figure out the best way to do it. One solution
is to create a virtual flash port on the gdb server. Namely, a block
of registers interpreted by the gdb server and jtag into flash. For
example, Flash Address Register (FAR), Flash Data Register (FDR),
Flash Control Register (FCR) and Flash Status Register (FSR). They
should be a reserved block not used by ARM and/or vendors (LMI, TI and
ST are prospective vendors).

We already have the ability to access real or virtual registers, as
well as sram. In response to the FCR, the gdb server jtag/swd a small
program on sram to rewrite the flash.

By the way, a single monitor station could track/maintain several
remote stations miles away. Actual sample rates (both system and apps
data) are very low (HZs), so it could be done with GSM/GPRS as well.
Of course, the targets are firewalled to talk to authorized IPs only.

Actually, this discussion should really be in comp.arch.embedded

 

[Joerg]

FWIW, while browsing around for some other parts I found the Analog
Devices AD7928. An 8-ch ADC that also comes in 10-bit and 8-bit flavors
and has a reasonable street price. Both the config string and required
HW handshake look quite clean. Nice part.