On Mon, 1 Feb 2016 16:04:45 -0600, you wrote:

>>On Fri, 29 Jan 2016 13:52:45 -0600, Emmett Redd Ph.D. wrote:
>>
>>> I am proposing to design and build an analog circuit
>>> intensive PCIe computer card. The analog circuit concepts
>>> are firmly in hand, but schematic capture, layout, etc.
>>> needs to be done. In fact, the core analog circuit is not
>>> extensive but the whole card has hundreds of repeats.
>>>
>>> But, I do not want the interface between the PCIe bus and my
>>> DACs and ADCs to be a learning attempt on my part and would
>>> like to find someone experienced here to design that
>>> interface, help with software driver development, and
>>> whatever else makes sense to hire done.
>>>
>>> Note: ITAR probably applies.
>>>
>>> Any recommendations of good providers that anyone has used
>>> or been will be appreciated.
>>
>>From the above it sounds as though you thoroughly understand
>>your transducers and your analog sections, but need help with
>>the rest. It might help a little to expand your description
>>to help get serious recommendations:
>>
>>* Critical layout issues already known?
>>* Sustained and burst transfer rates? (Buffering required?)
>>* Have you considered the M.2 x1, x2, and x4 NGFF? (Or is
>> this PCIe x1, x2, x4, x8, x16, or x32?)
>>* Commercial? Or scientific?
>>* Power?
>>* Closed loop control or open loop measurement?
>>* Operating environment?
>>* FPGA likely involved?
>>* You looking first for someone with broad knowledge to
>> guide the selection of others and guide the project or
>> will you handle the prioritization and selection?
>>* What equipment do you have on-site and what do you expect
>> to be available to those who help you? (scopes, etc.)
>>* Who is responsible for validating a stuffed board?
>>
>>I don't have anyone in mind. I'm merely suggesting more
>>information to help stimulate discussion.
>>
>>Jon
>
> Jon, Thanks for the questions. They are reproduced below
> with answers interspersed:
>
>>* Critical layout issues already known?

> Area. My analog chips have a total quoted area of 11232
> mm*mm on a conservative estimate PC board of 27000 mm*mm.
> And, I know there will have to be scale-setting resistors
> and diodes and decoupling capacitors, connectors, on-board
> voltage regulators, references, and the PCIe interface
> hardware. Maybe some of the passives can go on the back
> side of the board. The analog circuitry could be reduced in
> steps if it is impossible to fit everything in.

What about shielding (mu-metal cans), expected dissipation,
special high voltages, unusually low currents (fempto-amp),
unusually low voltages, etc?

>* Sustained and burst transfer rates? (Buffering required?)

> My 8 DACs can take serial data at up to 50 MHz (400 MHz
> bandwidth?) and my 5 ADCs are between 10 and 20 MHz (100 MHz
> bandwidth?). So buffering from the 2.5 GHz will be needed.

Is that sustained rates of data??? Or just bursts? How long
might a burst be? What's the longest stretch of total data
required? Will that have to be streamed to non-volatile
storage?

It's going to be very difficult to achieve those rates on a
sustained basis into any non-volatile storage (except perhaps
FeRAM or battery backed SRAM.) Let alone process it in real
time, if that's in the plan too. (If you really need
processing power, you might also consider connecting your
board to an NVidia graphics card (SLI) for access to its
processing power as an aux pre-processor before the x86 cpu
sees it.)

>* Have you considered the M.2 x1, x2, and x4 NGFF? (Or is
> this PCIe x1, x2, x4, x8, x16, or x32?)

> It is a full-size, plug-into-a-PC/workstation box so PCIe.
> The answer above implies x1 should be enough.

If the M.2 NGFF is used, stay with x4. Most motherboards will
support M.2 x4, I think. If PCIe card in a regular slot, then
stay with x8 or x16. Why less?

>* Commercial? Or scientific?

> Scientific, but want to keep commercial options open.

I was asking this because some all-in-one board design houses
will consider the idea of defraying some of the development
costs in exchange for commercial interest -- if they can be
convinced of that. But scientific pretty much doesn't even
open that opportunity door at all.

>* Power?

> With different chips covering the same area above, it is
> still an open question whether the analog ranges over +/-10
> V or +/-2.5 V. Looking at the higher value, the analog
> portion of the board should be less than 80 W.

I think this eliminates M.2, unless a separate power supply
is available. I also think it eliminates a "normal" PCIe
card, which is supposed to be capped at 25W absolute max if a
full height card, I think. The graphics cards are allowed up
to three times that, as I recall. This is going to be a
serious problem given that the analog alone might be 80W and
that you see an FPGA in there as well.

>* Closed loop control or open loop measurement?

> Actually, it emphasizes analog computation rather than
> control, though control is possible.

