Author Topic: EPROM Programmer Reading all 0's  (Read 12838 times)

0 Members and 1 Guest are viewing this topic.

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #25 on: February 20, 2016, 08:44:30 am »

Look at your program
You have a 8-bit binary data buss. You are wanting to send and receive a byte but are calling it a character.

When you tell compiler character it does what you said and does character.

 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #26 on: February 20, 2016, 08:55:20 am »
The output definitely works correctly because I've tested it. As it's an ASCII characters, which is stored as a binary value, the data bus outputs the binary value that corresponds to that value. When I read the character off of the data bus, I am asking the micro to take in the binary value and then print the ASCII character that corresponds to that binary value. I don't think that's the issue, as my tests don't seem to suggest it is, but I will change the type to a byte and test. Better to be safe than sorry.
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #27 on: February 20, 2016, 09:10:27 am »
I've run the test with the above change and the monitor just outputs the numerical value of the ASCII characters it was previously outputting. I think it must be something to do with the way the hardware is being controlled or the hardware itself, because the software seems to be operating as it should.
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #28 on: February 20, 2016, 09:25:11 am »
If you are using one program to write the data and a second program to read the data, what is happening between stopping one program, loading the second and running it?

Also
Think about the program you have, how good is it?

You are testing the hardware but are also testing the software. Is the code the way you will need it for the final project. If you make changes later, you could break something. Testing changes here could remove a lot of trouble later.

If you write a bigger program, you can actually make it easer to read and understand, but more importantly easer to find errors.

For an Arduino program, one of the first things I would want to see is what connections it is using off the board.
You list of pin constants is a half & half thing. You do some as constants and others you hide in the program.
While more typing is needed you could use Data0 - Data7 for constant names for data bus pins.

The name you give things can make it easer to spot and find errors.
Using some functions can also make a program easer to read. Think of your final program and create some functions that both do the job and make the code easer to read.
Data_bus_In, Data_Bus_Out, Set_Address, Memory_Read, Memory_Write
Memory_OE, Memory_WR

Some could have many names.
You could use the Z80 names, the chip names or the more common name. Note that on a constant definition you can follow it with a // comment for more detail

Extra work here that becomes a copy and paste into main program.


 
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #29 on: February 20, 2016, 09:42:16 am »
Code: [Select]
  // Reading Values from Memory
  digitalWrite(mem_enable, LOW);
  digitalWrite(mem_output, LOW);
  int a = digitalRead(13);
  int b = digitalRead(8);
  int c = digitalRead(7);
  int d = digitalRead(6);
  int e = digitalRead(5);
  int f = digitalRead(4);
  int g = digitalRead(3);
  int h = digitalRead(2);
  delay(2);

Not a bad example of how a little more typing would  help show errors

Create a constant

const int Memory_Read_Delay = 2;

Ant then read the code section above.
You are saying memory output enable, read data buss, Memory_Read_Delay
 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #30 on: February 20, 2016, 09:59:47 am »
I moved the delay to before the digitalRead() section of the code, but the same garbled data is coming back. There's a more fundamental issue going on here :S
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #31 on: February 20, 2016, 10:32:16 am »

I would make some changes to your program

First to read data from ram you have to know you have valid data in ram chip.

You get valid data in a ram chip by first writing data to a ram chip.

Second having many lines of output for an address makes it harder to see changes.

I think as a first run on console output I might do four columns output in binary on one line. Address {space} data_read {space} data_write {space} data_read
Note that that is three complete memory accesses to memory chip with address unchanged per line on console and data to console lines up in vertical.

This would let the test program write some more on the console output in front of this. With the test program part generating addresses and data and looping you can get a lot of testing done fast.
 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #32 on: February 20, 2016, 10:56:16 am »
Quote
think as a first run on console output I might do four columns output in binary on one line. Address {space} data_read {space} data_write {space} data_read

So you suggest reading from the address, then writing to it, and then reading from it again to see if the data is valid. I definitely think putting all of the code into one program is a good idea, then it eliminates the idea that there might be a powerloss during programming for a split second. I will make these changes and report back tomorrow!
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #33 on: February 20, 2016, 11:11:20 am »
Think of the big picture for this
You will need a menu so you can select program functions

You will need a bunch of functions to make program easer to write and change
This will also make it easer to read an verify if done correct.

All the numbers in current program as a programmer you have to translate to what they are. Would be much easer to read and see errors to use good names as constants.

