DNA-RTC board pin assignments

Rsadeika · 2012-08-04 10:28

So, I just got a DNA-RTC board, and I must say that the quality of construction is excellent.

I am having a problem trying to figure out the U9/uSD pin assignments. In the MGH Designs wiki, there is a diagram for the U9 which shows:
P0(16) - DO
P1(17) - CLK
P2(18) - DI
P4(19) - /CS
Does the P0,1,2,4 belong to the FRAM, and P16-P19 belong to the uSD? Does P3 get a mystery hookup?

For the P28(SCL), P29(SDA), is the EEPROM accessed as A0, and the RTC accessed as A1, and all other hookups would be A2, and so on?

Thanks
Ray

photomankc · 2012-08-04 11:00

The I2C EEPROM is A0 AND A1 (read/write address). Addresses in I2C are determined by the device so it's in the data sheet for whatever you add. I believe the uSD card and U9 share the DO CLK and DI signals and the CS line determines which should be listening, but I don't mess much with SPI yet so I could be wrong.

cavelamb · 2012-08-04 12:14

We need Martin to sign off on it, but this is what I think I see.
The solder bridges on the back side of the board set those options.
the blue indicates the default settings. (I'm hoping that I traced that out right)
The solder bridges here are shown from the tops side of the board!
(x-ray view). Flip left/right when looking at the bottom side.

more

jazzed · 2012-08-04 20:03

Martin has a nice web page with lots of info on the board: http://mghdesigns.com/wiki/dna:start

photomankc · 2012-08-04 20:22

Ah yes I see now there is a /CS line for each device.

dna:dna_jumpers.png

Rsadeika · 2012-08-05 03:33

This is my interpretation of pin assignments, so far:
U9 - FRAM & uSD
P0 - DO
P1 - CLK
P2 - DI
P4 - CS(FRAM)
P3 - CS(uSD)

Open (17) Pins for default board
P5 - P15
P16
P17
P18
P19
P20
P21

U12 - Dip8
P22 - P27

I2C - EEPROM, RTC
P28 - SCL
P29 - SDA

COMM
P30 - Rx
P31 - Tx

Hopefully somebody can confirm that this is correct. Since the U12 is an expansion socket, somebody might want to share, as to what kinds of things can be plugged in there, besides another FRAM chip. Since I will be starting a board exploratory project, FSRW will be the first Spin program I will be using, within SimpleIDE, of course. The implementation of RTC will be next, although I did not see any Spin programs for that. The last, and the hardest will be the FRAM chip, and how it can be used efficiently within the Spin modality. I hope somebody has some ideas for that.

Ray

photomankc · 2012-08-05 07:24

Reply to Thread ate my nice response so:

The SPI pins are either/or so you only use P0-P4 OR P16-20. The /CS lines decide which device is should listen to the shared bus lines. So either P5-P21 are free or P0-P15 are free.

Rsadeika · 2012-08-05 07:50

Using SimpleIDE, the following program mounted the uSD card. When I had 16,17,18,3 for DO,CLK,DI,CS, it did not mount the card. I also tried 16,17,18,19, which did not mount the uSD card. Yes it would be nice to have P0 - P15 open. So now I have to play around to see what is causing the problem when I want to use 16,17,18,19(3).

{{
 * @file MasterDNARTC.spin
 * This is the main MasterDNARTC program start point.
}} 

{{
 * Main program function.
}}
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
  
  DO = 0
  CLK = 1
  DI = 2
  CS = 3   // uSD card
  
  baudrate = 115_200
  
OBJ
  
  sdfat : "fsrw"
  pst : "Parallax Serial Terminal"
  
PUB demo | mount


  pst.Start(baudrate)
  
  waitcnt(clkfreq * 4 + cnt)
  mount := \sdfat.mount_explicit(DO, CLK, DI, CS)
  if mount < 0
    pst.Str(string(13, "Failed to MOUNT!",13))
    abort
  pst.Str(string(13, "SD card was found and MOUNTED!",13))
    
  sdfat.unmount

photomankc · 2012-08-05 08:12

The card uses those solder jumpers to determine which set of pins is used. Default is 0-4. If you want it on 16-20 then you have to desolder the jumpers and resolder them to bridge to the other set of pins. Thats not a programming change its a hardware change. It will never mount on 16-19 unless you physically change the solder jumpers.

Martin Hodge · 2012-08-05 19:17

photomankc and cavelamb have it right. The only thing I would add is that you don't necessarily have to use contiguous pins. For example if you needed pin 4 open for video you could jumper just U9-/CS to pin 20 and leave the rest at P0-P3. You could go even further and use some small pieces of wire to re-configure the order. Also, if you're not planning to use both Flash and uSD you can leave one of the /CS jumpers open and save a pin.

Rsadeika · 2012-08-06 04:21

I know that this is a very new board, but has anybody created a small suite of test programs for the board? The uSD reader is a fairly simple one, which I am sort of working on. The clock, and the FRAM seems to be a lot more difficult to understand, judging from the drivers I saw on the OBEX. Martin Hodge, what did you use to test out the components, from a software standpoint?

Hopefully the chart I have, for pin assignments, a few posts back, is now correct, and will save somebody some time. Now, I guess all that is necessary is the small test suite, to make sure all the components work, as expected, and then the next decision will be as to what side of the board the headers should be soldered.

Ray

Rsadeika · 2012-08-06 04:22

I know that this is a very new board, but has anybody created a small suite of test programs for the board? The uSD reader is a fairly simple one, which I am sort of working on. The clock, and the FRAM seems to be a lot more difficult to understand, judging from the drivers I saw on the OBEX. Martin Hodge, what did you use to test out the components, from a software standpoint?

Hopefully the chart I have, for pin assignments, a few posts back, is now correct, and will save somebody some time. Now, I guess all that is necessary is the small test suite, to make sure all the components work, as expected, and then the next decision will be as to what side of the board the headers should be soldered.

Ray

mindrobots · 2012-08-06 05:52

Hi Ray,

I did some testing on one of the prototype boards. Everything RTC, SD and SPI-Flash were tested extensively using Forth. The SD and SPI-Flash (single and Quad) were tested heavily using PropGCC and SimpleIDE. I really didn't do any Spin/PASM testing or use any of the drivers in the OBEX. The software I was worming on at the time drove my testing more than the hardware available.

The RTC is the same as used in the Spinneret, there is code for it in the Spinneret forum, here.

The SD is straightforward and matches up with the pins for the GG Propeller Platform board when using the P0-P3 set.

The .cfg file for PropGCC was just being created, so there were some issues there but once that got settled, I really didn't have any problems with the board for the things I ran.

I think at one point, I even had SRAM in U12 and Flash in U9. I didn't get around to trying any of the other dip-8 chips that could go into U12 but that looks like some fun projects for someone!

Martin Hodge · 2012-08-06 07:24

mindrobots did the lions share of RTC testing. I tested it too using the Spinneret drivers referred to above. The Flash (what you're calling "FRAM"*) was tested in both DIP-8 sockets by compiling, writing and running ebasic from the Propeller GCC demos. The DNA kind of spontaneously morphed into a "C-centric" device, but is perfectly capable of supporting Spin/PASM applications.

Rsadeika, your pinouts are correct for a DNA-RTC as shipped. I will add some pinout examples to the wiki.

----
*FRAM is different from Flash, unless you're experimenting with an actual FRAM chip, in which case you're in uncharted waters.

Rsadeika · 2012-08-06 09:29

My bad, I thought Flash RAM was abbreviated to FRAM, I am trying to deal with the stock Flash RAM.

I think the DNC-RTC board needs some Spin support, since propGCC is still in BETA phase. Eventually I will try the C/C++ on the board, but first Spin (SimpleIDE) stuff.

Ray

cavelamb · 2012-08-06 11:51

mindrobots wrote: »

Hi Ray,

The RTC is the same as used in the Spinneret, there is code for it in the Spinneret forum, here.

Unfortunately, the basic_i2c_driver link is broken, but changing the OBJ declaration is trivial
for someone who is up to speed with Spin. Beginners might not grok that right off the bat.

This is part and parcel of why the Spin repository that Ken is starting is really important.

[h=2]Driver for S-35390A RTC chip[/h]

Attached is a driver for the Real Time Clock chip on the Spinneret Web Server board.

You need to get the basic_i2c_driver file from the obex here: http://obex.parallax.com/objects/26/
Or alternatively you can use the pasm_i2c_driver from the obex here: http://obex.parallax.com/objects/611/ (you'll need to modify the OBJ section to change basic to pasm if you use this one)

Rsadeika · 2012-08-07 03:17

I have decided to move on to PropGCC, somebody else will have to delve into Spin support for the time being.

In regards to SimpleIDE PropGCC, the Board type selections are:
DNA
DNA-SQI
DNA-SQI-Alternate
DNA-SQI-Default
DNA:Alternate
DNA-Default
Is there a detailed explanation for these board types? I tried the DNA board type, and all of the memory model choices seemed to work. On some of the other board types, only the COG and LMM seemed to work, I think an explanation is in order.

Ray

Dave Hein · 2012-08-07 05:57

The Basic_I2C_Driver is located at http://obex.parallax.com/objects/672/ . The link probably changed when Mike updated it a while ago.

jazzed · 2012-08-07 07:13

Rsadeika wrote: »

I have decided to move on to PropGCC, somebody else will have to delve into Spin support for the time being.

In regards to SimpleIDE PropGCC, the Board type selections are:
DNA
DNA-SQI
DNA-SQI-Alternate
DNA-SQI-Default
DNA:Alternate
DNA-Default
Is there a detailed explanation for these board types?

Good question.

Martin Hodge · 2012-08-07 11:14

I don't know why there is a "DNA" and a "DNA:default" they are one-in-the-same. That seems to be an artifact of propeller-load and/or SimpleIDE me not understanding the file format.

Here's the matrix.

Flash in U9 with U9 and uSD on P0 - P4 ---> DNA
Flash in U9 with U9 and uSD on P16-P20 ---> DNA:HI

Flash in U12 with uSD on P0-P4 ---> DNA:SQI
Flash in U12 with uSD on P16-P20 --> DNA:SQIHI

There is already tons of Spin/PASM support for the board, just not yet for two of the new features, the RTC and Flash. In the meantime, you can still use it as a 100% compatible PP-USB replacement with USB power, which is what it was originally supposed to be.

Rsadeika · 2012-08-07 12:03

There is already tons of Spin/PASM support for the board, just not yet for two of the new features, the RTC and Flash. In the meantime, you can still use it as a 100% compatible PP-USB replacement with USB power, which is what it was originally supposed to be.

Yes, everybody knows about the "tons of Spin/PASM support", what I was going after was how easy is going to be to get the RTC and Flash up and running. As I mentioned, for me, at this time, it is way too time consuming. Do not get me wrong on this, I think it was an excellent idea to add the RTC and Flash. I hope that you sell a whole bunch of these boards.

Ray

mindrobots · 2012-08-07 12:10

As mentioned earlier, the RTC is the same as on the Spinneret, so the code for that pointed to earlier should work (or should work with a little adaptation).

Most of the boards that have SRAM or FLASH on them have been designed by third parties with a specific application in mind for that memory. There probably aren't general use SRAM and FLASH drivers in the OBEX. Spin has no use for that memory directly. PropGCC can and does use it for XMM memory models.

The C3 has both Flash and SRAM on it. There may be some example code for using it in C3 software bundle and manuals but it would probably need to be adapted because of the C3 hardware. There may be some C3 targeted items in the OBEX that use the SRAM or Flash.

OBC was using SRAM on his QuickStart board to provide extra token space for BASIC on his retro computer.

Ray, do you have a use in mind for the Flash? It was tested with the PropGCC cache drivers because initially it was added to the DNA board for support of large memory C programs. I don't think anyone set out to use it as a large volatile data space for Spin or PASM programs. Unless you have a specific Spin application in mind to use the Flash, it's probably going to be used for large memory model applications.

Most of my testing of the time was for feature functionality and reliability of the new hardware. I didn't have any specific applications in mind except when I used it to run jazzed's TetraProp with multiple PropForth Propellers spinning away madly through forth code.

Rsadeika · 2012-08-08 04:56

In my own subtle way I was just trying to point out that Spin + Flash RAM may not be a very good fit.

Ray

Martin Hodge · 2012-08-08 07:45

You've made good points in both threads, and I have taken them under advisement.

(yesterday was stressful for unrelated reasons, apologies if I appeared rude.)

going back to the SimpleIDE board selection topic, a side note: All the entries for the DNA only affect the configuration of the Flash and uSD. If you're not using either of those then you can select the default board configurations as they appear in the examples on the SimpleIDE page.

Martin Hodge · 2012-08-08 12:51

Added a lot of info about this today to the wiki http://mghdesigns.com/wiki/dna:propgcc-win
As always, feedback welcome.

--EDIT--

I spent some time today hacking around the config file and realized It's possible to unify the two DNA config files into one, simplify the selections, and make them more descriptive.

See this page for details.

The new dna.cnf is here.

dna-sqi.cnf should be discarded

The config file belongs in /opt/parallax/propeller-load/ for linux and c:\propgcc\propeller-load for Windows.

cavelamb · 2012-08-08 18:35

Thanks, martin.
That's way mo betta!

mindrobots · 2012-08-08 18:59

Sweet! Those configs make lots of sense.
Overall, the documentation looks great!

David Betz · 2012-08-09 07:07

Martin Hodge wrote: »

Added a lot of info about this today to the wiki http://mghdesigns.com/wiki/dna:propgcc-win
As always, feedback welcome.

--EDIT--

I spent some time today hacking around the config file and realized It's possible to unify the two DNA config files into one, simplify the selections, and make them more descriptive.

See this page for details.

The new dna.cnf is here.

dna-sqi.cnf should be discarded

The config file belongs in /opt/parallax/propeller-load/ for linux and c:\propgcc\propeller-load for Windows.

Thanks Martin! I pushed your dna.cfg changes to the Propeller GCC repository on Google Code and removed the now obsolete dna-sqi.cfg file.

cavelamb · 2012-08-09 10:55

David Betz wrote: »

Thanks Martin! I pushed your dna.cfg changes to the Propeller GCC repository on Google Code and removed the now obsolete dna-sqi.cfg file.

Dave, would it be possible to put links on the repository pages from one to the other?
Otherwise, the only way to find the related pages is though the links in your message above.
(Or am I missing something really obvious???)

Richard

David Betz · 2012-08-09 11:00

cavelamb wrote: »

Dave, would it be possible to put links on the repository pages from one to the other?
Otherwise, the only way to find the related pages is though the links in your message above.
(Or am I missing something really obvious???)

Richard

I'm sorry but I don't understand what you're asking? The Propeller GCC sources are in Google Code. You can find it thorugh the following link:

http://code.google.com/p/propgcc/

Are you asking me to put that link in some other place?

cavelamb · 2012-08-09 14:30

David Betz wrote: »

I'm sorry but I don't understand what you're asking? The Propeller GCC sources are in Google Code. You can find it thorugh the following link:

http://code.google.com/p/propgcc/

Are you asking me to put that link in some other place?

I'm sorry, Dave. Looks like it was the latter situation

.

I guess I'm asking Martin to add that link to his WIKI.

Maybe with some other links to support pages as well.
Or just add a links page?
Something to tie all the software resources together?

DNA-RTC board pin assignments

Comments