PIC micro internal memory read/write vs static RAM

Thread Starter

seanstevens

Joined Sep 22, 2009
160
I have an old Radio Shack scanner which uses static RAM (15ns) for holding its frequencies in channels etc. I was thinking to tap into it and use a PIC16F887 and a 2-line 16-character LCD display or maybe an SPI/I2C display to tag some text to the channels. Currently, the scanner just stops on a frequency out of 1000 and you have to remember what that channel is.
I was thinking I could either just use the PIC to track the channels via A0-A10 and just store a text for the channels, simple-ish enough but I was also thinking is the PIC internal memory fast enough to replace the internal static RAM, which I doubt but looking through the datasheet I can't seem to find the memory read/write timing graphs.
Can anyone give me an idea of read/write on the PIC, I seem to remember its in mS, not nS.
I know you can buy new scanners that have memory tags and I have 2 of them but a man's got to do projects when a man's got to do a project for a bit of fun.

Thanks,
 

DickCappels

Joined Aug 21, 2008
9,078
It sounds like you are considering replacing the RAM in the scanner with the PIC's internal RAM. If so, you might run into problems if the scanner "expects" the data in nanoseconds while the PIC might take hundreds of nanoseconds or even microseconds to supply the data.

A more successful method might be to dual-port the RAM but since you don't know for sure how the scanner accesses RAM even that is fraught with design hazards.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
Thanks for your reply @DickCappels.
I thought of replacing the RAM with PICs internal memory but then I kind of knew that would not work due to speed, wishful thinking I suppose.
So the simplest method I thought of was to tap the A0-A10 and feed it to a PIC, when the scanner stops (squelch open) the PIC uses a look-up table to show the channel number and frequency and the associated text tag. This wouldn't interfere with the normal operation of the scanner. The PIC would also be connected to a PC via USB with a UI for tag input and show the same information on the PC if the app was running.
Just an idea to bring a very old albeit really good scanner to 21 century.
 

upand_at_them

Joined May 15, 2010
918
Can you scope the RAM comm lines to see the actual speed? I'd suspect that the processor in the scanner runs quite slow compared to what today's PIC's can do.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
Can you scope the RAM comm lines to see the actual speed? I'd suspect that the processor in the scanner runs quite slow compared to what today's PIC's can do.

You are right. A good idea, I didnt think about that, its a processor from mid-80s! The memory is a TC5517CF-20. I could do that either with a scope or a logic analyser when I get around to doing that.
Looking at the specs of the scanner, it can scan 26 channels per second in fast mode and 13 in slow! Thats about 38.5mS per channel. The CPU has a 12.5MHz crystal.
 

Ian0

Joined Aug 7, 2020
5,839
You could just connect to the RAM in a read-only sort of fashion.
You could monitor the address lines and a strobe signal, and whenever the scanner reads the RAM you could read the address and data lines, then save a copy in the PICs internal RAM.

The only snag is that you would never know what was in RAM locations that the scanner never read.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
You could just connect to the RAM in a read-only sort of fashion.
You could monitor the address lines and a strobe signal, and whenever the scanner reads the RAM you could read the address and data lines, then save a copy in the PICs internal RAM.

The only snag is that you would never know what was in RAM locations that the scanner never read.
That is the plan @IanO. Tapping into A0-A10, D0-D8, OE, CS, W/R and Squelch. Read and store in the PIC. Although, I think I may do a little reading and decoding to see what exactly is the data in & out of the RAM to see if it can be used to make things easier.

Not sure if I understand your last sentence. I need to think about how this will work in terms of what is in the scanner memory and what data is being transferred as I dont know what language the CPU is talking with the memory, there are other data such as mode, channel spacing, etc being stored too I guess. If a simple language that can be decoded and the PIC could understand and just copy and know where everything is, would be great else, I would have to feed the data manually to the PIC via a small app...
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
Although looking at PIC16F887, it only has 8K memory and thats program memory. The scanner has a 16K (128*128), so PIC wouldnt have the required memory.... I am a little confused with the memory structure though
 

Ian0