If closed loops are potentially involved, you really need to
find a specialist here... even if you don't do that at first.
This is because it is VERY hard to do closed loop controls in
the presence of phase delays and most especially when these
delays vary all over the place. You want as short a delay as
possible and you want that delay to be as predictable as
possible, as well, with zero or as little variation as
possible. These things feed DIRECTLY into the hardware design
as well as understanding the limitations of PCIe and other
delays/speed ups within a complex PC system. If you want to
avoid closing the door on the possibility, you'll want
someone knowledgeable on the topic to impact your other
design discussions along the way to make sure you don't do
something really dumb that makes it near impossible, later.

>* Operating environment?

> MatLab under Windows.

Egads. Forget what I said before. Direct closed loop on any
reasonable basis is probably out of the question now. It's
convenient. But....

>* FPGA likely involved?

> I expect the interface between the PCIe mixed-signal analog
> components is likely an FPGA. We are only familiar with
> VHDL on Xilinx FPGAs.

Yeah. VHDL (and manual floor planning) with Xilinx software
is where most of my experience is at, as well. But I read
verilog, too, like most people doing this kind of stuff.

>* You looking first for someone with broad knowledge to
> guide the selection of others and guide the project or
> will you handle the prioritization and selection?

> I am very flexible on this point; my university, maybe not
> so. We will have to bid anything (since I expect the cost
> to be above $5k).

Yeah. It's going to be over $5k. If it is going to be bid
out, it's best you do as much "study" as you can so that you
can be somewhat informed about both writing proposals and
reading responses.

