|
One neat platform I didn't see in the OP is the mbed. The mbed is an ARM Cortex M3 on a wide 40-pin PCB, similar to a large Stamp and smaller than a lot of other prototype boards. It fits in breadboards and can be programmed and powered through USB. The device is actually two ARM chips - one runs your application and has its IO connected to the various board pins, while the other is the "programming" controller which drives the target's programming port as well as emulating a terminal and a flash drive over its USB port. mbed advantages: - if you're lazy, you can use an online IDE in your browser without installing any software at all (you can install a normal ARM tool chain if you want). - the mbed plugs into USB and looks like a USB flash memory key. To program it you just need to copy .bin files to the device, no drivers needed. Libraries allow you to read/write files off the flash disk as well. - the programming language is C++, and there's plenty of libraries for various IO devices - although the mbed board has a limited pinout, there's a ton of IO resources on those pins, including an Ethernet port and an additional USB master/slave port. There are libraries for both, and the USB libraries allow you to do things like emulate a keyboard to a computer, or get keystrokes from a USB keyboard. There are a few disadvantages: - Obviously some people don't like online tools. - I don't think you can directly debug it, but then, I haven't tried non-online tools. - The pinout is limited, and the USB and Ethernet ports do take up precious pins if you don't need those features. The limited pinout might switch me to the new (ARM-based) Arduino Due, but I haven't got my hands on one yet.
|
#
¿
Nov 10, 2012 06:57
|
|
|
|
| # ¿ Apr 30, 2024 10:54 |
|
|
peepsalot posted:OK, so my idea for now is to play around with audio on this msp430 and see how nice of a song i can cram into 16KB. I know i could implement some external storage, but I'm just more interested in testing the limits of what i can do with this chip and not wanting to order more ICs at the moment. I'm not super familiar with the msp430, but it does have some nice stuff on it for audio, depending on which variation you've got. Pretty much any microcontroller can do chiptune style stuff. With a 16-bit CPU and a 12-bit DAC (or a delta-sigma DAC) you can do basic sample (looped or one-shot) playback pretty easily, though your sample sizes are limited by available memory. Beyond that there's tons of DSP type techniques, particularly if you are using a CPU with a hardware multiplier on it. That's rather a broad subject, but if you're going to do sample playback, you can add envelopes and modulation. There's lots more you can do... I currently have a half-finished project to do some digital string simulation (a very basic physical model) in an mbed (an ARM board).
|
|
#
¿
Nov 24, 2012 08:55
|
|
|
PDP-1 posted:The CORDIC algorithm might be helpful for generating sine waves without a hardware multiplier. I wouldn't invest too much time in sine waves if you're interested in musically interesting sounds rather than the programming exercise. Sine waves are boring, and you will almost always prefer square, triangle, or sawtooth signals when you're making sounds, and you can generate all of them with a simple counter. Modulation is where things get interesting. Build an envelope (ADSR) and an LFO and goof around with AM and FM modulating whatever oscillator (whether its a simple wave or a wavetable). Modulation will take some multiplying but hopefully not so much that you'll miss the hardware multiplier.
|
|
#
¿
Nov 24, 2012 23:54
|
|
|
I got curious, so I took a quick look at a datasheet randomly picked off the NXP site (LPC1300), which says the internal clock is accurate to 1% over the full supply voltage and temperature range of the part (10.4 in http://www.nxp.com/documents/data_sheet/LPC1311_13_42_43.pdf). So, a clock could drift up to 1 second in 100 seconds.
|
|
#
¿
Dec 21, 2012 05:49
|
|
|
It's just a map of what address ranges are reserved for what uses across all types of ARM Cortex processors by the ARM standard, regardless of vendor. Any given chip can/will have less than the reserved amount of memory for any given range, it's just a reservation. A 32-bit ARM has 32 bit addresses and can address up to 4GB in theory, so its divided up this way. If you have a chip that has 64KB of RAM it'll probably be between 0x20000000 and 0x2000FFFF, other larger chips will populate more of the range reserved for RAM, but will never put a peripheral in that range. The upper half a gigabyte looks like its for vendor-specific hackery, with the first 1MB of that half a gig reserved for specific things.
|
|
#
¿
Dec 31, 2012 03:23
|
|
|
Delta-Wye posted:Is there any particular reason you're doing c++? The runtime overhead for most of the novel c++ features (polymorphism et al) make it an unusual choice for resource constrained systems like 8bit avr/pic/etc chips. Just scoping functions to a class is an ok reason to use C++, that's pretty much what I did for mbed programming. It's handy for modularizing IO that you can instantiate multiple times on different pins, for example, and more convenient than how you'd do it in C with no more overhead. The one advantage C++ has over other OOP languages is constructing static and stack objects so you don't have to use the heap at all, which is great all by itself for embedded. Plus, there's so many random BS features in C++ that you should never feel bad ignoring most of the language if a tiny subset solves your problem.
|
|
#
¿
May 15, 2013 02:17
|
|
|
|
| # ¿ Apr 30, 2024 10:54 |
|
|
Delta-Wye posted:Tell me again about how developing for ARM is fundamentally different than an 8bit micro ARMs are almost cheap enough now to replace 8-bit micros, at least in low-volume hobby applications where CPU cost comes out in the wash. 
|
|
#
¿
May 16, 2013 02:02
|
|
