6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 22, 2024 8:21 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 2 of 18
  [ 269 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 18  Next
  Previous topic | Next topic 
Author Message
scotws
PostPosted: Wed Apr 17, 2013 6:12 pm 
Offline

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany
Great work, and I think you're right with the Nano. Thanks for the protocol -- I've spent the last couple of days either at work or moving dirt and planting stuff in the garden, so nothing new here with anything else. My father always said that progress in Germany and Scotland was driven by the bad weather ...
Top
 Profile  
Reply with quote  
mkl0815
PostPosted: Wed Apr 17, 2013 7:40 pm 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
So your father is a wise man. I've found the time tonight to finish the prototype. It's big, it's ugly, but it works.
Image
My testprogramm still works, writing data to the EEPROM and reading the data again.
I also started with a tool named DipTrace to create a PCB for the programmer. If I've done right, it should be 10cm by 5cm (4" by 2") in size. I have to double check the schema again and then I can post the result of the PCB here. If everything seems right, I would order some boards at http://www.seeedstudio.com, they offer 5 boards of 5x10 cm for about 20$ (without shipping).
Next step is the firmware for the Arduino Nano. First I will try to increase write-speed by using page write mode and polling to minimize the write-cycle time.
Mario.

_________________
How should I know what I think, until I hear what I've said.
Top
 Profile  
Reply with quote  
mkl0815
PostPosted: Tue Apr 23, 2013 6:01 am 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
It took some time to figure out how to use /DATA polling to determine the end of a write cycle, but after I found the right sequence I could double the write rate for writing single bytes to the EEPROM.
By writing one byte at a time, the whole 8k EEPROM can be written in 48 seconds.
Here is the output of my terminal during the test:
Code:
5  4  3  2  1  0 
5  4  3  2  1  0 
start writing pattern 42 from 0x0000 to 0x03FF
finished writing
1024 bytes written in 5943 ms
start reading:

0x0000 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0020 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0040 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0060 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0080 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x00A0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x00C0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x00E0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0100 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0120 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0140 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0160 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x0180 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x01A0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x01C0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
0x01E0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42

The next step is to play with the page write mode to write 64 bytes very fast. The microcontroller I use has 2k of SRAM and the firmware does not need a lot of this, so I will use a 1k buffer to store the data before they get written to the EEPROM. This should speed up things later, when data comes from an external tool through a serial connection.

_________________
How should I know what I think, until I hear what I've said.
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Tue Apr 23, 2013 7:25 pm 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
This is good! Please consider publishing your code when you're done (preferably with an open source license)
Cheers
Ed
Top
 Profile  
Reply with quote  
mkl0815
PostPosted: Wed Apr 24, 2013 8:25 am 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
The whole project (hardware and software) of the programmer will be open source.
At the moment I'm testing the page write mode of the EEPROM. It's really fast and almost working, but I'm facing a strange behavior.
I've made a function that gets the start address, a pointer to a databuffer and the number of bytes (up to 64) to be written.
The function follows the sequence of setting /OE, /CE/ and /WE given in the datasheet for a page write.
The first call of the function writes the 64 bytes, but only the first 2 or 3 bytes on the eeprom are modified, the next 16 or 17 bytes stay as they are and the rest of the 64 bytes is modified as expected.
The second call of this function (with the same parameters) writes all bytes without any problems. Also all other calls of the function (with different addresses) writes all bytes are correctly to the eeprom. At the moment I've no idea what causes this behavior. I assume that this is not a problem with the function itself, but with the prior steps of accessing the chip.
Aside from the fact that I have to do the first page write twice, the whole 8k EEPROM can be programmed in about 4 seconds, if the data is already in an internal buffer. If I have to pick up the data from a serial connection between the write cycles, it will take longer. But I hope, that we stay below one minute once the firmware is completed and the external tools are working.

Some additional question for the hardware. At the moment I'm using the Arduino nano as the only communication channel (over a usb-serial connection to the host system). But the both TX and RX lines could be also available at a TTL level and also as "normal" serial connection via a MAX232.
Are there any interests for these additional (optional) features, if we make a PCB for the programmer?

_________________
How should I know what I think, until I hear what I've said.
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Wed Apr 24, 2013 5:31 pm 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
> open source
That's great - thanks!
> odd bug writing first page
That's an odd bug... but I have no ideas on it.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Wed Apr 24, 2013 8:52 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
mkl0815 wrote:
Some additional question for the hardware. At the moment I'm using the Arduino nano as the only communication channel (over a usb-serial connection to the host system). But the both TX and RX lines could be also available at a TTL level and also as "normal" serial connection via a MAX232.
Are there any interests for these additional (optional) features, if we make a PCB for the programmer?

I'm sure adding the RS-232 option to free it from USB dependency would make it more popular with some potential users. USB is not hobbyist-friendly like RS-232 is. Some may want to feed it with a home-made computer with no USB, or even with an older PC.

No ideas on the bug here.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
clockpulse
PostPosted: Thu Apr 25, 2013 12:00 am 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
mkl0815 wrote:
The function follows the sequence of setting /OE, /CE/ and /WE given in the datasheet for a page write.


It could 'possibly' be a timing issue, check the datasheet for setup/access times on your particular EEPROM, maybe you're accessing a little to quickly.
Top
 Profile  
Reply with quote  
mkl0815
PostPosted: Thu Apr 25, 2013 3:43 pm 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
I stumbled over Daryl's EEPROM programmer today. (http://sbc.rictor.org/28256.html) He follows a different approach to set the data and the address lines, but at the end the timing for reading and writing should be the same. So I can peek a little bit :shock:

_________________
How should I know what I think, until I hear what I've said.
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Thu Apr 25, 2013 5:00 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
mkl0815 wrote:
I stumbled over Daryl's EEPROM programmer today. (http://sbc.rictor.org/28256.html) He follows a different approach to set the data and the address lines, but at the end the timing for reading and writing should be the same. So I can peek a little bit :shock:


That code is only for byte-at-a-time programming. It does poll for write completion vs. timing the write cycle. I didn't bother with page mode as speed was not a primary design goal. Hope it can help. I cannot offer any ideas as to why you get the first time write errors.

good luck!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Fri Apr 26, 2013 12:30 am 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
If the first written packet is always wrong, might the chip not be ready? Does it need some time, or some dummy access, to prepare itself?
Top
 Profile  
Reply with quote  
Dr Jefyll
PostPosted: Fri Apr 26, 2013 5:16 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
The "funny" problem you describe makes me wonder about the power supply. I don't see any supply bypass capacitors -- do you have them hidden on the other side of the board? Two possible ways to proceed:

  • 'scope the supply to see if you can observe a brief sag as programming commences; or...
  • just add some capacitance and see if the symptom disappears. I'd suggest a generous electrolytic (10-100 uF maybe?) and also, located physically close to the EEPROM socket, a .1 or .01 uF with leads kept reasonably short.

Apologies if you've already taken care of this and the advice is redundant. Cheers,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Fri Apr 26, 2013 8:26 am 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Good thinking - there might well be a charge pump on chip which has to start up.
Top
 Profile  
Reply with quote  
mkl0815
PostPosted: Fri Apr 26, 2013 9:13 am 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
You are right, there are no capacitors on the board right now. But the interesting thing is, that the first bytes are written correctly. I've got my other AT28C64 eeproms yesterday and started also with one of them. There is the same problem, but with other bytes. So I think this is probably a timing problem. It seems that my shiftOut() function that sets the address lines takes too much time. I takes about 250 µs to set the lines and the bytes should be written every 150µs. Strange that it works after the first write attempt, but only for one of the chips.
I will try to speed up the shiftOut function to be sure that it sets the address lines within the timeframe.

For the PCB layout I will add some 10nF or 100nF capacitors between VCC and GND for all chips. I think I will come back with the schema and the layout as soon as it gets finished to get some hints for improvements. I'm not familiar with this kind of design work at the moment, but I'm always trying to learn something new.

@Daryl: I already saw it in the code after a closer look, that you "only" use the single byte mode. This is the mode that already works as expected. The way you build your programmer with the 74HC573 is quite interesting. Setting the address and data lines with the same outputs is a clever approach and should be much faster then my solution.
I'm really impressed from your work for different SBCs and all the "glue stuff" around it. Your page and this forum as well will be a good source for my own project and I'm sure I will have a lot of (maybe sometimes stupid :shock: ) questions.

Mario.

_________________
How should I know what I think, until I hear what I've said.
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Apr 26, 2013 12:33 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
mkl0815 wrote:
@Daryl: I already saw it in the code after a closer look, that you "only" use the single byte mode. This is the mode that already works as expected. The way you build your programmer with the 74HC573 is quite interesting. Setting the address and data lines with the same outputs is a clever approach and should be much faster then my solution.
I'm really impressed from your work for different SBCs and all the "glue stuff" around it. Your page and this forum as well will be a good source for my own project and I'm sure I will have a lot of (maybe sometimes stupid :shock: ) questions.

Mario.


Thanks for the kind words Mario. I think both designs have merits - yours requires less resources than mine. It's funny, but I started out just like you. I wanted to make an SBC, but needed a way to program an EEPROM, so I built the programmer first. Mine started with a PC parallel port, using the 74573's. After I built my first SBC, I dropped the parallel port and moved it to the VIA's.

I have a feeling it won't be long before you start on your SBC project. It has been a fun and rewarding experience for me, and I'm happy to share my successes (and failures). I have posted 90% of my work on my website. It's there for others, like yourself, to use for reference in their own projects. When I started, I studied the SBC's that others had built (Chris Ward, Lee Davison, and others), and went from there.

Keep the questions rolling too, there are no stupid questions!

Good luck and have fun!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 18
  [ 269 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 18  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 23 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.