A mic? Not sure if it has enough ram to do anything with analog signal processing.


@zigzagjoe really nice and cheap. The ram would be kind of a problem though. Aren't there cpu in that series with more ram?

Yeah, you can get ones with more RAM and ROM, but only in surface mount packages. That's one of two ARM chips in a DIP form factor available, so went with it in in the spirit of a hobbyist-friendly design. Other one is an 8-pin relative with even fewer resources, definitely not going to cut it.

If you throw DIP out the window, though, there's a lot of options - USB client, as much RAM/ROM as you could want, and more powerful Cortex-M3/M4 cores, to name a few. Possibly even a display interface, though that would increase complexity quite a bit.

Truthfully, it probably makes the most sense to just get a board made anyways, seeing as there are very few graphical LCD modules with through-hole-friendly layouts. FPC connectors, which you'd use for the display proposed by the OP, are all SMD. That color LCD is a hair better in that it has solder pads that you could conceivably solder wires to, but it's meant to be soldered to a board.

It'd also allow you to integrate a keyboard matrix for a semi-handheld product. As long as you don't go whole hog with BGA chips, SMD can be done at home without *too much* effort via a heat gun or toaster oven. Have even heard of people doing it purely by hand.

I think it could be a fun project anyways, working with the limited resources of the LPC1114. You would want most code to be interpreted code, with just the lowest level routines stored in ROM. Bootloader, input, low-level comms (rs232 or usb), display routines, storage routines, floating-point emulation, interpreter (obviously), and a basic monitor program. All the stuff that needs to be fast. Still, going to have a look to see what $3 gets you in a SMD ARM chip.

Re: eLua. Not enough RAM/ROM to manage it. You'd want as minimalistic a language as possible, if using the LPC1114. Fancier [SMD] ARM chips would have enough RAM that you could set things up that entire user binaries could be copied to a specific offset in RAM and execute them from there.

The SPI interface is what you are using to send SD commands. You most certainly are not accessing it 'exactly the same' as a flash chip - the physical interfaces are the same, the software interfaces are very different. Don't dismiss what I'm saying out of hand - you do not know everything. Again, see Sd2Card.cpp. That is the interface you will need to use to read and write blocks from a SD card.

Yes, there is a portion for software SPI, there is also a portion for hardware SPI. Yes, it has a FAT component, which is not part of Sd2Card.cpp - it's written in layers, of which Sd2Card is the lowest, and directly interfaces with the SD card. Fat functions use Sd2Card, and so on. Course, you can have a look at those if you like (can be rather terrifying).

Not for binary program memory, no; there's no way around that for either MCU without using one that exposes some of its internal bus. But for an interpreted program, it could be used to defray operating expenses of a SD card, possibly. Would be unable to keep much/any user code in RAM. Just something interesting i saw, anyways.

Linking software can get messy if it's allowed to grow out of control, but it'd be superior to using SD card in terms of access speed and ease. At the simplest level, though, linking software is quite simple, especially compared to rolling a whole SD stack. Of course, you'd want to implement either serial over USB or just plain bit banged serial, but hey, options. For programming, eeprom usage would be more deterministic than FAT layered on SD; simpler to deal with.

Just some thoughts, anyways.

z8, which the ez8 is based on, is just as elderly as the z80. Sorry, should have made that more clear. The ez8 is faster than the z8, but it will still be blown out of the water by any newer processor - such as the ARM Cortex-M0, powering that one chip, which is fully pipelined nevermind 32 bit and running at several times the clock frequency.

The ARM chip I linked was a microcontroller, too - no need to futz with ROM and RAM chips. If you give up DIP requirement, even more options become available. Could also use a module such as the teensy3 rather than a raw MCU, but it drives price up. That specific one, the LPC1114, has 22 IO pins available, which based on some quick futzing about is sufficient for the set up I described. Also, has 4kb of SRAM, vs 2kb per ez8 chip. 50mhz also strikes me as quite a reasonable speed. The IO pins are the hardest part, relatively, and with a shift register (or PS/2 instead) it's a nonissue.

Code size is a concern, though with thumb available it reduces the damage to some degree. Additionally, ARM/Thumb instructions are likely more powerful on a per instruction basis thus *possibly* leading to fewer instructions. Would need to do research to confirm that, though. Going to be hard to fit much more than a basic OS, library routines, and a simple interpreter in either of their ROM spaces, though. Achilles's heel.

The shift register was mentioned due to IO constraints of that specific ARM chip; it lowers the pin requirement to where that chip is usable. For scanning a key matrix, the speed reduction is largely moot. Or, of course, just use PS/2 and don't worry about it.

Yes, that LCD is cheaper, but it's also greyscale at a fraction of the resolution. For $4 more, it seems to me that getting colour and significantly more pixels is quite worth it. Does use more power, though, due to the backlighting.

Accessing a SD is not as easy as you seem to think, though: even throwing filesystems out the window, you must operate on a 512byte block basis, which eats into available RAM. Using the fatlib for AVR as a guideline, you are looking at something like 600-1200 bytes of RAM dedicated to the SD interface (with a FS), never mind code size. Implementing a PC-compatible FS, such as FAT32, will drive complexity way up, and be a pain to write with the lack of good development tools. No PC compatible FS throws away the primary benefit to using a removable storage interface. An i2c flash/eeprom IC will be far simpler to deal with, and maybe save a few pins, too.

USB I mentioned simply because you could: the 50mhz ARM can manage low-speed interfacing with user code active, and probably can do full speed interfacing (12mbs) with full cpu usage. It's a freebie - why not? A dedicated hardware interface is much better, as you say, but you can't get a DIP ARM chip that has it. The presence of a USB interface would also be a point in favor of not using a SD card. A USB stack will use up some RAM and ROM, though.

There are ez80 MCUs, but they are only available in large SMD packages. Pain in the ass to deal with for a hobbyist. Basically, I mentioned this first because it was a fun thought-experiment, and second because two ez8s increases hardware complexity, code complexity, cost, power use and reduces performance.... for the gain of similar mnemonics. Buying a PI or other some such is boring; having a hardware design that one can understand and tweak as well as play with bare metal code is way more fun.

@Art_of_camelot: Registered mostly to reply to this post; I was bored, and it was fun to design a minimal system (as outlined in my post). Originally discovered it as I had to purchase a TI-84 C for a class - can't use 89 - and was doing research concerning it. Absolutely disgraceful what TI ended up shipping, also, could have been so much more.

EDIT: Spelling