Memory {#40004) module question

lfreeze · 2014-09-17 10:43

I have a written a large routine, and the memory map tells me I am running out of space, (760 longs left).
I looked at the propeller memory card (#40004), the application ideas sections says, execute code from external memory
Is it possible to execute blocks/snippets Of code stored on the module? I looked at the related object on the object exchange
and it appears That it may be possible, but I am not sure. My ideal situation would be to call a pub from the memory module
and have the propeller execute the code as it is received from the memory module. If this is possible, does anyone have
a simple example of How This is done, that they are willing to share?

My alternative solution is to simply add another prop and connect it serially. I know this
Would work, but its more expensive and I wouldn't get to play with the memory module.

Thank you in advance for any help.

Larry

Duane Degn · 2014-09-17 11:02

lfreeze wrote: »

I have a written a large routine, and the memory map tells me I am running out of space, (760 longs left).
I looked at the propeller memory card (#40004), the application ideas sections says, “execute code from external memory”
Is it possible to execute blocks/snippets Of code stored on the module?

Larry,

You didn't mention if you're using C or Spin. I think it's easier to run large programs with C but it's also possible to do this with Spin.

Can you give us more information about your project? Sometimes some of the data can be stored externally and pulled in as needed.

One of my large projects is a robot remote with a touch screen. I was running out of memory but I was able to move all the text to the various menus to the SD card which greatly reduced the size of the code on the chip.

There are some threads about how to load Spin methods from a SD card I'll find the links and add them to this thread in a bit.

Duane Degn · 2014-09-17 11:25

Here's a thread about using overlays in Spin. Dave Hein attached code to post #34 which will run a method pulled from a SD card.

There are lots of tricks to making use of the space in the Propeller. Brad's Spin Tool (BST) removes unused methods. localroger has done some cool stuff showing how to use the same object multiple times with a program without having the object take up much space.

If you wanted to post your code, one of us may see ways you reduced its size.

lfreeze · 2014-09-17 14:50

Many Thanks Duane, post 34 looks like a solution, I have an sd card and socket so I will
Be doing some testing. My program is entirely in Spin. I could not attach my file to this posting,I got an error
message "578kb exceeds the limit of 488kb".
The sd card looks like a cheaper Alternative to the memory card or the additional prop.
Larry

lfreeze · 2014-09-18 17:43

No luck with the overlay program, I carefully formatted the sd card then copied the three
Binary files to it. I used windows explorer to verify that they were there. I double checked the sd pin assignments. All looked okay but this is the result I got:

Could not open test1.bin
test1.bin returned a value of 0
Could not open test2.bin
test2.bin returned a value of 0
Could not open test3.bin
test3.bin returned a value of 0

I then tried some old sd card test programs which use the fat0 driver. I could write
And read okay to the card.

I then tried modifying the code using the fat0 driver, I got the same result.

I am stuck, any suggestions would be greatly appreciated.

Larry

Duane Degn · 2014-09-18 18:20

lfreeze wrote: »

I then tried some old sd card test programs which use the fat0 driver. I could write
And read okay to the card.

I then tried modifying the code using the fat0 driver, I got the same result.

Apparently the newer driver performs some additional checks one the SD card and if it sees a problem it won't mount the card.

I've had to reformat several of my SD cards before they would work properly with the new driver. I had to use the long formatting method, if I tried using "quick format" the card still wouldn't work with the new driver.

In other words it's a feature not a bug (or at least that's what I was told).

lfreeze · 2014-09-19 08:24

Thank you for the suggestion, but Still no luck. I did the slow format and it’s really slow, took about 40 minutes. I thought I would try some simple testing, writing and reading some text files using the fsrw object. I downloaded the object and attempted to use it with the test.spin program that was Part of the download. It would not compile, the “sysdep” object could not be found.

I can still write and read test data using fat0 (kyes object) If it wasn’t for bad luck with this project, I wouldn’t have any.

My next effort is find another sd card and give it a try.

I looked at your link of projects, very very impressive, after looking at your accomplishments, I considered throwing away all my propeller stuff and taking up golf

Larry

lfreeze · 2014-09-19 15:04

Still no luck
I tried three separate cards. I formatted each card again using the slow method. Each card worked okay on simple
write read tests using the"SD-MMC_FATEngine.spin” driver. Each card failed when I ran the overlay.spin program using the fsrw driver.

I am now formatting the card at 16kb to see if that will help.

I did find one error, I was reading safe_spi_c3.spin and on line 92 I found this
Statement:

{{
This is a compatibility wrapper, and requires that the pins be
both consecutive, and in the order DO CLK DI CS.
}}
return start_explicit( basepin, basepin+1, basepin+2, basepin+3 )

I had this backward in my program, I corrected it, but still no luck.

Larry

msrobots · 2014-09-19 16:03

@Larry,

I noticed you are using two different drivers. Kyes Fat_Engine and FSRW.

Kyes Fat_Engine works fine for SD cards using Fat16 and Fat32. Depending on your Version of FSRW you might have trouble to use SD cards > 2GigaByte. The older Versions of FSRW do not support SD cards > 2GigaByte.

Since you wrote about not having the sysdep object I guess you have just FSRW included in Dave Hein's zip.

So download FSRW (2.6?) from the obex.

sysdep is the object to adjust pin settings to met your board design.

run the demos to verify FSRW can access your SD cards.

REPLACE fsrw in Daves zip with the newer version of fsrw.

try again.

Kye's Fat_Engine is way more sophisticated as FSRW. It supports Sub directories and a lot of other things FSRW does NOT support.

But it is also WAY slower. @Lonesock and @Rockiki(?) did a real great job with a fast SD card access without directory support.

just my 2 cents

Enjoy

Mike

lfreeze · 2014-09-20 10:29

Thanks for the suggestion. I downloaded the “fsrw.spin 1.6” object. I modified “fsrw_speed”
to work with fullduplexserial. I wired my board as described in “sdspiqasm” using the 20k pullup
resistors described and making sure they were on all six pins. I tried running “fsrw_speed” and got this:

Mounting.
Returned from start
-13

I did note that the fsrw object says “ This object provides FAT16 file read/write access on a block device”.
As suggested by others, I was using a 2GB sd card, but it was formatted At 32kb. The problem now became,
windows would not allow formatting a 2GB card at 16kb. I took an 8GB card and formatted it for 16kb.
I tried running “fsrw_speed” again and Got the same results. In order to validate my hardware I wrote, then read
some test data to the sd card using the "SD-MMC_FATEngine.spin" driver. The tests were okay.

Here is fsrw_speed program modified for full duplex serial that I used:

CON
        _clkmode        = xtal1 + pll16x
        _xinfreq        = 5_000_000
obj
   debug: "fullduplexserial"
   sdfat: "fsrw"
var
   byte tbuf[20]
   byte bigbuf[8192]
pub go | x

   debug.start(31,30,0000,19200)
   
   x := \start
   debug.str(string("Returned from start", 13))
   debug.dec(x)
   debug.tx(13)
pub start | r, sta, bytes
   'debug.start(12)
   debug.str(string("Mounting.", 13))        
   sdfat.mount(0)                          'this sets pin 0 as the basepin' fsrw sets the other pins in order starting at 0
   debug.str(string("Mounted.", 13))
   debug.str(string("Dir: ", 13))
   sdfat.opendir
   repeat while 0 == sdfat.nextfile(@tbuf)
      debug.str(@tbuf)
      debug.tx(13)
   debug.str(string("That's the dir", 13))
   debug.tx(13)
   sta := cnt
   r := sdfat.popen(string("speed.txt"), "w")
   repeat 256
      sdfat.pwrite(@bigbuf, 8192)
   sdfat.pclose
   r := cnt - sta
   debug.str(string("Writing 2M took "))
   debug.dec(r)
   debug.tx(13)
   sta := cnt
   r := sdfat.popen(string("speed.txt"), "r")
   repeat 256
      sdfat.pread(@bigbuf, 8192)
   sdfat.pclose
   r := cnt - sta
   debug.str(string("Reading 2M took "))
   debug.dec(r)
   debug.tx(13)
   debug.str(string("That's, all, folks! 3", 13))

I have tried everything, I would really welcome any additional suggestion

Larry

jazzed · 2014-09-20 13:46

Hi.

This may not make any difference in your case, but I've had all kinds of problems with the Quickstart + Memory board that were solved by using an external power brick. It seems like the USB +5V current is not really enough sometimes, and the Quickstart doesn't have the best PCB power layout with 0.01" traces. One of the USB ports on my Mac Mini has gone bad by using boards that are too power hungry. Sometimes my Windows 7 PC will simply reset if I plug in a hungry USB board that doesn't have an external power supply.

msrobots · 2014-09-20 23:33

lfreeze wrote: »

Thanks for the suggestion. I downloaded the “fsrw.spin 1.6” object. I modified “fsrw_speed”
to work with fullduplexserial. I wired my board as described in “sdspiqasm” using the 20k pullup
resistors described and making sure they were on all six pins. I tried running “fsrw_speed” and got this:

Mounting.
Returned from start
-13

I did note that the fsrw object says “ This object provides FAT16 file read/write access on a block device”.
As suggested by others, I was using a 2GB sd card, but it was formatted At 32kb. The problem now became,
windows would not allow formatting a 2GB card at 16kb. I took an 8GB card and formatted it for 16kb.
I tried running “fsrw_speed” again and Got the same results. In order to validate my hardware I wrote, then read
some test data to the sd card using the "SD-MMC_FATEngine.spin" driver. The tests were okay.
...

Larry

First of all you need Version 2.6 not 1.6(?) of FSRW.

Second: I am confused by 'sdspiqasm' - what is it and where it comes from?

FSRW and demo should only use 'sysdep' and 'save_spi'

else

I can not find error code -13 in FSRW. Is it maybe -23? That would be 'NO TWO FATS'.

Reading your post carefully I guess that you changed the default cluster size of your SD cards while formatting in windows?

You should not do things like that at all.

SD cards up to 2 GB use FAT16 file system by default. Bigger ones need FAT32 also by default, when you buy them.

The difference is how the content of the card is accessed by the driver. FAT16 addresses BYTES. So with a word pointer you end up at 2 GB and then is end.
SD cards > 2 GB address the content by SECTORS of 512 bytes. Thus the same word pointer now reaches up to a Terrabyte.

BOTH - Fat_Engine and FSRW 2.6 can read SD cards > 2 GB (SDHC) without problem as they come from any store without any reformatting.

The cluster size should be 32K (is default)

@jazzed has another point.

Feeding the board thru USB has many problems. One is that you can not really switch your board OFF.

So the SD card still is active, and stuck in the last sequence. While working with my 4 SD card RAISD board I often struggled with this.

You rerun your program, and the program is even OK, but it does not run. The SD card got stuck. (not resetting , since powered)

Solution:

Either remove power for a minute before your test run or remove the SD card and put it back. I learned that the hard way. And removing power includes removing USB connection.

Them SD cards are finicky. They need very low power to stay 'alive' in their state machine. Way less as if active and reading or writing.

Take a new not mangled with SD card. Scandisc or so. size does not matter.

Get FSRW running as described in download from obex, Look at the html files.

Since Kye's Fat_Engine works your board should be OK.

well - some suggestions, at least.

Enjoy!

Mike

lfreeze · 2014-09-21 15:13

Thank you for your last suggestions. They sent me in the right direction.

I had downloaded so many fsrw files that it became
Unmanageable. I erased everything I had downloaded and started again.

I downloaded fsrw version 2.6 and its associated files. I had a minor glitch in that
Fsrw.spin would not compile. It was looking for an object named
“sysdep.spin” and not finding it. I found a file named “sysdep_demo_ser.spin” which
Was part of fsrw download. I renamed it “sysdep.spin”

To my amazement I was able to successfully run test.spin (part of the download) and all was okay.

I then copied fsrw version 2.6 and its associated files to the folder containing the new download of overlay.spin.
I opened and saved a binary file of test1,test2, and test3 to the sd
Card. I installed the sd card on my board and tried running overlay.spin. The
Result was the same:

test1.bin returned a value of 0
Could not open test2.bin
test2.bin returned a value of 0
Could not open test3.bin
test3.bin returned a value of 0
Could not open test1.bin

I visited my local walmart to purchase some new 2gb sd cards, unfortunately they
Were out of stock. So I am on hold until I can acquire some new sd cards.
I will post when I have the results with the new sd card

Larry

Memory {#40004) module question

Comments