As this topic has been elaborated for long time - the question is whether a board with a sdram (ie 8Mx16 - AS4C8M16S-7TCN, $1.60 here on Cote d'Azur) is worth of a "prototype" run. For example Jaromir's board with the above sdram and a cr1220 RTC battery holder from the bottom side (frankly I am trying to influence him in that direction ). a. Is the driver stable enough? b. Any dependencies? c. Issues? d. Speed?e. Can we utilise those 8/16MB with retro somehow?f. Is somebody interested to order it (the prototype run will be 10pcs)?It seems only madscifi has got the real hands-on experience with it by now..P.

We discussed this a lot with Pito. He took flight from Monaco to my living room just because of this.

There seems to be no problem to fit all the components - PIC32, SDRAM, RTC, battery, headers - on single 5x5cm board, available at seeedstudio for 1USD/pc (10 pcs for 10USD). Almost the same as I've done before with SRAM.SDRAM are really cheap and plentiful, but we need rock stable low-level driver for it.

The SDRAM driver is, as far as I can determine, stable. It has several issues:

The first issue is that DMA and interrupts must be turned off during transfers to/from the SDRAM. At present the driver only disables interrupts, so it is incompatible with anything that uses DMA. This should not be a difficult thing to fix, but it might mean that the driver is incompatible with USB. I don't know enough about interfacing to USB to say whether or not this is actually a problem.

The other issue is that it does require a rather large (>1K) amount of kernel ram. There is nothing that can be done about this (short of putting a controller chip of some sort in between the CPU and the SDRAM) as the timing requirements are very strict and the driver depends accurate single cycle execution out of ram. The driver code has already been split into parts that can execute from FLASH (in C) and portions that must execute out of RAM (in ASM).

The final issue is that it takes a lot of pins.

The only real question is whether to support 8 or 16 bit data to the SDRAM. At present the driver only supports 8 bits, but 16 bits is pretty straightforward to add. Actually, moving to 16 bit transfers will shrink the part that executes out of RAM a little - it just means 8 more pins are lost to other uses.

@madscifi - thanks for the info! Assuming the USB is not required (still it is a retrocomputing gadget) for serial console (but for bootloader only) does it mean we have enough kernal ram for it?In each case I would at least be happy to discuss the pin layout herein, as my idea is to have following there:1. 36 pins for the sdram (16data + 12addr + 8cntrl = which ones?)2. 1xSPI for onboard SDcard (or two cards?) (~5pins)3. USB (bootloader only, used as 5V inp power conector) (2-3pins)4. 1xI2C for RTC (2pins)5. 1reset + 1usr button (2pins)6. 4 LEDS (4pins)

and pinheaders for:7. power down pin (1)8. 1xSPI (3+2pins)9. 2xUART (4pins)10. 1xI2C (2pins)11. an I/O port with at least 12 free pins (8+4pins)12. and few 5V pins, few 3V3 pins and a lot of gnd pins..

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

I've never had any heating issues with them, but then I never really exceed 100mA at 5V with them - and they are so small and cheap you have have different ones powering different areas of the board.

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Yes, those are good for powering various parts of pcb. That is better than one central reg. The worst case current consumption:pic32@80MHz 90mAsdcard 40mAsdram ~30mA (130mA, 200mA auto refresh) @140MHz BT module 40mALEDs 15mA ----------------------------Total 215mA

It also helps to reduce power rail noise from propagating around the board.

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

madscifi: could you list all hardware/pins/peripheral limitations when it comes to SDRAM? For example data pins have to be on single port, clock line feeded from specific peripheral etc...?After this I could start to design schematics and components placement. And then, routing. It will not be easy

I'm not sure if I'd like to power board from more separate regulators. It can be done, if there is a reason, like 30x30cm board with 5A total load. For 5x5cm board with total load 200mA it is pointless.I like to use generic 1117 regulators. Cheap (~0,1EUR) and plentiful. It has one drawback - cooling tab is on Vout potential, so you have to place it on piece of copper with Vout (3,3V). For smaller board this is not acceptable, as we need big groundplane, so I'll use LF33 (~0,25EUR) in DPAK, as it has cooling tab on GND. It is solid 1A regulator.I really don't want to mess with anything in SOT23 package. DPAK package itself has higher power margin than SOT23 with few square centimeters of copper.

I think USB and SDRAM shouldn't be problem. USB can be "unattended" while SDRAM block is transferred. USB hardware should do NACK-ing while it is not ready. Important is to check USB peripheral every few milseconds (or faster during enumeration) - I think this is OK for SDRAM access.

ICD3 - what I use - works much faster compared to PicKit3 But good to know about it. I'll definitively break out JTAG pins - at least on single row pin header. Full-sized JTAG connector would be probably too huge to fit on board.

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