|
Anyone know of a microcontroller that can do a 3MHz A/D conversion at about 8 bit resolution for about 2k points per trace? I have an analog system in mind that would run at about 300kHz and is going to need a uC installed to turn parts on/off, and it occurred to me that it'd be pretty sweet if we could run some of the signals through an analog mux to an A/D port so we could monitor single signals from a remote PC. It'd be like having a lovely oscilloscope right there on the board for debugging/tuning the system. Unfortunately this is turning out to be a rough thing to Google for (uC + ADC + fast is not a helpful combo). I found one XMEGA chip that could go to 1MHz, but thats about 3x the frequency I'm trying to monitor and dangerously close to the Nyquist limit. Any other good options?
|
#
?
Oct 21, 2013 01:45
|
|
|
|
| # ? May 9, 2024 22:11 |
|
|
Some PSoCs (the highest end 5LP models) have a 2MHz ADC. Edit: http://www.cypress.com/?mpn=CY8C5667LTI-LP009
|
|
#
?
Oct 21, 2013 02:10
|
|
|
Sinestro posted:Some PSoCs (the highest end 5LP models) have a 2MHz ADC. If he's only looking for 8 bits it won't matter, but I feel obliged to say <-----------------------
|
|
#
?
Oct 21, 2013 02:16
|
|
|
^^^ Well that inspires confidence  Sinestro posted:Some PSoCs (the highest end 5LP models) have a 2MHz ADC. Cool, thanks for the suggestion! I haven't played around with PSoC stuff before but it looks like an interesting option.
|
|
#
?
Oct 22, 2013 01:06
|
|
|
PDP-1 posted:Anyone know of a microcontroller that can do a 3MHz A/D conversion at about 8 bit resolution for about 2k points per trace? I have an analog system in mind that would run at about 300kHz and is going to need a uC installed to turn parts on/off, and it occurred to me that it'd be pretty sweet if we could run some of the signals through an analog mux to an A/D port so we could monitor single signals from a remote PC. It'd be like having a lovely oscilloscope right there on the board for debugging/tuning the system. There's a new PIC that has a 10MSPS 12bit A/D, a couple DACs, and some other fun analog stuff, PIC24FJ128GC010 Edit: I really liked your "lovely oscilloscope" on board idea  I think i'd like to do something similar... I just checked out the 12-bit INL/DNL, it looks like its really a 9-bit A/D at worst-case, which isn't too bad for your application, because at 10MSPS you have plenty of room to over sample. You wouldn't need an analog mux, just connect all the signals to the PIC, it'll do the muxing. This part also has USB so you wouldn't need (m)any external ICs.
isr fucked around with this message at 17:17 on Oct 23, 2013 |
|
#
?
Oct 23, 2013 06:17
|
|
|
Do you all think it is possible to reprogram a microcontroller over a serial bus with one master and multiple slaves? The application is basically an accessible master node and a bunch of physically inaccessible slave nodes. When it comes time for a firmware update, it would be awesome if I could reprogram the slave nodes from the master node's bus connection (or even just using the master node). But this is a really weird thing to do and I can't find any information about it on the internet. In this situation, all nodes would be reprogrammed with the exact same firmware, so it would be totally okay if the reprogramming worked globally.
|
|
#
?
Oct 31, 2013 18:35
|
|
|
Corla Plankun posted:Do you all think it is possible to reprogram a microcontroller over a serial bus with one master and multiple slaves? Is the bus one-to-all or master->single slave? Is it a popular bus like I2C or something?
|
|
#
?
Oct 31, 2013 19:46
|
|
|
SPI was my guess.
|
|
#
?
Oct 31, 2013 19:50
|
|
|
Its a design choice that I haven't really made yet, but I was thinking about RS485 because it seems appropriate for the application. Communication will only be initiated by the master and it will address slaves individually, although I am toying with the idea of a broadcast address that directs all slave nodes at once (and obviously doesn't expect a response to maintain a collision free bus). The latter method would be an easy way to reprogram everybody at once. I think I am at an impasse because I don't really know how the actual hardware portion of microcontroller programming works, and I'm not sure how hard it would be to create a device that programs microcontrollers (or itself). I suppose I will read up on it. Sorry about being vague, but the network and controllers are t.b.d based on this inquiry, and I also had to sign an NDA :/
|
|
#
?
Oct 31, 2013 20:33
|
|
|
Corla Plankun posted:Do you all think it is possible to reprogram a microcontroller over a serial bus with one master and multiple slaves? If you are able to address slaves individually, I don't see why it would be impossible but you may need to write a custom bootloader. I haven't seen anything using RS-485 specifically, at any rate. AFAIK, all you would need is a microcontroller that can reprogram it's own flash. For the bootloader, it could be as simple as starting up, waiting a bit to see if it's supposed to be programmed, and then jumping into the system code. There are lots of examples of this part. If it's supposed to be programmed, it reads in data and replaces the current system code in flash. You may be able to crib a bootloader from an existing project like Arduino.
|
|
#
?
Oct 31, 2013 20:49
|
|
|
Corla Plankun posted:Its a design choice that I haven't really made yet, but I was thinking about RS485 because it seems appropriate for the application. Communication will only be initiated by the master and it will address slaves individually, although I am toying with the idea of a broadcast address that directs all slave nodes at once (and obviously doesn't expect a response to maintain a collision free bus). The latter method would be an easy way to reprogram everybody at once. Why not do i2c and implement an update command? Then just use i2c broadcast to update each slave at the same time?
|
|
#
?
Nov 1, 2013 00:31
|
|
|
Yeah as long as your micro can rewrite its programming it's more than possible. Writing a custom boot loader is typically way easier than it sounds at first, too - you still get to write c and use all the hardware and interrupts and so on. That part of the code may have to live on a different section of flash is all. One more thing though - either relocate the heap for your boot loader code or don't use malloc in it, because the code you upload typically won't know the boot loader exists, and if the boot loader leaves a freelist or malloc structure somewhere the app code isn't expecting it can lead to some very annoying and hard to debug errors.
|
|
#
?
Nov 1, 2013 16:06
|
|
|
Has anyone tried using FastSPI_LED2 on an ATTiny85-based board? I got a couple of Gemma boards to make my fancy gloves stand-alone, and it just keeps failing on the compile, even though it supposedly does support them, if I'm reading it right. I really don't want to rewrite all my code to use the NeoPixel library - it's a lot less flexible.  Edit: The guys who make FastSPI just released RC5 thanks to my prompting. But the Gemma boards are worthless. drat things just outright failed. couldn't even get code onto them, and they show up as malfunctioning USB devices - the bootloader's failed. TwystNeko fucked around with this message at 06:22 on Nov 2, 2013 |
|
#
?
Nov 1, 2013 17:52
|
|
|
Anyone have a good resource for learning BLE? I have a TI dev kit. I was thinking it would be easy enough to start by capturing the boards discovery/connection sequences. This was confounded by a few things. The first being when I turned on the sniffer, it was immediately flooded by the hundreds of BLE devices my coworkers have lying around advertising themselves. This wouldn't be so bad but the packet sniffer software doesn't allow for crazy filtering tricks like "!=" or "OR" so I can't easily filter out the two devices I want. So I'm reluctantly left with having to learn something from reading about it instead of mashing around a working system. I've looked over the iOS and Android resources for the host side, but I'll be doing a lot more work on the device side. The TI docs are a good start and I'm sure they'll do the job, I'm just curious if anyone had a good reference.
|
|
#
?
Nov 6, 2013 21:17
|
|
|
I bought a TI sensor tag, I think it was $30. Using that and the accompanying iOS app I've been able to get a good understanding of how BLE is supposed to work. We are now planning on running to production using a PIC for motor control and a module from bluegiga to handle the BLE communication, translating to SPI to communicate with the PIC. Basically, check out the sensortag, it made it easier to grasp fundamental concepts.
|
|
#
?
Nov 8, 2013 13:02
|
|
|
Do any of y'all program microcontrollers with a linux toolchain? There are so many huge, proprietary IDEs out there that it seems like it might be hard to do, but I would love it if I could slim down the development process to just gedit and a makefile. I just tried this out with a Maple this morning, but it hasn't been altogether successful.
|
|
#
?
Nov 14, 2013 19:37
|
|
|
You can totally slim down the dev process to gcc and a serial programmer. I'd be very curious how you plan to debug anything nontrivial with that setup though. Debugging in an IDE with breakpoints and awareness of your code will take a fraction of the time compared to debugging with LED's providing bits of information about what's going on inside.
|
|
#
?
Nov 14, 2013 19:49
|
|
|
JawnV6 posted:You can totally slim down the dev process to gcc and a serial programmer. I use cgdb (http://cgdb.github.io/) along with the appropriate compilation of gdb, and a debugger. Maybe not as nice as Visual Studio, but it works very well across a lot of platforms.
|
|
#
?
Nov 14, 2013 22:29
|
|
|
JawnV6 posted:I'd be very curious how you plan to debug anything nontrivial with that setup though. Debugging in an IDE with breakpoints and awareness of your code will take a fraction of the time compared to debugging with LED's providing bits of information about what's going on inside. I've never used any of that stuff so it is all just bloat to me. Maybe I have never encountered a nontrivial bug?
|
|
#
?
Nov 15, 2013 00:52
|
|
|
I had a +5V rail drooping that was causing the ADC reading referenced against another plane to come back a little goofy. Of course, it didn't manifest in any sensible way the device just kicked into the next stage of operation. The ADC reading wasn't the only possible transition, it wasn't 100% fail, etc., so it took some onion-peeling to root-cause it. You can totally figure that out with a multimeter, an array of LED's to show the 12 bit ADC reading (once you somehow figure out that's what's going on) along with the state machine position and a dozen other triggers. But sweet jesus why would you subject yourself to that instead of using a tool designed for explicitly this scenario? Corla Plankun posted:Maybe I have never encountered a nontrivial bug?
|
|
#
?
Nov 15, 2013 01:10
|
|
|
A lot of chips will have gcc implementations. Some of the big debuggers and IDEs are based on them- like Atmel Studio for ARMs. All its toolchain is, is gcc and libavr. With all the weird and awful bugs that entails.
|
|
#
?
Nov 15, 2013 04:05
|
|
|
My work uses stm32 and gcc-arm. Our app is about 100k (binary) and uses basically every i/o channel on the chip. I almost never use a debugger, and I would trade a debugger for a bus pirate or saleae any day of the week. A lot if it is because our app was architected really well so there aren't a ton of surprises and its fairly easy to debug things programatically. I also do a ton of unit testing so any sort of higher level complicated logic is ironed out before I start trying to run it on the chip. Our application is pretty comms heavy and generally interrupt driven though so that kind of makes things not so hard, there just isn't a ton of complexity in most places. If we had an RTOS or 11,000 global variables or something I might feel differently.
|
|
#
?
Nov 15, 2013 06:50
|
|
|
In school I wrote an in-chip debugging routine that used a MAX232 to talk to a computer. It was kinda ridiculous
|
|
#
?
Nov 15, 2013 07:04
|
|
|
Corla Plankun posted:Do any of y'all program microcontrollers with a linux toolchain? As a general rule I prefer any app I write to be easily compiled from the command line. In an ideal world it takes two shell commands to get someone new (or myself on a new machine) up and running - a checkout of the project, and a build command. If the app relies on a huge IDE, it can become a lot harder to deal with (although it doesn't have to). If I am collaborating on a project, I want my collaborators to be able to use whatever editor/IDE they are most efficient and comfortable with. I also like knowing that not only my code is in version control, but my build steps and such are as well. That all said, I haven't gotten set up with the AVR toolchian on linux yet and am still using their windows IDE. It was much more approachable as a total newbie to embedded development (although I have a lot of software development experience). When I do switch over to the command line toolchain, I will post the details if anyone is interested. I planned to do it a while ago, but then I started house hunting and put in an offer. Turns out that buying a house, packing and whatnot takes a huge amount of time. Who knew?
|
|
#
?
Nov 15, 2013 13:29
|
|
|
armorer posted:As a general rule I prefer any app I write to be easily compiled from the command line. In an ideal world it takes two shell commands to get someone new (or myself on a new machine) up and running - a checkout of the project, and a build command. If the app relies on a huge IDE, it can become a lot harder to deal with (although it doesn't have to). If I am collaborating on a project, I want my collaborators to be able to use whatever editor/IDE they are most efficient and comfortable with. I also like knowing that not only my code is in version control, but my build steps and such are as well. 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.
|
|
#
?
Nov 15, 2013 15:19
|
|
|
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
|
|
|
JawnV6 posted:I had a +5V rail drooping that was causing the ADC reading referenced against another plane to come back a little goofy. Of course, it didn't manifest in any sensible way the device just kicked into the next stage of operation. The ADC reading wasn't the only possible transition, it wasn't 100% fail, etc., so it took some onion-peeling to root-cause it. I tried to do some register-/memory-peeking stuff with MPLab X and it was really cumbersome and counter-intuitive so I ended up writing my own thing that dumped what I cared about to the serial bus CSV-style every time it was modified so that I could put it in matlab and do weird stuff to it on my own. Judging by the discussions on microchip's forums, I think MPLab X is just a really bad IDE so maybe the other ones aren't so bloated-yet-unhelpful. I'm sorry for constantly posting dumb stuff in this thread about my noob idiot part-time embedded coding internship, but the main reason I post whenever any dumb thing comes to mind is because it seems like this thread is often dangerously close to falling off into the archives and I like it a lot and want it to stay alive.
|
|
#
?
Nov 15, 2013 20:03
|
|
|
Both versions of MPLAB are huge turds.
|
|
#
?
Nov 15, 2013 20:18
|
|
|
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.
|
|
#
?
Nov 15, 2013 20:30
|
|
|
JawnV6 posted:Sorry, I don't mean to sound so snippy. My preferred approach involves both. I like my build process to be simple and command line based, primarily for the reasons I mentioned in my last post. I like to code in an IDE most of the time though. I actually rather like Atmel's AVR Studio 6. I find it easy to work in, the debugger works well and is intuitive (although conditional breakpoints are not supported), and it's been all I've needed so far. Given that it is built on MS Visual Studio, it's not surprising that it has a solid feature set. I am a huge fan of good debuggers, and consider use of one to be a key skill for developers. There are certain times when using a debugger is not really an option (like if you are hacking on a linux kernel device driver, and it is crashing on startup) and so it's good to know other effective approaches to debugging, but I am not typically working in those areas. I take a bit of offense to the statement "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging..." because it really isn't like that in my industry. Some of the developers I know who have the best practices work in vi or emacs on linux. When they need to debug something, they dust off Eclipse (typically) and use it just for the debugger. They have just internalized the keyboard shortcuts and general mindset of their preferred editor to the point where their productivity is severely impaired using anything else.
|
|
#
?
Nov 15, 2013 21:02
|
|
|
armorer posted:I take a bit of offense to the statement "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging..." because it really isn't like that in my industry. Some of the developers I know who have the best practices work in vi or emacs on linux. When they need to debug something, they dust off Eclipse (typically) and use it just for the debugger. They have just internalized the keyboard shortcuts and general mindset of their preferred editor to the point where their productivity is severely impaired using anything else. I don't really follow. "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging" is distinct from "programmers from cmdline linux land who use good practices and reach for debuggers when appropriate".
|
|
#
?
Nov 15, 2013 21:06
|
|
|
In black and white text on a computer screen, the sentence reads like a blanket statement attributing shoddy practices to linux command line folk. There are definitely some people who meet your description, but there are an equal number of Windows/OSX IDE programmers who think they can get by with the same shoddy practices. If we just take the "from cmdline linux land" bit out entirely then I don't think anyone will object.
|
|
#
?
Nov 15, 2013 21:42
|
|
|
I kinda think that if your workflow requires that you spend a lot of time pressing F7 and watching numbers change in a watch window to figure out what your code does, you must have some pretty shoddy development practices.
|
|
#
?
Nov 15, 2013 22:03
|
|
|
I completely agree, but that still doesn't mean debuggers are not great tools. In the last few weeks I've had to debug two nontrivial things where debuggers were invaluable: The first was an IE9 table display issue where hidden <td> elements in large tables loaded via ajax and added to the DOM via innerHTML() would randomly still show up. It turns out this is a known IE9 bug, and the workaround is to remove any whitespace around the <td>s. Figuring out what the hell IE9 was doing without stepping through the Javascript and looking at various values would have been dubious at best. The debugger here gave me a quick and easy way to sanity check that the DOM was right and it was in fact IE9 being screwy. I was also able to step through the same area in Chrome and Firefox and see that they ended up with the same DOM. Yes, sure I could have resorted to the Javascript equivalent of printf - alert() - but it would have been really, really painful to debug that way. The second was a server side issue in Java with Lucene, where multiple distinct servers were sharing an index file and one was leaking a file lock over an NFS mount. Tracking that one down required remotely connecting a debugger to multiple machines simultaneously and stepping through the contested area of code on each box in lock step. Doing this without a proper debugger is outright impossible. You simply can't sync JVMs by making System.out.println() calls. A debugger is necessary sometimes, and if you don't know how and when to use one, you are simply not going to be effective at solving certain problems. Hopefully your development practices are good, and you rarely run into those issues, but they are sometimes out of your control (IE9, NFS weirdness). On the embedded side of things, I am still a complete novice. I find the debugger very useful for mundane things like confirming that my understanding of what registers get updated on different interrupts is actually right. I'll read the datasheet and think I know what it's saying, but then step through my code in the debugger and realize that I misunderstood it slightly. It makes it much easier and faster to see what is actually going on when you really aren't sure.
|
|
#
?
Nov 15, 2013 22:34
|
|
|
evensevenone posted:I kinda think that if your workflow requires that you spend a lot of time pressing F7 and watching numbers change in a watch window to figure out what your code does, you must have some pretty shoddy development practices. For me, the debugger mostly comes out when I'm having hardware-related issues - is the data from the SPI bus actually going into the buffer correctly? Is a configuration register getting fiddled with by some vendor-provided code when I didn't expect it (the answer is always yes)? Is the right thing happening on the microcontroller but that behavior isn't reflected in what the hardware does, pointing to an issue in either my hardware or in the vendor's silicon? This is stuff that you can't easily make automated unit tests for unless you feel like simulating your hardware and all of its peripherals - and even then, your simulation would have to match reality perfectly. And yeah a lot of this you could do by spitting it out on a UART or something, in the same way you can drive a nail with a screwdriver if you hit it hard enough. Arcsech fucked around with this message at 22:53 on Nov 15, 2013 |
|
#
?
Nov 15, 2013 22:47
|
|
|
evensevenone posted:I kinda think that if your workflow requires that you spend a lot of time pressing F7 and watching numbers change in a watch window to figure out what your code does, you must have some pretty shoddy development practices. armorer posted:I don't think anyone will object.
|
|
#
?
Nov 16, 2013 00:22
|
|
|
No I admit that I read it negatively. I doubt I'm the only one who did so, but I don't expect or want any apology.
|
|
#
?
Nov 16, 2013 04:24
|
|
|
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.
|
|
#
?
Nov 16, 2013 15:08
|
|
|
SybilVimes posted:learning the quirks and oddities of a new system for every hardware platform. This is kind of the job description g an embedded dev though... Most of the time the only reason what we can't do isn't automated from uml is because chips are different and weird. It boils down to being good at reading data sheets and doing what they tell you, while having the knowledge and experience to call the data sheet/vendor/app note out on its bullshit.
|
|
#
?
Nov 16, 2013 18:11
|
|
|
|
| # ? May 9, 2024 22:11 |
|
|
What do you guys think of the mbed platform? I'd rather my low level peripheral driver turd polishing amounted to something more than some code with a funny API that will stagnate on my company SVN server. It seems pretty win/win/win for the company, me and the platform to adopt something like this at work instead of rolling our own everything. Personally, it comes off as maybe a little Arduino-like, but they could just be good at hiding the gritty details. Any experience besides laughing at the concept of an online compiler?
|
|
#
?
Nov 16, 2013 18:13
|
|
