Got enough part PDFs, and I just started on PCB123 now. The first board is uni-processor as well but will have the headers to stack more Propellers up (the Propeller on additional cards will use the same part package as the one on main board - QFN-44, it's mostly thermal management reason.)
Also, as I stack more Propeller up, the more RAM memory I will get here, but they're all independent of each other (each CPUs will have their own SDRAM). I think with 8-bit GPIO to I2C bus converter, I can stack up to 64 boards or maybe more, until I would start to hit the bandwidth limit.
I am having a problem: I have to design some part copper layout for QFN-44 because my PCB123 doesn't have few part pinout / layout... Argh. (BTW, I do it off-line, though)
I am hoping to do up quickly as possible (wish I have my tower PC here - I am working on PCB123 on a laptop with anemic memory size. I am being real patient, though. Here, I have
256MB SDRAM on my laptop and my tower have 2GB DDR-II 800MHz memory, along with dual-core Athlon 64 X2 which I would just zoom through the CAD-related works.)
Alright... I am making a progress. I had to ditch PCB123 as it's a bit limiting...
Here, I am doing some trace draw-ups on KiCAD (Windows version) for the prototype board.
A voltage regulator isn't used right now, as I have a habit of leaving some unused parts as a reference then use it later on. (Size - real-estate referencing). However, I have hit a snag - something I want to ask few of experienced KiCAD users here about: Whenever I try to make a micro via that goes through maybe 3 or 4 layers, KiCAD, for some reasons, refused to do that - instead left the third layer trace unconnected as is apparent in 3D display viewer. Kinda annoying. I have to do the same with the thermal vias for the QFN-44 P8X32A microcontroller chip - same result as before - refusing to let me go through few more layers to GND. SDRAM, 47LVT573 and P8X32A are the parts I am having problem with stubborn via placer. Otherwise I am making a O.K. progress.
Here is the attached pictures of progresses as well as some via issue I was talking about.
(BTW the KiCAD version is 2010-05-05 2356)
Update: Problems with the vias are finally solved. I used the wrong vias type - I have to use one defaulted to be FAT and then created the custom vias size the same size as micro-vias so I could snake the connections up the tight area like the SDRAM chip I am going to use. So I should be pretty quick to whip up this prototype soon, hopefully. And, yes - I knew it will be expensive (it's a 4-layer SMD printed-circuit board which also will hold a BGA chip - they're quite expensive.) And, my order should be here on Tuesday the 8th of February this week.
I know it is an old conversation in this thread, but on the question of what to do with all of those I/O's...
Well, the most difficult (and ultimately most important) sense that humans have, and machines do not, is touch. This is simply because of the amount of nerve endings on a human's body, as compared to the amount of usable I/O's on any computing platform. Given this, one could get a crude "touch responsive" automaton. I am not sure what practical application for this gizmo would be, other than having a robot that either yelps in pain, or yells "Bad Touch!" once in a while.
Good question. That can be done by daisy-chaining via the I2C chips, or use the multiplexer chips - in this case, I am going to put on the USB host controller PHY chip (Vinculum II from FTDI, the same manufacturer who made the FT232R - an USB to RS232 port converter on the familiar Propeller Clips / Plugs) and use the USB host bridge on my prototype board.
I2C provides the easy way out as the Propeller defaults to boot from the EEPROM / FRAM / MRAM OS firmware ROM. You have to ask for that particular chip by its address (the datasheet will tell you what it is).
However, by Propeller's own "GPIO" IO pins, that's difficult as it only have 32 pins already there, right on Propeller P8X32A die. Surely, you can still cheat and hopefully you succeed. There is still 80% horsepower left untapped (hope I am not wrong) - which still leave plentiful more to pick its brains clean.
Touch response is pretty useful in many applications - one example being the touchscreen LCD on most new cell phones and convertible laptops. It could be the fancy pricey light dimmer which you slip your finger on solid plastic panel (capacitive touch sensing). When being used in conjunction with Propeller, you can have a touch-response MP3 player, DIY theater controller, and the funny-looking robot controller - whatever you want is up to you. Also, fortunately, most capacitive touch panel / touchscreen panel controllers come in I2C / USB / SPI / RS232 favors that you can choose for your particular application.
BTW, there are tons way of sensing the touch is accomplished by few of the methods: Capacitive coupling touch sensing, Infrared light (laser - VCSEL in many case, and with some, LED) reflective / modulation touch sensing (kinda like camera), Resistance coupling (like with some cheap PDA as well as with some older expensive PDA) touch repetive sensing, electro-coupling thin-film contact touch screen (some PDA like that $10 Royal touch PDA at Wal-Mart). The basic rule is to interprete what area is being touched - like with mouse touchpad on laptops, by reading out what the signal is in conjunction with the calibration information.
Also, I forgot to tell ya, Propeller can also, when properly programmed, respond to capacitive coupled touch response. It is a bit simple as it only use radio-frequency AC (not like DC from the battery - ceramic and air-gap capacitors responds better to Alternating Current) to differenate the current flowing between "dielectric" like plastic panel, and the electrodes and your finger. What's not simple at all, is to create delta-sigma calculation on the precieved currents from the home-brew capacitor sensor - the Propeller Education Kit book would provide you some hints on that frequency summing and capacitive load sensing.
Yeah did not even think about "touch screens" and the like, for flat-surface devices like you said, but are any of these technologies able to, say, wrap around the end-effecter and arm to give real time part location within grippers, or help judge if it is holding the said object too tightly? I know that you could just make smaller versions of this to fit in finger pads, but maybe going to the extreme of being able to sense when the arm is moving and runs into an obstacle, and be able to stop, and re-plot a path based on the item it ran into without relying on ultrasonics or IR signatures.
Yeah. There are so much way to sense the touch. Gripper on certain robots (even the hands of Asimo from Honda Japan) has the special polymer sheets (which is like the resistance touch-screen module in most PDA) which allows the computer to know if it's gripping the object (such as egg or even a Christmas tree orament) too tight - just to go easy on the PWM control of the motor. They are still researching to give the robot human-like touch sense (which is impossibly hard to perform upon the manufacturing of fake "skin"). So on hobbyist-level, we are just to tinker away with what we have.
About the accidental-avoidance, it's going to be a type of resistance or ultrasonic (PZT-transduced material - Sonic Acoustic Wave [SAW] sensor - on some touchscreen) which the robot will instantly know if it's touching something (like about to accidentally push that $10,000 Japanese painting vase off the stand table... O_____O ) - it will know instantly and move back, or just to catch it quickly. It is a matter of the accidental-avoidance software, it has to be written well enough (and the robot gotta still learn to know - which to nelgect the broken stuff or just to save that expensive vase - not a fun project.. But we still can settle on simple project for now as in some case it will still take lot of computing power to connect the dots to what it felt and saw. You can use either XMOS XS1-G4 or Propeller 1 / II chips, interconnect 'em all together to get extra raw processing horsepower. Just beware the power requirements that the microcontroller arrays will demand - for 8 Propeller 1 chips, it will draw up to 2.6 Amps at 3.3 Volts.)
BTW, if you got long-dead touchscreen LCD form a PDA that was accidentally smashed or just got a goodie bag full of LCD touchscreen polymer, you can certainly try - but just peel it off quite carefully.
Now, I figured out on SDRAM's part - for unused DQ pins, it should be pulled down. If peoples out here says "NOOOO!!!!", give me what's the best way to deal with unused pins...
I felt that I should go with six-layer PCBs, maybe stick with 4-layers one, just gotta find out.
I hit the rock bottom: The Propeller Tool refused to allow me to use the Propeller's GPRs (General Purpose Registers) and TPRs (Token Purpose Registers) for some reasons, as it would be necessary for me to whip up few ALU instructions necessary for the OS kernel in the IDE...
And, I downloaded the Windows version of BST, just in case - I am going to look through it tonight. Any comment about the tool's stubbornness would be appreciated as I may need to get around it if need to be.
Why was it so stubborn about the pure ASM was definitely new to me: I have done assembler before, and it was kinda not what I excepted, like for example: "MOV x, #4", and it just jump on GPR and say "Undefined symbol" - it really upset me in a way - as there's no way out.
Yeah, I got what manual said - it's a Load-Store RISC processor, so I tried to treat it as a PowerPC processor - compiled fine, but I need to find a bug because the emulator crashed.
So, I got GEAR, which is going to help A LOT. I will have to view what is the state the whole thing froze at. I had to play around a bit in pPropellerSim.jar (Java Propeller emulator).
About PowerPC, deSilva's manual mentioned something eeriely familiar, the container label. It was kinda a dead giveaway that the Propeller is an advanced RISC, like PowerPC, whereas I am familiar with the PowerPC ASM programming.
There is also a cheap ($10 to 40) PowerPC microcontroller, like MPC555 that you can actually use with Propeller without any hitch. (What I have been observing, they "think" about the same, except they both have profoundly different circuitry.) - If it's too expensive to buy at the e-store (such as Mouser), try buying it straight from Freescale, it's usually cheaper to buy directly from. I also have my own account there.
Mike G. I got the manual - every different kinds of Propeller ASM manual to find what I am missing out, now it's clear that I should try treat it like a PowerPC microcontroller - it worked. I now look it up whenever necessary to be ascertain.
Excuse me about "token" - there were "t0", "t1" and the like in Propeller simulator, so I thought it was TPRs (there are very few other microcontrollers that actually use TPR, not PowerPC microcontroller - it's primarily a computing microcontroller - which in this example you can have Propeller treat MPC555 as a calculator, since it already have an advanced FPU built-in).
Discovered it doesn't have TPR (as the whole emulator crashed miserably).
Now, I may want to ask: How can I call a new COG in assembly? Or should I better start one in SPIN language?
And, GEAR really helped sufficiently in debugging the whole things. Thanks, mirror!
And, speak of starting a new COG, which method you think would be better: When downloading onto SDRAM, should I use HUB SRAM as a FIFO (4KB page bulk write) or have a COG download something through SDRAM controller COG, under its explicit directions?
I see. Guess, I can just have two COGs (one askin' for the memory space and one controlling the RAM activity) gain access into the RAM.
On the other hands, I got only 12 address pins on my SDRAM. IS42S32400D-7BL is the RAM I am using - looks like I am lucky enough to save the extra pins, but bummers, I will still have to assign the pins to I2C, SPI, RS232, and another Propeller... But, at least I am thankfully for this RAM. (there is 32 DQ pins, but like what ISSI reps told me, I could just pull it down to disable the DQ pins.)
I think I got 5MB worth of a big PDF titled "Propeller Manual" probably is revelant toward in COGINIT and other goodies - I will try to read through it and find out.
Update - yep, Propeller Manual got what I wanted. COGINIT calls new COG or "resets" the currently running COG.
As I have asked jazzed via PM, I am wondering about using Maxim Semiconductors, Inc.'s MAX335 8-port switch for handling the SDRAM IO, so I would be able to translate the whole 32-bit pipelined SDRAM DQ IO pins into the mimicked DQ0 - DQ7 8-bit pipelines for Propeller microcontroller to download the whole 16MB onto the chip without wasting it all. I was forced to search for the switch as the SDRAM I bought was expensive - $11 bucks a pop. And, it was the only one available at Mouser's internet store at the time.
As I have asked jazzed via PM, I am wondering about using Maxim Semiconductors, Inc.'s MAX335 8-port switch for handling the SDRAM IO, so I would be able to translate the whole 32-bit pipelined SDRAM DQ IO pins into the mimicked DQ0 - DQ7 8-bit pipelines for Propeller microcontroller to download the whole 16MB onto the chip without wasting it all. I was forced to search for the switch as the SDRAM I bought was expensive - $11 bucks a pop. And, it was the only one available at Mouser's internet store at the time.
I don't understand why you are going that direction. Either 8 or 16 data bit SDRAM works fine directly connected to Propeller without special circumstances (except that addresses must be latched because the write command CAS cycle requires address and data be driven simultaneously). There is no benefit in using 32 bit wide parts with Propeller (well there might be a way, but it would be cumbersome at best). If I had to use a 32 bit part, I would use the DQM bits to enable the byte lanes rather than connecting another chip which probably wouldn't work anyway. You already have an example to follow so that you don't have to waste time or money. Mouser is not the only source for SDRAM parts. I suggest you look at what has come before you and try to make improvements rather than starting from scratch.
Well, the representative at ISSI told me that if I don't use all DQs, I end up wasting some memory (so he said: DQ pins are addressed for specific RAM paging on chosen banks)... If you have done getting 100% outta the RAMs using only few DQ pins, then I will drop the usage of switcher.
Losing 75% of RAM space due to using only DQ - 7 would be the things I would lose sleep over (Rambus XDR won't care if DQn / DQ pins aren't to be fully used - it lets you keep 100% of the spaces, regardless of the IO pipeline bits).
And, jazzed - good point, though. I was only able to purchase the 32-bit SDRAM at the time of purchase - others were sold out (but could have been ordered for some more by now). 8-bit SDRAM also come in TFBGA-48 / 54 favor, as well as TSSOP-44 / 54 package, so there is still an option for me in the future if I build more prototype in the future. ISSI IS42S16800E-75EBL is one example of TFBGA-54 8-bit SDRAM (I will buy this one in the future and maybe save 32-bit one if I feel like it - I got my Digikey account - hope they don't do funny on the order - like "out of stock" or something, like with Mouser - I would like to be able to order immediately when needed to be). BGA got obvious benefit of being smaller.
I know, I only can ask you few question that you probably can answer.
Guess no one seems to be interested anymore, so I probably will shelve this project. (There seems to be no encouragement and guides anymore, so I guess I can say - I am about to give up.)
BTW, jazzed - I am not being mean to you - you did succeed in using SDRAM on Propeller. The only trouble is, what about 32-bit SDRAM? I guess it's better to try and get 8-bit one like you suggested and stay with it throughout prototyping (providing I don't give up). And, I also found your source code a great reference.
I know, I only can ask you few question that you probably can answer.
Guess no one seems to be interested anymore, so I probably will shelve this project. (There seems to be no encouragement and guides anymore, so I guess I can say - I am about to give up.)
I answered your last question in great detail. You did not understand for some reason, that's why I conclude that I can not help you.
I guess if I want to succeed in building this supercomputer, it would be better to keep my mouth shut and research the part datasheets in great detail.
I didn't want to offend you guys - if I did, I apologize.
Leon, I knew about Address latch - I was talking about the the remaining data pins DQ8 - DQ31.
Anyways, I found a $3 16MB SDRAM with x8 memory bus (DQ0 - 7) at Arrow Electronics distributor, both ISSI - IS42S16800E-75EBLI-TR (TFBGA-54) and IS42S16800E-7TL (TSSOP-54) - all goes for $2.95 at Arrow NAC (North America Components) website. Not bad.
Note that, the RAM comes from ISSI, but I cannot force you guys to be sitting on this particular brand - there are zillions of manufacturer favors (actually five on Arrow website) that you perfer: Infineon Technoloies, ISSI, Micron Technology, Samsung Semiconductor, and Winbond. If you want x8 and only x8 - you will want to read the datasheet to be careful.
x16 and x32 SDRAM can be used, ablieit with careful efforts on your parts (jazzed's driver uses bit masking to try and switch over the remaining x24 / x8 buses over to used x8 bus). Clock jitters is one very important thing to consider (SDRAM are much more forgivable than DDR1 - II DRAM chips) - I have couple SDRAMs outta trash DRAM sticks so I also have some room to experiment here too, without the risk of smoking the brand new SDRAMs.
I still have to order more parts, like 74LVT573 latch for the address latching onto DQ pipelines from / to Propeller, to complete the list of needed parts - then that's it for the first one (for software testing before I make more Propeller board to stack upon the active board bottom to simulate the real-time environments).
And, I fully believe jazzed now - I found the patent talking about DQ masking - it confirmed what he was talking about. If it's too late and you got SDRAM with a bit too much legs, you can try doing bit masking like what jazzed was talking about. (like me, I got it too late, but at least I am now relieved now that I can actually use the whole memory spaces with the DQM setting.)
x16 and x32 SDRAM can be used, ablieit with careful efforts on your parts (jazzed's driver uses bit masking to try and switch over the remaining x24 / x8 buses over to used x8 bus)
I don't have a driver that tries such DQM tricks LOL, but it would not be a problem at all to do it.
I do have a design and code for x16 SDRAM that is 25% faster (for propeller) than the x8 design, does not require "careful efforts" LOL on DQMs, uses 2x 74LVC573's (cheaper and better than LVT which is getting hard to find) in SSOP20 for addressing, and is known to work with the Winbond (about $5 qty 1), ISSI, and Micron 16Mx16 (32MB) parts. Of course the design requires 21 Propeller pins, but that's only 1 more than the x8 design requires.
Yeah. I agree. I got everything crystal clear now - sometimes the RAM manufacturer's reps got it wrong, but they were correct in pin pulldown requirement, though. I am going to try DQM trick soon when I feel like trying it on a garbage SDRAM (will need to find TSSOP-54 schmartboard, though - not cheap, but neat for testing out the SDRAM operation).
And, also I found 74LVT573 at mouser, still available in TSSOP20 and TF-QFN20 package. I will use the alternative that you recommended that if Mouser has run out of the 74LVT573 bus. (I may go with other stores too, if need to be).
You said you don't have a driver that try the DQM masking, right? It sure looked like it, though. Maybe I need to drink coffee (or BAWL) if I need to be wide awake when I read the source code late at the night...
By the way, jazzed, you think it would be doable to copy some of your driver's codes into my kernel source code to call upon COG 1 to activate and maintain the SDRAM?
Last thing, I checked in Mouser - 74LVC573ABQ,115 (QFN-20) is dirt cheap - $0.60 and much faster - on goes my order list! Why smaller SMT? I usually am fussy about thermal management on higher speed logics - they get pretty warm when heavily used, and the other times, I don't have that much space on the board. It's just me, maybe.
Guess no one seems to be interested anymore, so I probably will shelve this project. (There seems to be no encouragement and guides anymore, so I guess I can say - I am about to give up.)
That's strange! I've encouraged you all along the way. In particular, I wanted you to start with a more simple design so you could get up and running rather quickly, see the rewards, start programming, and then expand from there. I think you took that advice and had placed a starter order for parts. Keep at it.
Comments
Also, as I stack more Propeller up, the more RAM memory I will get here, but they're all independent of each other (each CPUs will have their own SDRAM). I think with 8-bit GPIO to I2C bus converter, I can stack up to 64 boards or maybe more, until I would start to hit the bandwidth limit.
I am hoping to do up quickly as possible (wish I have my tower PC here - I am working on PCB123 on a laptop with anemic memory size. I am being real patient, though. Here, I have
256MB SDRAM on my laptop and my tower have 2GB DDR-II 800MHz memory, along with dual-core Athlon 64 X2 which I would just zoom through the CAD-related works.)
Here, I am doing some trace draw-ups on KiCAD (Windows version) for the prototype board.
A voltage regulator isn't used right now, as I have a habit of leaving some unused parts as a reference then use it later on. (Size - real-estate referencing). However, I have hit a snag - something I want to ask few of experienced KiCAD users here about: Whenever I try to make a micro via that goes through maybe 3 or 4 layers, KiCAD, for some reasons, refused to do that - instead left the third layer trace unconnected as is apparent in 3D display viewer. Kinda annoying. I have to do the same with the thermal vias for the QFN-44 P8X32A microcontroller chip - same result as before - refusing to let me go through few more layers to GND. SDRAM, 47LVT573 and P8X32A are the parts I am having problem with stubborn via placer. Otherwise I am making a O.K. progress.
Here is the attached pictures of progresses as well as some via issue I was talking about.
(BTW the KiCAD version is 2010-05-05 2356)
Update: Problems with the vias are finally solved. I used the wrong vias type - I have to use one defaulted to be FAT and then created the custom vias size the same size as micro-vias so I could snake the connections up the tight area like the SDRAM chip I am going to use. So I should be pretty quick to whip up this prototype soon, hopefully. And, yes - I knew it will be expensive (it's a 4-layer SMD printed-circuit board which also will hold a BGA chip - they're quite expensive.) And, my order should be here on Tuesday the 8th of February this week.
Well, the most difficult (and ultimately most important) sense that humans have, and machines do not, is touch. This is simply because of the amount of nerve endings on a human's body, as compared to the amount of usable I/O's on any computing platform. Given this, one could get a crude "touch responsive" automaton. I am not sure what practical application for this gizmo would be, other than having a robot that either yelps in pain, or yells "Bad Touch!" once in a while.
I2C provides the easy way out as the Propeller defaults to boot from the EEPROM / FRAM / MRAM OS firmware ROM. You have to ask for that particular chip by its address (the datasheet will tell you what it is).
However, by Propeller's own "GPIO" IO pins, that's difficult as it only have 32 pins already there, right on Propeller P8X32A die. Surely, you can still cheat and hopefully you succeed. There is still 80% horsepower left untapped (hope I am not wrong) - which still leave plentiful more to pick its brains clean.
Touch response is pretty useful in many applications - one example being the touchscreen LCD on most new cell phones and convertible laptops. It could be the fancy pricey light dimmer which you slip your finger on solid plastic panel (capacitive touch sensing). When being used in conjunction with Propeller, you can have a touch-response MP3 player, DIY theater controller, and the funny-looking robot controller - whatever you want is up to you. Also, fortunately, most capacitive touch panel / touchscreen panel controllers come in I2C / USB / SPI / RS232 favors that you can choose for your particular application.
BTW, there are tons way of sensing the touch is accomplished by few of the methods: Capacitive coupling touch sensing, Infrared light (laser - VCSEL in many case, and with some, LED) reflective / modulation touch sensing (kinda like camera), Resistance coupling (like with some cheap PDA as well as with some older expensive PDA) touch repetive sensing, electro-coupling thin-film contact touch screen (some PDA like that $10 Royal touch PDA at Wal-Mart). The basic rule is to interprete what area is being touched - like with mouse touchpad on laptops, by reading out what the signal is in conjunction with the calibration information.
Also, I forgot to tell ya, Propeller can also, when properly programmed, respond to capacitive coupled touch response. It is a bit simple as it only use radio-frequency AC (not like DC from the battery - ceramic and air-gap capacitors responds better to Alternating Current) to differenate the current flowing between "dielectric" like plastic panel, and the electrodes and your finger. What's not simple at all, is to create delta-sigma calculation on the precieved currents from the home-brew capacitor sensor - the Propeller Education Kit book would provide you some hints on that frequency summing and capacitive load sensing.
About the accidental-avoidance, it's going to be a type of resistance or ultrasonic (PZT-transduced material - Sonic Acoustic Wave [SAW] sensor - on some touchscreen) which the robot will instantly know if it's touching something (like about to accidentally push that $10,000 Japanese painting vase off the stand table... O_____O ) - it will know instantly and move back, or just to catch it quickly. It is a matter of the accidental-avoidance software, it has to be written well enough (and the robot gotta still learn to know - which to nelgect the broken stuff or just to save that expensive vase - not a fun project.. But we still can settle on simple project for now as in some case it will still take lot of computing power to connect the dots to what it felt and saw. You can use either XMOS XS1-G4 or Propeller 1 / II chips, interconnect 'em all together to get extra raw processing horsepower. Just beware the power requirements that the microcontroller arrays will demand - for 8 Propeller 1 chips, it will draw up to 2.6 Amps at 3.3 Volts.)
BTW, if you got long-dead touchscreen LCD form a PDA that was accidentally smashed or just got a goodie bag full of LCD touchscreen polymer, you can certainly try - but just peel it off quite carefully.
I felt that I should go with six-layer PCBs, maybe stick with 4-layers one, just gotta find out.
However, I am back to coding.
And, I downloaded the Windows version of BST, just in case - I am going to look through it tonight. Any comment about the tool's stubbornness would be appreciated as I may need to get around it if need to be.
Why was it so stubborn about the pure ASM was definitely new to me: I have done assembler before, and it was kinda not what I excepted, like for example: "MOV x, #4", and it just jump on GPR and say "Undefined symbol" - it really upset me in a way - as there's no way out.
What are these? The word "token" doesn't appear in the Propeller Manual.
What? How are you going to add instructions to the Prop? Or are you building an interpreter?
Looks fine, depending on how "x" is defined.
How about posting your code so we can see what is up?
So, I got GEAR, which is going to help A LOT. I will have to view what is the state the whole thing froze at. I had to play around a bit in pPropellerSim.jar (Java Propeller emulator).
About PowerPC, deSilva's manual mentioned something eeriely familiar, the container label. It was kinda a dead giveaway that the Propeller is an advanced RISC, like PowerPC, whereas I am familiar with the PowerPC ASM programming.
There is also a cheap ($10 to 40) PowerPC microcontroller, like MPC555 that you can actually use with Propeller without any hitch. (What I have been observing, they "think" about the same, except they both have profoundly different circuitry.) - If it's too expensive to buy at the e-store (such as Mouser), try buying it straight from Freescale, it's usually cheaper to buy directly from. I also have my own account there.
Mike G. I got the manual - every different kinds of Propeller ASM manual to find what I am missing out, now it's clear that I should try treat it like a PowerPC microcontroller - it worked. I now look it up whenever necessary to be ascertain.
Excuse me about "token" - there were "t0", "t1" and the like in Propeller simulator, so I thought it was TPRs (there are very few other microcontrollers that actually use TPR, not PowerPC microcontroller - it's primarily a computing microcontroller - which in this example you can have Propeller treat MPC555 as a calculator, since it already have an advanced FPU built-in).
Discovered it doesn't have TPR (as the whole emulator crashed miserably).
And, GEAR really helped sufficiently in debugging the whole things. Thanks, mirror!
And, speak of starting a new COG, which method you think would be better: When downloading onto SDRAM, should I use HUB SRAM as a FIFO (4KB page bulk write) or have a COG download something through SDRAM controller COG, under its explicit directions?
On the other hands, I got only 12 address pins on my SDRAM. IS42S32400D-7BL is the RAM I am using - looks like I am lucky enough to save the extra pins, but bummers, I will still have to assign the pins to I2C, SPI, RS232, and another Propeller... But, at least I am thankfully for this RAM. (there is 32 DQ pins, but like what ISSI reps told me, I could just pull it down to disable the DQ pins.)
I think I got 5MB worth of a big PDF titled "Propeller Manual" probably is revelant toward in COGINIT and other goodies - I will try to read through it and find out.
Update - yep, Propeller Manual got what I wanted. COGINIT calls new COG or "resets" the currently running COG.
Losing 75% of RAM space due to using only DQ - 7 would be the things I would lose sleep over (Rambus XDR won't care if DQn / DQ pins aren't to be fully used - it lets you keep 100% of the spaces, regardless of the IO pipeline bits).
And, jazzed - good point, though. I was only able to purchase the 32-bit SDRAM at the time of purchase - others were sold out (but could have been ordered for some more by now). 8-bit SDRAM also come in TFBGA-48 / 54 favor, as well as TSSOP-44 / 54 package, so there is still an option for me in the future if I build more prototype in the future. ISSI IS42S16800E-75EBL is one example of TFBGA-54 8-bit SDRAM (I will buy this one in the future and maybe save 32-bit one if I feel like it - I got my Digikey account - hope they don't do funny on the order - like "out of stock" or something, like with Mouser - I would like to be able to order immediately when needed to be). BGA got obvious benefit of being smaller.
Guess no one seems to be interested anymore, so I probably will shelve this project. (There seems to be no encouragement and guides anymore, so I guess I can say - I am about to give up.)
BTW, jazzed - I am not being mean to you - you did succeed in using SDRAM on Propeller. The only trouble is, what about 32-bit SDRAM? I guess it's better to try and get 8-bit one like you suggested and stay with it throughout prototyping (providing I don't give up). And, I also found your source code a great reference.
I answered your last question in great detail. You did not understand for some reason, that's why I conclude that I can not help you.
I didn't want to offend you guys - if I did, I apologize.
http://www.gadgetgangster.com/find-a-project/56?projectnum=359
It's just the SDRAM chip and a latch.
Anyways, I found a $3 16MB SDRAM with x8 memory bus (DQ0 - 7) at Arrow Electronics distributor, both ISSI - IS42S16800E-75EBLI-TR (TFBGA-54) and IS42S16800E-7TL (TSSOP-54) - all goes for $2.95 at Arrow NAC (North America Components) website. Not bad.
Note that, the RAM comes from ISSI, but I cannot force you guys to be sitting on this particular brand - there are zillions of manufacturer favors (actually five on Arrow website) that you perfer: Infineon Technoloies, ISSI, Micron Technology, Samsung Semiconductor, and Winbond. If you want x8 and only x8 - you will want to read the datasheet to be careful.
x16 and x32 SDRAM can be used, ablieit with careful efforts on your parts (jazzed's driver uses bit masking to try and switch over the remaining x24 / x8 buses over to used x8 bus). Clock jitters is one very important thing to consider (SDRAM are much more forgivable than DDR1 - II DRAM chips) - I have couple SDRAMs outta trash DRAM sticks so I also have some room to experiment here too, without the risk of smoking the brand new SDRAMs.
I still have to order more parts, like 74LVT573 latch for the address latching onto DQ pipelines from / to Propeller, to complete the list of needed parts - then that's it for the first one (for software testing before I make more Propeller board to stack upon the active board bottom to simulate the real-time environments).
And, I fully believe jazzed now - I found the patent talking about DQ masking - it confirmed what he was talking about. If it's too late and you got SDRAM with a bit too much legs, you can try doing bit masking like what jazzed was talking about. (like me, I got it too late, but at least I am now relieved now that I can actually use the whole memory spaces with the DQM setting.)
I do have a design and code for x16 SDRAM that is 25% faster (for propeller) than the x8 design, does not require "careful efforts" LOL on DQMs, uses 2x 74LVC573's (cheaper and better than LVT which is getting hard to find) in SSOP20 for addressing, and is known to work with the Winbond (about $5 qty 1), ISSI, and Micron 16Mx16 (32MB) parts. Of course the design requires 21 Propeller pins, but that's only 1 more than the x8 design requires.
And, also I found 74LVT573 at mouser, still available in TSSOP20 and TF-QFN20 package. I will use the alternative that you recommended that if Mouser has run out of the 74LVT573 bus. (I may go with other stores too, if need to be).
You said you don't have a driver that try the DQM masking, right? It sure looked like it, though. Maybe I need to drink coffee (or BAWL) if I need to be wide awake when I read the source code late at the night...
By the way, jazzed, you think it would be doable to copy some of your driver's codes into my kernel source code to call upon COG 1 to activate and maintain the SDRAM?
Last thing, I checked in Mouser - 74LVC573ABQ,115 (QFN-20) is dirt cheap - $0.60 and much faster - on goes my order list! Why smaller SMT? I usually am fussy about thermal management on higher speed logics - they get pretty warm when heavily used, and the other times, I don't have that much space on the board. It's just me, maybe.
MIT license applies on substantial chunks of code.
The 74LVC573's are also available in SO20 ... I have 25 by accident