The better you write the program the more time you save in long run

 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1425
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #34 on: February 20, 2016, 11:26:02 am »
Ya.  This halfassed reading program, followed by a writing program, fixed addresses, fixed data, etc.etc.etc.  Pretty much blows chunks.  As in the previous post, a menu system of some sort, defined functions that work, etc.  If you can't accomplish that in the Arduino environment, how do you expect to accomplish it in a Z-80 environment without the help of predefined functions and libraries?
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline rich

  • Regular Contributor
  • *
  • Posts: 249
  • Country: gb
Re: EPROM Programmer Reading all 0's
« Reply #35 on: February 20, 2016, 02:17:30 pm »
It’s true the code suffers from beginners-copy-and-paste style which should never be encouraged, so I agree with previous posters' encouragement to refactor into smaller named functions with correctly used constants.

To help in this process, a good approach would be to start a clean sketch. Implement only what you need so you can prove write/read of a single location in memory works. Nothing more! - No incrementing addresses, no getting data from the serial port. Nothing. Write it clean with functions and constants. Only when this works, can you allow yourself to write the extra code into your nice clean sketch. When you do add some of that code, you may need to refactor a little of what you already have, but that's how software gets developed and stays maintainable.

Here’s some boiler plate pseudo code to give you an idea of the structure this thread is hinting at:
Code: [Select]
setup() {
setupAddressBus()
setupDataBus(INPUT)
}

// keep loop simple, so during testing you can be flexible in what runs without comment out huge chunks of code, and you can turn it into a library easier later on
loop() {
bool passed = testSimpleWriteFollowedByRead()
if (passed) {
// Awesome
} else {
// Doh!
}
}

// By putting tests in their own functions you can call/reuse them again later when it goes titsup
bool testSimpleWriteFollowedByRead {
uint16_t address = 0;
uint8_t  data = 42

writeToAddress(address, data)

uint8_t readBack = readFromAddress(address)

return data == readBack
}
Code: [Select]
// Other functions you may end up defining along the way
writeAddressBus(address)
uint8_t readDataBus()
writeDataBus(uint8_t)
memOutputEnable(bool)
memWriteEnable(bool)
memChipSelect(bool)


When you have a working test, then add a new test function which writes a small block, reads it back and verifies it read correctly.
Call it from loop as
Code: [Select]
passed &= testBlockWrite()
Then add higher level functions specific to your project which make use of what you've just built and tested, e.g. memDumpToSerial(), or writeFromSerial() etc.

At some point it probably belongs in a library, rather than sketch(?) but I’ll leave that to someone more knowledgeable on the ardruino ecosystem than me.

Apologies if I pitched the level of this post too low, there was lots of useful advice before this post regarding coding nirvana, but sometimes you need a route map to get there in small stages.
 

Offline MarkS

  • Frequent Contributor
  • **
  • Posts: 528
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #36 on: February 20, 2016, 06:39:22 pm »
Simplify. Gut the code and change it so that it reads and writes from a single, hard-coded address. Manually change this address and recompile and see if you get different results for random, single, hard-coded addresses.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #37 on: February 20, 2016, 07:13:10 pm »

While I am thinking of it.
1. Do the pins on Arduino have other uses that could effect this program.

2. Using Intel hex properly, think you need a full line at a time in Arduino.
This keeps Arduino's ram use low while allowing easy programming using this format.

You will probably  want the following.
Rraspberry pi intel hex Input/output to Arduino ram, one line at a time.

Arduino input/output to ram chip or rom chip would then be to/from Arduino ram. Using an array for this data makes program shorter and easer to change/read.

Would be good idea to have functions that take data or return data to make it easer to work with the data in Arduino ram.


This code
Code: [Select]
// memory data buss
const int Pin_Data_D0 = 2;     // Data 0
const int Pin_Data_D1 = 3;     // Data 1
const int Pin_Data_D2 = 4;     // Data 2
const int Pin_Data_D3 = 5;     // Data 3
const int Pin_Data_D4 = 6;     // Data 4
const int Pin_Data_D5 = 7;     // Data 5
const int Pin_Data_D6 = 8;     // Data 6
const int Pin_Data_D7 = 13;     // Data 7

