64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›2 »

Delta-Wye: Sep 29, 2005

reading posted:

CodeComposer Studio, although lovely for a hobbyist due to the code size limitation, is pretty great for using TI's chips because the debug options in it are great for reasons mentioned above. Breakpoints are great for watching variables change as the code runs through, although I wish I could do it without causing big pauses in the execution.

I ended up buying a copy of cross studio for my msp430 stuff, but now that I'm more comfortable with gdb I've been thinking about moving to more ggc-based tools. Does anyone have experience with running gdb over a jtag? I get the impression it would be relatively painless but I haven't tried yet.

# ¿ Nov 15, 2013 18:06

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 13:26

Delta-Wye: Sep 29, 2005

JawnV6 posted:

Sorry, I don't mean to sound so snippy.

It's just that debug is very, very important. Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging can easily get to the 90% mark on a project without any red flags then have horrendous integration debug because they can't easily peek at what the software's doing. At that point it's a difficult decision between engineering a one-off solution with an oscilloscope and hardware or changing the entire toolchain. Neither impossible, but I wouldn't want to implement either right up against a deadline.

Notice that everyone who said IDE's weren't necessary backed it up with very good practices. Unit tests, strict development, etc. It takes some expertise to figure out when a debugger isn't necessary.

Well, you're still being snippy :colbert:

I like the power and configuration of command line tools, I think they can be used to great effect in those good practices you mention. I sometimes find myself being too lazy to run through with gdb but that's hardly the tools fault. When building things like automated unit testing, its great to keep a consistent toolchain across different projects and architectures and the gnu stuff seems like a logical choice.

SybilVimes posted:

Personally, I'd still be happier with a consistant and easily ported system that allows me to get on with debugging if I need to, rather than learning the quirks and oddities of a new system for every hardware platform. Thus the 'command line land' with gdb (and gdb-stub) is preferrable to me.

As one of those programmers from linux land, I decided it would be worth trying to get my dev environment for msp430 moved over to the gnu chain under linux. I was mostly worried about the drivers for the programmer (a Olimex special from quite a few years ago that can be finicky in Windows with the official drivers).

Installing the cross-development environment in gentoo was easy enough:

code:

emerge crossdev
emerge mspdebug
crossdev -t msp430

Compiling code is pretty easy:

code:

user@host$ msp430-gcc -mmcu=msp430f2131 msp430test.c -Wall -g -o testapp

To program the chip with the program, I need to use mspdebug. I was really worried about this step, but I plugged in my programmer and ran the list devices command and got this:

code:

user@host$ mspdebug --usb-list
Devices on bus 001:
    001:002 8087:0020 
    001:001 1d6b:0002 
Devices on bus 002:
    002:002 8087:0020 
    002:001 1d6b:0002 
    002:095 1a40:0101 
    002:091 046d:c313 
    002:104 046d:c219 
    002:108 15ba:0002 Olimex MSP430-JTAG-TINY (v1)
    002:102 046d:c52f 
    002:099 1a40:0101 
    002:096 1a40:0101 
    002:103 046d:c52b 
    002:098 058f:6387 
Devices on bus 003:
    003:001 1d6b:0002 
Devices on bus 004:
    004:001 1d6b:0003

Cool, found it without any actual work on my part. It always surprises me when Linux ends up with better support than Windows thanks to some dude working in his basement. Anyways, programming and starting the gdb stub isn't too bad either:

code:

root@host# mspdebug olimex-v1 -j
(mspdebug) prog testapp
Erasing...
Programming...
Writing  124 bytes at e000 [section: .text]...
Writing   32 bytes at ffe0 [section: .vectors]...
Done, 156 bytes total
(mspdebug) gdb
Bound to port 2000. Now waiting for connection...

Then I run the debugger and connect to the remote target:

code:

user@host$ msp430-gdb
(gdb) symbol-file testapp
Reading symbols from /home/dboyer/msp430/testapp...done.
(gdb) target remote tcp::2000
Remote debugging using tcp::2000
0x0000ffff in __ivtbl_16 ()
(gdb)

