Simple I/O on Windows PC

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?

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

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!

eighties). > But that just brings me back to my original problem of needing to bootstrap such a newly built circuit by

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.

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.

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.

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.

True for Arduino.

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

bootloader, then FLIP (Atmel's downloader) it. s/Atmel/Arduino/

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

bootloader, then FLIP (Atmel's downloader) it.

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 wrote:

-CC:\Arduino\hardware/tools/avr/etc/avrdude.conf

-Uflash:w:filename.cpp.hex:i

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

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

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.

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.)

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.

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

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

1 MB/s or 10 Mbit/s is not that hard, unless you use TTL or RS-232 :-) Profibus DP, which is essentially RS-485 runs at 12 Mb/s for about 100 m, but requires some impedance matching tricks. At 1.5 Mbit/s practically any barbed wire will do.

CANbus at 1 Mb/s can handle tens of meters and it uses bitwise arbitration, so the two way propagation delay limits the distance.

In any half duplex system, the line turnaround delay will quite effectively kill the throughput.

Even if the Z80 could send 100 KB/s or 1 Mb/s in burst mode, every node on the network must also be able to receive at that rate, i.e. the receiving station interrupt service times must be compatible, which finally limits the system throughput.

Some old PLC protocol even used such bizarre system

• Station A requests to transmit by sending a single byte.

• Station B sends a single byte Ack and enters receiver loop.

• Station A sends message in a loop and Station B receives by polling

• Station A responds with Ack/Nak depending on check sum check.

In such a protocol both Station A and Station B can use loops without interrupts. However, the "Request to transmit" to "OK to transmit" delay (often 10-300 ms) will drop the actual throughput considerably.

You can still get this granularity, just not from your X86 CPU, talking to an IO pin.

If you want assembler-level granularity, then just put a small uC at the end of the wire, it will likely cost less than the cable anyway. ( eg 65c for 44 pin AT89LP52, under 2c/io pin)

USB access constrains PC granularity to the order of ~1ms in Full speed, and maybe 4x faster in High Speed, but if you can arrange in packets, you can get quite high data flows.

It is not a brick wall, just a slightly different approach is needed.

I guess I don't understand your point. You want to program something using techniques that worked under MS-DOS. The problem with today's computers is not the hardware, but the OS. So just run MS-DOS. I think there are some functional equivalents to that you can find but I don't remember the names.

The problem you have asking for advice here is that you want to get to Baltimore and are asking how to cure your horse of colic. There aren't many here who can give you good advice on that because none of the reasonable ways to get to Baltimore include using a horse!

I would suggest that you look into using one of the Forth distributions to access one of the USB devices that look like a serial port, but give you pins you can control. The USB device will give you the hardware you wish to control and Forth will let you control a serial port with a minimum imposition from the OS. I am using Forth right now to control hardware I built and it is working quite well.

--

Rick

Then you must have picked the worst USB I/O board on the planet. COTS,

5$ USB-to-RS323 adapters do 115k2 Baud out of the box, i.e. about a factor 100 faster than that. But bytes/second, i.e. bandwidth, is not the problem with using a PC for this kind of thing anyway: latency is. You won't be reacting to outside stimuli within milliseconds using a Windows PC.

The pipes in a current PC are almost certainly wider than code of the type you're hinting at would know what do with. But they're also _long_, with lots of twists and turns to be maneuvered..

Nothing --- if you use the right tools for the job. A PC is not.

Efficiency is important for PC. First, when doing something you want to do computations as fast as possible and limit waste of processor time on other activites. Second, when system is almost idle you do not want to drain battery in a laptop so interrupts are better than busy loops. And typical system is for long time connected to network, so you have some asynchronous activity going on.

Closer to your original problem: when bit-banging speed will be limited by latency. To get low latency you need to put device on PCI bus, but design (and manufacturing in small quantities) of such device is expensive. Most applications can tolerate much larger latencies, so that is provided by cheaper solutions.

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

Possibly! This is a K8055, a 'USB experiment interface board', which I'd dismissed in the past as being too slow. However it has some qualities which I can now appreciate: it's simple, it's easy to interface to my language, and it works! (Because I do have my own languages, getting them to work with other systems always requires special effort. But the code I used to test out the K8055 is shown below. It needs only a 350KB DLL file.)

I've used RS232 quite a lot in the past, but never liked it. Always something that will not work, and customers always had problems with it too. In the current context, a serial link will also need some gubbins at the other end to re-assemble the data.

(Talking to the K8055 and writing bytes 0 .. 255 one after the other to the output pins (which conveniently have LEDs attached to see what's happening):)

from k8055d: clang function OpenDevice (int)int clang proc CloseDevice clang proc WriteAllDigital (int)

if opendevice(0)=-1 then println "Can't open USB card" stop fi

for i:=0 to 255 do writealldigital(i) od

closedevice()

--
Bartc

Am 21.06.2013 11:13, schrieb BartC:

RTS, CTS, DCD, DTR of a serial port?

Gunther

Just in case you are open to using something a bit faster, here is one of the type of devices I was referring to. I haven't tried this, but I am pretty sure it will do a lot better than 100 bytes/sec.

It uses an FTDI USB chip to interface to a Microchip MCU. The MCU is pre-programmed to let you twiddle bits on a number of pins to output or input and even has an 8 bit bus you can control. It uses FTDI drivers and if you don't want to mess with interfacing to their DLL you can talk to it as if it were a serial port.

How much simpler can it be?

Here is a link to the Digikey page for it.

Rick

--

Rick

You want to end up with ASCII *character* codes for source code. But editors rely on *key* code and modifier (shift, ctrl and alt) combinations in order to get there!

Linux, using console mode, tries to return such combinations as a stream of ASCII characters. That means complex multi-character sequences for non-printable keys, but only some combinations are allowed, and half of those have pre-existing special uses. The codes are also all over the place with many inconsistencies, with sequences of different lengths too. It's a mess. (I don't know what it's like using 'X', but I'm not attempting graphics at the moment).

There is a library called 'ncurses', but I've tried it and it doesn't really help, and it's also intrusive.

(I've spent the last week or so trying again with Linux, on three different systems, and getting nowhere with problem after problem, mostly trying to get the OS to work properly, and that's even before I get to my own problems!)

--
Bartc

Well behaved text mode Linux editor _does not_ depend on key codes. They depend on translations done by kernel. The translations are setable and allow user lot of customizaton. But if you want you want to dig into key codes, it is possible: /dev/input/event* device file give you access to low level information.

This is comples, but if handled properly allows user input/output on wide range of devices. The tivial example is using serial port for full screen operation (useful for debugging).

It take some time to find out how things are done. There are some capabilites that terminal have (or does not have). 'ncurses' allows you to test which capabilities terminal has and to use them. 'ncurses' is written with abstract view of terminals (which apparently you dislike) but otherwise is not intrusive: 'ncurses' offers you several functions which go beyond basics and assume specific way of termianl handling, but you are free to ignore them and just stay with basics.

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