SD Card shared amongst cogs? Anybody tried? Ideas?
Stephen Moraco
Posts: 303
So, creative me wants to move the HTTP listener to it's own cog and keep the main free for overall system function... and have the listener cog now more responsive to the web connection as well. Now this is only fun because as soon as one does this there is no longer any communication to the SD Card...
My technique (now seen as flawed) is to split out the listening/handling loop into it's own PRI then start it as an entry point with a cognew command like:
My symptom is that the "GET Response with file: INDEX.HTM" happens but not a thing after that.
(Yes, m_nPort0Cog does foretell the use of m_nPort1Cog for another listener... etc. If I can get this all working... That's why I'm passing the lock variable for the W5100 chip...)
Notice that this code is in the same file as it was before the split into it own method. So I didn't forsee the inability to access the SD Card as an issue of VAR/DAT Singleton stuff. But now that it is not working...
So, I'm looking for opinions/thoughts as to the failure-cause....
Any of you have ideas as to what's happening? Have you tried this yourself?
Thanks for your help with this
-Stephen, KZ0Q
----
INTERNET - Spinneret -- PROP, sensors -- Spinneret -cable- Spinneret - PROP, radios, sensors (Interesting?)
My technique (now seen as flawed) is to split out the listening/handling loop into it's own PRI then start it as an entry point with a cognew command like:
' start the web-server port-listener process (logicalSocket-0 on port 80) m_nPort0Cog := cognew(HTTPSocketListener(0, 80, m_lkW5100), @stkPort0)
My symptom is that the "GET Response with file: INDEX.HTM" happens but not a thing after that.
(Yes, m_nPort0Cog does foretell the use of m_nPort1Cog for another listener... etc. If I can get this all working... That's why I'm passing the lock variable for the W5100 chip...)
Notice that this code is in the same file as it was before the split into it own method. So I didn't forsee the inability to access the SD Card as an issue of VAR/DAT Singleton stuff. But now that it is not working...
So, I'm looking for opinions/thoughts as to the failure-cause....
Any of you have ideas as to what's happening? Have you tried this yourself?
Thanks for your help with this
-Stephen, KZ0Q
----
INTERNET - Spinneret -- PROP, sensors -- Spinneret -cable- Spinneret - PROP, radios, sensors (Interesting?)
Comments
a) I'm using safe_spi as SPI driver. This driver is singelton by itself.
b) Above safe_spi, I have written an abstraction level handling the datatypes I need in a database fashion. This object is also singelton, and make use of a lock insuring no critical parts are invoked twice simultaneous, e.g. all method calls to safe_spi are executed sequentially, never in parallel.
What object(s) are you using to access your SD card? If it is multi-thread safe (MT safe, as described above), there should be no problems, but if not MT safe, you must use locks to serialize all calls to it.
I'm using the objects from the spinneret git server. And nope, they are not singletons (using VAR and no locks) if I remember correctly. Thanks for letting me know that it is what I thought it should be... and for sharing your encouraging success!
Hey Spinneret contributors,
any reason we shouldn't convert the SD objects for Spinneret into Singleton-patterned objects?
-Stephen, KZ0Q
You don't HAVE to make the driver singelton to use it MT-safely. It's just an easy way doing it. Sometimes it's not possible, e.g. if you have several statefull backend devices. Still, you can use it MT-safely by a client/server model. Write a server owning the device driver, handling all I/O to it. Then write a small singelton API to communication with your sever via the shared hub memory. This way you can have many clients using your resource, but still only one instance of the drive driver, owned by your server.
But yes, most often a single simple singelton device driver in the first place is the way to go.
Oops, my bad. The Spinneret code repository is in SVN not GIT. I meant i'm using the versioned
code from our SVN repository. In the case of the SD related code I'm using it unmodified.
-Stephen, KZ0Q
As far as I can see, the SVN repository "spinneret-web-server" do not contain any code at all handling SD Card, so I still have no clue about what unmodified code you are using.
Start the Propeller Tool IDE, load your main program, press F8 to get Object Info, take a screen copy and attach the content of that window here, please. Sorry for being such a ... but this is the third time I've asked what objects you are using accessing the SD Card, and I still got no answer nor clue. :cool:
Kuisma, again I apologize... I'll tell you what code I'm using in this post... it was not my intent to hide, it just didn't matter to me since I've converted many objects to singleton patterns.... I didn't mean to frustrate you, ok?
I'm laughing at myself when you posted this reply because I can see how I got to being confused by whats in SVN or not.
My projects are all in GIT (yes, just another version control system and the, what, 8th or 9th i've used in my career so far...) and upstream from me is the SVN repo. for Spinneret. I started my project before the SVN repo was created [see my earlier post identifying troubles due to no single source for spinneret code...]
So I ended up with a local copy of all the latest files used in all the examples for Spinneret projects at the time I gathered them from the Forum.
As a starting position, I used the latest of all the files used in examples (the best/most complete for each device on the Spinneret) and checked for latest in OBEX where there was overlap. It's during this process that I ended up with:
SD2.0 FATEngine Wrapper (SD2.0_FATWrapper.spin)
by Roy Eltham
and
SD2.0 File Allocation Table Engine (SD2.0_FATEngine.spin)
by Kwabena W. Agyeman
... These are great working solutions but are not structured for multiple cog use. And I hadn't forseen that I needed this structuring. Additionally, I'm just getting to the point where i have enough of my formal application running that I now have more than one cog that cares to access the SD card. So... this all make better sense now?
Now, after all of this I'm left with two needs/questions: (1) are the spinneret contributors going to come down to choosing one driver-set for the SD Card and will it then appear in the SVN repo,? and (2) which are you using since you are already past the issues I'm facing?
-Stephen, KZ0Q
Ah, ok. Those are not possible to use multiple object multiple cogs as is.
You can solve this in one of several ways:
a) Talk to Kwabena about implementing it.
b) Branch the code and implement it yourself.
c) Talk to Roy about extending his wrapper to a two part client/server as described in post #4 above.
d) Write a general "mt-safe" wrapper for wrapping any non-singelton object using the same model as in #4 as well.
SD Card is not in any way unique to the Spinenret, and there are already several objects out there for both low level I/O and file systems, so I guess this is the wrong forum.
I'm using safe_spi (from fsrw.sf.net) for block level access of the SD Card. This driver is already singelton as is and I'm making it MT safe by using locks in my object implementing the abstract data types used, as I described in post #2 above. I.e. I'm not using FAT or any other file system.