That's not the issue in my case.
Without knowing the intricacies of email handling, I wonder if it has to do with SSL settings/ports -
Time Warner Cable does not support encrypted connections yet!!!
I don't think that's the case
I'm on Time Warner, using Firefox (and NoScript), and had no problems at all.
Ordered two and they've already shipped.
I used my Google Chrome notebook to order. All I had to do was open a new account as evidently it doesn't know the old account from the original website. I didn't have any problems ordering my boards. In fact I received them today.
For what it's worth, I registered with my gmail account. (My old registration didn't work, and it didn't even work on the non-beta site anymore.. I had been using my corporate (work) email account for that, but when I re-registered I used a gmail account and had no trouble).
I got 5 emails this morning from the Beta Parallax registration process -
In this example, it appears they were hung up on the Parallax server since it was received from 67.104.29.59 (Parallax) on Monday when it was generated on Saturday.
Received: from [67.104.29.59] ([67.104.29.59:38947] helo=smtp-01.parallaxinc.com)
by hrndva-iedge05.mail.rr.com (envelope-from <no-reply-ecmbeta@parallax.com>)
(ecelerity 2.2.3.46 r()) with ESMTP
id 58/73-29229-F8652125; Mon, 19 Aug 2013 17:31:59 +0000
Received: from rsvl-web-06.parallax.com (unknown [67.104.29.57])
by smtp-01.parallaxinc.com (Postfix) with ESMTP id 1B00864266B
for <######@twc.com>; Sat, 17 Aug 2013 05:55:38 -0700 (PDT)
Received: by rsvl-web-06.parallax.com (Postfix, from userid 33)
id F17671C08F7; Sat, 17 Aug 2013 05:55:37 -0700 (PDT)
To: ######@twc.com
Subject: Account details for ron at Parallax E-Home (Beta)
X-PHP-Originating-Script: 33:htmlmail.mail.inc
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Sender: no-reply-ecmbeta@parallax.com
From: "Parallax E-Home (Beta)" <no-reply-ecmbeta@parallax.com>
Message-Id: <20130817125537.F17671C08F7@rsvl-web-06.parallax.com>
Date: Sat, 17 Aug 2013 05:55:37 -0700 (PDT)
X-Brightmail-Tracker: AAAAAQAAAlk=
Good news. The Propeller Memory Card is back on the Daily Deal today and this time I was able to change my password and log in to buy one. Bad news is that I was also able to order a Propeller Mini even though I'm pretty sure they're out-of-stock.
David,
Your work is not forgotten. The Propeller Memory Card will have SimpleIDE support, but it was better to release it now without it than to delay the memory card while the SimpleIDE team was working to release version 0.9.40. Also, I implemented the changes mentioned in this post, so it might have broken the driver you posted.
Before getting it officially listed as a board type in SimpleIDE, I can add your C code to the product downloads section, or I can add a link to a forum post or object exchange entry if you want to be able to update it quickly. I can send you one of the final prototypes, essentially indistinguishable from the production units, if you would like to verify it with the new pinout.
David Carrier
Parallax Inc.
Hi David,
I got the Propeller Memory Card that I ordered when they were being offered at a discount but I haven't been able to get it to work with my PropGCC cache driver yet. I admit that I only made a brief attempt but I'm surprised that I'm having trouble. It looks like the only thing you changed from the prototype card you sent me that would affect the flash and SRAM was to move CLK to pin 7. I've changed that in my driver but the new module still doesn't work. Is there anything else I need to keep in mind when using the production board instead of the prototype? I'm not trying to use the SD card yet so those changes shouldn't be causing me trouble.
I got the Propeller Memory Card that I ordered when they were being offered at a discount but I haven't been able to get it to work with my PropGCC cache driver yet. I admit that I only made a brief attempt but I'm surprised that I'm having trouble. It looks like the only thing you changed from the prototype card you sent me that would affect the flash and SRAM was to move CLK to pin 7. I've changed that in my driver but the new module still doesn't work. Is there anything else I need to keep in mind when using the production board instead of the prototype? I'm not trying to use the SD card yet so those changes shouldn't be causing me trouble.
Thanks,
David
Not that there was really any question about this but I've run the demo Spin code that goes with the Propeller Memory Card and that seems to work fine so I know the hardware is working.
David,
I tested the prototypes of the current layout by plugging it into a breadboard and individually jumpering the pins to the Propeller in the previous order and running your example code. I'd recommend to try that out, run it, swap P4 and P7, and try getting the code working again.
David,
I tested the prototypes of the current layout by plugging it into a breadboard and individually jumpering the pins to the Propeller in the previous order and running your example code. I'd recommend to try that out, run it, swap P4 and P7, and try getting the code working again.
— David Carrier
Parallax Inc.
Thanks David. I'll try your suggestion later. I guess there must be some pin dependency in my driver that interferes with moving CLK to pin 7. I'll get that fixed and send you the revised driver.
Thanks David. I'll try your suggestion later. I guess there must be some pin dependency in my driver that interferes with moving CLK to pin 7. I'll get that fixed and send you the revised driver.
I figured out what was wrong without having to do your breadboard experiment. The problem is that my driver checks the JEDEC ID during driver initialization and the ID of the W25Q32DW is different than the ID of the W25Q32FV in SPI mode. For some reason, the FV chips report a different JEDEC ID when in SQI mode than when in SPI mode. I'll have to make my JEDEC ID check more flexible. Do all of the production boards use W25Q32DW chips?
I've attached a driver that will work with either the prototype or production Propeller Memory Card modules. Use the "pmc.cfg" configuration file for the production boards and the "pmc-proto.cfg" configuration file for prototype boards. I've included an already built driver named winbond_sqi_flash_sram_xcache.dat" and the sources required to build it. These configuration files work with the QuickStart+HumanInterfaceBoard+PropellerMemoryCard combo or the DemoBoard+PropellerMemoryCard combo.
For example, to load a program using a production module:
Got my card yesterday (discount and the daily deal, woo hoo). Tried it immediately on the Demo Board, running the demo program and accompanying SPI driver object from Parallax.
A couple of glitches - but no show stoppers:
The demo program was starting too fast for me to switch over from Prop tool to the Serial Terminal, so I put a couple of "CharIn" statements at the beginning of the program to give me a chance to start the terminal program before output started.
Also, for some reason, it tells me the flash has 0 blocks, but I know that's not true (the flash is working). Must be a glitch.
The rest of the demo program works fine, storing and retrieving from both flash and SRAM.
A little help for the clueless - since the flash, SRAM and SD card all multiplex on the same pins, will a special object/driver be necessary to use all three? For instance, if I start one of the existing SD card objects out there, won't the pins collide with the flash/SRAM object on operations?
Also, for some reason, it tells me the flash has 0 blocks, but I know that's not true (the flash is working).
I got mine the other day and was trying it out today. I also wondered about this and was trying to figure out how it knows how many blocks. I'm wondering if it has to do with the JEDEC number? I don't understand enough about these type of devices.... yet :-)
I got mine the other day and was trying it out today. I also wondered about this and was trying to figure out how it knows how many blocks. I'm wondering if it has to do with the JEDEC number? I don't understand enough about these type of devices.... yet :-)
Yes, the JEDEC ID will tell you the capacity of the card. Check the data sheet. The last of the three bytes is a size code. Looks like 0x14 for 8 Mb, 0x15 for 16 Mb, and 0x16 for 32 Mb (what we have on the Propeller Memory Card).
Also, for some reason, it tells me the flash has 0 blocks, but I know that's not true (the flash is working). Must be a glitch.
The reason that it displays 0 blocks of flash is because of a small bug in the demo code...
The existing code for this condition will result in TRUE or FALSE (actually, 1 or -1) and that is being put into the Blocks variable, in this line:
if Blocks := Memory.Start(spiClk, spiDI, spiDO, spiCSflsh, spiCSsram, spiWP, spiHOLD) < 1
To make the Blocks variable equal the number of memory blocks, a couple of parenthesis are needed:
if [COLOR=#ff0000][B]([/B][/COLOR]Blocks := Memory.Start(spiClk, spiDI, spiDO, spiCSflsh, spiCSsram, spiWP, spiHOLD)[COLOR=#ff0000][B])[/B][/COLOR] < 1
since the flash, SRAM and SD card all multiplex on the same pins, will a special object/driver be necessary to use all three? For instance, if I start one of the existing SD card objects out there, won't the pins collide with the flash/SRAM object on operations?
This will depend on the SD card object. If the object releases the pins (sets them low and as inputs) once it's finished, it shouldn't cause a problem. It shouldn't be hard to add a method to most objects to release the pins if the object doesn't already do so.
This will depend on the SD card object. If the object releases the pins (sets them low and as inputs) once it's finished, it shouldn't cause a problem. It shouldn't be hard to add a method to most objects to release the pins if the object doesn't already do so.
I just checked out mailbox. No Memory Card yet.
So do you know if fsrw2.6 releases those pins as you suggest?
I made the modification mentioned above by dgately. That fixed the number of blocks reporting. Thanks!
I also played around adding FSRW 2.6 to the demo. Attached is a working demo. It gives you the option of getting a directory of the SD card or writing "Hello World!" to the SD card. Seems to work ok with the memory chips. The FSRW uses its own "SafeSPI" driver along with the "SPI Memory Driver" for the flash and static ram memory chips.
I also added a method I found somewhere called "DecN" to the Parallax Serial Terminal object and renamed it so as not to confuse.
Just so that I don't get any false credit here- some of the cool snippets of code for the SD Card where contributed by other members here.
Let me know if I made any mistakes.
Edit: Modified program to exit if no SD Card present or doesn't mount.
Comments
I don't think that's the case
I'm on Time Warner, using Firefox (and NoScript), and had no problems at all.
Ordered two and they've already shipped.
Thanks for the feedback. It is curious why the verification email worked with Gmail but not with the two Time Warner Accounts I tried.
-Tor
In this example, it appears they were hung up on the Parallax server since it was received from 67.104.29.59 (Parallax) on Monday when it was generated on Saturday.
WHOIS by IP address
I got the Propeller Memory Card that I ordered when they were being offered at a discount but I haven't been able to get it to work with my PropGCC cache driver yet. I admit that I only made a brief attempt but I'm surprised that I'm having trouble. It looks like the only thing you changed from the prototype card you sent me that would affect the flash and SRAM was to move CLK to pin 7. I've changed that in my driver but the new module still doesn't work. Is there anything else I need to keep in mind when using the production board instead of the prototype? I'm not trying to use the SD card yet so those changes shouldn't be causing me trouble.
Thanks,
David
I tested the prototypes of the current layout by plugging it into a breadboard and individually jumpering the pins to the Propeller in the previous order and running your example code. I'd recommend to try that out, run it, swap P4 and P7, and try getting the code working again.
— David Carrier
Parallax Inc.
Thanks,
David
For example, to load a program using a production module:
To load a program using a prototype module:
pmc-cache.zip
A couple of glitches - but no show stoppers:
The demo program was starting too fast for me to switch over from Prop tool to the Serial Terminal, so I put a couple of "CharIn" statements at the beginning of the program to give me a chance to start the terminal program before output started.
Also, for some reason, it tells me the flash has 0 blocks, but I know that's not true (the flash is working). Must be a glitch.
The rest of the demo program works fine, storing and retrieving from both flash and SRAM.
A little help for the clueless - since the flash, SRAM and SD card all multiplex on the same pins, will a special object/driver be necessary to use all three? For instance, if I start one of the existing SD card objects out there, won't the pins collide with the flash/SRAM object on operations?
- Earl
I got mine the other day and was trying it out today. I also wondered about this and was trying to figure out how it knows how many blocks. I'm wondering if it has to do with the JEDEC number? I don't understand enough about these type of devices.... yet :-)
The reason that it displays 0 blocks of flash is because of a small bug in the demo code...
dgately
This will depend on the SD card object. If the object releases the pins (sets them low and as inputs) once it's finished, it shouldn't cause a problem. It shouldn't be hard to add a method to most objects to release the pins if the object doesn't already do so.
I just checked out mailbox. No Memory Card yet.
So do you know if fsrw2.6 releases those pins as you suggest?
I don't know myself. I thought Kye mentioned his SD driver did release the pins.
I'll look into this more when I receive my cards.
I also played around adding FSRW 2.6 to the demo. Attached is a working demo. It gives you the option of getting a directory of the SD card or writing "Hello World!" to the SD card. Seems to work ok with the memory chips. The FSRW uses its own "SafeSPI" driver along with the "SPI Memory Driver" for the flash and static ram memory chips.
I also added a method I found somewhere called "DecN" to the Parallax Serial Terminal object and renamed it so as not to confuse.
Just so that I don't get any false credit here- some of the cool snippets of code for the SD Card where contributed by other members here.
Let me know if I made any mistakes.
Edit: Modified program to exit if no SD Card present or doesn't mount.