sx and ram

frdchang

hello,

how would i go about adding more ram to the SX microcontroller?·

i'm unfamiliar how memory systems work since the microcontrollers i used always had an adequate memory system.·

however i liked the SX small size to fit my micromouse application.

cliff notes:
where can·i find details on
1) adding more memory to sx
2) adding fast A/D converter (does the SX support serial?)
3) how does the code get into the SX microcontroller?· (i looked at some data sheets and it did not seem to have a serial interface built in...)

my motivations:
i want to build a palm size micromouse....meaning the chassis will be the circuit board propogated with the microcontroller + h-bridge + sensors.

cheers.
fred


·

Bean

You cannot add ram per se. Usually people add EEPROM memory using a serial EEPROM.

1) How much extra memory do you need ?
2) How fast of an A/D ?
3) Get the SX Tech Kit from parallax

Terry

frdchang

hello,

i would like about 2k RAM.

can i write to eeprom? and how fast? (as in micromouse application in which it will navigate a 15cm x 15cm cell maze at 3m/s... and it needs to write to memory to keep track of where it is...and i think the data structure will be at least 1k... plus i need some overhead ram)

2) A/D needs to be faster than 1ms with low noise
3) i will get the SX tech once i make sure i know how i will approach this!

(i believe this is a wonderful microcontroller.....

cheers,
fred

Paul Baker

It is quite likely your needs can be met, but I would need a little more info.
Are you correct in your size of the maze and the micromouse's speed?
Given your figures it would take 50 milliseconds for it to travel from one end of the maze to the other.

What is the size of the board real-estate can you spare for external devices?

Are you using through hole or surface mount parts?

How frequently do you need to access memory?

Which variety of the SX are you (will be) using?
If you have the 28, for a parallel sram youll need an address latch to overlap functionality of the pins.
A 48 or 52 has enough IO to directly interface with the device.

Cypress makes cheap SRAMs·that are faster than even the SX needs
for instance the CY7C128A-25PC is a 2kx8, 25ns access time, DIP package, and the CY7C128A-20VC a 2kx8, 20ns SOJ both availible in single quantity for under $5

For the SX28, you will need to write code to mimic the alternation of data and address pins that other microcontrollers do and latch the address byte which shares the bus with the data lines.

As for serial EEPROM, using a 3MHz·part (5MHz parts run at 2.7V which requires dual power and level shifters, a messy proposition) at roughly 30 cycles per read/write your talking about 10uS per access, Im using Atmel's·AT25020-10PI as reference (2Kx8, 3MHz, 8DIP, 1.8/2.7/5.0V, SPI·for $3.09 at an online retailer)

Parallel EEPROMS have an access times from 70ns to 200ns and range from $7-$15 they would interface essentially the same as an SRAM.

For your A/D needs 1ms is pretty slow compared to the speed of the SX, so I'd go for a serial ADC. Depending on your number of bits of accuracy, can go with·the National Semiconductor ADC08832IN is an 8bit·successive aproximation ADC with sample and hold and 2 channel multiplexed input, microwire interface, <1 bit error rate, 4us sample time,·8DIP for $2.42.
If your input signal is noisy, its best to run your signal through a simple RC low-pass filter before feeding it into the ADC.

Or you can go the high end with Analog Devices AD7703AN a 20bit sigma-delta ADC, 4 wire interface, with built in low pass filter and self-calibration, 4KSPS 20DIP for $23.87.

Of course there are many other parts that could fit the bill, depending on your priority of speed, price, features etc
If you can answer some of my questions I can help narrow down your choices. And I can do some quick sketches of a schematic of the parts if you need·a bit of help in that area once youve decided on your parts.

Coriolis



Post Edited (The Eye of the Storm) : 8/7/2004 5:12:01 AM GMT

frdchang

hello,

thanks for your response,

the maze is actually 18 cells x 18 cells (i think) and each cell is 15cm x 15cm. the feedback control loop will run every 1 ms which means i have to
1) update my mouse location every 1 ms (which means i estimate about 20 memory access every 1ms)
2) update feedback control loop which 75mhz more than covers
3) i would like 12 channels instead of the usual 8 channels for the ADC and it should be pretty fast.