A good way to find the right folks is to know some area or
two well enough that you can make some predictions about what
to expect as a likely "goal." Then look for proposals from
others that actually give you a prospective idea that matches
your own analysis (which you don't tell them in advance.) If
they tend to predict what they can achieve near what you feel
should be achievable, then you probably found someone who is
knowledgeable and not just blowing smoke. There might only be
one or two or three of these things. But use your own
strengths to find a few and then ask others to give you an
estimate of what they feel they can achieve there. Or, don't
even ask. Just see if any of the proposals touch on those
issues without your prompting and see what they say.

It is good to bet on someone who manages to comes back with
some estimates that, in areas you already know something,
look about like what you feel is right.

>* What equipment do you have on-site and what do you expect
> to be available to those who help you? (scopes, etc.)

> We have a LogicPort and a LabJack and can get 60 MHz digital
> scopes, multimeters etc.

60MHz?? Seriously? Crap. I have both analog and digital
scopes at 400MHz (Tek 2465B and an MSO from HP.) I guess that
won't be much of a burden for anyone.

>* Who is responsible for validating a stuffed board?

> That might best be done by the stuffer, but we could
> negotiate that.

I don't think the stuffer can verify much. I was asking about
verification of your functional goals. That requires
software, drivers, VHDL tools, probably networked JTAG tools,
and probably lots more.

Jon

Posted by: Jon Kirwan

Beginning Microcontrollers with the MSP430

On Fri, 29 Jan 2016 13:52:45 -0600, Emmett Redd Ph.D. wrote:

> I am proposing to design and build an analog circuit
> intensive PCIe computer card. The analog circuit concepts
> are firmly in hand, but schematic capture, layout, etc.
> needs to be done. In fact, the core analog circuit is not
> extensive but the whole card has hundreds of repeats.
>
> But, I do not want the interface between the PCIe bus and my
> DACs and ADCs to be a learning attempt on my part and would
> like to find someone experienced here to design that
> interface, help with software driver development, and
> whatever else makes sense to hire done.
>
> Note: ITAR probably applies.
>
> Any recommendations of good providers that anyone has used
> or been will be appreciated.

From the above it sounds as though you thoroughly understand
your transducers and your analog sections, but need help with
the rest. It might help a little to expand your description
to help get serious recommendations:

* Critical layout issues already known?
* Sustained and burst transfer rates? (Buffering required?)
* Have you considered the M.2 x1, x2, and x4 NGFF? (Or is
this PCIe x1, x2, x4, x8, x16, or x32?)
* Commercial? Or scientific?
* Power?
* Closed loop control or open loop measurement?
* Operating environment?
* FPGA likely involved?
* You looking first for someone with broad knowledge to
guide the selection of others and guide the project or
will you handle the prioritization and selection?
* What equipment do you have on-site and what do you expect
to be available to those who help you? (scopes, etc.)
* Who is responsible for validating a stuffed board?

I don't have anyone in mind. I'm merely suggesting more
information to help stimulate discussion.

Jon

Posted by: Jon Kirwan j...@infinitefactors.org

Jon, Thanks for the questions. They are reproduced below with answers interspersed:

* Critical layout issues already known?
Area. My analog chips have a total quoted area of 11232 mm*mm on a conservative estimate PC board of 27000 mm*mm. And, I know there will have to be scale-setting resistors and diodes and decoupling capacitors, connectors, on-board voltage regulators, references, and the PCIe interface hardware. Maybe some of the passives can go on the back side of the board. The analog circuitry could be reduced in steps if it is impossible to fit everything in.

* Sustained and burst transfer rates? (Buffering required?)
My 8 DACs can take serial data at up to 50 MHz (400 MHz bandwidth?) and my 5 ADCs are between 10 and 20 MHz (100 MHz bandwidth?). So buffering from the 2.5 GHz will be needed.

* Have you considered the M.2 x1, x2, and x4 NGFF? (Or is
this PCIe x1, x2, x4, x8, x16, or x32?)
It is a full-size, plug-into-a-PC/workstation box so PCIe. The answer above implies x1 should be enough.

* Commercial? Or scientific?
Scientific, but want to keep commercial options open.

* Power?
With different chips covering the same area above, it is still an open question whether the analog ranges over +/-10 V or +/-2.5 V. Looking at the higher value, the analog portion of the board should be less than 80 W.

* Closed loop control or open loop measurement?
Actually, it emphasizes analog computation rather than control though control is possible.

* Operating environment?
MatLab under Windows.

* FPGA likely involved?
I expect the interface between the PCIe mixed-signal analog components is likely an FPGA. We are only familiar with VHDL on Xilinx FPGAs.

* You looking first for someone with broad knowledge to
guide the selection of others and guide the project or
will you handle the prioritization and selection?
I am very flexible on this point; my university, maybe not so. We will have to bid anything (since I expect the cost to be above $5k).

* What equipment do you have on-site and what do you expect
to be available to those who help you? (scopes, etc.)
We have a LogicPort and a LabJack and can get 60 MHz digital scopes, multimeters etc.

* Who is responsible for validating a stuffed board?
That might best be done by the stuffer, but we could negotiate that.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.

Posted by: "Redd, Emmett R"

Jon,

Thanks for the list. Some things I can probably answer and some things need some study, but I will try to get a mostly complete set before I respond so the information is collected in one post rather that coming to the community in drips and drabs.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: m... [m...]
Sent: Friday, January 29, 2016 4:45 PM
To: MSP430 List
Subject: Re: [msp430] PCIe Card Engineering Services

On Fri, 29 Jan 2016 13:52:45 -0600, Emmett Redd Ph.D. wrote:

> I am proposing to design and build an analog circuit
> intensive PCIe computer card. The analog circuit concepts
> are firmly in hand, but schematic capture, layout, etc.
> needs to be done. In fact, the core analog circuit is not
> extensive but the whole card has hundreds of repeats.
>
> But, I do not want the interface between the PCIe bus and my
> DACs and ADCs to be a learning attempt on my part and would
> like to find someone experienced here to design that
> interface, help with software driver development, and
> whatever else makes sense to hire done.
>
> Note: ITAR probably applies.
>
> Any recommendations of good providers that anyone has used
> or been will be appreciated.

From the above it sounds as though you thoroughly understand
your transducers and your analog sections, but need help with
the rest. It might help a little to expand your description
to help get serious recommendations:

* Critical layout issues already known?
* Sustained and burst transfer rates? (Buffering required?)
* Have you considered the M.2 x1, x2, and x4 NGFF? (Or is
this PCIe x1, x2, x4, x8, x16, or x32?)
* Commercial? Or scientific?
* Power?
* Closed loop control or open loop measurement?
* Operating environment?
* FPGA likely involved?
* You looking first for someone with broad knowledge to
guide the selection of others and guide the project or
will you handle the prioritization and selection?
* What equipment do you have on-site and what do you expect
to be available to those who help you? (scopes, etc.)
* Who is responsible for validating a stuffed board?

I don't have anyone in mind. I'm merely suggesting more
information to help stimulate discussion.

Jon

Posted by: Jon Kirwan

Posted by: "Redd, Emmett R"

I am proposing to design and build an analog circuit intensive PCIe computer card. The analog circuit concepts are firmly in hand, but schematic capture, layout, etc. needs to be done. In fact, the core analog circuit is not extensive but the whole card has hundreds of repeats.

But, I do not want the interface between the PCIe bus and my DACs and ADCs to be a learning attempt on my part and would like to find someone experienced here to design that interface, help with software driver development, and whatever else makes sense to hire done.

Note: ITAR probably applies.

Any recommendations of good providers that anyone has used or been will be appreciated.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.

Thanks Blakely.

Like Jon I've used lots of languages over the years, often trying out a
new idea on the PC in C or even VB and then porting it to a micro in
assembler. Like you I have mostly worked in assembler because it reads
cleanly, and logically to me. There is nothing cryptic or hidden about
it, what you see is nearly always what you get. I like to thrash things
until they bleed before I use them in designs, and I did this to great
lengths with the MSP. I too find porting between micros, a fairly simple
process, and, as Jon says it is often a great way to learn new things,
or get a different insight into something. A few years ago I thought it
was much easier than porting between different C implementations.

In recent years I have had no constraints, other than physical ones on
what I do. I no longer work commercially because my health has failed me
suddenly on a couple of occasions and forced me to let people down, and
on many occasions I believe that my situation has been taken advantage
of, so I work for me now. Oddly I seem to have even less time, again
partly due to health, and partly because there is almost no end to the
depths of exploration I need indulge in to produce what I want. I guess
this has always been part of the excitement of design. Every design is a
new field, or has been, so years back I had to dig out the maths and get
acquainted with DSP, because the text books quoted formulae that weren'y
explained, and used symbology that meant something totally different to
me. I jumped into semiconductor manufacturing and found an affinity for
it, so robotics design, and chemistry and physics, then GPS, underground
mining, and communications, learning new fields all the time, (and
trying in my old age not to forget some of the older stuff).

My latest venture is the most exciting by far. I started it in 1993, 7
years before my own accident, but never had the time to devote to it,
and was also highly criticised and sometimes even ridiculed by the
'experts' of the day, so it became something I read a lot about and
occasionally built and tested new ideas, but never took it all the way.
A couple of years ago I was in a very bad place and needed to do
soemthing to dig my way out of it. I had a few off the wall ideas but
instead I threw everything into testing my old ideas, as I didn't even
know if they would work, I just couldn't see why not, and that, I feel
is often as good a reason as any to pursue something new. I also felt
that if I didn't do it then it would never happen.

The result of this is that the two people who tested my first (crude)
system have gone from wheelchair bound C5 quadriplegics to being able to
drive, lift themselves in and out of their chairs, feel things they
hadn't felt for 6 years, ride a horse unaided, pass their drivers
licence test, regain control of bladder and bowel, and generally do
things they were told they would never do again. One has feeling back
from her arms to her feet. I'm about to embark on the next stage of
this, sending machines to another dozen people in the US, a guy in
Brazil and a few people in Australia. The machines are free, as are all
the consumables, cables and software updates (thanks in a large part to
my first victim). I am hoping for the same slow but steady progression
as the first 2 machines showed. Eventually I hope this will become
commercially available to everybody, at an affordable price, but for now
I struggle to make ends meet on a state disability pension, but I
believe that what I am doing is the most meaningful thing I have ever done.

Now the relevance of this is that it is all done with an MSP430F2618,
running the crap out of it. It runs round the clock for 3 days on a
battery charge, thanks to the low power modes of the MSP, and there is
enough grunt to not only run the core code, but wifi, BT and soon I am
hoping it will be able to track and image spinal cord and neural
activity in real time. I don't think this would be feasible in C on this
processor.

Why choose the MSP430 for this job, which obviously calls for a fair bit
of processing power, especially when you see the likes of Ti suggesting
ARM or DSP processors for simple things like blood ox or ECG? The answer
is boringly simple. I know the MSP430 inside and out. I had an off the
shelf MSP430F149 based board from 2000 with one of my early test
designs on it that I was able to update for the 2 test systems, so no $
outlay. I had an MSP430F2618 EVK that I could test some new ideas for
the latest design on, again no $outlay.. I had the tools for the MSP
ready to hand, again no $ outlay, and, finally I had the IAR Kickstart
program for free, so there was no cost at all in doing the core micro
based work, which meant that the little that I could put aside each
week, could be hoarded for more important things. Things like making the
PCB and buying the parts, custom made batteries, (super cheap, $3.50
each in a 100 lot for 3000mAh Li poly 3V7 cells in a foil pack with a
customised PCM board) custom shielded cables and a nice box from Hammond
because they will pre drill and cut, and are very reasonably priced.

Progress has been necessarily slow, but when you are on the phone to
somebody, who, when you first spoke to them was unable to even swap
their position in their wheelchair, and they say "I have to hang up in a
minute Al, I'm about to drive up a mountain and need to concentrate a
bit". Or you receive a video in your email showing a girl sitting on her
horse and walking it around a paddock for the first time in 6 years,
then 2 months later I get another video of her lifting herself out of
her chair into a Polaris quad and driving off across the fields, it
makes you feel that you haven't wasted your time. It makes me feel
vindicated in my beliefs.

This is why I do what I do, I cannot imagine doing anything else, and
have always felt that I wanted to design things that made a personal
difference to people, but like most working engineers haven't been able
to do as I pleased as much as I would have liked. I am lucky to have
been born into this very precise era when one person can indulge their
inquisitive nature and do such things, because I fear that it is all
becoming too black box, prebuilt boring stuff. We have gone from valve
technology to billions of transistors per square cm in just just over 50
years, a spectacular rate of advance that should continue to the point
where the machines design other machines and all we do is give them a
list of 'wants', a 'Wish List Converter' module.. Now if only I could
get DOS or similar for my PC so that I could grab all of it's potential
for myself instead of losing it to windows and the thousand things I
don't need to do that windows thinks I should.!

Cheers

Al
On 19/01/2016 4:48 AM, b...@yahoo.com [msp430] wrote:
> I have not visited here much of late - guess the lack of projects or
> new processors or laziness(?).
>
> Nice to Jon and Al- both of whom have given me invaluable help over
> the years.
>
> I use the IAR assembler tools as well. The are fast YACC based tools.
> I use them for the MSP430, 8051, and Renesas RX family. Nice to be
> able to work with the same tools sets. I don't use the IAR IDE at all
> nor their .h files. For every product, I create that defines every
> register, every bit and uses a fair amount of ASCII graphics. The idea
> behind this is that as an appendix, it follows the product and serves
> to complete the documentation. The chief advantage I find is that you
> get a great exposure to the hardware and peripheral base that each
> processor family supports. And like much code, it becomes the template
> for subsequent additions to that family. The downside is that it
> takes a long time to create. I am working on the RX family now and
> some members there have a huge number of configuration registers.
>
> Everything is done from command line invocation in (ALT - F9)
> UltraEdit with the result box popping up in the editor.
>
> My fallback assembler is the X32 Universal Assembler - a table driven
> product that allows you to define your own Mnemonics and Opcodes. It
> can be expanded to add new instructions. I did this to extend their
> H8 tables to support the H8S family - most notably the STM and LDM
> multiple stack push/pop instructions. And it is very useful when
> porting code. If I were more ambitious, I would create a
> Meta-Assembly language and then define the Opcodes for each member
> family. Of course a good Macro capability in most assemblers can do
> the same thing.
>
> The real reason I code exclusively in assembler is that it reads
> better to me. It matches my thinking and appears perfectly clear.
> Maybe it is just a mental limitation of my part, but C is just too
> ugly to read and easily gets obfuscated beyond comprehension.
>
> Blakely LaCroix
> Minneapolis, Minnesota, USA

On 18 Jan 2016 10:18:46 -0800, you wrote:

> I have not visited here much of late - guess the lack of
> projects or new processors or laziness(?).

I've got it set up so that transactions here appear as email
events in my email, but automatically filed in a special
folder marked for what it is. All of the emails are also
sorted into threads, automatically, with responses indented
relative to those they are responding to (where possible.) I
can read, or not. But if I don't, a count gradually rises up
on the number of emails I've not yet looked at. So at some
point, I either just zero the count and ignore everything or
else I go take a look.

It doesn't require any more attention than I want to provide
at any given moment.

> Nice to Jon and Al- both of whom have given me invaluable
> help over the years.

Thanks!

> I use the IAR assembler tools as well. The are fast YACC
> based tools. I use them for the MSP430, 8051, and Renesas RX
> family. Nice to be able to work with the same tools sets.
> I don't use the IAR IDE at all nor their .h files. For every
> product, I create that defines every register, every bit and
> uses a fair amount of ASCII graphics. The idea behind this
> is that as an appendix, it follows the product and serves to
> complete the documentation. The chief advantage I find is
> that you get a great exposure to the hardware and peripheral
> base that each processor family supports. And like much
> code, it becomes the template for subsequent additions to
> that family. The downside is that it takes a long time to
> create. I am working on the RX family now and some members
> there have a huge number of configuration registers.

With contract work I do for customers, I let them tell me how
the development must go. I also ask them questions about the
future they see and let them know that C programmers (without
assembly coding experiences or with only modest experience
there) are easier to find than good, qualified assembly
programmers. So it may make a difference to them if they want
to replace me, later on. If they are as informed as I'm able
to make them and they still don't mind if I use assembly
coding then I consider the issue "up to me" and I make a
decision based upon what I imagine as mutual considerations
in balance.

If the project/product is my own (and I do that, as well)
then I usually will go to use assembly coding only. But not
always. If it is my product, I want to maximize my margins.
And this includes using the smallest/cheapest micro I can
manage. Even if I completely change the processor out, to a
completely different core (say, from MSP430 to PIC18), it's
not difficult for me to recode things quite quickly. There
are some significant differences when moving from a 16-bit
register core with "lots" of registers to an 8-bit core with
only a couple of registers. But in the process of recoding, I
also then find "opportunities" which again allow me to be
more competitive. I also face different power modes,
different trade-offs, etc. And I don't find all of that much
more difficult in assembly, than in C, say. So assembly
doesn't carry significant downsides. Also, in the early
stages of a new release of a micro, there usually will be an
assembler (or if not, it takes me almost no time at all to
adapt a table-based assembler tool to the new processor)
before there is a C compiler. In short, I often consider
assembly coding as not only a viable option, but a preferred
option when considering my own product development. But then,
I don't have any worries about finding a good assembler
programmer, either. ;)