void Byte_to_Mem_Data_Buss(){
 // Writing Values into Memory
  digitalWrite(Pin_Data_D7, bitRead(Data_Byte, 7));
  digitalWrite(Pin_Data_D6, bitRead(Data_Byte, 6));
  digitalWrite(Pin_Data_D5, bitRead(Data_Byte, 5));
  digitalWrite(Pin_Data_D4, bitRead(Data_Byte, 4));
  digitalWrite(Pin_Data_D3, bitRead(Data_Byte, 3));
  digitalWrite(Pin_Data_D2, bitRead(Data_Byte, 2));
  digitalWrite(Pin_Data_D1, bitRead(Data_Byte, 1));
  digitalWrite(Pin_Data_D0, bitRead(Data_Byte, 0));
}
could be this code using arrays
Code: [Select]
int Pins_Data_Buss[] = {2, 3, 4, 5, 6, 7, 8, 13}; // memory data buss pins D0 .. D7

void Byte_to_Mem_Data_Buss(){
 // Writing Values into Memory
   for (int i=0; i <= 7; i++){
     digitalWrite(Pins_Data_Buss[i], bitRead(Data_Byte, i));
    }
}
 

And when you pass the data into function becomes this
Code: [Select]
void Byte_to_Mem_Data_Buss(byte Data_Byte_in){
 // Writing Values into Memory
   for (int i=0; i <= 7; i++){
     digitalWrite(Pins_Data_Buss[i], bitRead(Data_Byte_in, i));
    }
}


Due to the pin numbers being in an array addressed 0 to 7, many parts of program get a lot shorter while program gets easer to check for errors.

Changing i in loops above to Bit_Number could be an additional step.

 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #38 on: February 21, 2016, 05:45:22 am »
Ok, I've nearly finished writing the new code that combines both functions into one system. The user can input the command that they want to execute, write or read.

