Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Sinestro
Oct 31, 2010

The perfect day needs the perfect set of wheels.

Arcsech posted:

Buy an MSP430 Launchpad or a Stellaris Lauchpad or something like that and mess around with it for a while. DO NOT use an Arduino if you're attempting to get an embedded systems job, you will be laughed at all the way to the door. Right or wrong, the Arduino has a rep for being nothing but a kid's toy but the MSP430 line are some pretty commonly used microcontrollers, and of course ARM is beefy as hell (for a uC).

:kiddo: Is it OK if I just use them as cheap, ubiquitous AVR dev boards with a bootloader on them, but skip the libraries?

Sinestro fucked around with this message at 03:02 on Jan 20, 2013

Adbot
ADBOT LOVES YOU

Captain Capacitor
Jan 21, 2008

The code you say?

Sinestro posted:

Protocol Buffers

This is the library that I'm using. It's about 5k for the encoder and 5k for the decoder.

porktree
Mar 23, 2002

You just fucked with the wrong Mexican.

Martytoof posted:

I did all these AVR tutorials on an ARM board and it was a great learning experience: http://newbiehack.com/MicrocontrollerTutorial.aspx

Thanks for this link. This is perfect for me.

Arcsech
Aug 5, 2008

Sinestro posted:

:kiddo: Is it OK if I just use them as cheap, ubiquitous AVR dev boards with a bootloader on them, but skip the libraries?

Yes, just don't show the Arduino itself in any pictures you put in a portfolio - stick it in a breadboard or something. I just know a lot of engineers who see the people who blink an LED, then claim they're masters of everything embedded and associate that attitude with the Arduino.

I still think the MSP430 Launchpad is generally better though - easy to use, ultra-cheap at $5, and a very, very commonly used uC.

Victor
Jun 18, 2004

Arcsech posted:

DO NOT use an Arduino if you're attempting to get an embedded systems job, you will be laughed at all the way to the door. Right or wrong, the Arduino has a rep for being nothing but a kid's toy but the MSP430 line are some pretty commonly used microcontrollers, and of course ARM is beefy as hell (for a uC).
Heh, at my job we're switching away from an Arduino Mega to our own board with an STM32F4xx chip for our quadcopter flight board. I think a few questions could easily winnow the ranks of applicants. For example, ask them if they like the IDE (correct answer is it's nice for simple stuff and ridiculous for anything non-simple), if they like the TWI library (correct answer is it's nice for simple stuff but horrible for robustness), etc.

Sinestro posted:

I didn't know they did. You have made me work on my UAV for the first time in weeks because comms code was sucking the life out of me.
How are you liking Google protocol buffers on embedded devices, so far? I have to do the same thing at work for our quadcopter. We're using AeroQuad code now and it's... not as robust as what we'd like. (I probably ought to be politically correct.)

KetTarma
Jul 25, 2003

Suffer not the lobbyist to live.

Arcsech posted:

Yes, just don't show the Arduino itself in any pictures you put in a portfolio - stick it in a breadboard or something. I just know a lot of engineers who see the people who blink an LED, then claim they're masters of everything embedded and associate that attitude with the Arduino.

I still think the MSP430 Launchpad is generally better though - easy to use, ultra-cheap at $5, and a very, very commonly used uC.

Meh. Every project I've done and taken pictures/video of has an Arduino in it even if it's just supplying 5VDC to something else from a laptop. Are things like a motion activated paintball gun or a light-seeking robot worth talking about if they're using an Arduino or is the whole thing faux pas?

For what it's worth, I ordered a MSP 430.

Sinestro
Oct 31, 2010

The perfect day needs the perfect set of wheels.

Victor posted:

Heh, at my job we're switching away from an Arduino Mega to our own board with an STM32F4xx chip for our quadcopter flight board. I think a few questions could easily winnow the ranks of applicants. For example, ask them if they like the IDE (correct answer is it's nice for simple stuff and ridiculous for anything non-simple), if they like the TWI library (correct answer is it's nice for simple stuff but horrible for robustness), etc.

How are you liking Google protocol buffers on embedded devices, so far? I have to do the same thing at work for our quadcopter. We're using AeroQuad code now and it's... not as robust as what we'd like. (I probably ought to be politically correct.)

They are lovely. It abstracts away a lot of the loving awfulness of binary comms.

Delta-Wye
Sep 29, 2005
Here is a weird question that I thought someone here may have some insight off the top of their head. When I'm doing embedded programming (say, MSP430) I usually use the smallest datatype available. If I know a value will fit into a char, I'll use a char, even if I am not particularly memory constrained. That is to say I don't just hold ASCII characters in a char datatype, but use it as a 8-bit integer. Supposedly this doesn't work very well on a platform like the MSP430. I was told that the 16-bit processors will read a 16-bit value out of memory, mask it to an 8 bit value, do the required operation, then have to mask it again with the contents of memory when storing it. Needless to say, such masking operations would add computational overhead so if you are not memory constrained it is more computationally efficient to use a 16-bit (int) value.

I haven't taken the time to dig up documentation that specifies one way or the other, or compile c code to assembly and see what it is doing, but am interested if anyone has insight. If it adds a ton of overhead, this would be a counterproductive habit I should break because I am rarely that memory constrained. For cases like a massive array of 8-bit samples or something, the computational overhead may be acceptable, but otherwise I've been doing a very silly thing.

Soricidus
Oct 21, 2010
freedom-hating statist shill

Delta-Wye posted:

I usually use the smallest datatype available. If I know a value will fit into a char, I'll use a char, even if I am not particularly memory constrained. That is to say I don't just hold ASCII characters in a char datatype, but use it as a 8-bit integer.
It's usually preferable to use the explicit 8-bit types from <stdint.h>, i.e. int8_t or uint8_t. More typing than "char", but less typing than "unsigned char", and it can make your code clearer if e.g. you can start distinguishing between "char*" (a string) and "uint8_t*" (byte data).

Delta-Wye posted:

Supposedly this doesn't work very well on a platform like the MSP430. I was told that the 16-bit processors will read a 16-bit value out of memory, mask it to an 8 bit value, do the required operation, then have to mask it again with the contents of memory when storing it.
I'm not an MSP430 expert, so take this with a pinch of salt, but I don't think this should be a showstopper for you since IIRC its instruction set includes 8-bit operations as well as 16-bit. You will probably see masking if the compiler has to convert between 8-bit variables and ints. It'll depend on your code whether this happens enough to make any difference.

With more confidence I will suggest that <stdint.h> can help here as well. For example, it provides the type "uint_fast8_t", which in theory translates to whatever datatype will store an 8-bit quantity in the most computationally efficient way. In practice you're at the mercy of your compiler vendor. If you don't trust the compiler, you'll have to look at the assembly.

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Delta-Wye posted:

Here is a weird question that I thought someone here may have some insight off the top of their head. When I'm doing embedded programming (say, MSP430) I usually use the smallest datatype available. If I know a value will fit into a char, I'll use a char, even if I am not particularly memory constrained. That is to say I don't just hold ASCII characters in a char datatype, but use it as a 8-bit integer. Supposedly this doesn't work very well on a platform like the MSP430. I was told that the 16-bit processors will read a 16-bit value out of memory, mask it to an 8 bit value, do the required operation, then have to mask it again with the contents of memory when storing it. Needless to say, such masking operations would add computational overhead so if you are not memory constrained it is more computationally efficient to use a 16-bit (int) value.

I haven't taken the time to dig up documentation that specifies one way or the other, or compile c code to assembly and see what it is doing, but am interested if anyone has insight. If it adds a ton of overhead, this would be a counterproductive habit I should break because I am rarely that memory constrained. For cases like a massive array of 8-bit samples or something, the computational overhead may be acceptable, but otherwise I've been doing a very silly thing.

On any given platform, loads, stores and integer operations will be fastest on datatypes that have the same width as the machine word. Some architectures provide explicit instructions for loading, storing and operating on half words or bytes or whatever, either for convenience or for speed. I wouldn't bother worrying about this until you found some bit of code you're working on where you need to perform X operations in Y ms but are currently taking 2Y ms and the generated assembly looked like it was wasting time marshalling and demarshalling bytes into 16-bit words or whatever. You're much more likely to be wasting time doing something like blocking on a slow peripheral or polling vs waiting for an interrupt anyways, at least in the code I've worked on.

peepsalot
Apr 24, 2007

        PEEP THIS...
           BITCH!

The MSP430 assembly instruction set definitely has opcodes for byte operations. I'm pretty sure the byte and word variations of these instructions all take the same number of clock cycles. You can check out the instruction set in the MSP430X2XX Family user guide (the chip family that comes with the launchpad).

Delta-Wye
Sep 29, 2005

Otto Skorzeny posted:

On any given platform, loads, stores and integer operations will be fastest on datatypes that have the same width as the machine word. Some architectures provide explicit instructions for loading, storing and operating on half words or bytes or whatever, either for convenience or for speed. I wouldn't bother worrying about this until you found some bit of code you're working on where you need to perform X operations in Y ms but are currently taking 2Y ms and the generated assembly looked like it was wasting time marshalling and demarshalling bytes into 16-bit words or whatever. You're much more likely to be wasting time doing something like blocking on a slow peripheral or polling vs waiting for an interrupt anyways, at least in the code I've worked on.

The operations in question were quick interrupt routines on a battery powered MSP430 sensor. A few extra instructions in the work loop could take away weeks of runtime. In theory anyway. It was a homework assignment at the time so we took note of the expected runtime based on the code as is and I didn't look into it further.

movax
Aug 30, 2008

Delta-Wye posted:

Here is a weird question that I thought someone here may have some insight off the top of their head. When I'm doing embedded programming (say, MSP430) I usually use the smallest datatype available. If I know a value will fit into a char, I'll use a char, even if I am not particularly memory constrained. That is to say I don't just hold ASCII characters in a char datatype, but use it as a 8-bit integer. Supposedly this doesn't work very well on a platform like the MSP430. I was told that the 16-bit processors will read a 16-bit value out of memory, mask it to an 8 bit value, do the required operation, then have to mask it again with the contents of memory when storing it. Needless to say, such masking operations would add computational overhead so if you are not memory constrained it is more computationally efficient to use a 16-bit (int) value.

I haven't taken the time to dig up documentation that specifies one way or the other, or compile c code to assembly and see what it is doing, but am interested if anyone has insight. If it adds a ton of overhead, this would be a counterproductive habit I should break because I am rarely that memory constrained. For cases like a massive array of 8-bit samples or something, the computational overhead may be acceptable, but otherwise I've been doing a very silly thing.

I like re-using a global types.h per platform I develop on (sometimes the compiler has a good one) where I just typedef byte/word/dword/etc to the appropriate compiler type for that platform (union'ing them comes in handy too sometimes). The 430 does have byte opcodes though as peeps said.

Victor posted:

Heh, at my job we're switching away from an Arduino Mega to our own board with an STM32F4xx chip for our quadcopter flight board. I think a few questions could easily winnow the ranks of applicants. For example, ask them if they like the IDE (correct answer is it's nice for simple stuff and ridiculous for anything non-simple), if they like the TWI library (correct answer is it's nice for simple stuff but horrible for robustness), etc.

How are you liking Google protocol buffers on embedded devices, so far? I have to do the same thing at work for our quadcopter. We're using AeroQuad code now and it's... not as robust as what we'd like. (I probably ought to be politically correct.)

As anyone who has read my posts knows I've kind of got a little hatred for the Arduino, but even putting that aside, I can quickly knock out applicants by asking them to do bitwise operations in C / write a sample ISR during interviews. I don't mind reminding them of the syntax or anything like that, but some people can't even grasp the concept of bitwise operations or architecting an ISR without function calls. When I inquired a bit further, well, there are apparently communities out there convincing people that Arduino skills make you an embedded wizard and the rest of us wasted our time/money in school/elsewhere acquiring our skills.

Victor
Jun 18, 2004

movax posted:

As anyone who has read my posts knows I've kind of got a little hatred for the Arduino, but even putting that aside, I can quickly knock out applicants by asking them to do bitwise operations in C / write a sample ISR during interviews. I don't mind reminding them of the syntax or anything like that, but some people can't even grasp the concept of bitwise operations or architecting an ISR without function calls. When I inquired a bit further, well, there are apparently communities out there convincing people that Arduino skills make you an embedded wizard and the rest of us wasted our time/money in school/elsewhere acquiring our skills.
Heh, sounds like you've found good embedded FizzBuzz tests. My preferred method of expressing disapproval of said Arduino folks is to point out where Arduino fails. For example, the Arduino TWI library is not fault tolerant, and can block one's program forever. My boss and I are in the process of writing robust, asynchronous TWI interfaces, although they may become unnecessary if the STM32F4xx TWI interface is sufficiently different. Another example of where Arduino will never be ready for prime-time is that they don't trust users to handle serial data ready ISRs. I suppose I could get jaded though, and resort to the easier criticisms. I endeavor not to, though! :v:

On the other hand, I hugely approve of the Arduino because it Just Works. I dunno how many other dev platforms do. It doesn't take many bits of configuration before it is extremely hard to track down why things aren't working and frustrate the hell out of someone who isn't already fantastic at troubleshooting. I got bitten the other day by a broken makefile, which didn't have dependencies set up properly and thus wasn't recompiling enough. I kept making code changes and the problem didn't get fixed! I know what it's like to experience that problem without the expertise I have now; I would often switch from doing digital electronics to computer games in high school because getting things to work was so insanely frustrating. I still made stuff like a graphical LCD I could write to with a VB mspaint-like program over the parallel port (later a countdown timer to when my new girlfriend would fly across the country to my senior prom, using Windows fonts), but I missed out on a lot because of how much of a pain in the rear end things were for someone without a mentor.

Someday, maybe I'll be part of making something Arduino-like, which combines Just Working with solid coding practices. I wanted to do that in college (around the time Arduino started up in fact) but other people were too busy. :-/ It seems like the people who know how to design and code really well don't have time for hobbyists. :smith:

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip
The arduino libraries aren't the only bad I2C routines out there.

Victor
Jun 18, 2004

Otto Skorzeny posted:

The arduino libraries aren't the only bad I2C routines out there.
If you're commenting on the version I helped write, criticism is more than welcome. I don't have much experience writing robust embedded code. If you're not, then yes, there is that pesky 80/20 rule.

movax
Aug 30, 2008

Otto Skorzeny posted:

The arduino libraries aren't the only bad I2C routines out there.

Everyone reinvents I2C libraries all the time, and some of the app notes companies put out have sample routines that aren't entirely production-level robust. IMO more companies should be putting out "offical" software libs / "extensive samples" for use by their customers. It can't take much more than 1 or 2 Sr. SW engineers + a week or two to release (even warranty-less) well-written, solid, interrupt-driven serial comm code for SPI/I2C and friends.

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip
e: didn't see movax's post, this is re: Victor

Haven't seen your code. Hope it's good. I2C is simple enough but it gets screwed up often. My recommendation is that you provide versions of your functions with specified timeouts.


In my post, however, I was referring to Cypress' I2C routines for the PSoC 3 and 5, which have a similar flaw that looks like

code:
...

send_a_thing();
while (!BIT_IN_A_SFR_WHICH_INDICATES_AN_ACK_WAS_RECEIVED);

...
Thus, if the slave doesn't get the first byte, it will hang forever waiting for a response that isn't coming. As I mentioned in an earlier post that consolidated my many and varied complaints about Cypress Semiconductor and the products thereof, on the bright it serves as a good excuse to gain experience with the implementation of a watchdog timer :v:

Blotto Skorzany fucked around with this message at 04:16 on Jan 22, 2013

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

movax posted:

Everyone reinvents I2C libraries all the time, and some of the app notes companies put out have sample routines that aren't entirely production-level robust. IMO more companies should be putting out "offical" software libs / "extensive samples" for use by their customers. It can't take much more than 1 or 2 Sr. SW engineers + a week or two to release (even warranty-less) well-written, solid, interrupt-driven serial comm code for SPI/I2C and friends.

Yeah, this and fixed point arithmetic are two wheels that get reinvented as octagons all the time, it's almost comical. :sigh:

movax
Aug 30, 2008

Otto Skorzeny posted:

Haven't seen your code. Hope it's good. I2C is simple enough but it gets screwed up often. My recommendation is that you provide versions of your functions with specified timeouts.


In my post, however, I was referring to Cypress' I2C routines for the PSoC 3 and 5, which have a similar flaw that looks like

code:
...

send_a_thing();
while (!BIT_IN_A_SFR_WHICH_INDICATES_AN_ACK_WAS_RECEIVED);

...
Thus, if the slave doesn't get the first byte, it will hang forever waiting for a response that isn't coming. As I mentioned in an earlier post that consolidated my many and varied complaints about Cypress Semiconductor and the products thereof, on the bright it serves as a good excuse to gain experience with the implementation of a watchdog timer :v:

Yep, I did that exactly whilst writing some quick and dirty I2C code (I believe that is also in Microchip stuff). OR maybe it was waiting on a CAN Tx message, can't remember. Setting a timer or utilizing a RTOS where you have global WDTs will take care of issues like that though the latter is a bit heavy for most projects.

Victor
Jun 18, 2004

Otto Skorzeny posted:

Haven't seen your code. Hope it's good. I2C is simple enough but it gets screwed up often. My recommendation is that you provide versions of your functions with specified timeouts.
Yep, there are timeouts. They aren't implemented in a portable fashion yet. More eyes make for better code, though!

movax posted:

Everyone reinvents I2C libraries all the time, and some of the app notes companies put out have sample routines that aren't entirely production-level robust. IMO more companies should be putting out "offical" software libs / "extensive samples" for use by their customers. It can't take much more than 1 or 2 Sr. SW engineers + a week or two to release (even warranty-less) well-written, solid, interrupt-driven serial comm code for SPI/I2C and friends.
Hahahaha this is so true. I wrote the below:

ASHIMA.md posted:

embedded-atmel-twi is a robust driver module for Atmel's Two Wire Interface (I2C) on Atmel's AVR ATmega chips. It includes handling for bus errors not documented in Atmel's TWI slave and master Application Notes (the flowcharts are incorrect), and implemented in the slave code but not the master code. The Master driver can operate in a synchronous or queued asynchronous mode. The slave implemented so far implements a multi-byte memory interface.
That's right, Atmel's TWI master application note has it handling bus errors in a way that will stall the I2C bus if not all execution. :doh:

armorer
Aug 6, 2012

I like metal.
All of this dislike for Arduino (coming from embedded programmers) has me wondering... Do you really get that many applicants who only have a bit of Arduino experience and expect that to land them an embedded programming job? I write software for a living and I can't imagine someone learning Scratch and expecting that to land them a job designing back-end data processing systems. (If you are not familiar with Scratch, it is an extremely simple graphical programming language to teach kids about coding.) Is the dislike mostly because of your professional background?

I personally think Arduino is great for the hobbyist crowd, artists, kids, and for just getting your feet wet with electronics. There is a huge, active, and friendly online community. There are recent books with easy to follow projects. It is very easy to get things up and running without having to read (and comprehend!) a 200+ page datasheet. I can't imagine someone thinking that it qualifies them for an embedded systems job though. It is more like a gateway drug to embedded programming. At least, it was for me.

A while back I picked one up on a whim, along with an ethernet shield and some electronic components. In barely more than one evening I had a fully automatic Nerf gun that I could fire remotely by clicking a button on a web page. (Having a strong software background, it was trivial to get that project up and running.) If I were to do it now, I would use a Raspberry Pi because it would be cheaper, easier, and allow for a lot more features. At the time though the Pi wasn't available. After that project I quickly realized that buying a $30 board for a project was completely ridiculous, so I figured out how to build my own Arduino compatible circuit on stripboard for about $6. I made a bunch of other little toys that way, and got better with the electronics side as a result.

Some of my project ideas were extremely space constrained though, and even $6 was excessive for some things, so I started to teach myself AVR C so that I could directly program ATtiny85 chips. That is where I am now, still learning my way around Atmel's line, and trying to develop some good practices for embedded development in general. If the Arduino didn't exist though, and I had to start here rather than work my way through easier successful projects, I would never have picked up this hobby. The layers of abstraction that Arduino provides make it easy for someone to get a few successes under their belt.

KetTarma
Jul 25, 2003

Suffer not the lobbyist to live.
Getting an Arduino and making projects definitely was a good way to get used to the terminology and basic concepts before moving on to AVR. I'd like to think I would've stuck with it before getting an Arduino... but there's a huge difference in the success you feel from making a light blink with a 555 timer and making a robot that can avoid obstacles. Now that I'm comfortable with Arduino, I've been trying more things that don't involve it.

Captain Capacitor
Jan 21, 2008

The code you say?
I'm already hitting my first obstacles with my project. I've got a MicroSD breakout board hooked up to my board using Software SPI (simply because I lack the proper cables at the moment) and the SD library I'm trying at the moment (although all of them seem to be based on fat16lib) seems to be giving me issues. I'm getting inconsistent file writing issues. Sometimes the files aren't even opened, or the bool operator of the File object will not necessarily be indicative of whether or not the file is writable. :sigh: I just want to log to a file.

FSMC
Apr 27, 2003
I love to live this lie
First try a different uSD card. I found sticking a capacitor usd supply fixed problems I was getting. Pull-up resistors on the data lines might help if the breakout board doesn't have any. You can also narrow down the problem between hardware/software by writing raw data, reading back and then comparing.

Arcsech
Aug 5, 2008
Anybody have an "Complete Idiot's Guide to Interrupts on the Stellaris Launchpad"? Because I've been beating my head against the wall with this drat thing.

All I want it to do is turn on the loving LED when I press the button, and I want it to do it with an interrupt. But it never hits the breakpoint I set at the start of the ISR. The example code they have with timer PWMs isn't really all that helpful.

some kinda jackal
Feb 25, 2003

 
 
Vague question: Is there any MCU with an on-package accelerometer?

I mean a single chip solution, not a development board. I can obviously just add a separate accelerometer to my project but I'm just curious if this thing exists.

Delta-Wye
Sep 29, 2005

Martytoof posted:

Vague question: Is there any MCU with an on-package accelerometer?

I mean a single chip solution, not a development board. I can obviously just add a separate accelerometer to my project but I'm just curious if this thing exists.

I've never seen such a thing, and to be honest, I'd be surprised if it was common place at the moment. As far as I know, MEMS hardware takes special manufacturing processes than typical ICs and combining the two with a complicated MCU design would be a feat. That said, I am seeing more tightly coupled IMU chips lately (https://www.sparkfun.com/products/11028, which includes some amount of onboard processing) and a SoC with a builtin IMU isn't a terrible idea on the surface.

movax
Aug 30, 2008

Arcsech posted:

Anybody have an "Complete Idiot's Guide to Interrupts on the Stellaris Launchpad"? Because I've been beating my head against the wall with this drat thing.

All I want it to do is turn on the loving LED when I press the button, and I want it to do it with an interrupt. But it never hits the breakpoint I set at the start of the ISR. The example code they have with timer PWMs isn't really all that helpful.

Most interrupt controllers function similarly:

- There's an interrupt enable register
- Interrupt flag status register
- Possible interrupt vector/etc selection
- Enable Global Interrupts after everything is set up

It sounds like (assuming the debugger is configured properly) you're not enabling the interrupt properly (or the interrupt source isn't happening) if it's never breaking. Is it a change notification interrupt or something?

some kinda jackal
Feb 25, 2003

 
 
Is your ISR defined in the startup_xyz_something.c file?

Arcsech
Aug 5, 2008

Martytoof posted:

Is your ISR defined in the startup_xyz_something.c file?

Yeah. I should have put more detail, I was just very tired and frustrated when I made my last post.

I have this keypad: https://www.adafruit.com/products/419

And I'm trying to make it work with interrupts. I wrote some code to poll it and modified it, so it's not the best or most efficient code, this is just me screwing around, but here's all the relevant code:

[edited out-I'm dumb]

Edit: I just missed that you need to enable interrupts after registering your interrupt handler.

Arcsech fucked around with this message at 10:06 on Feb 3, 2013

peepsalot
Apr 24, 2007

        PEEP THIS...
           BITCH!

Anyone used the TI capsense library for msp430? http://www.ti.com/tool/capsenselibrary

Every time I try to read the documentation for this thing I just end up more confused than when I started. I'm trying to mash together one of the examples included with the capsense library with this hardwrae uart example, but they are designed for different clock rates. And I'm thoroughly confused about how any of these clocks are being used.

For now I'm just trying to limit to pinOsc, since that requires no extra components.

The explanation of the fastRO vs RO in the docs didn't make any sense to me. I can't tell what are the practical applications, pros/cons of any of these thousands of different ways to set up this capsense poo poo.

In structure.h there are some constants that you are supposed to comment/uncomment I guess, and then CTS_Layer and CTS_HAL check if they are defined, and sets up things differently depending on what is there:
#define RO_PINOSC_TA0_WDTp 65
//#define RO_PINOSC_TA0 66

So the first one uses TA0 and the watchdog timer for something, but the second one only needs TA0? Why?

Captain Capacitor
Jan 21, 2008

The code you say?
This is going to sound really dumb, but I just got the chance to head in to an actual Radio Shack (as opposed to the renamed Canadian ones) and it was amazing. Actual ICs and everything. PIC controller kits, Parallax stuff, shields, displays and some awesome starter kits. Managed to get an Arduino Micro and Esplora and save on the shipping.

:smith::canada:

Bad Munki
Nov 4, 2008

We're all mad here.


Radioshack is all right in a pinch, and as long as you aren't in one that is JUST cell phones, they'll usually keep their parts bins fairly well stocked, but I find that their parts are generally 5-10 times more expensive than, say, digikey or mouser, even after you factor in shipping. I mean, a buck for a 5-pack of resistors? Really?

The other stuff (shields and displays and PICs and kits and such) sounds a bit surprising, though. Could be that whoever runs that particular shop is into that stuff, I know they have a fair degree of freedom as to what they stock.

Bad Munki fucked around with this message at 15:30 on Jan 30, 2013

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip
I have never been to a Radio Shack that had discrete components or ICs. I thought they were the stuff of myth

armorer
Aug 6, 2012

I like metal.
I am fortunate (?) enough to have a Radio Shack two blocks away that stocks discrete components. The selection and prices leave a lot to be desired, but I have been happy for its existence a few times when I just needed one part to wrap up a project. The people who work there have no idea what most of the parts are though, and are generally useless if I have questions.

csammis
Aug 26, 2003

Mental Institution
The Radio Shacks around me (suburban Kansas City) all stock the shields and displays and so on but their selection of discrete components is maddening. Only a few different resistor and capacitor values and all the stores in the area seem to have the same stock :smith:

Bad Munki
Nov 4, 2008

We're all mad here.


I think it really depends on whether it's a cell-phone radioshack or a "proper" radioshack. The shacks in Fairbanks AK, Des Moines IA (two of them there that I checked), and even the mall here in Erie PA all carry discrete components.

As for the employees knowing anything about the stuff, yeah right, I mean, their job is to operate the cash register. Sometimes a manager will be able to help you find a part, but it's usually little more than "the parts drawers are over there." Which is all pretty understandable to me, really: brick and mortar stores really can't compete with these online shops like digikey and mouser that can offer a zillion individual parts at cut-rate bulk prices, it's just not feasible. So instead they have to offer a very limited selection, and mark the parts up enough to even make it worth the time it takes to stock them, and even then, they sell so little of it that most store managers probably just view it as wasted space.

Jonny 290
May 5, 2005



[ASK] me about OS/2 Warp
The good Radio Shack here has the Sparkfun/whatever shelf with not only Arduinos but stuff like BASIC Stamps and other platforms, and has full-height parts drawer racks. And they know that when I walk in that I know what I need already, haha. I actually bought my first Uno there on a complete impulse. 35 bucks isn't bad for instant gratification.

Adbot
ADBOT LOVES YOU

Bad Munki
Nov 4, 2008

We're all mad here.


That sounds like an exceptional setup, that's pretty cool. And yeah, there's a lot to be said for being able to fondle a few parts and then walk off with them.

  • Locked thread