Arm vs AVR & SD memory card support

Recently there has been a lot of traffic on the electronics side relating to moving over to some sort of ARM processor with a shield similar to the Arduino.

I wrote a long reply, which probably relates more to the firmware and the how much time it takes to write code.

A month or two ago I set out to make my own firmware using AVR. Mostly because I needed to solve the issue reading SD cards. Seems like it would then be simple to just replace the low level read routines that worked with compact flash with SD.

Not so fast here. The SD code takes more space, So I had to disable a feature to fit it into the 8bit processor. Next issue is that SDHC involves gigabytes of space rather than megabytes. It took me a while to realize I needed smaller buffers for the file and directory reads.

With the floppy DMA it was best to read in a whole track at a time. So a large external ram was used. SDHC over serial is much slower than DMA, A single cluster may be 32K. Everything is mapped in 512K chunks. Much quicker to process 512K blocks than 32K blocks under SDHC.

It took me a month to figure this out. Sure I could have read the same file on commercial hardware in a microsecond. What is the fun in that?

SD is already on the v1.2 hardware. I found quite a number of free FAT libraries written in C. So there is really no need to ignore this support for external cards.

What I found interesting, the simple task to change some code from reading compact flash cards to read the same from SDHC has taken me more than a month. A project I had estimated at 5 to 7 days. I still probably have a week of work to do on the MIDI system.

After that I can get back to implementing the file system changes to the version that I posted to the github site. Even that only takes things as far as being able to play a gcode file in time slices like a midi file Much work needed on the method for actually sending the pulses to motors.

Having invested in AVR I have not had a lot of exposure to the ARM shield type boards being proposed. I would suspect that most of my code could be reused, although it would probably need to be re-written in C, which would make Triffid Hunter's code more of a practical starting point for conversion.


The only reason I bring any of this up, is that is is possible to provide SDHC support inside of 8 bits of flash space along with a simple G-code interpreter. Inside a time sliced microkernal?

I guess the real question is should the firmware be at a high enough level were users use something like perl to configure the setup settings? Or am I missing something here regarding just who the customer base for the firmware really is?

-julie

Good question that.

The intended audience, I guess in writing here the intended audience is firmware hackers like us.

The wider audience are likely to be machine builders that just want to down load an image (or hook up a friends identical and already running machine) and burn it, while they focus on what their own aims are.

Mechanical R&D Folk
Printing R&D Folk
Electronics R&D Folk
etc

I think provided firmware is available to systems integrator/kit sellers the end users of these bots are unlikely to care, being more focused on the end product of the machine than how it gets there.

Intended audiences then is a dificult question to answer, because there are so many.

The short answer is anybody who might use your particular controler board and firmware combo. The audiences are as varied as the potential soolutions and their combinations.

Most developers here though do develop things with themselves as their primary audience and the rest of the world that they share their work with as a secondary audience.

Who do you feel the audience is.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Clicked on this 'cause I saw a May 24th date. Only to realize it is year old.

Thread necromancy waves fingers. Oooky spooky music in the background. As the sorcerer in best Gilbert and Sulivan traditions cries arise o' thread arise...

So what have I accomplished in a year? Mostly traditional player piano and band organ work. Not a lot of folk who do this anymore.

I did however do a lot more with reading SD cards. Can do this now on a Tiny 45, and in C too. Using the Petite fat file system on Elm. Code was written for an 8 K device, but with no display I was able to rout around the long file name stuff and Unicode translation.

More fun at ESC I got some sample tiny 44 chips (more pins) in a five millimeter MLF package. Connecting some fine wires the chip works.

Still have the LPC espresso that prompted this thread. This time at ESC I took some workshops on it. Also seminars and workshops over the years on the atmel capacitive touch panels. Attempts to weedle a sample LCD touchscreen were not successful, so I revived a NTSC monitor project from a decade ago to see if this could work for a display. The 18MM diagonal makes it a bit small. The 18 volt bias is not too promising.

Sparkfun might have a 30 dollar color phone display on an arduino shield. Most of these kits seem to be hovering around 90 to 120.

So an interactive display seem a bit off for the time being.

So I am still Fuzzy on the official SD support, not having read these threads for a few months. Exists? yes: no

Hmmm ... these are the "Official" electronics, as far as random folk have told the wiki:
http://reprap.org/wiki/Official_Electronics
At some point it will know about the "Gen X Electronics" and the "Gen 10 Electronics" (I'm trying to get Camiel to name that one the "Salmon Electronics" so that he doesn't get red-queened by the Gen 11 Electronics guy the next day.

According to Kliment:
Indeed, I have SD support working. My firmware is at [github.com]

SD printing has been independently replicated at least twice (that I know of) and I am putting a shield together that attaches to the back of RAMPS (no assembly required if you have passthrough/stackable headers, minor soldering required otherwise).
http://forums.reprap.org/read.php?219,74143,78629#msg-78629

So I am still Fuzzy on the official SD support, not having read these threads for a few months. Exists? yes: no
Sounds like yes. You may want to pop into IRC a bit more. If you do, tell Kliment to update
http://reprap.org/wiki/RAMPS
and let the wiki know SD is working and tell the wiki what his setup is.

---

-Sebastien, RepRap.org library gnome.

---

Remember, you're all RepRap developers (once you've joined the super-secret developer mailing list), and the wiki, RepRap.org, [reprap.org] is for everyone and everything!

Hi sheep.

A firmware worth looking into at the moment is the Teacup Project. These guys have a branch that is producing code for SD card support. (All in C, but targeted at Arduino based chips & boot-loaders)

I think Casaino was attempting to port this to ARM. not sure how far he got though.

I think there is guy over there called Architect who is looking into a separate control panel. Which may or may not have SD card capability.

Worth having a rummage through the firmware experimental threads relating to teacup.

[forums.reprap.org]

---

Necessity hopefully becomes the absentee parent of successfully invented children.

yes teacup has preliminary SD support in the 'sdcard' branch. I'm waiting for a mega to arrive so I can actually test it- can't fit both teacup and the SDFAT libraries onto my '328!

I have started another project called 'soupcup' with a totally different approach. One of its features is to pre-calculate most of the per-move math and create a line of gcode including the stored values, with the ability to either send this expanded line to the host or store it to a file on the SD card. It also does not fit on my '328. It remains to be seen whether it's faster to calculate these values or parse them.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> yes teacup has preliminary SD support in the
> 'sdcard' branch. I'm waiting for a mega to arrive
> so I can actually test it- can't fit both teacup
> and the SDFAT libraries onto my '328!
>
What libraries are you using?
How much space does teacup currently use? This is straight C, Right?

Petite FAT fits inside a Tiny45 and compiles with GCC to about 2.5K for read only support. No file name display, although there are options and more K if one wants to be able to open Unicode paths in a number of popular languages.

-julie

yep, I'm using petit fat revision 8237, albeit with write support. takes about 17k of flash for me. teacup takes about 24k flash, so they both take more than half of the '328's flash.

Even with the absolute minimum configuration (basically only mount, open and read), petit fat still takes about 8k flash so still wouldn't fit alongside teacup without cropping teacup's features back by a significant degree. I don't know how you got this 2.5k figure, but I can't achieve it.

Teacup's dependencies are just avr-libc and toolchain, and is written in straight C.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware