| 16:20.47 | *** join/#edev purl (~purl@rikers.org) |
| 16:20.47 | *** topic/#edev is Discussion of embedded systems (Hardware/Software/Linux/WinCE/Commercial Device Repurposing) : Busybox and Buildroot : http://www.elinux.org |
| 16:37.05 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 16:37.57 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-fef8de00-126.dhcp.inet.fi) |
| 16:51.15 | *** join/#edev CosmicPenguin (~nobody@soa.codeaurora.org) |
| 16:51.16 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 16:54.23 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 17:07.17 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 17:08.47 | *** join/#edev prpplague (~danders@nat/ti/x-hmfeoxpwvbdaurln) |
| 17:10.01 | *** mode/#edev [+o prpplague] by ChanServ |
| 17:15.29 | *** join/#edev bgamari (~ben@physicsnat56.physics.umass.edu) |
| 17:17.24 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 17:42.32 | MonMotha | so, anyone have any suggestions for how to store "a lot" of data in a manner that's as uncomplicated as possible to access? |
| 17:42.46 | MonMotha | bare metal system, no OS |
| 17:43.40 | MonMotha | I do have an SD controller on the chip, but the vendor provided driver is already 2600 lines of terribly written, incomprehensible C not targetted to my toolchain (and their code has a history of being generally non-functional) |
| 17:43.47 | prpplague | MonMotha: not sure what size and options you want, but storing raw data to SD is pretty easy |
| 17:44.03 | MonMotha | prpplague: that was my thought, too, until I saw the "driver" for the SD controller |
| 17:44.05 | prpplague | MonMotha: don't use partition or fs |
| 17:44.16 | MonMotha | right, that was my plan |
| 17:44.30 | prpplague | MonMotha: you can implement it using spi or bitbang |
| 17:44.42 | prpplague | MonMotha: a bunch of the hobby mp3 players do that |
| 17:45.03 | MonMotha | prpplague: is that really going to be any easier? I do also need reasonable bitrates (~1.5Mbps effective throughput) |
| 17:45.17 | prpplague | yea its pretty easy |
| 17:45.19 | prpplague | one sec |
| 17:45.48 | MonMotha | I was also of the impression that SPI mode was removed from a lot of MicroSD cards |
| 17:46.03 | prpplague | MonMotha: http://www.sparkfun.com/products/10628 |
| 17:46.08 | prpplague | MonMotha: yea it depends on the size |
| 17:46.22 | prpplague | MonMotha: most of the microsd larger than 8gb don't seem to have SPI support |
| 17:47.02 | MonMotha | hum, I remembered playing with it about 4-5 years ago and even the small ones back then often lacked it. I was seriously WTFing over why my stuff wouldn't work until I just swapped in a full size card and it mysteriously started working. |
| 17:47.32 | prpplague | MonMotha: thats usually the init routine |
| 17:48.30 | MonMotha | prpplague: the issue at this point is that my client is already upset about cost (and it's not helping that the estimate they ended up receiving didn't even include this feature at all since it hadn't been discussed at the time) |
| 17:48.47 | prpplague | MonMotha: ahh |
| 17:48.52 | MonMotha | so my goal is to make something work as quickly as possible, and my experience with SD cards has been that won't likely be the case |
| 17:48.59 | MonMotha | I'm sure I could make the SD controller on here work |
| 17:49.02 | MonMotha | but not on their budget |
| 17:49.06 | prpplague | understood |
| 17:49.23 | prpplague | MonMotha: let me think on a it for a minute and finish a couple of emails |
| 17:49.43 | MonMotha | prpplague: no problem. I was also looking at simple SPI Flash ROMs, but the biggest I can find in stock is ~32MB |
| 17:52.14 | MonMotha | prpplague: do you happen to have a copy of something resembling the "spec" for SD cards? I constantly get annoyed at the command "names" (aka CMD5, etc.) |
| 18:04.14 | *** join/#edev florian (~fuchs@sign-4d094ebb.pool.mediaWays.net) |
| 18:04.14 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:11.06 | MonMotha | prpplague: nm on the "spec", found the infamous Sandisk datasheet |
| 19:31.08 | MonMotha | prpplague: ping |
| 19:31.23 | prpplague | pong |
| 19:33.17 | MonMotha | prpplague: know of any good, reasonably platform independent SPI mode code for SD access? It seems dumb to reinvent the wheel. |
| 19:33.29 | MonMotha | but most of the examples I can find are very tied to e.g. Arduino, etc. |
| 19:34.06 | MonMotha | the people who made this chip handily put a SPI controller mux option on the same IO lines as the SD controller. Un-handily, they got the data lines (in/out) backwards |
| 19:34.20 | prpplague | MonMotha: if i were working on it, i'd look for the code in barebox(aka u-boot2) |
| 19:37.01 | MonMotha | prpplague: hum, looks like it would work except for the GPL issues |
| 19:38.24 | prpplague | gpl issues? |
| 19:38.27 | prpplague | you using closed source? |
| 19:38.51 | MonMotha | prpplague: very much so, yes |
| 19:38.59 | prpplague | ahh |
| 19:39.13 | MonMotha | so far, I've written everything, so that's not a problem, but the client cannot/will not be troubled with complying with the GPL |
| 19:39.17 | prpplague | can't help you much then |
| 19:39.25 | MonMotha | honestly, the software stack on this thing so far is quite tiny. Using a CM4 is MAJOR overkill |
| 19:42.08 | prpplague | interesting |
| 19:59.53 | roxfan | MonMotha: http://www.basementcode.com/avr/sd_fatfs/fatfs.php (linked ffsample.zip has code for accessing cards) |
| 20:00.49 | roxfan | https://www.sdcard.org/downloads/pls/ <- simplified SD spec (with protocol) |
| 20:04.57 | roxfan | http://elm-chan.org/docs/mmc/mmc_e.html another good overview |
| 20:05.01 | prpplague | since AMR filed for bankruptcy, the spam emails i get from them have tripled |
| 20:06.30 | roxfan | http://elm-chan.org/fsw/ff/ffsample.zip updated sample SD code |
| 20:08.18 | mnemoc | prpplague: tincantools dies with them? |
| 20:08.36 | prpplague | mnemoc: ?? |
| 20:09.23 | mnemoc | prpplague: sorry for my confusion, I had the idea that AMR was the name of your former employer |
| 20:09.34 | prpplague | mnemoc: ahh AML |
| 20:09.37 | mnemoc | :p |
| 20:09.49 | prpplague | mnemoc: right, no AMR, parent company of American Airlines |
| 20:10.05 | mnemoc | oh |
| 20:14.37 | prpplague | http://abcnews.go.com/blogs/business/2011/11/american-airlines-plunges-into-bankruptcy/ |
| 20:15.17 | prpplague | http://www.bloomberg.com/news/2012-01-25/us-airways-confirms-exploration-of-options-related-to-amr.html |
| 20:19.38 | MonMotha | roxfan: the issue isn't that I don't know how to do it (I do). The issue is that the client is unwilling to pay for a dedicated reimplementation or really event much more than a few hours of integration, so to make it possible, I need effectively drop-in code |
| 20:19.42 | *** join/#edev bsdfox (~h36sa@c-98-238-207-83.hsd1.ca.comcast.net) |
| 20:19.42 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 20:20.03 | roxfan | then try the last link |
| 20:20.56 | MonMotha | roxfan: right, I have that. Looking at it, I'm not sure how well it will integrate into my (otherwise fairly real-time) system |
| 20:21.32 | MonMotha | the basic logic is fine, I'd just probably have to re-work it to be interrupt driven and non-blocking |
| 20:21.45 | MonMotha | which isn't a problem per se, but I suspect it exceeds my client's budget |
| 20:21.50 | MonMotha | which may just mean this is impractical |
| 20:51.01 | wmat | prpplague: i fixed that issue with the memory limit on elinux.org |
| 20:53.09 | SpeedEvil | :) |
| 20:55.52 | prpplague | wmat: thanks! |
| 20:56.01 | prpplague | gives wmat a beer and cookie |
| 21:06.59 | wmat | burps |
| 23:09.20 | *** join/#edev NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 23:58.42 | *** join/#edev ChanServ (ChanServ@services.) |
| 23:58.42 | *** mode/#edev [+o ChanServ] by pratchett.freenode.net |