Joined Aug 7, 2020
5,839
What I mean is if you are just monitoring the address lines and the processor never reads, say, address 0x2FC0, you would never know what was in there.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
What I mean is if you are just monitoring the address lines and the processor never reads, say, address 0x2FC0, you would never know what was in there.
I see, well I can live with that as I am interested in the stored memory and their text tag. Every time it stops on an active channel, it will read the content and store it, if over time it doesnt stop on a channel, then that can be manually selected or just deleted as it would possibly be inactive.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
If it only has address lines A0 to A10, then it’s 2k x8, 16k bit, but the PIC only has 384 bytes.
Thats where I was confused. I could use part of the program memory as the SRAM or EEPROM are both too small. The program memory is slow compared to RAM, this is where my original doubt about the possibility of using the PIC memory. But, as mentioned before, it only scans 26 channels per second, which would be within PIC capabilities think, I am trying to find some timing diagram...
 

atferrari

Joined Jan 6, 2004
4,647
I have an old Radio Shack scanner which uses static RAM (15ns) for holding its frequencies in channels etc. I was thinking to tap into it and use a PIC16F887 and a 2-line 16-character LCD display or maybe an SPI/I2C display to tag some text to the channels. Currently, the scanner just stops on a frequency out of 1000 and you have to remember what that channel is.
I was thinking I could either just use the PIC to track the channels via A0-A10 and just store a text for the channels, simple-ish enough but I was also thinking is the PIC internal memory fast enough to replace the internal static RAM, which I doubt but looking through the datasheet I can't seem to find the memory read/write timing graphs.
Can anyone give me an idea of read/write on the PIC, I seem to remember its in mS, not nS.
I know you can buy new scanners that have memory tags and I have 2 of them but a man's got to do projects when a man's got to do a project for a bit of fun.

Thanks,
Are the frequencies always the same?
Are they selected by you or by design?
Is the sequence ffixed?
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
Are the frequencies always the same?
Are they selected by you or by design?
Is the sequence ffixed?
I select my local airport / radar service and place the frequency in a channel. Once in, it will hardly get changed unless it goes out of service.
They are selected by me
What sequence?

This is all an idea and thinking aloud so to speak. If cant decode the traffic between cpu & RAM, I may just program the scanner and use an app on the PC to program the same channel on the PIC that corresponds to the address lines so that when next the scanner stops on a channel with a certain address the PIC would know what the tag associated with that channel is , if that makes sense.
 

upand_at_them

Joined May 15, 2010
918
If you're using a PICKit2 to program your PIC's, the PICKitMinus project will allow you to use it to program newer PIC's as well. I would go with something newer that's better and faster than the *old* 16F887. (My current project uses a PIC18F26Q43 running on a 64MHz internal oscillator.)
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
I have a PICKIT4. Wow, 64MHz that is fast! Thank you thats also a good idea.
I have programmed 887 and PIC18F45K22 the latter apparently does 64MHz too.
 

Ian0

Joined Aug 7, 2020
5,839
You could add a serial EEPROM, which is about as fast as a sloth on Horlicks. I'm guessing that the scanner runs through a fairly short program and repeats the same read sequence over and over again. If you scan the Address and Data lines only when you are not hanging about waiting for the EEPROM, then slowly and randomly you will build up a copy of the RAM.
 

Thread Starter

seanstevens

Joined Sep 22, 2009
160
You could add a serial EEPROM, which is about as fast as a sloth on Horlicks. I'm guessing that the scanner runs through a fairly short program and repeats the same read sequence over and over again. If you scan the Address and Data lines only when you are not hanging about waiting for the EEPROM, then slowly and randomly you will build up a copy of the RAM.
Serial EEPROM, thats why I didnt mention it, its just as slow. The scanner has 10 banks of 40 channels, any bank can be in the sequence of being scanned (1 - 10), and then it repeats again.
I have to say this again, even though there is a static RAM in there rated at 15-20nS access, the scanner scans only 26 channels per second - that is slow and I am guessing within the ranges of writing and reading from an EEPROM isnt it?
The reason besides the CPU being from the early 80s, the PLL chip needs a long sequence of serial data to set it to any frequency then PLL needs to settle and frequency sampled for activity. Do we not think a fast PIC can match that?
 

michael8

Joined Jan 11, 2015
297
Do you know what data the scanner puts in the ram? Horrible idea: remove the ram and have it be an output port from some
micro (PIC?). When the scanner reads it you supply the data for the (next?) channel to scan using the address lines
provided by the scanner to decide which channel data to present.
 
Top