> Everything is done from command line invocation in (ALT -
> F9) UltraEdit with the result box popping up in the editor.

Ah. Okay.

> My fallback assembler is the X32 Universal Assembler - a
> table driven product that allows you to define your own
> Mnemonics and Opcodes.

Hehe. I hadn't read this when discussing a table assembler
above! I see we think alike here, now.

> It can be expanded to add new
> instructions. I did this to extend their H8 tables to
> support the H8S family - most notably the STM and LDM
> multiple stack push/pop instructions. And it is very useful
> when porting code. If I were more ambitious, I would
> create a Meta-Assembly language and then define the Opcodes
> for each member family. Of course a good Macro capability
> in most assemblers can do the same thing.

Someone probably has already done this. Perhaps someone here
will point you (and me) to such a project!

Linkers which don't need to have specific intelligence (such
as being able to do link-time, optimized code generation),
should be quite general. You really only have two independent
memory achitecture models out there to support: von Neumann
and Harvard. And if you fully support the Harvard model, it's
trivial to support von Neumann. You to support named (and
unnamed, if you want) abstract segments, be able to combine
segments into groups (if you want), and be able to locate
them somehow. All the linker has to do is support a symbol
table, accept patch markers, and do a little "patching" of
the literal strings it sees.

There are some nice features in an assembler that I'd like
and I suppose those would take some work to achieve. But the
bottom line is that I would guess someone has taken on this
project already. I suppose I should go look and see. Maybe I
will.

> The real reason I code exclusively in assembler is that it
> reads better to me. It matches my thinking and appears
> perfectly clear. Maybe it is just a mental limitation of my
> part, but C is just too ugly to read and easily gets
> obfuscated beyond comprehension.

I think "obfuscation" is largely a matter of familiarity with
the language and its idioms. (And a matter of who's writing
the code, of course -- new authors will often be far, far
more confusing in their code generation because they are NOT
familiar with the idioms nor are they very clear in their
thinking processes.) But I've been using C since 1978, so I'm
very comfortable with it. That said, for my projects, I still
will often use assembly language.

VB.NET, for example, is very intimidating for someone not
familiar with it. It can also be "almost familiar," too.

Here's an example that would be "familiar" even if you have
no real idea how it exactly achieves its purpose:

Private Iterator Function Fibonacci() As IEnumerable
Dim mA As Integer = 1
Dim mB As Integer = 1
Do
Yield mA
Dim r As Integer = mB
mB += mA
mA = r
Loop
End Function

Here's an example that would be more intimidating, even given
the idea that you already know what it might do given the
name of the function:

Private Function Factorial(ByVal N As Integer) As Long
Dim fset As Integer() Enumerable.Range(2, N - 1).ToArray()
Dim result As Long = 1
Parallel.ForEach(Of Integer, Long)(
fset,
Function() As Long
Return 1
End Function,
Function(item, s, sb)
sb *= CLng(item)
Return sb
End Function,
Sub(f)
Dim v As Long = Interlocked.Exchange(result, 1)
Do
f *= v
v = Interlocked.Exchange(result, f)
Loop While v <> 1
End Sub)
Return result
End Function

The above code spreads out the computations across multiple
cores. The function accepts an integer N and computes a long
result value. It's not difficult to read if you are familiar
with the idiom. But it's horrible if you aren't.

That said, writing the above code in assembly would be fairly
easy (perhaps easier) if you already had multi-core support
in your custom O/S. And the assembly code would probably be
easier to read and understand, too (my opinion.) So once
again it's a wash, or perhaps argues for assembly. But this
is a simple case of a trivial algorithm, too. So I don't make
too much of this, either way. Just mostly fun to look at for
a moment.

I think the main point is this. There is no "one answer that
fits all circumstances." Anyone who argues that assembly
coding is dead is, in my view, arguing from a narrow and
ignorant perspective. Anyone who argues that assembly coding
is always better is, similarly in my view, also arguing from
a narrow and ignorant perspective.

Details about circumstances matter.

A quality programmer will continually pursue the acquisition
addional skills. This means different language and their
semantics and syntax tradeoffs. This means mathematics. This
means electronics. This means optics. Cripes, I can even see
where it could include MIG welding, at times!

(I worked on developing a glass sorter which required optical
skills and electrical and electronic skills and welding
skills as well as programming skills. Being able to create
and setup simple experimental/test circumstances to explore
and validate different approaches at lower cost early in a
project can help in making sure that the final goals are
worthwhile and achievable before too much money is spent.)

I like to consider everything available and then, after I
understand the boundary conditions and goals well enough,
make choices. Having more skills than less means more choices
are available to consider. And that may mean the difference
between success and failure.

I think good assembly coding skills are one of the more
important programming skills for an embedded programmer to
get under their belt and with which to feel at home. But by
no means, the only such.

Jon

>Blakely LaCroix
>Minneapolis, Minnesota, USA

Posted by: Jon Kirwan

I have not visited here much of late - guess the lack of projects or new processors or laziness(?).

Nice to Jon and Al- both of whom have given me invaluable help over the years.