I have a ways to go yet; this is extremely cumbersome at the moment but these tools are scriptable. It only took me a few minutes to get a "make debug" command that compiled the project (as necessary), programmed the chip, and started up the gdb stub in one go. I should be able to turn it into a couple quick and easy commands to do just about anything I need if I want to stay on the commandline. m3oh has some information that leads me to believe that Eclipse can be made to run all of this stuff if I wish to move to a GUI, which would be pretty slick too.

In the interest of full disclosure, I was one of the printf debuggers for far too long

# ¿ Nov 16, 2013 22:35

Delta-Wye: Sep 29, 2005

Martytoof posted:

Hey gang. I bought a new car so I want to put a neat garage door opener in it. In true nerd fashion I want to DIY this. Obviously the programming aspect of it isn't difficult. It'll just be two uC's handshaking over some kind of wireless sensor network. That's kind of where I break down though. Xbee is definitely one way to do this, but Xbees seem to be kind of pricey per-unit. I was hoping to do this whole thing for under $20. Any recommendations for lower cost wireless UART communication? The range literally only has to be like 20 feet so I don't need anything super fancy. I just don't really know what my options are other than the Xbees I'm familiar with.

Sparkfun has a bunch of dumb wireless modules that may work for you. Are you thinking you'll need bidirectional communication?

# ¿ Dec 5, 2013 04:21

Delta-Wye: Sep 29, 2005

Yeah, I think those look pretty nice for bidirectional comms. They look like they will need some configuration before they are ready to rock - do you have a library? If not, be aware you'll have to write a driver of some sort.

These would provide drop-in wireless, but are unidirectional and probably shittier in most other respects to be honest:

https://www.sparkfun.com/products/10532
https://www.sparkfun.com/products/10534

# ¿ Dec 5, 2013 06:41

Delta-Wye: Sep 29, 2005

Bad Munki posted:

I bought a bag of these (not that exact auction or seller, but the same product, quantity, and price point):

http://www.ebay.com/itm/10pcs-NRF24...=item5d4551b2f2

I haven't gotten around to trying them out yet, but there are some good libraries for them and they might do what you want. And the price is hard to beat, a 10-pack for (or so) is pretty drat cheap, so you can put them in whatever else you want, too.

I've used nordic radios - I mostly didn't recommend them because I've never seen them that cheap. That's cheaper than the individual chips :catstare:

edit:

Sparkfun's done some neat things with Nordics:
https://www.sparkfun.com/news/729
https://www.sparkfun.com/tutorials/135

Admittedly, the radio is built into the hardware they're using on the second one.

s/car door/garage door/g

Delta-Wye fucked around with this message at 18:44 on Dec 5, 2013

# ¿ Dec 5, 2013 18:36

Delta-Wye: Sep 29, 2005

Mr. Powers posted:

I didn't mean to suggest that they are similar, but there are some parallels in terms of design patterns. I.e. if you want to do x in C, you can do the same x in VHDL this way.

What kind of 'things' do you have in mind? I'm leaning towards JawnV6's opinion in general, but there may be some carry over I guess.

# ¿ Dec 5, 2013 20:31

Delta-Wye: Sep 29, 2005

Rescue Toaster posted:

What's the best way to start learning the linux kernel, especially in regards to device driver development. Something like Raspberry Pi? Beagle Board Black? Something I could like... hook up a SPI device and provide a /dev/ for it would be the sort of platform I'm looking to start with.

As long as the Linux kernel has decent support for the SoC it shouldn't really matter. I've had to do a bunch of patch backporting to get GPIO, power management and a few other features working correctly on a gumstix board.

I suppose that's one way to start learning the linux kernel though :getin:

# ¿ Dec 11, 2013 22:30

Delta-Wye: Sep 29, 2005

Rocko Bonaparte posted:

Can somebody confirm for me that there isn't really a turn-key solution for interfacing with SPI in Python with the Raspberry Pi? I see some people have written wrappers, which I will be trying, but I was hoping by now there was something standard and blessed.

Have you tried to read and write directly from /dev/spi with the normal file handling functionality?

# ¿ Dec 18, 2013 19:59

Delta-Wye: Sep 29, 2005

Rocko Bonaparte posted:

I didn't have a handle for it in /dev/spi. Actually it looks like SPI is kind of the shady area of the Raspberry Pi, which makes me sad. There also doesn't appear to be a Python3-friendly module for SPI interaction that would work on the Raspberry Pi. At best I eventually got a spidev wrapper working in Python2 enough to light an LED on and off if I told it to just transmit piles of 0xFF's and 0x00's alternately. I couldn't get anything coherent out of this MCP3008 ADC package I was trying to test with a potentiometer. There's some C code out there so I am thinking I have to drop down into C-land and try ioctl or making my own driver; the Python honeymoon ended pretty quick.

There is nothing wrong with C ( :getin:

), but Python can do ioctl calls.

EDIT: Although if the hw support is poo poo, you're hosed either way. I'm always surprised how terrible the software support for SoCs seems to be. Developing one is expensive enough, I'm surprised it isn't worth hiring a coder to knock out the necessary kernel parts for rock-solid support.

Delta-Wye fucked around with this message at 05:08 on Dec 20, 2013

# ¿ Dec 20, 2013 05:04

Delta-Wye: Sep 29, 2005

Vcc/gnd swap? :smith:

# ¿ Feb 16, 2014 04:16

Delta-Wye: Sep 29, 2005

The MSP430 is engineered from the ground up for that target market. IMHO it makes them a bit of a pain in the rear end to use; there are tons of clock domain stuff to fiddle with, and every peripheral has more options and configuration steps compared to PIC or Atmel's offerings in order to shave off a bit of power usage here and there. TI has a few app notes that may be of interest though. I like this one, it's simple and somewhat counter intuitive if you haven't studied static vs. dynamic losses in logic gates.

https://www.ti.com/litv/pdf/slyt356

# ¿ May 15, 2014 15:18

Delta-Wye: Sep 29, 2005

Pan Et Circenses posted:

I got an STM32 up and running with just the ST-Link programmer, GCC, and some open source Linux based ST-Link flasher/gdbserver software. The only vendor tool there was the hardware programmer. That project was actually C++, and the whole setup worked fine... never understood the embedded obsession with sicking to straight C!

If you don't have a good bit of experience with embedded systems, I wouldn't really recommend it at all as a way of starting out. If you're looking to get a little deeper, it's probably a good project. Make sure you understand linker scripts and why you'll need to use one to produce your binary.

My experience is that the things that makes C++ valuable over C (polymorphism, for example) come with undesirable run-time overhead.

If you're used to developing for a STM32 and not a PIC8 or something of equivalent power, then this is largely why you don't understand it; it's an old holdover from a crowd of curmudgeons.

# ¿ Dec 2, 2014 07:02

Delta-Wye: Sep 29, 2005

poeticoddity posted:

I don't have to send a lot of data (usually under 10 bytes at a time and generally at least double-digit milliseconds between transmissions) but it does need to move quickly. On some things, the time sensitive stuff could be moved around if I have a good way to sync a time reference between uCs.

Time synchronization is a common problem:

http://www.cs.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html#Section4.0

Check out flooding time protocol.

# ¿ Dec 13, 2014 03:23

Delta-Wye: Sep 29, 2005

ante posted:

Hey, so give me two good reasons to use anything other than internal oscillators.

I would assume better stability / accuracy, but other than that... ?

An example would be a situation where you wanted multiple clock domains. For example, MY UNDERSTANDING is that an external 32KHz clock running a timer peripheral is cheaper power-wise than running the internal RC oscillator on an MSP430. However, you may want to run the intenral oscillator for the CPU when it wakes up to do work because who cares about the accuracy of an 4 or 8 MHz clock when you're only running a couple dozen instructions and then going back to sleep.

# ¿ Jan 31, 2015 16:25

Delta-Wye: Sep 29, 2005

Vivado doesn't support the spartan 6 family because gently caress you, that's why.

Anything seems like it would be an improvement over the vendor applied tools when it comes to xilinx and altera, but I'm not sure if I'd go running to altium of an companies expecting an improvement.

# ¿ Jul 13, 2015 18:46

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 13:26

Delta-Wye: Sep 29, 2005

thanks dad

# ¿ Aug 4, 2015 19:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›2 »