Show Posts
Pages: 1 2 [3] 4 5 ... 452
31  Using Arduino / Microcontrollers / Re: Reburn STAMP BASIC on: July 18, 2014, 01:15:14 am
Quote
Note that while this board would work pretty well as a general purpose prototype board, it's designed for using the Propeller chip, which isn't even a Basic Stamp...
32  Using Arduino / Programming Questions / Re: Free Flash memory remaining? on: July 18, 2014, 12:50:06 am
Quote
I'm adding and holding data as needed in FLASH thanks to PROGMEM.
You can't "add" to PROGMEM data in flash at runtime; PROGMEM is read-only data.  you use pgm_read_byte() or similar to read the data from PROGMEM variables, and there is no equivalent for writing data.  (The "bootloader section" of the AVR can write to flash, but that doesn't use PROGMEM and requires manual operations considerably more complex than dereferencing pointers.  And Arduino sketches are not in the bootloader section, so they can't do it anyway.)

Now, the flash memory space goes from 0 to 32k, and part of that overlaps the RAM address space (which goes from 0x100 to 2k+0x100), so if you carelessly dereference PROGMEM pointers, you'll end up reading/writing to RAM instead, which MIGHT look like it's working as long as the addresses you write doesn't overwrite data important for something else...)
33  Using Arduino / Programming Questions / Re: Fast DigitalWrite, made from Wire lib source on: July 18, 2014, 12:39:46 am
Quote
Quote
no one has implemented a variation that handles all the different cases of constant/variable pinnumber/value at the maximum theoretical speed
Given the AVR internal design limitations, it is impossible to get the best/fastest i/o performance when things are not known at compile time.
What I meant was:  It's possible to get "the best" performance given a particular set of criteria.  For digitalWrite(pin, val), there are four interesting cases that might be optimized:
variablePin, variableVal : this is the case implemented by the current digitalWrite() function.  It's pretty slow, but it needs to be.
constantPin, constantVal: this case is optimized by most of the "digitalWriteFast" implementations.  for many cases, it becomes a single AVR instruction.
constantPin, variableVal : codeNewton's implementation does this, sort of.  Implementation speed in a complicated version could be dependent on WHICH pin is used.
variablePin, constantVal : this could be slightly faster than the "both variable" case.
My initial statement was meant to mean that I haven't seen a "digitalWrite()" equivalent that does separate optimization paths for all 4 cases...
34  Using Arduino / Microcontrollers / Re: Reburn STAMP BASIC on: July 18, 2014, 12:25:27 am
Quote
I was gifted a stamp professional development board
There's not enough information there to tell exactly which stamp variation you actually have (there are a bunch.)  Many of the Basic Stamps are based on one-time-programmable chips that you won't be able to re-program even given a current PIC development device.  Even if you have a board with a flash-based chip, none of the Stamp boards are designed for using as a general purpose development board - there is no connector for uploading microcontroller code, nor any debugging port access.  (just the loader for the tokenized basic-like language used by the stamps, which is stored in EEPROM external to the microcontroller.)

And that's not how you should use it anyway.  Keep in mind that the Basic Stamps are essentially the "prior generation" of "easy-to-use" microcontrollers (compared to Arduino.)  They're interesting and relatively powerful devices in their own right, and significantly and interestingly different from an Arduino.  Since interpreting bytecodes loaded from serial eeprom is inherently rather slow (a BS2 executes about 4000 statements/second, compared to ~1M for an arduino), the stamp moves a lot of the "heavy lifting" into well thought-out "statement" definitions (some of which have been copied into arduino (shiftout comes to mind, and BS has a bunch of useful statements that are not present in arduino.)  You should give it a try even if you dislike basic; since code tends to be statement-selection (library call) intensive, the language doesn't really bare much more resemblance to traditional basics than, say, a bash shell script.

If you really would rather program bare PICs (in assembler or C), you'd be better off trading your stamp for one of the Microchip starter kits.  Or get a Chipkit (PIC32, arduino sorta-compatible) and use that.  (a lot of people would urge you to skip the 8bit PICs entirely; the 16 and 32bit PICs are a lot more modern-programmer-friendly.)
35  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 15, 2014, 01:40:48 am
Quote
The arduino is an 8 bit processor  so every time you add two long numbers together it has to load and unload bytes 16 times.
That seems like a misleading statement.  To handle a (32-bit) long, it takes approximately 4 times as many instructions as it does to do the same operation on an 8-bit operation.  For an add, that does end up being about 16 instructions, but the similar 8-bit add would have used 4.  ("loadA, loadB, add, storeC"  vs "loadA0, loadA1, loadA2, loadA3, loadB0, loadB1, loadB2, loadB3, add0, adc1, adc2, adc3, storeC0, storeC1, storeC2, storeC3")
36  Using Arduino / Programming Questions / Re: Fast DigitalWrite, made from Wire lib source on: July 15, 2014, 01:32:05 am
There was relatively extensive discussion of the arduino max pin toggle speed (digitialWrite, and alternatives) in this old thread: http://forum.arduino.cc/index.php?topic=4324.0
The exact details may have changed somewhat, but the basics should still be the same.

Note that most of the faster alternatives rely on on both the pin number and the value being 'written' being constant.  If they're not, you won't get nearly as much improvement (if any.)  AFAIK, no one has implemented a variation that handles all the different cases of constant/variable pinnumber/value at the maximum theoretical speed: you either get "fast" if everything is constant, or "slow"  (or "doesn't work") if anything is non-constant.  The original arduino implementation actually isn't "awful", considering what it does.

I agree that fat16lib's variation is one of the nicest C++ style versions.  I learned a lot just by trying to figure out what he had done...
37  Using Arduino / Microcontrollers / Re: Atmega328P-PU identifies itself as 328-PU on: July 08, 2014, 02:23:55 am
There were some messages on avr freaks  to the effect that the whole signature row COULD be written using undocumented programming commands...
38  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: July 03, 2014, 12:42:02 am
Using a standard "queue" template to implement a serial port buffer is the sort of thing that gets C++ programmers sneered at by embedded systems people...

Although I'm not sure that it would necessarily do a bad job, if you were really careful about which one you used.  (probably you would get an implementation that kept extra pointers around in case you wanted to unread/reread, whether you wanted them or not.
39  Using Arduino / Microcontrollers / Re: Several pgm flash areas ? on: July 01, 2014, 04:24:11 am
The AVR can not store programs in any kind of external flash; you have only the internal flash.
I don't think there is any way to refactor the internal flash that won't make it bigger.  Minimally, you'd probably need some (additional) table of vectors to the functions provided by your libraries, so that your kernel would know where they were.

You could think about using some sort of interpreted code; that could be stored in external flash, if you can take the performance penalty.  You could store an awful lot of BASIC or FORTH on a 16GB microSD card.  (but the thought of managing several MB of forth or basic ought to be making you cringe.)
40  Using Arduino / General Electronics / Re: Stepping serial up to 9v. on: July 01, 2014, 03:20:50 am
It's probably something like a max232 with "diode or-ing"; that's sort of the usual cheater's solution for "multidrop rs232"
If you have the schematics, YOU should be able to duplicate the circuit...
41  Using Arduino / Programming Questions / Re: How to clear serial buffer? on: July 01, 2014, 02:12:33 am
Quote
The point was that the serial interrupt pushes data into the incoming buffer, and Serial.read() pops it out. Had the Serial.read() method been called Serial.pop(), it would have been clear that the function removes data from the buffer.
Well, that would confuse the hell out of me, because "push" and "pop" are operations that I associate with a last-in-first-out "stack" data structure (just like the push and pop assembly instructions on AVR.)  That isn't at all how the serial buffer works!  (yeah, I've noticed that some C++ and Java standard "containers"  implement push/pop for non-FIFO access.  What an awful idea!)

Clearing the serial input buffer is a fairly flawed idea.  You don't/can't know how much data is still "in transit" somewhere in the communications path.  It's much better to read the data and look for particular data patterns that will tell you exactly where you are.
42  Using Arduino / Microcontrollers / Re: Microchip crystal errata? on: July 01, 2014, 01:42:23 am
I do that sort of things in my schematics.  You're placing a bunch of caps, and they're all in the same package, so you duplicate an existing cap and plunk it down all over, hoping that you'll remember to change the values to the "real" values before you turn it on.
(Since I build my own boards, I can usually correct at the last minute if need be.)   It's a bad habit.  It wouldn't surprise me TOO much to have a board handed off to a manufacturer without the final corrections.  A GOOD manufacturer would notice and call your attention to the potential problem.  But lately, "low cost" is more important/common than "good."
43  Using Arduino / Installation & Troubleshooting / Re: Frustration with Nano (v.3.0) USB Serial Connections on: July 01, 2014, 12:17:35 am
Some of the Nano clones appearing (on eBay/etc) use a non-FTDI USB/Serial chip, so no amount of fiddling with the FTDI driver will cause them to work.  For example, this one:  http://www.ebay.com/itm/Mini-USB-Nano-V3-0-ATmega328-5V-16M-Micro-controller-CH340G-board-For-Arduino-/131227868823?pt=LH_DefaultDomain_0&hash=item1e8dca5e97 apparently has a CH340G chip, which doesn't even have a Mac Driver that anyone has found :-( (other vendors may not be so forthcoming on which chip they use.)
This one claims to use a PL2303 chip, which is widely cloned, and some of them are being de-supported by Prolific (the original chip vendor.)  This one doesn't say, but clearly has yet-another chip: http://www.ebay.com/itm/Arduino-Compatible-Nano-V3-0-ATmega328-5V-Micro-controller-Board-Mini-USB-/331178319577?pt=LH_DefaultDomain_0&hash=item4d1bc41ed9


On the one hand - Yeah!  non-exact clones with reduced cost of materials!
On the other hand... People are getting boards that they can't get to work.  Boo!
44  Using Arduino / General Electronics / Re: header block tails are TOO SHORT. WHERE can I get the good ones? on: June 30, 2014, 10:56:49 pm
As for USB-micro connectors, there is some discussion here: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=144000
Including  a number of useful referrals to "better than average" connectors.
Molex: http://www.digikey.com/product-detail/en/0475890001/WM17143CT-ND/1832255
Kycon  KMMX-BSMT35S-BTR
Hirose  ZX62D-B-5PA8
FCI 10103592 (and several "nearby")
45  General Category / General Discussion / Re: MULTITHREADING POSSIBLE IN ARDUINO BOARD on: June 30, 2014, 09:06:27 pm
Multithreading is possible.  It doesn't usually mean the same thing as "multiprocessing."
Multithreading is NOT the same as running multiple things at the same time.
Multithreading is usually neither necessary nor a good idea to handle "7 hardware devices."
Pages: 1 2 [3] 4 5 ... 452