|
Thanks for the input guys. I actually came up with a sweet projectbox enclosure for mine and dragged a few cables out the back. I'll grab a pic on Monday when I get back to the office. Really loving Atmel Studio + Dragon combo right now though.
|
#
?
Jun 15, 2013 00:49
|
|
|
|
| # ? May 10, 2024 03:55 |
|
|
Hey STM32 guys - Sony is making it's smart watch "officially" hackable. http://developer.sonymobile.com/services/open-smartwatch-project/ Looks like it might be fun to play around with, although the stock firmware already does a ton of things.
|
|
#
?
Jun 15, 2013 13:30
|
|
|
Does anyone have an experience with MRAM? Was thinking of using some for a project because it has some really nice advantages over Flash, but it seems like it's kind of a new technology--the only commercial vendor seems to be Everspin, and it's their only product. Would probably be using the SPI verson. http://www.everspin.com/overview.php
|
|
#
?
Jun 16, 2013 05:32
|
|
|
I would at least take a look at FRAM. There's a few different manufacturers, and it's more mature. I have no idea what the MRAM cost is, but FRAM can get fairly cheap in reels of 1500 for such a specialized chip. If you just need a few for a project, FRAM is available in regular packages (soic8) vs just QFN, though it is about $12 bucks per chip for say 1Mb.
|
|
#
?
Jun 16, 2013 14:44
|
|
|
Rescue Toaster posted:I would at least take a look at FRAM. There's a few different manufacturers, and it's more mature. I have no idea what the MRAM cost is, but FRAM can get fairly cheap in reels of 1500 for such a specialized chip. TI makes an MSP430 with some FRAM embedded on it but it's ~64KB tops
|
|
#
?
Jun 16, 2013 15:36
|
|
|
Yeah he didn't say how much he needed but those MRAM chips start at ~256Kb, so I'm guessing quite a bit. Obviously if you need a smaller amount of persistent storage then FRAM will really win out.
|
|
#
?
Jun 16, 2013 20:15
|
|
|
We use a couple FRAM chips on my main project at work and the stuff is the tits - fast, real low power, easy to talk to since there are no delays, etc. It's kind of expensive but definitely worth it. Be aware that Ramtron et al. sometimes switch back and forth between kbits and kbytes in their documentation, but there is almost always a spot where the size of the chip is specified unambiguously (eg. it will say "1 MB (131,072 bytes)" or something). I've been waiting on samples from Everspin for a while now, and I'll report back when they send me something and I get a chance to try it out; my understanding just from reading datasheets and looking at prices is that MRAM scales up better and will be cheaper for 1 megabyte+ chips, but FRAM is great if you just want 128k or whatever.
|
|
#
?
Jun 16, 2013 20:36
|
|
|
It's going to replace a larger flash that gets used for logging/daq. But the idea is that the speed, extra write cycles, and byte-addressable writes will let me use a more efficient data structures and just simpler code overall to make up for the smaller size.
|
|
#
?
Jun 16, 2013 20:49
|
|
|
That's exactly what we use FRAM for, I expect MRAM will fit the bill just as well. When you get to selecting components you'll find that generally I2C for these NVRAM chips tops out at 400 kHz, SPI at 3.4 MHz and the manufacturer's parallel protocol at 40 MHz or so (and get 4 or 8 bits at a time), so if you have free pins you can go Pretty Quick.
|
|
#
?
Jun 16, 2013 22:17
|
|
|
One possibility that I used once was if your data kind of streams in and/or you have to modify previous data before committing, but you can't afford to lose any was to cache it in a small FRAM (2KB in this case) and then when that was filled up commit it to a large block flash. 2KB(16Kb) FRAM and 8MB (64Mbit) flash, two little 8-SOIC chips for less than 4 bucks these days, and could run as fast as the SPI interface on my micro could (I think FRAM was 20mhz, flash was like 25Mhz). Or now just using one of the MSP430's that has FRAM in it, if that chip works for you. Of course this might not work depending on your specific requirements, just an idea. Plus you can use some of the FRAM for statistics, preferences, number of blocks written, etc... since that data changes often. In most cases you might only need like 512 bytes of FRAM for actual data to make a 256 byte ping/pong buffer for a flash block. Rescue Toaster fucked around with this message at 01:07 on Jun 17, 2013 |
|
#
?
Jun 17, 2013 01:00
|
|
|
Has anybody ever used gdb for debugging a target from a host machine? I'm just curious, I learned about it in a class and it sounds complicated since gdb's command line interface gets very difficult to use very quickly, since terminals cannot display as much info as a GUI. So cross-debugging on a target seems really confusing, but kind of neat.
|
|
#
?
Jun 18, 2013 03:37
|
|
|
Kire posted:Has anybody ever used gdb for debugging a target from a host machine? I'm just curious, I learned about it in a class and it sounds complicated since gdb's command line interface gets very difficult to use very quickly, since terminals cannot display as much info as a GUI. So cross-debugging on a target seems really confusing, but kind of neat. I have, and it is not really all that bad. But, I have always used the command-line GDB without a GUI, so it really wasn't much different to me. Like any tool, command-line GDB is only useful once you memorize a handful of commands that you use all of the time and then branch out into the more advanced features.
|
|
#
?
Jun 18, 2013 03:56
|
|
|
Slanderer posted:Is TI still horrible at the documentation for those things? I've been wanting to get a Beaglebone Black recently, since my original Beaglebone disappeared a long while back. I remember the documentation for the hardware being incomplete at the time, and not all of the basic drivers were done, which was cool. I've quite enjoyed my BBB. I have been very happy with the projects that I've managed to do with it over the three months that I've had it. The 3.8.x kernel has started to become far more stable, which is probably the only kernel branch that BBB users are interested in right now (it is where most of the BBB's features are being enabled). USB has come a long way in just the last month or so, HDMI audio/video stabilized about six weeks ago, Android support is catching up slowly, and documentation is continuing to spread via wikis and mailing lists. Now, that being said, most of the BBB community has a superficial view on the platform. Helpful souls will gladly provide suggestions when you have problems, but those solutions are being cooked up by a much smaller part of the community. The others, while avid users, just parrot many solutions back to people on the mailing lists and whatnot. I've had to solve many of my own problems by digging into the kernel and looking things up for myself, but at least I try to share what I've found with others to hopefully avoid having someone else do the investigation over again because he/she couldn't find the answer to the same questions. With the BBB, I've entered what I like to call the "dumb looks" phase of experience. When I ask questions, I just get dumb looks. I'm no expert, but I'm in that no-man's land where what I'm doing is just above the waterline of where most of the knowledge exists. That means that I'm down to picking apart the kernel code and digging through TI's 4000 page documents. It can be rewarding, but it can also be pretty tiring. But, it is also the point where neat, non-trivial projects begin to take shape. It's a good little platform. Give it a try.
|
|
#
?
Jun 18, 2013 04:11
|
|
|
I'm just going to chime in that it's been a bit of a struggle to get started on the BBB, but I was going right for Kernel development so my experience isn't exactly typical. I'm currently trying to port a project from 2010 to work with the BBB and I'm dreading every next step.
|
|
#
?
Jun 18, 2013 04:42
|
|
|
Kire posted:Has anybody ever used gdb for debugging a target from a host machine? I'm just curious, I learned about it in a class and it sounds complicated since gdb's command line interface gets very difficult to use very quickly, since terminals cannot display as much info as a GUI. So cross-debugging on a target seems really confusing, but kind of neat. If you don't like command line debugging, there are a lot of gui's that can use GDB as a backend (I use eclipse).
|
|
#
?
Jun 18, 2013 09:40
|
|
|
Kire posted:Has anybody ever used gdb for debugging a target from a host machine? I'm just curious, I learned about it in a class and it sounds complicated since gdb's command line interface gets very difficult to use very quickly, since terminals cannot display as much info as a GUI. So cross-debugging on a target seems really confusing, but kind of neat. I have found that cgdb makes the learning curve just a little softer: http://cgdb.github.io/
|
|
#
?
Jun 18, 2013 12:14
|
|
|
hendersa posted:I've quite enjoyed my BBB. I have been very happy with the projects that I've managed to do with it over the three months that I've had it. The 3.8.x kernel has started to become far more stable, which is probably the only kernel branch that BBB users are interested in right now (it is where most of the BBB's features are being enabled). USB has come a long way in just the last month or so, HDMI audio/video stabilized about six weeks ago, Android support is catching up slowly, and documentation is continuing to spread via wikis and mailing lists. I second the "dumb looks" thing. I asked for help with an issue with my beaglebone A6 on a forum, and I made sure to point out that it WASN'T the loving beaglebone black, it was the regular one, and I got people telling me to reflash the eMMC and so forth (which only exists on the BBB). So loving irritating.
|
|
#
?
Jun 20, 2013 03:23
|
|
|
I've never used embedded systems beyond low/mid performance MCUs programmed in C, and usually that's sufficient for my needs. However for an upcoming project I will need a substantial amount of data throughput, so I think I will need to leverage a more powerful platform such as a Beagleboard. However I only have vague ideas on how I would do so. Basically what I have is two slave devices which will need to spew out a stream of sampled data (average of about 2MB/s from each, packet size is flexible), and I need a master unit to suck up that data and either store it on nonvolatile memory, analyze and compress it in real time, or send it to another host PC which can do those things. The interface between the two slave units needs to be either wireless (could be SPI, USB, or ethernet, depending on what the wireless adapter needs), or fiber optic (USART) if wireless is too much to ask. For the two slave devices I plan on using Atmel UC3 MCUs, I'm only looking at using one of these platforms for the master unit. So I've never done any Linux/Ubuntu development (most of my MCU work revolves around timing-intensive low level tasks, coded in C or assembly), so how suitable would a Rasberry Pi or Beagleboard be for handling high speed data acquisition? Ultimately I've never done anything with wireless networking, but I'm wondering how difficult it would be to use wifi to handle the telemetry. Has anyone here used any USB wifi adapters and use them as to communicate with other slave devices like this (as opposed to just connecting into another pre existing network)? Just trying to get a sense of whether I'm looking at in the right direction, thanks in advance!
|
|
#
?
Jun 22, 2013 13:00
|
|
|
You should be able to get that kind of performance out of USB 2.0, but programming reliable high speed USB drivers can be pretty tricky from what I understand. I haven't done it myself but a coworker just finished a project where he was doing something similar and ran into a few surprises, despite being a guy who really knows his poo poo about comms.
|
|
#
?
Jun 22, 2013 15:55
|
|
|
A while back I looked into coding a USB interface for the Atmel UC3 devices, and it was so overwhelmingly complicated that I gave up and went for a FTDI solution. Atmel gave pretty much no support for their devices and USB itself is far more complicated than I expected it to be. I'd like to avoid having to code my own drivers if possible. But USB itself isn't really a solution for me, since is would only be an intermediate link in the chain (assuming you're suggesting I use a USB wifi adapter). The wifi part itself is a much bigger mystery for me. I was hoping that there were existing drivers specifically for the hardware platform that let you talk to the wifi as a port directly, without having to worry about the USB part of it.
|
|
#
?
Jun 23, 2013 02:41
|
|
|
It sounds like the easiest thing to do would be to find a WiFi g device that communicates over SPI and can handle at least 20 Mbps (I'm guessing such things exist). (20 / 8 = 2.4 MB/s) You might actually need more; it depends on the amount of SRAM you have available to buffer the data-taking when it's sufficiently over 2.4 MB/s.
|
|
#
?
Jun 23, 2013 19:49
|
|
|
Victor posted:It sounds like the easiest thing to do would be to find a WiFi g device that communicates over SPI and can handle at least 20 Mbps (I'm guessing such things exist). (20 / 8 = 2.4 MB/s) You might actually need more; it depends on the amount of SRAM you have available to buffer the data-taking when it's sufficiently over 2.4 MB/s. I've found a lot of SPI/USART wifi modules that have radio baud rates of 54Mbps, but it seems that their actual throughput rates are always far lower (most limit at 1Mbps). One exception I've found is this guy which advertises 22Mbps of throughput, but it seems that a good deal of the networking tasks has to be handled by your host MCU, and of course it's meant to be used with drivers from full-blown operating systems (winXP, winCE, or Linux 2.6.xx). Maybe that would be okay with a Beagleboard though?? Even then that would only be okay for the master side, for the slave side I'd still need a fast wifi module that doesn't require an OS... I've read some literature about overhead and efficiency in wifi protocols, and apparently it's quite feasible to get actual throughput of at least half of the radio baud rate, but for some reason modules that actually do so are incredibly rare... edit: actually redpine signals seems to make a bunch of modules (warning 13MB PDF), a few of which may fit the bill. Most have the TCP/IP bullshit handled internally, at the cost of lower throughput, while a couple require the bullshit to be handled by the host, and advertise much higher throughput. They say they provide drivers for both options (including the UC3 series MCUs I was planning on using on the slaves) but I can't actually find any details on that... at least it's a lead. ANIME AKBAR fucked around with this message at 21:42 on Jun 24, 2013 |
|
#
?
Jun 24, 2013 12:50
|
|
|
I'd like to make a composite USB device that acts as a virtual serial port and storage device. Lots of uCs will work for this, of course, but I was hoping someone here might have a recommendation for something with a good USB library or sample code. Cheapish dev tools would be cool.
|
|
#
?
Jun 28, 2013 17:41
|
|
|
taqueso posted:I'd like to make a composite USB device that acts as a virtual serial port and storage device. Lots of uCs will work for this, of course, but I was hoping someone here might have a recommendation for something with a good USB library or sample code. Cheapish dev tools would be cool. If you want to go that way, the Linux usb gadget stuff in the kernel will provide that if you have a processor (arm, most likely) that will run linux.
|
|
#
?
Jun 28, 2013 18:24
|
|
|
Delta-Wye posted:If you want to go that way, the Linux usb gadget stuff in the kernel will provide that if you have a processor (arm, most likely) that will run linux. The USB stuff is just going to be a configuration interface to an industrial device. The old version runs on a beefed up 8051 micro. I would prefer not to expand to something big enough to run Linux if I can help it. STM32F4 is what I'm looking at right now, and the Discovery dev board is cheap. But, Atmel actually has composite USB sample code and ST doesn't (that I can find). vvv I probably wouldn't be much help. My project will need to be on our own HW and the storage will basically look like ROM to the end user and will be backed by the uC's internal flash. taqueso fucked around with this message at 18:53 on Jun 28, 2013 |
|
#
?
Jun 28, 2013 18:48
|
|
|
taqueso posted:I'd like to make a composite USB device that acts as a virtual serial port and storage device. Lots of uCs will work for this, of course, but I was hoping someone here might have a recommendation for something with a good USB library or sample code. Cheapish dev tools would be cool. Edit: search for "uTasker". Victor fucked around with this message at 18:55 on Jun 28, 2013 |
|
#
?
Jun 28, 2013 18:49
|
|
|
I'm looking to build my own prototype board for fun and educational purposes. It will have a micro, some LED's, external memory (flash) and I would like to incorporate serial output from the mico. I am assuming I will need some serial chip connected to the micro (via I2C?) and will need some driver code to output control the serial chip output. I'm not really sure where to being designing the serial circuit, what kind of chip would should I look into? I will be doing this project by myself and designing the PCB as well, I have a little experience doing PCB design and work in firmware but any suggestions or pointers would be helpful.
|
|
#
?
Jun 30, 2013 08:04
|
|
|
It depends on the micro, they have varying levels of USB support. With smaller micros, you usually connect a USART to an FTDI chip that takes care of all the USB-related trickiness and just makes your device look like a serial device. On STM32 it pretty much has full USB support built in, you might need a level shifter depending what voltages you are using.
|
|
#
?
Jun 30, 2013 16:55
|
|
|
Anybody do a lot of work on both AVR and PIC? I've used AVR's for ages but I'm looking at getting into some PIC stuff too. Mainly because of the dsPIC33 series which has some pretty amazing features and performance at pretty great discounts compared to what AVR offers. In my particular case the models that have a CAN bus controller integrated are *dramatically* better than the AVR CAN models that cost significantly more. I really like the way the PIC compiler supports bitfields for structs and IO registers, it's so much nicer than the AVR bit manipulation & automatic type-promotion shitshow. But the lack of optimization on the free XC16 compiler is pretty terrible. Having non-free toolchains seems so totally ridiculous these days. Any other caveats or gotchas when transitioning from AVR to PIC? Or any other advice/resources/tutorials anyone can recommend to someone who knows microcontroller development but just wants to learn 16-bit PIC specifically?
|
|
#
?
Jun 30, 2013 17:32
|
|
|
Rescue Toaster posted:Anybody do a lot of work on both AVR and PIC? I've used AVR's for ages but I'm looking at getting into some PIC stuff too. Mainly because of the dsPIC33 series which has some pretty amazing features and performance at pretty great discounts compared to what AVR offers. In my particular case the models that have a CAN bus controller integrated are *dramatically* better than the AVR CAN models that cost significantly more. I've done probably a dozen PIC projects/products so far; I like them and their tools better than AVR in every way (though I also started with PICs). I used a dsPIC with its integrated CAN controller + DMA engine pretty easily (1 hour to get up and running) for a project, no major issues. The Real ICE is the best tool they offer, but it's pretty expensive; you'll probably be fine with a PICKit 3.
|
|
#
?
Jul 1, 2013 15:54
|
|
|
I like how they have an IDE for OSX and I wouldn't have to dig around for a month trying to get a thing set up on my own which is a thing that a newbie like me has  AVR I'm looking at you 
|
|
#
?
Jul 1, 2013 20:13
|
|
|
movax posted:I've done probably a dozen PIC projects/products so far; I like them and their tools better than AVR in every way (though I also started with PICs). I used a dsPIC with its integrated CAN controller + DMA engine pretty easily (1 hour to get up and running) for a project, no major issues. Thanks. Sounds promising. For my purposes & limited run size I can always just go up a flash size if the optimization is a problem. Plus being able to prototype the CAN chips in DIP is really nice. Also the DMA not being a giant pain to use is awesome. EDIT: Microchip gets bizarrely selective about what pins have PPS and what are hard wired, and which are available. For the dsPIC33EP/MC50x series that I was looking at, there's no PPS support for CTS/RTS flow control... unlike every single other 16-bit pic I've looked at so far. The 28 pin ones have no assigned CTS/RTS pins, so flow control is unavailable. The 44 pin TQFP has an RTS pin, but no CTS pin (seriously wtf?). Only the 0.5mm 64 pin versions that cost as much as all the higher end dsPIC's anyway have both pins (still no PPS). Rescue Toaster fucked around with this message at 17:30 on Jul 3, 2013 |
|
#
?
Jul 3, 2013 03:51
|
|
|
Rescue Toaster posted:Thanks. Sounds promising. For my purposes & limited run size I can always just go up a flash size if the optimization is a problem. Plus being able to prototype the CAN chips in DIP is really nice. There are some dsPICs without an SOSC! The thing about the dsPIC is that most of the parts are developed for specific customers, so you end up with some weird things. Is CTS/RTS required really? Whats the application?
|
|
#
?
Jul 4, 2013 02:46
|
|
|
movax posted:I've done probably a dozen PIC projects/products so far; I like them and their tools better than AVR in every way (though I also started with PICs). I used a dsPIC with its integrated CAN controller + DMA engine pretty easily (1 hour to get up and running) for a project, no major issues. Get a PICKit 2 if your part supports it, a PICKit 3 is 2nd best, don't get a Real ICE. Don't Get A Real-ICE.
|
|
#
?
Jul 4, 2013 02:48
|
|
|
Rescue Toaster posted:Thanks. Sounds promising. For my purposes & limited run size I can always just go up a flash size if the optimization is a problem. Plus being able to prototype the CAN chips in DIP is really nice. Yeah, it's all kind of crazy hosed up, they must have piles and piles of RTL around they just throw together. At least the dsPICs have a reasonable breakdown in terms of GP/MC/etc. PPS is more common on the PIC24Fs I've found and only the lower pin count ones at that.
|
|
#
?
Jul 4, 2013 02:49
|
|
|
Rescue Toaster posted:Any other caveats or gotchas when transitioning from AVR to PIC? Or any other advice/resources/tutorials anyone can recommend to someone who knows microcontroller development but just wants to learn 16-bit PIC specifically? microchip.com/microstick , check out the microstick II. Its what I use for quick prototyping, it comes with a few 28-Pin DIP PIC24s, and a PIC32. You can program/debug/etc with it pretty easily. There are some making GBS threads things about it, like they didn't bring out VDD/VSS to the pins so you'll have to solder some wires if you want to do certain things. I agree that XC16 sucks, their compilers all suck. I've heard very few copies actually get sold. The 16 bit PICs are really easy to program in ASM. If you want to learn 16-bit PICs, learn to program them in ASM. Then, when the compiler gives you poo poo, (it will!) you'll be able to find it faster. As for learning to program them, the dspic30 programmer's reference manual (i have to google it every time) covers the programmer's view of the part, then check out the specific device data sheet for pinouts/peripherals. isr fucked around with this message at 03:00 on Jul 4, 2013 |
|
#
?
Jul 4, 2013 02:54
|
|
|
isr posted:microchip.com/microstick , check out the microstick II. Its what I use for quick prototyping, it comes with a few 28-Pin DIP PIC24s, and a PIC32. You can program/debug/etc with it pretty easily. There are some making GBS threads things about it, like they didn't bring out VDD/VSS to the pins so you'll have to solder some wires if you want to do certain things. I've had pretty good experiences with the free version of XC16 but I fully admit I'm not at very high device utilization / large complexity projects. Will agree that programming them in ASM is pretty easy though.
|
|
#
?
Jul 4, 2013 02:59
|
|
|
XC16 is okay compared to XC8, and 99.9% of the time both are fine. The dsPIC/PIC24 core was designed (supposedly) with C in mind, so its rare that you run into a compiler bug. The 8-bit PICs just aren't C friendly at all. Its amazing the compilers work as well as they do, but its often you'll be asking yourself "is this a compiler bug?" when your project isn't working and you don't know why... But programming 8-bit pics isn't fun in assembly. The ~Special~ function registers are banked, so you have to keep track of which bank you're in or you might clear a timer when you thought you moved a pointer (or something)
|
|
#
?
Jul 4, 2013 03:03
|
|
|
isr posted:XC16 is okay compared to XC8, and 99.9% of the time both are fine. The dsPIC/PIC24 core was designed (supposedly) with C in mind, so its rare that you run into a compiler bug. The 8-bit PICs just aren't C friendly at all. Its amazing the compilers work as well as they do, but its often you'll be asking yourself "is this a compiler bug?" when your project isn't working and you don't know why... I have heard horror stories about the PIC16 in particular out of the 8-bit PICs; apparently it has some kind of incredibly asinine/weird architectural design that results in compilers sucking / being hard to write for it.
|
|
#
?
Jul 4, 2013 03:07
|
|
|
|
| # ? May 10, 2024 03:55 |
|
|
movax posted:I have heard horror stories about the PIC16 in particular out of the 8-bit PICs; apparently it has some kind of incredibly asinine/weird architectural design that results in compilers sucking / being hard to write for it. Yeah the PIC16 is an odd duck. The early ones looked more like the modern PIC10's/12's. The architecture works well with small memory, small ram, simple simple simple. Well as more memory is added and there's no more room in the opcode for address bits, now you have two other bits you have to keep track of manually before doing any memory operation. You have a stack in pic16, like 32 deep i think now. But, you can only see the top of it. If you want hardware pointers, you can have them! Two of them, to be exact. PIC18 answered a lot of the problems in the PIC16 while keeping good backwards compatibility. I'm glad i don't have to work with them that much any more...
|
|
#
?
Jul 4, 2013 03:12
|
|