Simple I/O on Windows PC

> last stage was uploading the binary program, and was invoked like this
> 
> C:\Arduino\hardware\tools\avr\bin\avrdude -CC:\Arduino\hardware/tools/avr/etc/avrdude.conf
> -q -q -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:filename.cpp.hex:i
> 
> 
> 
> That would be a stumbling block even if I replaced all the other steps. The 
> interface is USB, with apparently a COM port superimposed, but I've no idea
> what protocols are needed to rewrite the flash memory and restart the
> processor.

There should be a USB bootloader on the AVR side.  I am not sure if it's compatible with the Atmel bootloader.  If not, first thing is to reflash the chip (SPI ISP) with the Atmel bootloader, then FLIP (Atmel's downloader) it.

BartC wrote:
> "Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message news:XH2xt.156150$tu1.36428@fx20.am4...
>> BartC wrote:
>
>>> Sure, but I don't know how! And it's difficult to find out because people
>>> are expected to use tools like this so that the direct methods are not
>>> documented. The great, sprawling nature of the software (with the paths in
>>> some arguments being twelve-deep!) makes it hard to figure out what's what
>>> as well.
>>
>> I'm not sure which tools you are referring to in "tools like this".
>>
>> If the tool is an execution environment (e.g. an o/s or Arduino)
>> then read the documentation. if there isn't any, choose one that
>> is documented!
>
>> If the "tool" is the compiler/linker/downloader and debugging,
>> then that is all taken care of by the IDE provided by Atmel.
>> Windows, gag spit, but usable. There are a limited number of
>> selections to be made, e.g compile for speed/size, which
>> programmer/debugger you are using, but the choices are pretty
>> straightforward (even if the resulting compiler switches etc
>> aren't!).
>
> The 'tools' were the software, 'Arduino 1.0.5', '...based on Processing', which is a packaging of a gcc compiler (or is it g++) among other things.
 > Very untidy when you look into it.

Is it tidy if it doesn't work?

> My approach has always been far simpler and much tidier
 > (it had to be because I didn't have 250MB of spare disk space!)

What's the cost of your time vs a disk?

 > But I'm fairly new to these new systems and I only just
> understand that an Arduino is itself a
> packaging of an AVR processor.

Arduino = processor + bootloader + libraries + compiler.

It is intended to be simple for a beginner when used as
a whole. Of course, if you rip it apart it is no longer
simple. So what? Neither is a processor if you rip it apart!


>> If the "tool" is the processor and you are programming bare silicon,
>> you simply read the processor data sheet.
>
> That's another valid approach of course, and what I used to do (in the early eighties).
 > But that just brings me back to my original problem of needing to bootstrap such a newly built circuit by
> downloading code from a host computer. I think I can use my K8055 board to get started with that, and worry about speeding up the downloads later.

No idea about those tools.

I used the AVR IDE and AVR Dragon, and built my own PCB using
the laser printer technique. It worked without hitches and
enabled me to do what I want.

On 21.06.2013 11:13, BartC wrote:
> Suppose I have an x86-based PC running Windows 7; I have a couple of simple
> tasks:
>
> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)

While those tasks are simple, a PC hasn't been in a _long_ time.  And 
yes, doing simple things in a massively complex system will be anything 
but simple.

> At what point over the last 20-30 years did something so simple become next
> to impossible?!

Pretty much when Microsoft finally decided to create an actual Operating 
System for PCs, i.e. as of the move towards Windows NT.  The kill-shot 
was the switch to the NT line of Windows for consumer PCs, e.g. Windows 
2000.

Until then, the primary reason such things were still relatively simple 
on PCs was because DOS (and the Windows versions based on it) didn't 
bother to do much of anything with those peripherals, so neither did it 
get in your way.

But a real OS has to manage all aspects of the system.  It has to decide 
which program gets to use which peripheral when, and how.  So it has to 
get in your way when your program tries to just do with the peripherals 
whatever it pleases.

In the end, you're no longer programming a computer --- you're running 
code on its operating system (or something even further "upstairs" than 
that).  So you'll be talking to a pseudo-file provided by a high-level 
software device driver that abstracts a USB device connected to a PCI 
bridge sitting on one of the CPU's external links.  And that's the 
simple case, mind you.

> It just doesn't sound right either

What doesn't sound right is to use a PC for this kind of activity.  It's 
the wrong tool for the job, and has been pretty much since PCs replaced 
home computers.  It just used to barely support them, more by lack of 
care than by any kind of conscious design decision.  But those days are 
over.

edward.ming.lee@gmail.com wrote:

> There should be a USB bootloader on the AVR side.

True for Arduino.


> I am not sure if it's compatible with the Atmel bootloader.

What Atmel bootloader? They prefer to poke the flash directly.


> If not, first thing is to reflash the chip (SPI ISP) with the Atmel bootloader, then FLIP (Atmel's downloader) it.
s/Atmel/Arduino/

On Friday, June 21, 2013 3:31:40 PM UTC-7, Tom Gardner wrote:
> edward.ming.lee@gmail.com wrote:
> 
> 
> 
> > There should be a USB bootloader on the AVR side.
> 
> 
> 
> True for Arduino.
> 
> 
> 
> 
> 
> > I am not sure if it's compatible with the Atmel bootloader.
> 
> 
> 
> What Atmel bootloader? They prefer to poke the flash directly.
> 

Atmel has serial and USB bootloaders for certain chips.  They come preloaded on the chip, unless someone like Arduino wipes it out.


> 
> > If not, first thing is to reflash the chip (SPI ISP) with the Atmel bootloader, then FLIP (Atmel's downloader) it.
> 
> s/Atmel/Arduino/

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message 
news:b2k2ccF4a4jU1@mid.dfncis.de...
> On 21.06.2013 11:13, BartC wrote:

>> It just doesn't sound right either
>
> What doesn't sound right is to use a PC for this kind of activity.  It's 
> the wrong tool for the job, and has been pretty much since PCs replaced 
> home computers.

You might be right. With the solution I will probably go with first (an 
experimental USB i/o board), I can get a throughput of 100 bytes/second. 
Thirty years ago, with a Z80 computer a thousand times slower than my PC, it 
would probably have managed 100,000 bytes/second! I wonder what went wrong?

-- 
Bartc 

BartC <bc@freeuk.com> wrote:
> "Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message
> news:lZ0xt.110435$jM6.74585@fx13.am4...
> > BartC wrote:
> >> Yes, I've been playing with an Arduino, that's what gave me the idea to
> >> attempt something of my own. But the little 32KB board I have, comes with
> >> 256MB of software on the PC, with 6000 files in 2000
> >> directories! That's a lot of software to get in the way and make any
> >> solutions using this rather unwieldy.
> >
> > I don't see why you think the size/number of the files on the PC is
> > relevant.
> >
> > Even if you have an Arduino, it doesn't mean you have
> > to use the Arduino environment: you can program bare
> > silicon directly in C or assembler.
> 
> Sure, but I don't know how! And it's difficult to find out because people
> are expected to use tools like this so that the direct methods are not
> documented. The great, sprawling nature of the software (with the paths in
> some arguments being twelve-deep!) makes it hard to figure out what's what
> as well.
> 
> I did manage to eliminate the GUI (an entire Java subsystem was included
> just for this purpose), but I was still left with a series of five programs 
> that had to be run for each update, with some hairy-looking parameters. The 
> last stage was uploading the binary program, and was invoked like this:
> 
> C:\Arduino\hardware\tools\avr\bin\avrdude -CC:\Arduino\hardware/tools/avr/etc/avrdude.conf
>  -q -q -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:filename.cpp.hex:i
> 
> That would be a stumbling block even if I replaced all the other steps. The
> interface is USB, with apparently a COM port superimposed, but I've no idea
> what protocols are needed to rewrite the flash memory and restart the
> processor.
> 

What do you really want?  If you want PC as it was in 80-s, then
just keep the old one, because new machine are going to be quite
different.  In fact, Raspberry Pi is probably closest to environment
of old PC between modern offerings.

The simple fact is that modern processors are many times faster
than processor in PC -- Raspberry Pi is of order 1000 faster,
and desktop PC is about 50000 faster.  But this is not having
"the same only faster".  To get high speed modern processor
plays trics as executing many instructions in parallel, etc.
If you try to use them "old way" you may find out that
your processor is 10 times faster or maybe equal speed to
the old one.  In particular, it is hard to get data from
CPU to external world and back faster than in 100ns.
Desktop processor can do about 1000 instructions during
that time.  So it should be pretty clear that bit-banging
is extremally inefficient in modern machines.  You may
not like USB, but it allows to transport relatively
large amounts of data to diverse devices with only
little CPU work.  Of course, if you try bit-banging
via USB you will make very inefficient use of USB and
roundtrip below 1-2 miliseconds is hard to do.

Coming back to your direct question: if you want to get
data in and out of PC your one of best bets currently is USB.
Simpler interfaces like serial or parallel ports are
diappearing and alternatives are of comparable or bigger
complexity.  There are cheap "serial" or "parallel"
cables which on the PC side appear with API like old
serial or printer port and on the other end offer
apropriate hardware interface.  At least on Linux
you do not need to install any extra software on
the PC side to use them (IIUC in Windows you need
to install a driver).  (Most of) Arduino is essentially
equivalent to such USB/serial cable connected to AVR
processor.  That is the "main" processor is connected
to a "communication" processor via a serial link.
"comunication" processor translates USB trafic to
serial and back -- from the point of view of PC
the "comunication" processor looks exactly like
USB/serial cable.  To do interesting things via
serial link you need software to support it at
the both ends.  The AVR processor in Arduino
contains preburnt loader module which waits
for program image to burn into memory.  On the PC
side the avrdude program sends program image
and control codes.  If avrdude command line
is too complicated for you, then use GUI.
The GUI was created exactly for folks who
think that sparing 256 MB on disc is not
worth effort needed to understand details.
Note: if are able to find argument to avrdude
that work for you one time, you can create a
script (.bat file or more modern equivalent)
that invokes avrdude with right arguments
and just use to script.

Also. Raspberry Pi can be used for this: you can
connect to Raspberry Pi via standard Web protocols
and use its I/O lines.  If you look in detail at
all software involved in such setup, then you
could say that it is horribly complicated.  But
if you just want to get the data in/out, you
can do this relatively easily, all complexity
is hidden.

Final remark: if you want "ready made"
software, than you better like what majority
(or at least some significant minority) likes.
Othewise you need to be rich enough to hire
somebody to write custom software for you
or do it yourself.  "do it yourself" may mean
choosing check boxes for options in GUI,
changing configuration files, writing scripts
or writing from scratch.  Just do not be
surprised that getting highly efficient custom
system from scratch is not a childs play -- it
never was (old bit-bunging software made quite
inefficient use of CPU and easyness was due
to using standard componets of PC).

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

BartC <bc@freeuk.com> wrote:
> "Hans-Bernhard Br?ker" <HBBroeker@t-online.de> wrote in message 
> news:b2k2ccF4a4jU1@mid.dfncis.de...
> > On 21.06.2013 11:13, BartC wrote:
> 
> >> It just doesn't sound right either
> >
> > What doesn't sound right is to use a PC for this kind of activity.  It's 
> > the wrong tool for the job, and has been pretty much since PCs replaced 
> > home computers.
> 
> You might be right. With the solution I will probably go with first (an 
> experimental USB i/o board), I can get a throughput of 100 bytes/second. 
> Thirty years ago, with a Z80 computer a thousand times slower than my PC, it 
> would probably have managed 100,000 bytes/second! I wonder what went wrong?
> 

Maybe the Z80 computer "terminal/keyboard handling was too crude"
and users wanted different one?  For typical home use access to
experimental boards is irrelevant.  You can get systems which
interface nicely with experimental boards, but that take
extra software and hardware.

Note that actually getting 1_000_000 bytes per second at reasonable
distance is not that easy due to electical charactristics.  You
can get it via USB or ethernet if you use block tranfers.  If
you want single byte transfers, than it is likely that your
Z80 would have trouble with 100_000 bytes per second.  AFAIK
in early PC era parallel printers freqently peaked at
few kilobytes per second.   Modern interfaces can do much
more (there are cheap gadgets that transfer tens of megabytes
per second), but using block transfers and at the cost of
complexity.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

"Waldek Hebisch" <hebisch@math.uni.wroc.pl> wrote in message
news:kq2qu4$88$1@z-news.wcss.wroc.pl...
> BartC <bc@freeuk.com> wrote:
>> "Hans-Bernhard Br?ker" <HBBroeker@t-online.de> wrote in message
>> news:b2k2ccF4a4jU1@mid.dfncis.de...
>> > On 21.06.2013 11:13, BartC wrote:
>>
>> >> It just doesn't sound right either
>> >
>> > What doesn't sound right is to use a PC for this kind of activity.
>> > It's
>> > the wrong tool for the job, and has been pretty much since PCs replaced
>> > home computers.
>>
>> You might be right. With the solution I will probably go with first (an
>> experimental USB i/o board), I can get a throughput of 100 bytes/second.
>> Thirty years ago, with a Z80 computer a thousand times slower than my PC,
>> it
>> would probably have managed 100,000 bytes/second! I wonder what went
>> wrong?
>>
>
> Maybe the Z80 computer "terminal/keyboard handling was too crude"
> and users wanted different one?

A typical screen would have been memory-mapped so that random positioning,
colour control etc (to the capabilities of the display) would have been
completely controllable and 100% flexible.

In Unix (and Linux etc) this is all hidden behind half-a-dozen layers of
software which also hides many of the capabilities. You end up with
something as inflexible and frustrating as a dumb terminal.

> Note that actually getting 1_000_000 bytes per second at reasonable
> distance is not that easy due to electical charactristics.  You
> can get it via USB or ethernet if you use block tranfers.  If
> you want single byte transfers, than it is likely that your
> Z80 would have trouble with 100_000 bytes per second.

My Z80 estimate was based on a loop like this:

loop:
  ld al,(hl)
  inc hl
  out (n),al   ; or ld (nn),al
  djnz loop

At 4MHz, 100,000 iterations per second is quite possible. The write
operation can also be decoded to help step a counter or whatever happens at
the destination (for example if the intention is to populate a memory chip),
making effective throughput even faster.

As for the distance, the destination would likely be right next to the host
machine! (This would be an i/o or memory-mapped port.)

> AFAIK
> in early PC era parallel printers freqently peaked at
> few kilobytes per second.

That would have been limited by other factors: the physical printing speed
for example. The maximum speed of parallel data over a typical ribbon cable,
even of 2m length, I doubt would have been that low.

> Modern interfaces can do much
> more (there are cheap gadgets that transfer tens of megabytes
> per second), but using block transfers and at the cost of
> complexity.

Because I was doing a lot of this stuff in the eighties, I have a certain
idea of what is possible, and what is needed to achieve it. So for example,
a typical printer driver, for printing colour images to a dot matrix, might
only have used a few dozen lines of code, of which the inner loop might be
different between Epson and HP printers! (Different escape codes, and
different orientation of the data.)

Now a downloaded HP printer driver would fill four entire hard disk drives
of the time; and it wouldn't work with Epson either!

So I dispute that the complexity and size of a lot of these things is
actually necessary.

-- 
Bartc 

"Waldek Hebisch" <hebisch@math.uni.wroc.pl> wrote in message 
news:kq2pdr$oep$1@z-news.wcss.wroc.pl...
> BartC <bc@freeuk.com> wrote:

>> That would be a stumbling block even if I replaced all the other steps. 
>> The
>> interface is USB, with apparently a COM port superimposed, but I've no 
>> idea
>> what protocols are needed to rewrite the flash memory and restart the
>> processor.

> In particular, it is hard to get data from
> CPU to external world and back faster than in 100ns.
> Desktop processor can do about 1000 instructions during
> that time.  So it should be pretty clear that bit-banging
> is extremally inefficient in modern machines.

Accessing RAM is also inefficient. And then you have disk drives which are 
magnitudes slower than that. And presumably a PC will have numerous devices 
with registers to read and write that are also inefficient to access 
compared with a normal instruction stream.

But these are necessary to access from time to time, so allowance is made. 
It's not as though this 'bit-banging' is continuous. But if that was what is 
needed sometimes, so what? My PC spends most of its time waiting for me to 
press a key. It's not a mainframe computer where I'm paying for CPU time by 
the second!

-- 
Bartc