Show Posts
Pages: 1 [2] 3 4 ... 9
16  Using Arduino / General Electronics / Re: Rugged stretch-resistant / headphone wire - where to buy it? on: March 15, 2012, 11:08:41 am
It's a wearable display of sorts using electroluminescent materials. Yes, I am aware of the hypothetical safety implications - besides the low current, there will be secondary insulation built into the garment itself to avoid any 'surprises' should the wiring fail so completely as to break its insulation. This sort of thing has been done before quite a lot at the hobbyist level without incident (or op-eds preaching against the dangers of such projects, a la the dire newspaper article I read today about the Cinnamon Challenge). People have used whatever wire was handy, but given the large number of elements to be wired, I want something that will last, and ideally allow building in enough slack to accommodate reasonable variations in body sizes.

Does anyone have suggestions as to my original question?
17  Using Arduino / General Electronics / Rugged stretch-resistant / headphone wire - where to buy it? on: March 15, 2012, 10:13:50 am

Hi all,
I am working on a project that requires moderately high voltage (up to 120Vpeak @ 0~500 Hz, low current) signals to be routed through a wearable belt or vest subject to a lot of stretch, so the wiring has to be small and flexible, but fairly rugged. The type of wire used on typical headphones would be ideal: braided, 2- or 3-conductor, embedded with cotton/polyester(?) fibers to safely take up any stretching loads, and of course extremely flexible. But, I can't seem to find that stuff available to buy, or even what to call it (obvious Google queries like "fiber-embedded wire", etc. don't turn up anything relevant).

Literally buying headphones off the shelf and sacrificing them for the cable isn't ideal - I don't think they'll handle that kind voltage anyway.

Anyone know what this type of wire is called, and/or where to buy it?

18  Using Arduino / Programming Questions / Re: stk500_recv(): programmer is not responding when programming bootloader on: January 22, 2012, 01:53:13 pm
Are you using the ArduinoISP sketch with Arduino 1.0 by any chance? I recently chased down a problem I was having very similar to yours - avrdude "writing..." to about 96%, then failing. This thread has the details.

Try using a pre-1.0 Arduino IDE (0022 or 0023) to build and upload ArduinoISP. Alternately, the user Coding Badly is offering a patched version of ArduinoISP in that thread that should work with 1.0.
19  Using Arduino / Programming Questions / Re: Custom cores question/problem on: January 20, 2012, 02:33:12 am
Thanks, that (option 1) solved it!

Out of curiosity, if all the functions contained there are vanilla C-style, is there any advantage/difference (e.g. in code size or performance, or other considerations) to one of these approaches over the other?

20  Using Arduino / Programming Questions / Custom cores question/problem on: January 19, 2012, 12:43:56 am
Hi,
I'm working on a custom Arduino-based board for low-power projects. As part of the effort I have added a handful of utility functions to the 'core' for power management. In the hope of creating as little mess as possible, I did it as follows:

* Created new files, mosquino.c/mosquino.h, containing the custom stuff (functions, and macros + prototypes respectively) in the custom core's directory (...My Documents\Arduino\hardware\Mosquino\cores\arduino\)
* #include "mosquino.h" from WProgram.h

Although macros defined in these files are 'visible' from the sketch, the functions are not... even if mosquino.h is #include'd into the sketch by hand:

Code:
core_test.cpp.o: In function `setup':
C:\DOCUME~1\Tim\LOCALS~1\Temp\build5515614687940556259.tmp/core_test.cpp:32: undefined reference to `power_full()'

A look in the build temp folder shows at least that a mosquino.c.o file was built and contains references to the function.

Currently using a core derived from 0022 and the 0022 IDE (haven't had time to patch it up to 1.0 yet).

Is this behavior expected? That is, is there some peculiarity/voodoo in the Arduino IDE's build process that causes this to fail, or am I missing something simple? (i.e have been away from c++ too long :p )?
21  Using Arduino / Microcontrollers / Re: UNO vs. Optiboot vs. ArduinoISP - what's the current status? on: December 12, 2011, 10:12:43 am
Solved!...ish.

Re-googling the "protocol error, expect=0x14, resp=0x64" as of this morning turned up the following:
http://arduino.cc/forum/index.php?topic=82567.0
which points to
http://code.google.com/p/arduino/issues/detail?id=661

Going back to 0022 fixes it. This problem (once auto-reset is ruled out) appears specific to the Arduino 1.0 core.

In short, here is what I know so far:
* In the Arduino 1.0 core, the serial buffer size has been reduced from 128 to 64. For reasons unknown (the STK500 protocol + UNO shouldn't ordinarily leave <64 bytes unhandled), this causes the ArduinoISP sketch to break during writing the first Flash page(?).
* There is no bug in the Uno bootloader that breaks ArduinoISP, and there never was. The "Currently, you cannot use an Arduino Uno as an ISP programmer..." note on the ArduinoISP page is a sham - it refers to the auto-reset issue (recent Optiboot versions have an explicit hack-around for this), which is well known and easily worked around in other versions.
* THE FIX to use ArduinoISP with UNO (or anything else): Install the previous Arduino (0022) and use that to compile/upload ArduinoISP. It's probably a good idea to keep both around for a while, as it appears 1.0 makes a laundry list of other changes that appear likely to break certain sketches. You could also hack around in the core to re-increase the buffer size, but I don't recommend this generally.


I've also added these findings to the top of the thread, since as of this morning it appears to be the top Google hit for this error message.
Users from the future, hope this is helpful :-)
22  Using Arduino / Microcontrollers / Re: UNO vs. Optiboot vs. ArduinoISP - what's the current status? on: December 10, 2011, 04:28:39 pm
Thanks for the info! I am curious why the owner of the ArduinoISP page is so coy about this being the issue - the problem is easily worked around, fairly well known, and in my experience (linked above) can affect pre-Uno (at least Duemilanove that I know of) Arduinos too. But I'm glad to know there shouldn't be any separate bootloader-specific issue aside from the auto-reset.

That said, I am still perplexed by the result above. The bootloader I'm trying to install is the Mosquino bootloader (Sanguino's Adaboot with very minor changes) for an ATmega644PA, which I've done (using a Duemilanove/168) dozens of times without incident. With the same target board, the same .hex file and the same version of ArduinoISP, with the Duemilanove and the Uno side by side, the process consistently works flawlessly on the Duemilanove but always fails as above on the Uno.

This leads me to guess it's not an addressing issue - since that should have failed in both cases, right? The only thing I can think of is a timing issue exposed by the differences (latency / serial buffer size?) between the Uno's USB->serial solution and the FT232 used in previous versions (although if this were the case I'd expect more people to have discovered it by now...) Does this seem reasonable?

To test it, are there any known quick & easy ways to slow down the rate at which avrdude (ArduinoISP?) tries to perform flash operations?
23  Using Arduino / Microcontrollers / UNO vs. Optiboot vs. ArduinoISP - what's the current status? on: December 09, 2011, 02:55:49 pm

UPDATED: Here is what I know so far: As of 12/12/2011...

* There is no bug in the Uno bootloader that breaks ArduinoISP, and there never was. The "Currently, you cannot use an Arduino Uno as an ISP programmer..." note on the ArduinoISP page refers to the auto-reset issue (recent Optiboot versions have an explicit hack-around for this), which is not Optiboot-specific, is well known and easily worked around in other versions. The workaround for this is to place a low-value (~120 ohms) resistor between the Arduino's RESET header and 5V to force RESET high, or (if you have a soldering iron) cut the RESET-EN jumper to disable auto-reset outright. Again, if you go the jumper-cutting route, you need a soldering iron to undo this.

* However, there is a (separate) problem that occurs with Arduino 1.0. In the Arduino 1.0 core, the serial buffer size has been reduced from 128 to 64. For reasons unknown (the STK500 protocol + UNO shouldn't ordinarily leave >64 bytes unhandled), this causes the ArduinoISP sketch to break during writing the first Flash page(?).

* THE FIX to use ArduinoISP with UNO (or anything else): Install the previous Arduino (0022) and use that to compile/upload ArduinoISP. It's probably a good idea to keep both around for a while, as it appears 1.0 makes a laundry list of other changes that appear likely to break certain sketches. You could also hack around in the core to re-increase the buffer size, but I don't recommend this generally.

------

Hi,
I seem to be going on a protracted webforum pointer chase trying to find out the current status of using ArduinoISP with an UNO board. The ArduinoISP page (which has not been updated on some time) obliquely mentions a bootloader(???!!!) issue that causes the sketch not to work with an Uno, which "will be fixed soon". Various posts on various other webforums (example) say it works just fine for them, and/or there was no issue to begin with (aside from the well-known issue of having to defeat "auto-reset" before burning the bootloader - e.g. cut the jumper, or wire a 120 ohm pullup resistor to RESET to force it high).

Based on those, I advised my coworker to buy an UNO and use it as a programmer for Arduino+AVR based projects. I've been using it on my home Duemilanove board for some time without incident, unfortunately those are not commonly available for sale anymore. The UNO arrived, and sure enough, it fails consistently with ArduinoISP / avrdude at about 96%, as follows:

Code:
D:\arduino-0022\hardware\tools\avr\bin\avrdude.exe -b 19200 -p atmega644p -C D:\arduino-0022\hardware\tools\avr\etc\avrdude.conf -c stk500v1 -P COM2  -V -V -V -V -U flash:w:ATmegaBOOT_644P.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude.exe: Device signature = 0x1e960a
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "ATmegaBOOT_644P.hex"
avrdude.exe: writing flash (65466 bytes):

Writing | ################################################   | 96% 0.01s
avrdude.exe: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
Writing | ################################################## | 100% 5.17s

avrdude.exe: failed to write flash memory, rc=-4

avrdude.exe: stk500_cmd(): programmer is out of sync

More forum goose-chasing based on this error message has turned up various non-official Optiboot hacks / forks of various ages that are supposed to work around the issue... whatever that undocumented issue happens to be.

I tried the one described here:
http://aeroquad.com/showthread.php?2364-Uno-optiboot-issue ->
http://aeroquad.com/showthread.php?2352-AeroQuad-Flight-Software-v2.4&p=24446&viewfull=1#post24446 ->
http://aeroquad.com/showthread.php?2365-Uno-problems-with-2.4&p=24448&viewfull=1#post24448

(successfully replaced the Uno's bootloader using the Duemilanove +ArduinoISP) ...but no change. Westfw's Optiloader also sounds promising, but sounds like would require a lot of hand-hacking to work in my case (burning a custom bootloader to a custom '644-based board). Keep in mind this is for a coworker (analog guy who is new to microcontrollers), and I would like to send him off with the give-a-man-a-fishing-pole solution rather than handing him a fish (i.e. handing back his Uno with some various not-well-understood hacks pre-applied). To that end I need to understand for myself what the actual issue is.

Soooo....

Can anyone explain what the actual issue is that causes the existence of (???an older???) Optiboot on the Uno board to break the ArduinoISP sketch? Perhaps more importantly, how is it that ANY bootloader issue is affecting the operation of any user sketch to begin with, since the bootloader should be long since out of the picture by then?

Thanks!

24  Using Arduino / Networking, Protocols, and Devices / Re: An interface for ANT radios... librarification advice? on: September 09, 2011, 09:07:30 pm
You don't wire the ANT chip to a sensor, but you can wire them both to the same Arduino. You shouldn't need both an ANT and XBee radio, unless you are building an ANt-to-XBee network bridge :-) To interface to a PC, some dedicated USB receiver sticks are available (Garmin makes the 'official' one, but Sparkfun also has a version), or a second Arduino plugged into the PC can act as the receiver.

Sparkfun has modules using the older 'AP1' variants for about $25, about comparable with XBees. (They are hardwired in async. serial mode; the final library should support this mode too.) If you are making your own PCB it can be much cheaper (the IC itself is ~$3.50). If you go that route, I'd recommend using the newer 'AP2' series chip (nRF24AP2).

Anyone with advice / best-practices on a library design as described above? :-)
25  Using Arduino / Networking, Protocols, and Devices / An interface for ANT radios... librarification advice? on: September 08, 2011, 11:22:13 pm
Hi all,
Attached is a preliminary sketch that provides an interface to low-power ANT radios (used by most Garmin and Suunto sports products). ANT is a TDMA protocol in which the radio Tx/Rx are only powered during very short pre-arranged timeslots and spend the other 99.9% of their time sleeping. All the timing is handled by the radio IC - when data is transmitted or received (which occurs at a regular interval), it generates an interrupt and transfers an event message to the host (e.g. "Tx OK" event or received payload, etc.). Message rate can range from once per two seconds (minimum) to up to some low hundreds per second(?) maximum, although a dozen or less per second would be typical.

The code attached shows a very simple use case where the Arduino creates a single broadcast channel and then sends one payload (in this case, the same payload) each time it is waked by the radio interrupt (e.g. in response to the last payload being transmitted, which generates an "EVENT_TX" event). As ANT is intended for very low-power systems, the interrupt-driven "sleep until something interesting happens" use-case shown will be very common.

While the code attached "works", I'd like to make it into a full-fledged Arduino library that can ideally be called from higher-level libraries (e.g. future mesh-networking stack), and operate by having the user or higher-level library register their own event handlers (e.g. callback functions) for the different types of event messages generated by the radio.

Some specific advice I could use on the 'best' way to make this into a library are:

Code efficiency - C vs c++ libraries? (I've heard it's possible to make a straight C library for Arduino, but never actually seen one. Is it worth it?)

Function calls (e.g. digitalWrite) inside an ISR - does this generate problems, performance or otherwise? (I know that the compiler for PIC18 micros adds an absolutely dreadful amount of context save/restore the moment the ISR includes a function call, is this the case for avr-gcc as well?)

Best practices on making the library functions usable by other libraries?

Using and passing callbacks to a function inside a class? (related to previous question - a function in library B passing its address to a function in library A to register as an event handler. I seem to recall reading this is a giant nono.)

Thanks!
26  Using Arduino / Displays / Re: New library for epaper-like (bistable) graphical displays on: August 19, 2011, 07:37:31 pm
I think it makes the most sense to keep image commits exclusively as a user-controlled function. These type of displays mainly fill a niche for low-power systems where the image content changes infrequently (ebook readers, sensor displays, remote controlled price tags). The fact is anyone showing full motion video, etc. will save power and $ using a conventional LCD. For the rest, nobody will know better than the user whether they are done writing a new image or not, and we don't need to waste power second-guessing them.

That said, with a framebuffer one could easily add a few extra bytes for tracking the 'dirty' (changed but not committed) area. This display can do partial updates down to a single line (entire lines though; no rectangular areas), so for the cost of 4 more bytes we can store a flag for whether each line has changed or not, and determine the minimum enclosing area. Or, 2 bytes and we store the lowest and highest line that contains changes. Then a "commit_auto()" type function could be added to commit the dirty area and reset the flags.

Like with pin numbers (unlike some library authors ;-), I lean in favor of leaving more in control of the user, even if it makes things slightly more complex. A possible solution is to have a 'xxxLCD' and 'framebuffer' as separate libraries (the resulting 'framebuffer' object just being a thin wrapper around a hunk o' RAM and dirty area flags), and let the user pass in a pointer to the framebuffer if one is desired.
27  Using Arduino / Audio / Re: Crazy idea but bear with me - using sound for data transmission on: August 18, 2011, 08:12:52 pm
I can't remember where I saw these, sorry. The data-over-keyboard-LEDs method in particular was ages ago.

While I am thinking about the latter though... there was a very early 'computerized' (Timex?) wristwatch that could be synced with a PC via a special program that flickered the PC screen between black and white rapidly while the watch (with embedded photosensor) was held near it. Probably slow as hell unless you use multiple photodiodes / amplitude / color modulation or something more clever (cellphone video of QR Codes?), but commandeering the screen via e.g. a Javascript-capable browser may be easier than getting access to the speakers.
28  Using Arduino / Displays / Re: New library for epaper-like (bistable) graphical displays on: August 18, 2011, 06:16:38 pm

on() off()
Because the display is bistable the library should hide the on() and off() functions. Let the library call them when needed, why bother the user with it. In other words, let the library do the energy management! OK with external power this would mean overhead but I guess the complexity of both functions are minimal.

Good idea. It's possible that a user will want to control that themselves (e.g. back-to-back commit()s of small image areas; the "big brother" of this display is 132x64), but probably unlikely. Speaking of power management, an #ifdef for the PinChangeInt library (if available) to sleep until the display update is finished would reduce power usage quite a bit. I was in kind of a 'get er done' mood for this first release ;-)

Quote
set_temp_comp(int temperature)
Could a breakout board be build with sensor to do this automagically?

Maybe! The breakout board linked above actually has pads for an optional thermistor and cap that could be read by measuring the time constant across them, but I haven't tested this yet. The temp comp table from the manufacturer only has steps of 5degC anyway, so it need not be too accurate.

Quote
pixmap(int x, int y, const char * pImg)
How it knows the size? or is it full screeen?

It's the same format as a GLCD image - the width and height are encoded as the first 2 bytes of the image.

Quote
commit()
Is it possible to read out the display to see the commit() is done? Or is commit async?

There is a BUSY pin that can be polled (or tied to an interrupt) to see if the display charge pump has finished pumping (about 300ms) and again to see when commit is done. Handling this in a smarter way (the current version just polls for it) is definitely on my todo list :-)

Quote

Missing functions;
clearEndOfLine(x,y);  to partially clear the (text) display, not a must but a nice to have.

Good idea.

Quote
setPixel(x,y) , getPixel(x,y)
Is this possible?

Unfortunately not, on this display at least. Several limitations currently in the library (e.g. text and images aligning on 8-pixel vertical page boundaries) stems from the fact that the display RAM is not readable on this display. This makes a read-modify-write operation impossible without maintaining a local framebuffer (something I steered clear of for now in interest of memory footprint, although it may be an option in the future).
29  Using Arduino / Displays / New library for epaper-like (bistable) graphical displays on: August 18, 2011, 12:09:48 am
Hi all,
I just released the first version of a display library for 'epaper-like' bistable displays (displays that retain their last image even without power). This initial version supports the 128x32 cholesteric displays from Kent Displays, Inc. This is the display used in the 2010 Defcon badge. Other displays and display types (e-ink??) to be added as they become commercially available to hobbyists and/or I get my hands on one ;-)

Library download with fonts + example sketch
Library documentation
Schematics/PCB (EAGLE 5) and gerbers for a 128x32 display breakout board.

The font and graphics formats are compatible with GLCD.

Action shot:
30  Using Arduino / Audio / Re: Crazy idea but bear with me - using sound for data transmission on: August 17, 2011, 09:48:18 pm
Sounds suspiciously like a modem to me ;-) Everything old is new again! There's actually been a resurgence lately in data-over-audio and old acoustic modulation schemes thanks to certain locked-down hardware companies wanting a cut of everyone's action. Have a look at the papers and source code of HiJack, an open-source design for laundering data through the iPhone/iPad headphone jack without paying "Made for iPhone" extortion. They report some 8kbit/sec over it.

The but-how-do-I-encode-audio-if-I-can't-load-software problem is likely solvable too. A web-hosted conversion app (assuming there is some kind of network access) would work, although an internet link suggests easier ways of moving data ;-) Even without internet, the machine likely has MSIE, some other web browsers (javascript), WSH, Python or some other scripting language installed that could be used for this in a desperate case.

That said, I have seen several other crude data-moving tricks from locked-down machines - one faked a USB keyboard and encoded the data in USB HID control packets (used for stuff like toggling the Caps Lock, repeat rate / etc.). Heck, one used a plain non-USB keyboard and literally toggled the data out on the CapsLock/NumLock/Insert LEDs.
Pages: 1 [2] 3 4 ... 9