Pinguino Forum

Full Version: PIC32 PINGUIONO's and SD
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
Yayy - good to hear about a work-around!

rtcc or something it pulls in has to be the issue, then, wow.


Yes it worked.

I guess before I move on, I would like to, not only fix the code so that it simply runs, but to make the code encompass all the great things I have learned getting here and not necessarily SD related.

So, here goes my list:
1. i2c.c address the i=0 addition I suggest here
2. spi.c address it to add MICRO support and to include the missing {} I suggest here
3. sdmmc.c set and use SDCS for MICRO as pin 40, not 41, and SDCS as 8 for OTG so we don't have to send the mount() function a number.
4. sdmmc.c remove READ_LED and WRITE_LED from MICRO condition so that the yellow LED is not monopolized by SD routines
5. diskio.c edits as above in post #70
6. AND for when I add my GPS chip and have an accurate time, I want to be able to send that dateandtime to the get_fattime() function.

With respect to 6, in VB6 we could declare function input variables as optional. That way, 99% of the time you could call a function without passing the optional variable but that 1% of the time you want to send the GPSdateandtime you could. There has to be a way of doing that here too, is it the ... feature I have noticed? Or we just use a new global variable but get_fattime() would have to use it.

Did I miss anything?

Hopefully one of the developers will action your list.

C is much faster than VB (say 20 times) by various means, including not usually having varying or optional params. You can't really have zero or one, it would have to be one or more, so that largely rules out a single optional param. Besides, when there's get_xxx there ought to be a set_xxx when that makes sense (as it looks to do here). Or, yes, a global though it's not really a good way to write things (elements of programming style and all that).

Ideally someone would make a time-keeping set of device-independent APIs which readily support any or a mix of time sources, whether clock-calendar chips, internet (NTP etc) or whatever.

Hi Dale,

Could you confirm that in your post #72 you mean the diskio.c file attached to my post #70. Sorry to be pedantic but I just want to make sure we are one the same page.

With regard to your item 3 in Post #72, I think that rather than hard coding for a particular board in any of the library files this should be covered by the SD.mount( ) function as we have been using. I have started drafting something on the wiki SD.Library which will hopefully makes clear what I am thinking. By doing it this way I think that the same code could also be used with an external SD card connector (assuming that people remember that the pin connections are slightly different for SD cards, miniSD cards and microSD cards) by only changing the Pinguino Pin Number in the SD.mount function call and connecting the SPI2 lines for the other three connections as appropriate.

Item 4 needs expanding to remove all of the other #if defines and #if !defines we have remmed out over the last few days in SD library various files.

If you can accept what I say about item 3 above, I will undertake to clean up the various SD library files and get them submitted to one of the core developers for inclusion in a future revision of x.3. I will then update the SD Library wiki page accordingly.

Finally re Item 6. I think that this is one to park for the time being until you have details of how you are getting the GPS date and time. There is a way of having optional parameters in a function call but it generally needs a way of telling the called function how many parameters there are, for example CDC.printf has a format string and then an optional number of other parameters to be printed, the format string telling the function how many parameters to expect. The other thing is it might be too specialised an application to warrant including it in the core - you could just "tweak" a local copy of diskio.c so that get-fattime calls you own GPSdatetime function as required.

Finally just one response to pingotg's first comment in Post#73 - remember this is an open source/open hardware project and relies on people giving their time and effort freely for the benefit of all, hence my offer to do the necessary for the SD library files.


Yes diskio.c file attached to post #70.

If we have to pass 8 or 40 to mount() to take care of an 'if' someone adds external hardware then why can't we add sending tim also, so most of the time it is used as mount(40,0) and if you want to sent it GPS time, change the 0. Tit for tat, sorry, really not a problem for me either way as I am now comfortable changing core code as needed, just want to make it easy and actually more flexible for those that follow.

I think that the hours, days and weeks it has taken me to discover these core issues far out weighs the time it would take to change the core code, even if it is volunteer.

And I know you have put many hours into this too so lets just finish it without further accounting of effort. I am sure you know by now, I am concerned about having others benefit from my journey.

Hi Dale,

I am sorry if I did not make myself clear, based on our experience over the last few days, and primarily your effort, I think that there is a good chance that the code we currently have will probably support external card readers with no further changes and there are quite a few available as either shields or breakout boards available (and some even have real time clocks on them but that is another story Wink )

In addition to the tidying up the changes to the library files, the various example files also need to be updated to keep them in step and cover the range of "supported boards" as per my draft wiki page, so my proposal was based on the minimum changes to support to what is currently available and hence testable. Once there are a range of date/time sources available (recognising that there have been some recent posts on DFC77 modules) that may be the better time to see how the "right" one is selected, there may be a more elegant way that having an additional parameter in the SD.mount function call.

Finally, my comments about effort were definitely not intended for you, but were rather a response to someone else's comments.

(07-05-2012, 04:05 PM)mf01 Wrote: [ -> ]Finally, my comments about effort were definitely not intended for you, but were rather a response to someone else's comments.

Sorry, it must have went over my head Confused

All is Cool

I like elegant! I am with you now, Wiki page is good!! Make that GREAT!!

Hi Dale,

the wiki page is a start - I wrote it this morning whilst the experience of the last few days was fresh in my mind and also as a way of clarifying my thoughts about how the SD library could be used. Feel free to add to or amend as you think fit - it is a wiki. I will try to add pages for some of the key SD Library functions in due course but if you want to help feel free. I find that trying to document such functions helps me identify gaps in my understanding.

Pages: 1 2 3 4 5 6 7 8