Slashdot Mirror


EPROM Burning Under Linux?

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.

3 of 10 comments (clear)

  1. Crap! I missed it! by twdorris · · Score: 2

    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. :-(

  2. hmm.. by Zurk · · Score: 2

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

  3. eprom programmers for linux by small_dick · · Score: 2
    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) 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.

    --


    Treatment, not tyranny. End the drug war and free our American POWs.
    See my user info for links.