However, whilst looking at the datasheet for the SRAM (http://www.farnell.com/datasheets/1674430.pdf) something has occurred to me. During a write cycle, does the memory output enable need to be low (output active state)? In the foot notes for the write cycle timing diagram, it mentions that when #OE is low certain timing restrictions apply. Does this imply that I need #OE low during a write cycle or am I just being stupid?

If I do then this may explain all the garbled data I am getting, because I am fairly sure the memory would just be reading garbled data.
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1425
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #39 on: February 21, 2016, 06:28:13 am »
No.  Put OE# high during a write.  Just avoid the issue in the first place.
The footnote says "During a WE# with OE# low".  If OE# is high, the footnote doesn't apply.

As far as timing goes, you're driving everything with an Arduino and a '595 right?  Don't worry about the timings so much.  You won't be getting anywhere near the minimum spec's and 'overspeeding' the SRAM.  This particular SRAM can run at 70ns and faster.  A regular Arduino runs at about 16Mhz and depending on your code, it's gotta get thru all the libraries before a pin toggles anywhere.  You'll be lucky to be able to toggle a pin at more than 100khz...on a good day...unless you're writing in straight C and bypassing all those libraries.
All you need to worry about is the sequencing.
eg. Read = CE# high, OE# high, WE# high, Address on bus, CE# low, OE# low, Read the data, OE# high, CE# high, done.
eg. Write = CE# high, OE# high, WE# high, Address on bus (you can put the data on bus here as well even though the diagrams don't show it, doesn't matter and might save you some headache), CE# low, WR# low, WR# high, CE# high, done.
« Last Edit: February 21, 2016, 06:30:44 am by Skimask »
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1425
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #40 on: February 21, 2016, 06:37:53 am »
On a side note, if you get your hands on a 3V coin cell, 1 regular ol' diode, 1 schottky diode, 10K resistor, and a bit of wire, your SRAM can be turned into a "PROM"...more correctly a non-volatile SRAM.

Hard wire the coin cell - to Vss
Hard wire the coin cell + to the schottky diode then to Vcc and to one side of the resistor.
Other side of the resistor to CE#
And the other diode goes between Vss and the positive rail on the circuit board.

When everything is powered off, the coin cell keeps the SRAM alive and keeps CE# high thru the resistor, and the diode prevents the coin cell from attempting to power the rest of the system.
When you power the board up, system voltage powers the SRAM as normal, and the 10K resistor prevents the coin cell from being able to hold CE# high (eg. the Arduino can pull it low whenever it wants).

Bam.  Instant goodness.
Figure a regular ol' 2032 coin cell is worth about 200mAh.  Datasheet shows a data retention current of about 20uA max.  That comes out to about 416 days on a single coin cell, in worst case conditions, according to the datasheet.  I wouldn't expect it to last a year, but a solid few months surely isn't out of the realm of possibilities.

EDIT:  Added the second diode as noted in the post below.  Exploding coin cells are a bad thing...or so I've heard. :D
« Last Edit: February 21, 2016, 07:30:43 am by Skimask »
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 7072
Re: EPROM Programmer Reading all 0's
« Reply #41 on: February 21, 2016, 07:10:04 am »
+1, but add an extra Schottky diode in series with the coin cell so it doesn't go *BANG* due to the 5V supply from the board trying to charge it.
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1425
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #42 on: February 21, 2016, 07:28:48 am »
DOH.  Ya, good call.
Updating original.
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #43 on: February 21, 2016, 08:23:30 am »
Okie Dokie, progress. I've now rewritten the code into one set that does everything! I've moved the python script onto a windows PC, the Raspberry Pi was getting a bit laggy, this just makes the experience a bit better for me. The Arduino firmware has been updated to do everything. You tell the system what function you want to execute through the python shell, and then the shell shows you the output of the Arduino as it executes your command. Everything compiles correctly.

Now comes the not so great news! :S

I'm still getting some seriously weird output from the Arduino. First things first, here's the code:

Python Script:

Code: [Select]
# This is the file handler code for the EPROM Programmer, it sends the hex data across a serial port from the PC to
# the Arduino Micro Controller so that it can be programmed into the EPROM.

# Importing necessary libraries
import sys
import serial

# Variables for tracking the current character and the current address
current_address = 0

# Opening Serial Port
ser = serial.Serial('COM11', 9600, timeout = 1) # Please change the COM Port depending on which COM Port your Arduino is attached too

# Creating File Object and Opening File
filename = 'ROM_32K.HEX' # Please change the name of the file accordingly, making sure the file is in the same folder as this code
txt = open(filename)

print("Welcome to the Arduino EPROM Programmer, please type 'Write' to write the specified file, 'Read' to read")
print("from memory and 'End' to close the program")

while(1):
    # Taking User Function input
    function = raw_input('Desired Function: ')

    # Write Function
    if function == "Write":
        ser.write("Write")
        print('Executing Write Function')
        while(1):
               
                # Reading the next Byte from the Hex File
                current_char = txt.read(1)
                print(current_char)
                # Checking if we have reached the end of the file
                if current_char == '':
                        ser.write('}')
                        print('Finished Writing File')
                        break
                # Writing the current character over the serial port to the Arduino
                ser.write(current_char)
                # Reading the Arduino's Output to see if the byte has been written correctly
                print('Current Address: ', current_address)
                print('Read One: ', ser.read(1), 'Byte Written: ', ser.read(1), 'Read Two: ', ser.read(1))
                current_address += 1

    # Read Function
    if function == "Read":
        ser.write("Read")
        print("Executing Read Function")
        while(1):
                # Reading the Arduino's Output to see the character it has read from memory
                print('Current Address: ', current_address)
                print('Read: ', ser.read(1))
                current_address += 1
       
       

Arduino Firmware:

Code: [Select]
/* This is the source file for the EPROM Programmer! The pin declarations in this file are specifically setup
 *  for the Arduino Micro, however you can modify the pins to fit your own Arduino Board. This code is paired with a python
 *  script that sends the hex file byte by byte to the Arduino, which will then put it into the correct address of the memory
 *
 *  The hardware for this programmer is two 74HC595 Shift Registers driving the address BUS, with the data BUS and control
 *  pins directly connected to the Arduino Digital IO
 *
 *  For more information please visit my website at: [url=http://www.RCtalesofarookie.weebly.com]www.RCtalesofarookie.weebly.com[/url]
 *
 *  Created by Sam Maxwell
 *  FEB 2016
 */

// Constant Variables that hold pin assignments, please change these for your specific Ardunio Board
// Variables for the 74HC595 Shift Registers, used to drive the address BUS
const int Serial_Clock = 12;
const int Register_Clock = 10;
const int register_output_enable = 11;
const int Serial_Output = 9;

// Variables for the Memory Control Pins
const int memory_write_enable = 0;
const int memory_chip_enable = 1;
const int memory_output_enable = 14;

// Variables for the Data BUS
int Data_BUS[] = {2, 3, 4, 5, 6, 7, 8, 13};

// Variables for storing the current character and the current address
char current_character;
int current_address = 0;

// Variables for storing the current operation mode
String current_mode;

// Main Code
// Setup
void setup(){
  // Beginning Serial Communication with PC, used for communication with Python Script, as well as for debugging
  Serial.begin(9600); // Serial at 9600 Baud

  // Assigning Pin Modes that remain constant regardless of the function
  // Shift Register Pin Modes
  pinMode(Serial_Clock, OUTPUT);
  pinMode(Register_Clock, OUTPUT);
  pinMode(register_output_enable, OUTPUT);
  pinMode(Serial_Output, OUTPUT);

  // Memory Control Pin Modes
  pinMode(memory_write_enable, OUTPUT);
  pinMode(memory_chip_enable, OUTPUT);
  pinMode(memory_output_enable, OUTPUT);

  // IMPORTANT!!! Pin Mode assignments for the data BUS occur during the Read and Write functions as pin modes change depending on the function being used

  // Making sure pins are at correct levels before cycles begin
  // Shift Registers
  digitalWrite(register_output_enable, HIGH);

  // Memory Control Pin Levels
  digitalWrite(memory_write_enable, HIGH);
  digitalWrite(memory_chip_enable, HIGH);
  digitalWrite(memory_output_enable, HIGH);
 
}

void loop(){
  while(Serial.available() < 1){
  }
  current_character = Serial.read();
  if(current_character != '\n'){
    current_mode = current_mode + current_character; // Appending the read byte to current_mode String if it is not equal to new line
  }
  if(current_mode == "Write"){
    current_address = 0;
    while(current_address < 35000){ // Python Script Prints } if the end of the file has been reached
      if(Serial.available() > 0){
        current_character = Serial.read();
        Increment_Address();
        Read();
        Write();
        Read();
      }
    }
  }
  if(current_mode == "Read"){
    current_address = 0;
    while(current_address < 35000){
      Increment_Address();
      Read(); // Executing the Read Function if current_mode == Read
    }
  }
}

void Write(){
  // Reading Current Character from Serial Connection
  current_character = Serial.read();
 
  // Write Cycle
  // Setting Data BUS Pin Modes to OUTPUT for Writing
  for(int Data_Pin = 0; Data_Pin < 8; Data_Pin++){
    pinMode(Data_BUS[Data_Pin], OUTPUT);
  }

  // Setting Data Bus Values
  for(int Data_Pin = 0; Data_Pin < 8; Data_Pin++){
    digitalWrite(Data_BUS[Data_Pin], bitRead(current_character, Data_Pin));
  }
 
  // Setting Memory Control Pins
  digitalWrite(memory_output_enable, HIGH);
  digitalWrite(memory_chip_enable, LOW);
  digitalWrite(memory_write_enable, LOW);

  // Sending character that is going to be written over serial port for python script
  Serial.print(current_character);

  // Delay to allow Data to become valid
  delay(2);

  // Setting Memory Control Pins
  digitalWrite(memory_write_enable, HIGH);
  digitalWrite(memory_chip_enable, HIGH);
}


void Read(){
  // Read Cycle
  // Setting Data BUS Pin Modes to INPUT for Reading
  for(int Data_Pin = 0; Data_Pin < 8; Data_Pin++){
    pinMode(Data_BUS[Data_Pin], INPUT);
  }
     
  // Setting Memory Control Pins
  digitalWrite(memory_write_enable, HIGH);
  digitalWrite(memory_chip_enable, LOW);
  digitalWrite(memory_output_enable, LOW);

  // Delay to allow Data to become valid
  delay(2);

  // Reading Data
  for(int Data_Pin = 0; Data_Pin < 8; Data_Pin++){
    current_character = current_character + (digitalRead(Data_BUS[Data_Pin]) << Data_Pin);     
  }
  // Setting Memory Control Pins
  digitalWrite(memory_output_enable, HIGH);
  digitalWrite(memory_chip_enable, HIGH);

  // Printing current character over the serial port for the python script
  Serial.print(current_character);
}

void Increment_Address(){
  // Setting Shift Register Control Pins
  digitalWrite(register_output_enable, HIGH);
  digitalWrite(Register_Clock, LOW);

  // Checking if current address is higher than 255 and shifting out bytes accordingly
  if(current_address < 256){
    // Shifting Out Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, current_address);
  }
  else{
    // Shifting Out High Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, (current_address >> 8));
    // Shifting Out Low Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, current_address);
  }

  // Setting Shift Register Control Pins
  digitalWrite(Register_Clock, HIGH);
  digitalWrite(register_output_enable, LOW);

  // Incrementing the value of current_address by one
  current_address = current_address + 1;
}

And here's the output that this code gives:

Write:



Read:



Once again I call upon your help!

Quote
On a side note, if you get your hands on a 3V coin cell, 1 regular ol' diode, 1 schottky diode, 10K resistor, and a bit of wire, your SRAM can be turned into a "PROM"...more correctly a non-volatile SRAM.

That's a great tip! I'll probably use that to test this on the actual computer board, possibly program the SRAM and then plug it into the computer and try and boot. If it works then I know everything else is working! That's going to be really helpful.
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 7072
Re: EPROM Programmer Reading all 0's
« Reply #44 on: February 21, 2016, 08:36:48 am »
You can build the backup circuit using either two stacked turned pin sockets or by bending out the Vdd pin of the SRAM and using a single turned pin socket.  Its worth adding a 0.1uF cap between Vdd and Vss right at the SRAM.   Both diode cathodes go to the actual SRAM Vdd pin.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 5843
Re: EPROM Programmer Reading all 0's
« Reply #45 on: February 21, 2016, 09:07:57 am »
Put LEDs on the data and address buses (with a very high value resistor, just enough to cause them to light with a few uA but not enough to load the buses significantly) and slow down the cycle enough that you can see the address and data changing.

Also wire up a few switches and LEDs so you can test the SRAM itself independently.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EPROM Programmer Reading all 0's
« Reply #46 on: February 21, 2016, 09:27:24 am »
Code: [Select]
  // Checking if current address is higher than 255 and shifting out bytes accordingly
  if(current_address < 256){
    // Shifting Out Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, current_address);
  }

Not allowed action.
You have two 8-bit chips in series, you have to shift out 16 bits each time.

Note that you are also breaking rules for "shiftOut"

Code: [Select]
    // Shifting Out High Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, highByte(current_address));
    // Shifting Out Low Byte
    shiftOut(Serial_Output, Serial_Clock, MSBFIRST, lowbyte(current_address));

edit
do a small number of addresses and then repeat same range.
« Last Edit: February 21, 2016, 09:29:00 am by C »
 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #47 on: February 21, 2016, 09:32:48 am »
I was wondering about that section of code, I just used what seemed to work last time when I ran some testing with LED's, but when I came to look at it a second time whilst writing this code it didn't really make sense. I will make the changes you've put.

What I still don't understand is why the byte the Arduino is receiving over the serial port is completely wrong. It keeps getting \xff, which (after some research) seems to refer to a hex value that cannot be printed in ascii. I need to look at this, as it must be part of the problems. It might be something to do with the python code I am using. I'm going to try and enter some values directly through the Serial Terminal and see what the Arduino's response is.
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 

Offline rich

  • Regular Contributor
  • *
  • Posts: 249
  • Country: gb
Re: EPROM Programmer Reading all 0's
« Reply #48 on: February 21, 2016, 09:40:09 am »
This is a step forward than the earlier code, but did you actually test any of this code in smaller chunks before throwing a mass of data down from the pi and hoping ?

Bugs I can see immediately:

1. Increment_Address probably doesn't work as intended and looks to be a regression from your earlier code which you had already tested and it worked.

2. Even if you hardwired the data bus to a fixed value and did successive calls to Read(), I doubt you would get the same data each time as it looks like you don't reset current char and just keep adding to it.




 

Offline Alberto

  • Regular Contributor
  • *
  • Posts: 70
  • Country: 00
    • Tales of a Rookie - Blog
Re: EPROM Programmer Reading all 0's
« Reply #49 on: February 21, 2016, 09:56:32 am »
Well if anyone wants some code to generate what looks like alien language for a movie, look no further:



Quote
This is a step forward than the earlier code, but did you actually test any of this code in smaller chunks before throwing a mass of data down from the pi and hoping ?

I am going to test the address BUS and data BUS now, but your right, I should have tested it in small chunks first. Don't know why, but I've really messed this process up. :D

Quote
2. Even if you hardwired the data bus to a fixed value and did successive calls to Read(), I doubt you would get the same data each time as it looks like you don't reset current char and just keep adding to it.

That I hadn't thought of. I guess my thinking is that current_character is reset when I call for the next byte from the serial buffer. Is that not how this works?
Tales of a Rookie - http://rctalesofarookie.weebly.com/
------------------------
Exploring the World, One mistake at a time!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf