Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Hardware

EPROM Burning Under Linux? 10

Posted by Cliff from the where-can-I-get-one-of-these? dept.
twdorris asks: "With all the talk about embedded Linux and with all the focus from typical Linux "guys" on hardcore hardware, I find myself a bit surprised by what appears to be a lack of support for EPROM burners under Linux. I have a Pocket Programmer make by Intronics that I use to burn performance mods to my car with. It's about as simple a task as there could be. I just need to burn 27c512's (a very common, simple EPROM). Yet I was not able to find any way to do this natively under Linux. Instead, I was forced to use DOS for this task (until I recently wrote a program to do it under Linux). Using DOS/Windows for things like paying bills is one thing...that's a typical "user" application that I don't mind relegating to a "user" OS. However, burning EPROMs is something that sure seems more appropriate to be doing under Linux. Anybody got any pointers to an EPROM burner and/or software that will work under Linux for this very much hardware related task?" That's a good question. I wonder if twdorris would mind sharing the code -he- used to burn EPROMS with Linux.
This discussion has been archived. No new comments can be posted.

EPROM Burning Under Linux? More

EPROM Burning Under Linux?

Comments Filter:
  • http://www.altera.com/html/mktg/isp-jam.html#intro

    The Jam(TM) Standard Test and Programming Language (STAPL), JEDEC standard JESD-71, is a standard file format for in-system programmability (ISP) purposes. Jam STAPL is designed to support programming or configuration of programmable devices and testing of electronic systems, using the IEEE 1149,1 Joint Test Action Group (JTAG) interface. Jam STAPL is a freely licensable open standard.

    I use this to program from an embedded Z180 with JAM code ported from the example source. If your devices support JTAG, it can be done with this and a 4 wire interface.(i.e. parellel/serial port)
  • > but it would be very difficult for Linux to supply data in spec.

    I agree, but not impossible. It would make for an annoying device driver, but you could just put a busy wait loop in the driver to wait an appropriate amount of time. I would hate to do it, but it should work OK. Of course, this approach will not work for all types of programmable memory, though. Some are extremely sensitive to timing. The ones I'm most interested in, however, are the run of the mill, 27c512s and 27c256s that just have a minimum specified time.
  • I've been waiting for my "ask slashdot" question to be posted for weeks and when it finally is posted, I missed it. Ugh!

    As for sharing the code I wrote to burn EPROMs under Linux, I would be happy to. It only works with the Pocket Programmer made by Intronics, but that's a pretty popular programmer. As others have already posted, the real issue is getting the timing right when burning EPROMs. It's a real bitch!

    Under DOS, one just has to write a simple timing loop to calibrate your code for that particular PC and then just enter a while loop of some sort while burning to wait the appropriate amount of time. Under a non-realtime, multitasking OS like Linux, however, you aren't guaranteed any particular amount of processor time and given the VERY poor granularity of the PC clock (something like 10ms!! Ugh!), relying on usleep or something similar just doesn't cut it.

    I guess a related question that I have is whether writing a pure device driver to do this type of thing would make the task any easier. The code I have written is strictly a user level application and it's impossible to get any sort of guaranteed processor time for this task. I'm not afraid of coding up a device driver, but before I delve too far into it, I wanna know if it's even going to help matters any. I suspect my real problem here is the accuracy of the PC clock, though. :-(

  • hmm.. (Score:2)

    by Zurk ( 37028 )
    the most common objection to this is that winnt and linux are multitasking OSes. this makes it somewhat dicey to reflash an EEPROM from under these OSes....too much time or load and wham - dead eeprom. thats why you dont get awdflash for linux, windows nt or any other windows (DOS only). i think you could do it using the real time threading on linux but its often simpler to just write an assembly bios flasher (or an eeprom one) under a non multitasking OS like DOS which is basically a glorified file loader. and FreeDOS is available if you dont like M$.
  • Generally I just use some old XT, but it would be nice to do it under Linux.
    I am sure someone somewhere has done it, but if thats does not seem available then I know enough to do it.
    If it *realy* is needed email me and I will churn out a simple programer (27C64), that should provide enough of a start for the rest.

    conversly I would be keen to help any real programers with the electricle side.

    cya, Andrew...

  • Well at least some plans and some source code, looks like it could be ported just needs some care when it comes to the timing.
    have a look here [zws.com].

    cya, Andrew...

  • actually, it's really not EPROM "burning"; it's programming... Generally though, at least in my experience, an EPROM or EEPROM or whatever will come with it's own proprietary programmer, and it is this programmer with which the computer must interface. There isn't a really good way to write a program to tell the programmer to program PROMs because of the fact that programmers have a generally unique interface (wow... that was almost as confusing to write as it will be to read). It is actually possible to program the things manually, and it really doesn't take a sophisticated program to preform this operation. Just build your own programmer to which you know the interface, and write a program to interface with the serial port of you puter. Personally though, I think that something like this is pointless, because anyone that really needs to program a PROM will most likely know how to do it themselves, and you can't expect something universal to come out and be supported under linux when hardware (the physical programmer you would need to build) is involved.

    As far as the embedded market goes, EEPROMs again have a specific proprietary interface such as the one in your computer that holds your BIOS information. programs would need to be written for each specific proprietary implementation. And this isn't supported any better or worse under DOS/Win. Infact, it's probably easier to write the needed programs under linux because of it's openness and extensibility. Which would make me think that Linux should be a better choice for the embedded market anyway: not because it has an extensive library of programs which support intricate things such as programming strange and wonderful hardware, but because it is much easier to write this kind of software on an open unixlike system than under DOS or Win...

    But all that is just my $0.70710678118654752440084436210485 ... So take it as you will...
  • I've seen two basic styles of chip programmers. Ones that have large enough buffers to hold a copy of the chips contents, and ones that depend on the data being transfered in time to meet the timing specs of the chip.

    The ones that can hold all the data in a buffers usually accept Hex or S-Record format sent over a serial port. These should be able to be adapted to be used under linux with little or no problem. The drawback is that the memory and the processing power needed on the programmer makes these devices very expensive.

    The ones that format the buffer on the computer and send them in time to meet the chips programming specs can be cheaper, (an ISA card with some line drivers on them) but it would be very difficult for Linux to supply data in spec. (Maybe with RT-Linux?)
  • first off, the person is asking about EPROMS, not EEPROMS.

    and yes, you do "burn" eproms. it's been called that for years. it's a pseudonym for programming them.

    EPROMS and EEPROMS do not, in general, have a "proprietary burner". there are a plethora of EPROM/EEPROM burners on the market that work with many devices; indeed, some of them allow you to define new devices on the fly by entering the information from the manufacturer's data sheet.

    there is no reason that unix or linux could not program a device. the drivers are more difficult to write since you must be priveledged to access the hardware. there are ways around this; either run the program as root or write a proper device driver.

    by bumping up the process priority and/or running the burn software as root (as most CD burning software for linux does) the context switching issues become moot. i have never seen a eprom burner that does not have some type of buffer to handle latency issues.

    the reason they're mostly written for dos is : it's simple, a non-moving target and nearly everyone has a copy of DR-DOS or MS-DOS or whatever laying around.

    more burners are coming with windos s/w now, as DOS continues to fade into the past. I used to sell xeltek programmers, and i just checked their (website [xeltek.com]) and they have both DOS and WIN drivers for their devices.

    I know of no company supporting Linux for their EPROM burners.

    Having said all that, I seem to recall that you can setup "dosemu" such that it can run dos programs which access a series of I/O ports and utilize interupts. I have yet to try this with my burner, which currently runs under Caldera's DOS/DRDOS on it's own partition. It may work.

    Leave some kind of reply if you are interested, and I will try and get to it and post the results back.

    --- S.D.

  • Reading the 27x512's is easy as pie. Just need a 24-bit IO card (an 8255 on a board does this nicely). Maplin [maplin.co.uk] sell one of these cards which you can build yourself for under 30ukp. They're dead easy to interface to aswell.

    In terms of writing to one, I'm currently in the process of investigating how. The biggest problem is the 50us (I think it's microseconds, not sure off-hand though) pulse to the PGM (I'm working from memory here) line. This is the "timing critical" part of programming. One way to do it would be to use a monostable, or other timing circuit to provide just one pulse. Using that in conjunction with the 24 bit IO card to set the address/data lines, programming should be easy.

    Caveats:
    24 IO lines are all used up for address (16 bits) and data (8 bits). You'd have to use another IO thingummy to get it to work (I'm going to try using the serial port). Then I just set the data/address lines, pulse the appropriate serial line and a 50us pulse will be sent to the chip. I can wait a millisecond (say) before programming the next byte. Ok, it'd take a minute to program a chip fully - how often are you programming chips though, given it takes 20 minutes to erase one?

    -- Maz
    Varying the mileage you get in direct proportion to the number of MP3 related posts on freshmeat.net

Slashdot Top Deals

"May your future be limited only by your dreams." -- Christa McAuliffe

Close