I use the IAR assembler tools as well. The are fast YACC based tools. I use them for the MSP430, 8051, and Renesas RX family. Nice to be able to work with the same tools sets. I don't use the IAR IDE at all nor their .h files. For every product, I create that defines every register, every bit and uses a fair amount of ASCII graphics. The idea behind this is that as an appendix, it follows the product and serves to complete the documentation. The chief advantage I find is that you get a great exposure to the hardware and peripheral base that each processor family supports. And like much code, it becomes the template for subsequent additions to that family. The downside is that it takes a long time to create. I am working on the RX family now and some members there have a huge number of configuration registers.

Everything is done from command line invocation in (ALT - F9) UltraEdit with the result box popping up in the editor.

My fallback assembler is the X32 Universal Assembler - a table driven product that allows you to define your own Mnemonics and Opcodes. It can be expanded to add new instructions. I did this to extend their H8 tables to support the H8S family - most notably the STM and LDM multiple stack push/pop instructions. And it is very useful when porting code. If I were more ambitious, I would create a Meta-Assembly language and then define the Opcodes for each member family. Of course a good Macro capability in most assemblers can do the same thing.

The real reason I code exclusively in assembler is that it reads better to me. It matches my thinking and appears perfectly clear. Maybe it is just a mental limitation of my part, but C is just too ugly to read and easily gets obfuscated beyond comprehension.

Blakely LaCroix
Minneapolis, Minnesota, USA

On Wed, 13 Jan 2016 10:43:07 -0800, I wrote:

>and any finite set of compiler algorithms.

I meant, "THAN any finite set of compiler algorithms."

Sorry,
Jon

Posted by: Jon Kirwan

On Wed, 13 Jan 2016 00:20:52 -0800, you wrote:

>Wow, what a discussion I've sparked!

Well, most of us were just trying to clarify your question
and/or trying to be directly helpful. But "resonances" do
take place. ;)

>>5. Assembly is all they know, and they don't want to learn C.
>
>Bingo! I learned the bare essentials of assembler taking electronics
>(digital specialty) at BCIT in 1974/1975.

I learned assembler in 1972. So right about the same time.

>I started by building microcomputers, which were hardly available at
>the time, from the chips.

Same here. And I learned still more late 1975 I think,
through hard won experience trying to diagnose and then fix
design problems in the Altair 8800's 4k dynamic RAM cards
(they WERE designed INCORRECTLY.)

>Never took programming per se,

I've also never taken a single class on programming, then or
since. I have, however, _taught_ computer science classes for
years at the largest 4-yr university in my state -- computer
architecture (2nd yr), assembly programming (2nd year),
operating systems (3rd yr), and concurrent programming (3rd
year.)

>but the computers were only
>useful with software, so I developed my 6809 structured assembler and
>a crude text editor for my 6809 based computer. And a 4800 baud
>cassette interface for data storage - 4 times faster than any
>commercial ones and more reliable.

Interesting. I designed and built a 600bps modem using a
6-pole transmit and a 10-pole receive filter in the 1970's.
The cassette interface I didn't do, but I suspect that it is
a somewhat less complex design. I do remember using one on
the first IBM PC (1983) which was included in the ROM BASIC
they provided and prior to that on the TRS-80, I think.

>I wrote among other things the first "Paint" program ever sold to the
>public, "TV Graphics Editor" (1982) for Radio Shack Color Computer
>(MC6809), and the world's first graphic adventure/role playing game,
>"Viking Raider" (1984) for the Commodore 64. (Not a single untouched
>256 byte block of memory remained, but I got everything in! About 150
>screens of RLE map/scenery. Oh yah, the 6502 cross assembler that ran
>on the Radio Shack CoCo for that project was another stuctured
>assembler I wrote. I recall it only took 5 days to write, but it was
>essentially just an adaptation of the 6809 version.)

This was around the time that I started a new business to
write and sell Winning on Wall Street for technical security
analysis and accounting for the Apple II and the IBM PC. Had
to write lots of drivers for newly arriving equipment and was
forced to use assembly coding on both machines for some of
the work (but not all, by any stretch.)

I don't remember your editor (didn't use the Radio Shack
computers that much at the time) or RPG (didn't use the C64
much either back then), though. Speaking of which, I have
BOXES of Commodore 64's and peripherals and manuals and
software here. One of these days I will need to figure out
what to do with all that stuff I've packed away.

>When I saw "Mac Paint" on the first Macintoshes, I thought they had
>copied my "TV Graphics Editor", but there were enough differences
>that I cancelled that thought, and I found out later that there was
>an even earlier "Paint" program that had circulated in university
>circles, on which Mac Paint was based.

Interesting.

>When I got into the 68K I started writing AKO really sophisticated
>stuff, but I never got it to market.

I did do some applications on the 68020. But not many. I was
truly in love with the 88k, though. That was a nice looking
CPU architecture to my eye of that day.

>I dislike C.

I don't dislike it. I first was exposed to it while working
on Unix v6 in 1978 and really got to like it then. I've been
using it since.

