 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) | Forum Quick Jump
|
 | 
Dr_Acula
Registered Member
      
Date Joined Dec 2008
Total Posts : 606
| Posted 11/2/2009 4:58 AM (GMT -8) |   | Thanks heater. I have so much working on the board - vga, keyboard, low level PASM to read and write bytes to a ram chip. Just need to pull it all together. It is a bit frustrating as Cluso said that the SD card would be the easy bit - just change the pins over to whatever you are using, but it is turning out to be the really hard part. And the SD card is the reason I'm over here at the prop forum as it has defeated all but one member of the N8VEM group (Juha seems to have disappeared though he did leave us with some SD card code in Z80. But no-one else understands it). So in a way, the SD card code that the prop uses is rather unique.
The triblade code has some initialisation code that switches between the SD card and the ram, and this might be a problem. The only thing is that I can't find where this code might be being called from. As far as I can trace, it jumps straight into the SD card code before even thinking about talking to the ram. But then again, one would have expected Cluso's triblade code to at least tristate the ram chip out before attempting to talk to the SD card.
Re Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
I was kind of hoping that wasn't the case. But since that is the way to do things, I at least do have some PASM code to flash a led on this particular board:
' **********************************************************************************************************
LedHigh ' turn led on, leave other pins low, assumes setup already done
mov outa,HC138A16_18 ' set data lines to zero, gate high and select A16-18 latch
or outa,#8 ' turn the led bit on 00001000
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
LedHigh_ret ret
Tracing through SD code that doesn't work is going to be very tedious as I don't know what it is supposed to be doing! It may be easier to go back to the Z80 code and build an SD card reader/writer for the N8VEM. Though if it can just get to the stage of selecting the /CS line the rest ought to work.
I think you might be right in that it puts the data into an array, then reads it out somewhere else. Hopefully Cluso will have some ideas. I think he was looking at a complete new set of faster sd code anyway.
www.smarthome.viviti.com/build | | Back to Top | | |
|
Yoda
Registered Member
Date Joined Mar 2009
Total Posts : 61
| Posted 11/2/2009 9:13 AM (GMT -8) | | James,
Exactly what are you trying to do? Are you tyring to eliminate the /CS that Cluso put in or do something else? If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
Dave | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/3/2009 4:29 AM (GMT -8) | | If you are trying to get it to work on the prop board with all the latches you designed, then providing the 4 SD pins are not shared with or on a latch, then the SD routines should just work.
Hi Cluso,
No, unfortunately it doesn't work.
The hardware is very simple. 4 propeller pins to 4 pins on a standard sized SD card. Those pins don't go to anything else so there are no conflicts.
I tried a very simple bit of PASM code just to prove that the wires connecting the propeller to the SD card were connected.
' ********************************************************************************************************
CSLow ' set /CS pin low on the SD card for testing purposes /CS=pin9, CLK=pin14, /DI=Pin15 (and DO=13 HiZ)
SDLowDirect long %00000000_00000000_11000010_00000000 ' direction of pins
mov dira,SDLowDirect ' set pins as outputs
SDLow long %00000000_00000000_00000000_00000000 ' set /CS, DI and Clk low
mov outa,SDLow
CSLow_ret ret
This at least works - the volts go to the card and can be set high or low.
I looked at PropDOS but it appears to use a TV driver rather than VGA. I couldn't find PropCMD.
I guess what I need is to single step the fsrwFemto code one step at a time till it sets /CS low. In the Zicog code is a very useful debug routine;
UART.str (string("Test point"))
So I had a idea of putting that in the fsrw code:
pub mount_explicit(DO, Clk, DI, CS) | startBlk, sectorspercluster, reserved, rootentries, sectors
{{
' Mount a volume. The address passed in is passed along to the block
' layer; see the currently used block layer for documentation. If the
' volume mounts, a 0 is returned, else abort is called.
}}
UART.str (string("mounting SD card "))
But it gave an error in the compiler. So - is there a way of outputting text from within other objects?
Re Yoda
If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
Yes, the idea I'm working on is putting CP/M into one propeller. Latest schematic attached. That means latches for the ram chip and hence slower code, but the upside is lower cost. I'm not 100% sure what Cluso changed in the SD driver code - a clue is a comment "'' RR20090917 _rr001 mount --> mount_explicit " but I'm not sure which bit. Do you have a link for the stock SD code by any chance?
www.smarthome.viviti.com/buildPost Edited (Dr_Acula) : 11/3/2009 12:39:50 PM GMT
File Attachment :
Propeller_v2_rename_as_pdf.txt 125KB (text/plain)This file has been downloaded 8 time(s). | | Back to Top | | |
|
Cluso99
We live onboard
Date Joined Apr 2008
Total Posts : 2276
| Posted 11/3/2009 5:55 AM (GMT -8) | | James: Here is the original PropDos (it is in the obex). Yes it uses the TV. VGA is not that difficult to substitute, just a few calls need to be added to VGA spin and call the object TV. It's probably even easier to use FDX and just add the extra routines - I think I already did that for you with my FDX_rr004.
However, it may be easier in the long run to just run the first bit of the ZiCog spin code to read the SD card. I suspect you are not getting that far but maybe looking at other stuff which is not important. Strip what you dont want and use FDX to give you feedback.
BTW, you will still require my mods for passing the correct pin numbers (mount_explicit). At least you can compare the changes I have done.
I suspect you have a hardware design problem. Do you have 10K pullups on all 4 SD signals? You should have pullups. Have you supplied GND to both pins on the SD (the uSD only has 1)? Have you got DI and DO reversed? DI is not D1 and DO is not D0(zero)? OK
Here is the SD pinout http://pinouts.ru/Memory/sdcard_pinout.shtml
1=/CS, 2=DI, 3&6=GND, 4=3V3, 5=CLK, 7=DO, 8&9=nc
I suspect you may have missed the fact that pin 9 is the short in, then comes pins 1 to 8 ???
Links to other interesting threads: | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/3/2009 3:06 PM (GMT -8) | | Hi Cluso, thanks for the feedback.
Re "Strip what you dont want and use FDX to give you feedback.", what is FDX?
Actually, what I really need is the ability to output a short message back to the terminal for debugging purposes. I guess to write this in basic, one would use PRINT "Got to test point 1". Then in another subroutine, PRINT "Got to test point 2". I'm not sure how to translate that to spin, as the UART object works from the main routine but not from within other objects. So my understanding of the fundamentals of spin is obviosly flawed, as I was expecting spin calls to work from within other spin calls, not just from the 'main' rountine. And I presume that if that is the case, then it wouldn't matter whether you are sending text to the PC terminal or to a VGA or a TV object. Or maybe there is a way around that. (I know now it is not possible to drop in a line of spin code to print a message in the middle of PASM code). I guess I'm a guy who likes to pull things to bits to see how they work!
Re pullups on SD pins, since no other code is using the pins, would they not be left either high or low (never tristate)? Or could there be problems in the brief moment when the propeller restarts and the pins are tristated (and possibly oscillating at 50/60Hz from mains nearby?). I found this www.parallax.com/Portals/0/Downloads/docs/prod/comm/32313-SDCardAdapter-v1.0.pdf which has pullups. Is there a board that plugs into and some simple code to demonstrate how to use an SD card? Indeed, I did a bit of a search of google and found a few promising leads, but is there an example anywhere of a project that uses a standard sized sd card, with some simple code, and some photos of how the pins are connected and a schematic? It might have been a year or two ago before people moved on to the tiny micro sd cards?
I *think* the pinout is correct, ie the first pin is pin 9, then pin 1 etc. But some of the unused pins are floating and maybe need pullups as per that application note above. I'll put in the pullups once I can put a halt after the code that pulls /CS low.
Post edit: This is a darn fast forum. I post something asking for an SD card example, and as soon as I post, the post right above mine has an example! Toby, I see you have not just one, but *two* sd cards. Do you have a schematic for that and maybe a closeup photo of the connections round the sd card? Thanks++ in advance.
www.smarthome.viviti.com/buildPost Edited (Dr_Acula) : 11/3/2009 11:12:39 PM GMT | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/4/2009 2:57 AM (GMT -8) | | I am getting closer to the quest for a debug statement.
As I understand it the Main program calls Objects. These might then call sub-objects The main routine defines objects in the "obj" section. A main routine then can use these objects in the form myobject.xxx. So far, so good and all very simple and objects can be used to encapsulate tasks (like printing to a PC terminal program) with a single command. However, these objects only appear to be able to be called from the main program. You can't call them from within other objects?
So, in BASIC, PRINT "Hello World" might call an object PRINT which sends something to the screen. Or perhaps it is easier to describe in C, which uses the printf(). These are commands that you get used to using and they always work. But not, it appears, in spin. These functions only work from the main program.
BUT, I found a clue!! Inside the fsrwFemto_rr001.spin object are calls to a sub-object called ldr. This is not mentioned anywhere in the obj list of the main program. But it does appear in the object list of the sub fsrw object.
SO - in the obj section of the fsrw object I added the uart object:
obj
'
' The object that provides the block-level access.
'
ldr : "sdspiFemto" ' SPIN program loader and support routines
UART1 : "FullDuplexSerial_rr004" 'FDX v1.2 with mods
And then I added this:
pub startSD(ioControl)
UART1.str (string("Starting SD in fsrwFemto")) ' added code to test where it is up to
return ldr.start(ioControl)
At least this does not give an error any more from the compiler. It doesn't actually print anything from that sub object, but it is one step in the quest for a PRINT "HELLO" from within an object.
So I think I am getting close to building a simple debugging system. Any help would be very much appreciated.
Addit: @Toby, I'm using 512Mb cards. My task list is to 1) print "Hello" from any nominal line in the spin code (not just from the Main spin code), then 2) trace out the code in the fsrw object to find where it sets /CS low, then 3) find where it sets the Clock and /DO lines low, and test those go out to the correct pins on the SD card, and then 4) add in the pullup resistors and then 5) hopefully read or write a file off the SD card.
Addit addit: More info - I think the above test starting two instances of uart means they will clash. (there was one extra bit of code to start the second uart too). Anyway, I'll leave the quest for debugging statements for the moment in search of actual debugging.
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer
r := sd.startSD(@ioControl) 'start the SD routines
calls this
pub startSD(ioControl)
return ldr.start(ioControl)
which calls this
PUB start(ctrlBlk) | t '' Start the I2C I/O driver (standalone)
control := ctrlBlk '' using address of 2 longs for control
stop ' Stop a previous copy
computeTimes
long[control][0] := 0 ' Initialize the control block
long[control] := 0
cog := cognew(@i2cEntryPoint,control) + 1 ' Start a new cog with the I2C driver
return cog > 0 ' Indicate success
and printing out the value it returns a value of -1
I tried making cog a nominal value (eg 5) and changing the last line to 'return cog' and it returned the number. But what does the '> 0' mean? And what does the value of -1 mean - is this a fail on the part of starting the sd card access, or is it a fail on the part of finding a spare cog?
www.smarthome.viviti.com/buildPost Edited (Dr_Acula) : 11/4/2009 11:47:16 AM GMT | | Back to Top | | |
| 848 posts in this thread.
Viewing Page : |
| Forum Information | Currently it is Friday, November 20, 2009 10:39 PM (GMT -8)
There are a total of 393,734 posts in 55,521 threads.
In the last 3 days there were 82 new threads and 700 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09.
55 Guest(s), 2 Registered Member(s) are currently online. Details
Todd Chapman, Sal Ammoniac |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009 |
|
|