i would like the lowest pin count on the SX while using the easiest memory interface..... (which seems like 'eye of storm' suggested the 48 pin)

my mouse will be the size of the linked micromouse but i would like it to be one PCB (not stacked like the linked micromouse) using a 4 layer PCB.. which means things will be crowded.

how do you even interface memory to the SX? (is this covered in the manual?) do i need to write a boot config code that tells the microcontroller where the memory is...etc...etc? (take note..my prior microcontroller had all the memory interface already configured.... adding memory is seomthing new to me)

thanks,
fred

Paul Baker

OK, that linked micromouse (which I deleted from orig post (here it is again for those who may wonder about his reference http://www.micromouse.co.uk/hector/images/hector.jpg)) has considerable realestate even with only one board, you should be able to fit everything you need on there using easier to prototype DIP parts.

A heartbeat of 1ms gives you a fairly healthy margin using the SX at 50MHz, that gives you 50,000 clock cyles between each pulse. If you find yourself wanting absolute simplicity go for the serial eeprom,··http://www.sxlist.com has code for practically every serial interface you can think of. Given a 10uS access time you can do 100 memory access per pulse, Im ballparking the processor load from the serial interface will be 30-40% but that depends on the complexity of the serial interface.

The SX48 and 52 are surface mount devices and unless you're very skilled at soldering and using flux properly or happen to have a hot air pencil or reflow oven, I dont suggest you trying. But Parallax sells a prototyping version of the SX52 at http://www.parallax.com/detail.asp?product_id=45207·this is actually a "hidden" product, you cant navigate to it without searching or viewing all products. BTW you would still have to buy the SX-Key to program it.

With the ADC, Texas Instruments TLC540 is 12 channel, however one channel is a constant voltage for calibration purposes (its $3.96), the TLC545CN is a 20 channel (again 1 is a calibration voltage) with a 76KSPS or reading all of your 12 channels 6 times per heartbeat it's a 28-DIP for $6.18. An alternative is to use an 8-channel ADC with analog switches on all or some of the inputs and double up you signals, a pin from the SX would switch which signals are fed to the ADC.

One note, if you decide to use serial interface for both your ADC and your memory and they are different formats you'll have to mesh the isr's for each of them, again theres example code at the sxlist website.

The general way of making the SX interface with any external component is to understand the timing diagram of the part your interfacing with. To start of on the system mechanics level assuming your using the SX28, refer to the attached drawing. The general operation of the circuit is:

1. Place low end address on port B

2. Latch address

3. Place upper end address on port C

4. If write, Place data on port B, else switch direction of port B to input.

5.·If Write set·Write mode (SRAM idles in Read mode), else read port B data in.

6. If Write reset to Read mode,·or reset /OE.

The way the circuit has been set up, steps 2 and 3 can be combined.

Now for the nitty gritty refer to http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C128A.pdf·page 4, Read Cycle 1.·You'll see a very simple timing diagram, the tAA and tRC are the times we are concerned with, on page 3 it shows both of these to be 25ns for the DIP part I quoted in the previous article. So this means the Address cannot be changed faster than 25ns and the data will be availible 25ns after we send the address (step 3 above is when the whole address is presented to the SRAM), niether of these timings restrict us because at 50MHz the cycle time is 20ns and our interface take several cycles, and by the time we've finished setting·port B's·direction register, the data is ready to be read. (the address latch signal·tied to /OE actually places us into Read cycle 2, but dont worry about that, the circuit takes care of that, this is done to prevent the SRAM from trying to place data on the bus when we are trying to write the lower address, an inverter may be nessesary to get the proper level relationship between /OE and the address latch)

Now for a write cycle, we will be using the /WE controlled timing diagram. Ignore /CE because it is always low in our circuit. The times we are interested in are tAW tWC tPWE tSD (there are other times which normally are important but for this device they are 0, meaning we dont care) for this device they are 25ns, 25ns, 20ns and 15ns which means 25ns minimum write cycle time, 25ns minimum between address is presented and write occurs (as indicated by /WE going high), /WE cannot be toggled faster than every 20ns and the data to be written must be on the bus for 15ns before the write occurs. Again none of these times are slow enough to pose a problem of timing. By following the algorithm above we naturally adhere to the timing rules. If we were to use a slower device such as the parallel EEPROM we would have to insert nops in to space out our timing.

Dont forget to place pull up resisters on the busses or turn on SX's internal pull ups.

I know running the SX at its max 75MHz(100MHz for SX52) sounds tempting but finding resonators above 50MHz is difficult, plus 50MHz will give you all the power you need.

I know this may look complicated but it boils down to little more than 5 lines of code for a write or read, assuming with overhead each read/write takes 10 cycles, thats 5000 possible accesses between each heartbeat or reading and writing the entire contents of the memory with more than 900 extra cycles to spare.

btw Im Paul, my nick is supposed to be Coriolis that was my first post to the forum so I didnt notice the error.

Post Edited (Coriolis) : 8/7/2004 9:54:43 AM GMT

frdchang

hello,

you are very helpful.

i'm pretty good with surface mount soldering... so i don't mind the extra pin counts for some extra horsepower and ease of interface....

i want to get a chip as fast as possible because i do not know if my algorithm will need to use sin, cos, or some complicated function yet.. (it seems like i can do everything simply with mult and addition, but i do not know for sure... so extra horsepower is always wanted)


do you recommend me buying the kit and playing with the kit microcontroller first...? then delve into the CPU i want? (ya know..this sounds like a good idea to get my feet wet)

ok....thanks!

i have this feeling i will spam this board allot..

cheers,
fred

frdchang

hello again...

so if i used a 100mhz chip, which gives a 10ns cycle time...but setting up the ports direction takes up one cpu cycle... so its already almost over the 20ns wait time... so i'm ok... as in if i write code for a slow chip... and i feel like going 100mhz... the software doesn't change right?

thanks for the circuit diagram as well.... that alleviated some of my fears for interfacing with memory.

thanks,
fred

Paul Baker

Yeah I would suggest getting one of the kits and start prototyping with that, then moving to surface mount when you have your design down (and move up in I/O if you think you need it after experimenting), but I just realized that by combining steps 2 and 3 this circuit is just as fast as one with no latch, so you may want to stick with the SSOP version of the SX28 unless you really dont have room for a 20 pin SOIC, SSOP or TSSOP.

Have feet wetting,
Paul

Paul Baker

you may have to delay out the time /WE is low by a cycle for a write and wait a cycle for the read. Here basically how you determine it: write the code to interface it, calculate the number of cycles for each line of code. Compare times between state transitions in your code with the timing diagram for the device (I ussually print it out and write the times next to the symbols) if any of the transitions occur in less time in your code you have to insert nops until the code take equal or greater time (say /WE was low only 10ns, the timing diagram shows that we need to expand it by 1 cycle to 20.

BTW there are tricks to trig functions such as single quadrant table lookup, or if you need to generate sinusoidal waveforms you can use the gravity trick.

Paul

Post Edited (Coriolis) : 8/7/2004 9:52:02 AM GMT

frdchang

hello,

how would one add ram to the sx chip? i see how the ram would interface with the chip, but how would i address it?

(how would i have the program run off the chip)...

it seems like i have to run a little program that is internal to the chip.... and that little program shuffles data back and forth from the ram....which seems tedious.

i may need only 1-2k of ram...but i'll need 16k to 32k of programming space. (the chip above linked in http://rocky.digikey.com/WebLib/Cypress/Web Data/CY7C128A.pdf seems like it has 16k of ram... which maybe enough both ram and programming space)

what does 4096 x 12 mean for the eeprom size? 4096 banks of 12 bit address spaces? so is that 16k of eeprom?

so a tactic i can do is load the program into eeprom.... (if my assumption that its 16k is correct that its enough)... and then use the ram as that dynamic data storage.... and since the ram interface is a couple step process.... i'll have to write a function and call it everytime i wanted ot read and write to ram... write_ram(data, address).

this seems wrong to me... is there a better way? i don't think i'm fully grasping on how to expand the ram of the sx chip..

thanks for the responses so far!

cheers,
fred

Stanley Frederickson

While you can interface various RAM or EEPROM chips to the SX chip, they won't really help you expand the built-in memory of the SX chip. This is especially true for code space. The SX memory architecture is such that data and code space are completely separate and there are no commands (to my knowledge anyway) that allow you to write to the code portion of memory. Therefore you are stuck with the built-in space for native code since this is the only place that the processor will fetch the instructions from and you can't modify it at runtime to page in more code from an external source.

You could use an external memory chip to help expand the amount of memory for data storage. This would result in a system that would allow you to page in data from the external chip and place it in the registers of the SX and vice versa. The processor won't do this paging for you automatically, you would have to call code to move the data back and forth between the registers of the SX and the RAM chip.

The SX chip is a RISC processor. One of the common features of RISC chips is that they have fixed length instructions. In theory they are supposed to have fewer instructions as well but most modern RISC processors break this rule. On the SX chip, the fixed length of the instructions are 12-bits. This is why you see the 4096 x 12 value being used for the size of the code space. This means that you can fit 4096 instructions in the code space of the processor since each instruction is 12-bits long.

Paul Baker

Im sorry to say frdchang than stanley is correct,·there is no means for expanding the program space for the SX. The SX (and the vast majority of RISC microcontrollers) have a Harvard archictecture, where the program space and data space·are on seperate busses. The main reason for this is that having a program space of an arbitrary number·of bits (12 in the SX) allows·placing one instruction per address. This greatly simplifies the pipeline, increases system throughput (MIPS)·and·helps enable a deterministic processor which is a primary goal in all of·Ubicom's microcontrollers.·The drawback is that it makes program space expandibility difficult and I'm not aware of a Harvard architecture microcontroller which has this expandability.

I didnt understand before that you were trying to add program space, I typically interpret RAM=data, flash=program.

The spec you linked is a 2KB memory 2KB x 8 bits/byte =16Kb memory (B=byte, b=bit).

The only way I can think of "sortof" expanding the program memory at this late hour is by using a multiprocessor configuration so 16KB program space would require 4 SX processors of the 48/52 variety. You would subdivide the code so each processor is responsible for execution of portion of the code. Data which must be shared between routines which are located on different processors is transfered on a common bus. Judicious placement of code can reduce the amount of interprocessor communication. Anyways this is a fairly complex solution and greatly increases development time not to mention debugging the system would be very ardious if possible at all.

I am quite supprised you really need this much code space, if this is for your maze navigator·you should be able to make do with the 4K. In my undergrad robotics course, noone in my class had a program larger than 4K (with the exception of one person who chose to fill up the remainer of the 64K with a clip of "Who let the dogs out" that it played after it sucessfully traversed the maze (of course he made his robot look like a dog)) and this was on the relatively code bloated 68HC11 (which by the way is VonNeuman Architecture where program and data memory occupy the same space (it's also CISC and operates at 4MHz :P))·and some of the projects were fairly complex (a couple robots navigated a maze then met in a common area and enganged in battle with each other with IR "cannons").

Are you storing large data tables in memory? You made mention of trig functions, sin and cos of any number can be·generated using only a single quadrant of data (ie store quadrant 1 of sin,·2nd quad is generated by traversing 1st quad backwards, 3rd is 1st forwards but negative and 4th is·1st backwards and negative, and of course cos(x)=sin(x+pi/2)). Also you could do away with the table altogether and use the power series equations (cos(x) = 1 - x^2/2! + x^4/4! - ...· and sin(x) = x - x^3/3! + x^5/5! - ... where x is in radians) this sacrifices speed for program space but you can balance the speed vs accuracy. Depending on your desired accuracy, you can also approximate the value by using "fitted" parabolas (ie a parabola fitted to the points 0, pi/2, pi yields for 0<x<pi sin(x) ~= -(2x/pi - 1)^2+1, this equation generates the maximum error of .056·between pi/7 and pi/6. See the attached capture of math.com's function plotter. The error can be reduced further by fitting the parabola to·sin at points 0, pi/4 and·pi/2 but I'm not doing that at this hour).

Hope some of this helps, Paul

simon

Hi!

I have not read the entire Thread, but a serieal EEPROM is very slow.
The atmel 24c16 i am using takes around 5ms (@5v) for the actual write to its internal
eeprom (@2.8V ~10ms).
The write command is as short as mentioned above but you can
only write one byte, then wait 5ms and after that you can write/read again.

Bye, Simon