>I have the hubris to think I (and I speak only for
>myself) can do anything better and faster in assembler. ...with a
>processor having a nice architecture and instruction set. From the
>68K stuff on I've always tried to document and comment what I do very
>fully. That's what will make the code easier for others to deal with
>it later more than what language it's written in. I often find C very
>hard to figure out just because it is so often sparcely commented -
>also because the source is so often split into several or even many
>files, which is of course a reflection of author philosophy or 'C
>traditions' more than of the language itself.

Like anything else, we use the tools we know well when facing
tasks. I suspect that if you spent the time it takes to
become familiar with C, and learned how to hand-compile
assembly code from C source (you should be able to write
assembly code from C source almost as fast as you can write
-- it's actually quite easy), then you might enjoy it more.

For embedded use, it's my opinion that you really need to
thoroughly understand what a compiler "models" and what it
generates from the code you write. So if you type a line of
code, you should have a very good idea what it produces (you
should be able to do some of the optimizations quickly by
hand, as well.)

I had a really good time a few years ago when I got involved
in a debate between those who believed that modern x86/x64 C
compilers were far better than assembly programmers when
generating code. We did limit the challenge to local
optimizations over functions (not global, across them.) Two
of us engaged the "assembly side" of the project (which
lasted some months over the C newsgroup debate period.) I,
and my cohort, were able to produce assembly code that bested
the best compiler results by over a factor of 2 in speed and
by 30% in size, as well.

One of the lessons I learned from engaging this project is
that we humans can think in ways that NO COMPILER optimizer
can achieve, so far. The function was a simple one -- a
commonly found "greatest common divisor" function. The
solution for us was quite simple -- we "inverted" the
algorithm mentally which fit the x86 hardware better. No
compiler optimizer has ANY IDEA how to do that. And so far as
I'm aware, no one has even written a paper on how to
generalize the concept. I have some ideas how that might be
done. But... well, I don't have the spare time to pursue that
anymore.

We humans can be far, far more creative about what we can
apply and any finite set of compiler algorithms. What
compilers do REALLY WELL is "book-keeping" a large number of
things at once and in consistently applying principles over a
large set of code. Linkers have also developed substantially
in their intelligence, as well.

There is, I think, a bit of a sea-change ahead though. In the
case of these "multi-core" cpu systems regularly available
now, functional languages can offer some things that are much
more difficult to manage with imperative languages like C (or
assembly.) I'll give a trivial example using Haskel:

factorial n = product [1..n]

This lets the compiler and operating system work out how to
spread this function's necessary multiplications across
multiple cores, automatically. A "partitioning" algorithm can
automatically use the number of available cores to break up
the set 1..n into separate pieces, which are then supplied to
the cores in isolation for the work to be performed. It can
then perform the final product from the pieces. And it can do
all of this differently on different machines, with different
values of n, and upon 2nd and 3rd invocations (as it can also
"learn" in the sense that the partitioner itself can observe
prior behavior of earlier partitions and develop better ones
over time.)

This problem didn't exist, years ago. But it will be an
increasing problem over time. These are difficult to achieve
with imperative languages, but of course not impossible. For
example, .NET under Windows does provide paritioning classes
for exactly this kind of purpose and now includes a
Parallel.For and Parallel.ForEach method. But the code does
have to be modified and tinkered with and even then it's not
quite so easy for a programmer to "get right."

At the assembly programming level, all this is of course also
possible. In fact, you've got ALL of the necessary semantics
available at the assembly level (some of which are NOT
entirely provided to high level compilers -- even C++.) So in
really critical cases, you are back to writing assembly code
even on massive-memory systems like today's workstations if
you truly need outstanding performance. But you usually
target yourself there for the high bandwidth stuff or where
languages simply do not provide the semantics.

There is a really good Ph.D. thesis book here:

http://www.cs.yale.edu/publications/techreports/tr364.pdf

which I read in 1985 when it came out. (I soon was working on
a MIPS R2000 board for the IBM PC.) You can see some
semantics there that still isn't available today on modern
compilers. So you can imagine how many more ideas also are
not present, as well. Compilers are VERY LIMITED in what
semantics they offer. The compensate this by being very good
at book-keeping and consistency.

>I'm not sure why I've typed all this. Now it's past bedtime and I
>haven't done the work I meant to!

hehe!!

I'm very glad you did write! You very much clarified your
position as well as justifying my earlier writing to David
(which I couldn't have anticipated but am happy to have been
luckily more right than wrong about.)

Jon

>--Mr. Prejudiced
>
>PS: Hey, who swiped all my indents and spacings? (Rhetorical question) Grr!
>
>>test D1; SkipCS |BCS to end brace (BCS on 68K = JCS on MSP)
>>{
>>whatever
>>whatever more
>>dec D0; loopNE |BNE to start brace
>>}
>
>Posted by: Craig Carmichael
>
>
>
>