Forums

Simple I/O on Windows PC

Started by BartC June 21, 2013
> 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&#2013266166;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