 |
|
 |
| 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 10/25/2009 2:35 AM (GMT -8) |   | Re Cluso The last few times I compiled I left the 8080 option defined. So now you have to compile using bst. Also, you seem to be using an older version (not rr126) as you have floppy support enabled. We are past that so that is why it probably didnt find drive B in floppy format. You should get a CPM message saying 8HD meaning 8 hard disks.
Yes I've just taken the entire package of files Cluso gave me and stripped it back to just the necessary ones, put back in the right #defines and made sure the right files are on the sd card. Also edited the BST.BAT file, and copied the necessary .dll files over for a minimal teraterm.
It took about half an hour and you need to know the ins and outs of the code. There is quite a lot of code accumulating that is legacy code that adds the complexity of multiple nested #ifdefs. These ifdefs are starting to become a language in their own right, but they are not really structured, ie no indents and it is hard to match up the endifs with their corresponding ifdef. Also there are many #else commands that made sense when there were just two board options, but with the ramblade there will be three (and with a board I'm working on there will be four) so they all need to change from #else to #elseifdef. I don't know if there maybe is a way of adding to the #ifdef syntax in some way. I was wondering about the option of #ifdef mydefine and then #endif mydefine. That would be backwards compatible.
Bottom line is it probably is time to rerelease a package with everything in one file. All the spin code. All the working hard drive images (but not necessarily the ones we needed to get here, eg the floppy ones). Plus BST and ? a terminal program. I put one together and minus the hard drive images it is only 400k.
Re the comments on the schematic and board for just blade 2, that will almost certainly become unnecessary once the tiny ramblade comes out.
Hmm, Cluso, I just had a thought. Since many of the parts in the ramblade are a bit unusual and since shipping is so high for one chip and since you are throwing together a very attractive package (soldering up the tiny chips), I wonder about adding another $10 and including a micro sd card with all the software on it? The hard drive images, plus a folder you copy back onto the PC with all the spin code and BST etc? Ok, it will become obsolete over time, but at least that will be a package that will work out of the box just by plugging it into a demo board, and then users can see it working quickly and then once it works they can go online and get the latest version?
www.smarthome.viviti.com/build | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 10/27/2009 5:11 AM (GMT -8) | | With much fanfare and excitement, the Southern Hemisphere Zicog/Tribade Conference (v3) was held earlier today. Apologies were noted from heater...
Cluso is getting very close to releasing the ramblade. One option available will be a presoldered version including a micro sd card with all the necessary software on the card. The single package version has got me thinking about this in a different way. Here we have a tiny CP/M computer all in one package that fits into a standard prop demo board.
But - it can fit into other boards too, as long as those boards copy the prop demo board standard. We discussed the software standards one could have. From the CP/M boards point of view, it can have 256 software I/O ports, eg OUT n,byte or IN n,byte where n is the port number. From the host boards point of view, each of these can be trapped in some spin code. From time to time, the CP/M board would ask for a list of changed I/O ports and those are sent over via a 2 wire interface.
But the possibilities for the host board are endless. It can have vga, keyboard, LCD display, audio and some analog I/O and relays and optocoupled inputs. It can also talk to three different types of wireless comms - RS232 modules (Hope/Yishi etc), raw RF modules with some filtering in spin, and even direct RF at a few megahertz with the appropriate antenna (?a loop antenna). It could talk to the 4dsystems serial camera module and capture pictures. It can use the nifty FSK object to send data via audio or a phone line or a handheld CB radio. Spin code in the host will pre-process the data to a format that CP/M likes, which is generally of the form of two bytes - one is a 'flag' byte to say a byte has arrived, and the other is the actual byte.
With radio and video capture, plus the multiple languages available in CP/M, it ought to be possible to start building intelligent networks, eg mobile robots that rove around taking pictures and sharing the information. We also discussed the ability to update software via wireless, even the protocols one could use to emulate a simple bittorrent upgrade system via wireless with multiple nodes.
Now the ramblade design has been fixed, I'm going to start thinking about the parameters for a host board. All very exciting!
www.smarthome.viviti.com/build | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/1/2009 4:17 AM (GMT -8) | | @Cluso, would you mind answering a technical question please?
I'm trying to trace program execution. I get this
UART.str (string("Starting Hdisks... "))
crlf
blockno := 0
count := 8192
FindSDblock
then
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer
r := sd.startSD(@ioControl) 'start the SD routines
UART.str(string("SD started..."))
CheckError(not r)
r := sd.mount_explicit(spiDO,spiClk,spiDI,spiCS) 'mount the SD
UART.str(string("SD mounted..."))
CheckError(r)
Which prints "SD started..." on the screen and then hangs.
I've change the pins so my pins should be correct.
spiDO = 13
spiClk = 14
spiDI = 15
spiCS = 9
I think it then jumps to sd.mount_explicit which is;
pub mount_explicit(DO, Clk, DI, CS) | startBlk, sectorspercluster, reserved, rootentries, sectors
By this time, should /CS be low?
I'm going back to 'r := sd.startSD(@ioControl) 'start the SD routines'
Does this set /CS low? What is @iocontrol?
I'm trying to work at a very simple level - where is the code that sets /CS low for the first time?
Help would be most appreciated as I'm getting lost in amongst the code.
www.smarthome.viviti.com/build | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/1/2009 7:17 PM (GMT -8) | | | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 11/2/2009 3:31 AM (GMT -8) | | Hi again Cluso. The quest for the /CS low code continues.
But now I'm really stuck. To be totally frank, Spin has me completely confused. I see code like this:
if (brlong(@buf+$36) == constant("F" + ("A" << 8) + ("T" << 16) + ("1" << 24)))
startBlk := 0
To someone used to coding basic, I think this is something like
if brlong$="FAT1" then startBlk=0
But it seems a hard way to do things for a high level language. Everything has to be grouped into groups of 4 bytes and it uses a lot more characters to describe what you want to do. My personal opinion is that if it is going to be this hard to do strings, may as well do them in assembly. I've written string compare routines in Z80 assembly that are easier to understand than this.
Anyway, gripe over. My goal is to find the code that makes the CS line low. Then I can put a halt after that line and test if indeed it went low.
The routine
pub mount_explicit(DO, Clk, DI, CS)
calls this
if initSDCard(DO, Clk, DI, CS)
abort -string("InitSDCard mount")
I think that then jumps to this
pub initSDCard(DO, Clk, DI, CS)
return ldr.initSDCard(DO, Clk, DI, CS)
Which then jumps out of the fsrwfemto_rr001.spin object and goes to the sdspifemto.spin object. Which has the alias of ldr in the main spin program...
Which takes us to this code also called initSDCard()
PUB initSDCard(DO,Clk,DI,CS) | t '' Initialize SD card access
t := cnt
repeat while long[control][0] & ioTestRdy ' Wait for previous I/O to finish
long[control] := 0
long[control][0] := ioSpiInit << 24 | DO << 18 | Clk << 12 | DI << 6 | CS
repeat while long[control][0] & ioTestRdy ' Wait for this to finish
return (long[control][0] & ioTestErr) <> 0 ' Return any error code
But I can't see anywhere there that outputs a high or a low to a pin.
So, rather than ask how to do this (part of this is a learning exercise!), can I ask whether there is a way I can add in little bits of code that send debug messages back to the PC?
eg, in the main program, one could add
UART.str(string("Test point 1"))
Is it possible to add these sorts of debug messages in other (what I would call subroutines, but I think are called objects), eg in sdspifemto.spin? And, what would be even more useful, in the middle of PASM code in some way?
Or maybe another option is a completely new program, stripped right back to the bare essentials that opens a file on an SD card, writes"A" to the file and closes it. Just to test the card actually works.
Help would be most appreciated!
www.smarthome.viviti.com/buildPost Edited (Dr_Acula) : 11/2/2009 11:38:20 AM GMT | | Back to Top | | |
| 849 posts in this thread.
Viewing Page : |
| Forum Information | Currently it is Friday, November 20, 2009 10:59 PM (GMT -8)
There are a total of 393,737 posts in 55,521 threads.
In the last 3 days there were 82 new threads and 702 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09.
54 Guest(s), 6 Registered Member(s) are currently online. Details
Peter Verkaik, BradC, Harley, Chris Savage (Parallax), Rich_W8VK, potatohead |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009 |
|
|