|
Martytoof posted:Did anyone who ordered that Stellaris Launchpad board for five bucks apiece get their order? Reaching back a ways here, but I just got mine via FedEx today. I put the order for 2 in on Sept 27th. So I'd say that they will ship them to you eventually - that Dec 17th date may be legit.
|
#
¿
Nov 28, 2012 03:05
|
|
|
|
| # ¿ Apr 27, 2024 20:20 |
|
|
Martytoof posted:Oh I hadn't even thought of that issue. That alone makes prescalers more sensible. Thanks! There is a short series of AVR articles on hackaday which made prescalers "click" for me. The discussion of the timer/prescaler code is applicable to other chips as well. (There is a bunch of other useful info in the series, and I am just getting into this, so it was valuable to me to read the whole thing.) If you want to read the prescaler bit: It is in the 3rd article in the series (here). Search for "Setting up the clock for use with interrupts" and read through his discussion of what the code is doing. He covers the prescaler configuration in nice detail.
|
|
#
¿
Dec 11, 2012 14:05
|
|
|
Martytoof posted:If I wanted to have my uC produce a lifelike sound instead of a harsh "BEEP" through a standard piezo speaker, what would be the best/simplest/cheapest way to implement something like that? There are also ICs for this sort of thing, although I will add the disclaimer that I have never used them. Something like this maybe?
|
|
#
¿
Dec 13, 2012 22:05
|
|
|
Without knowing what kind of hardware the python program would be running on, it is tough to say for sure. That is higher throughput than I would expect to be able to get from SQLite (or mysql) though. You are looking at a lot of overhead if you try to write each measurement individually in it's own transaction. You might be able to batch write those 100 records each second, or structure the table so that a row corresponds to a second of data or something rather than a single measurement. (Also, wouldn't it be 200 writes per second? 25*8?) I am curious why you expect to have so many reads? I honestly expect that you won't even get close to those performance numbers if you are running this on a standard issue desktop computer. I would suggest writing up a little python app that just loops and writes fake (but representative) data to your intended database target to see how the machine performs.
|
|
#
¿
Dec 20, 2012 12:41
|
|
|
Poopernickel posted:... Most of my professional experience is on the PC software side, and I do the electronics / embedded software stuff as a hobby. I have worked on large backend data processing systems in the past, and I would not expect to get transactional throughput like that without specialized hardware and/or some serious performance tuning. That said, I have been dealing with much larger records than what it sounds like you will be writing. It sounds like you are mostly concerned with small numeric vectors, so it may work out. From what you have said, I definitely think it is a good idea to decouple the polling component from the GUI. I would probably design the system such that one process was (or several were, if necessary) responsible for polling the serial data and writing that out. The big question is can you write it out to a database fast enough to keep up. Assuming that you can write the data to a database fast enough, then you could obviously write a separate GUI application which reads from the database periodically and refreshes the screen. At that point you could also have that GUI client be a standalone app which you could run on several PCs at once if necessary (assuming that the backend database could support whatever load that caused.) You could even get fancy and build features into the GUI that let the user scroll around through the data, zoom in, dynamically adjust the axes, print, and all that good stuff. Do you have a requirement that the data be available long term? Or can you discard data that is older than some timeframe? (Your table will become very long and skinny over time if you can't clear out old data.) Is it OK if there is some lag time between data acquisition and display? (ie: can the GUI lag a few seconds behind the measurement, or does it need to show what you are reading *now*?) Is it ok if you lose some measurements (ie: does it even have to be transacted, and/or can you skip some readings if you lag too much in order to catch up)? Assuming that each of the three measurements you mention can be captured in 32 bits, and that you add a 32 bit timestamp, you have 16 bytes of data you are collecting 8 times / second from 25 sensors, or 3200 bytes ~ 3MB / sec. If this really is representative of the data you plan to write, I would suggest trying it out with a small mysql (or SQLLite, or postgres) database with a simple loop that writes random floats to the database in a loop to see how it performs. This will give you a much better idea of what you can expect to get out of your hardware than my back of the envelope speculation. Keep in mind that on the real system, some CPU will also be taken up polling for data. I don't really know off hand how much that will tax the system. I would say that a reasonable first pass would be to try batch writing the measurements in one second chunks (batches of 200 measurements from the 8*25 metric). That will cut down on your transaction overhead. I have done this sort of thing before using an in memory queue where the measurements are written into a queue and the consumer reads them out into batches. The queue consumer just reads stuff off the queue and remembers it until it hits the batch limit, at which point it writes it all out. You would basically have a multi-threaded process with a few threads responsible for the serial polling and one responsible for the database writing. The GUI would be an entirely separate app, most likely with a read only login for the database.
|
|
#
¿
Dec 21, 2012 03:36
|
|
|
Poopernickel posted:Mocking up a little application is a great idea - especially because this is sounding more and more feasible as I dig into it. I could probably do my database operations in chunks as you describe. It might work, although it will almost certainly be more portable if you use the database as a shared repository. Using STDOUT like that is a bit like drinking from the firehose as well. If the GUI is supposed to just follow the latest data then it is probably fine, but if you want the user to be able to scroll around, zoom, change the axes and stuff, it might be difficult if data is still being appended to the graph constantly. Also, if you want to support multiple GUIs for the same device, you will want the data in a database. Thinking about this more though, another option that might give you the best of both worlds is something like this: Have the GUI directly update from the data reading component, without any database in between. After updating the GUI, then drop the data onto a queue like I mentioned and let it be written to the database asynchronously. That way your display is updated as quickly as possible, but the data is still stored for logging purposes. Then you could have a mode in the GUI (maybe added later) where it opens up a historic dataset and lets the user scroll around in it. That mode would only read from the database though, and wouldn't have to worry about keeping up with the device in real time. If you take this approach, your database writes can be batched as large as you need and it doesn't really matter. One downside to this approach is that if you kill the process it might not have finished logging everything that the user has seen in the GUI.
|
|
#
¿
Dec 22, 2012 03:17
|
|
|
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.
|
|
#
¿
Jan 22, 2013 14:17
|
|
|
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.
|
|
#
¿
Jan 30, 2013 15:42
|
|
|
Pardon my ignorance, but what is the issue with dual headers? Is it basically that you can't easily plug the whole board into a breadboard? I made a little custom adapter to hook up the dual headers on my Raspberry Pi to a breadboard (although Adafruit sells one under the name "Cobbler"). I suppose it was a bit of a pain, and would be a larger pain on a board with more pins.
|
|
#
¿
Mar 25, 2013 20:39
|
|
|
It never occurred to me to stick half into one breadboard and half into a second. It seems so obvious now - thanks for that! With the raspberry pi you have a 26pin dual header, so I just ran a ribbon cable to a little adapter that spaces the header pins wide enough to span the center of a breadboard. That isn't really viable on something like this with so many pins though.
|
|
#
¿
Mar 25, 2013 21:06
|
|
|
I am trying to teach myself AVR programming, and I got an AVR Dragon. So far it hasn't blown up on me (or blown up any chips), but it only sees light use. I soldered in a zif socket and some headers into the unpopulated sections of the board. Depending on what chip you want to program, you need to run a bunch of jumper wires from point to point on the dragon. I thought that was a pain in the rear end since I am working with a couple of chips and didn't want to keep moving jumpers around, so I made little "patch" boards with protoboard so I can just plug the right one into the dragon for whatever chip I am programming. Keep in mind that I am quite a newbie with this stuff and really just teaching myself as I go along, so my recommendation probably isn't worth much. So far though it has worked for me and I've been able to code in AVR Studio and dump it to a few chips without any problems. I plan on laser cutting or 3d printing a partial case for the dragon in the near future, because it is just a raw circuit board and could be damaged relatively easily.
|
|
#
¿
Apr 26, 2013 12:45
|
|
|
Martytoof posted:Probably a really frowned-upon opinion, but I'm starting to think everything I need to do I can just do on an arduino because I'm way too impatient to do low level stuff these days. If you keep in mind that you can get an atmega328p, put optiboot on it, and build a super simple circuit around it to have a $5 "arduino uno", then I say go for it. The strength at that point is entirely in the abundance of pre-written libraries though. That said, I am a software developer who started mucking around with this stuff in his free time to make fun toys. So I am by no means an expert. I am trying to learn the lower level stuff mostly because I find it interesting, but if I need to make something quickly I default to slapping something together with arduino libraries.
|
|
#
¿
May 7, 2013 12:48
|
|
|
Delta-Wye posted:Arduino is for people who are too lazy to read an Atmel datasheet. Of course, when they go to do 30-45 analog reads in a row (the multiplexor guide said it would work!!!!!) and find out that it's hellishly slow they lack both the ability to recognize the problem (ADC reads take a long time) or the solution (kick them off and use an ISR to grab the data instead of spinlocking and waiting). Who guessed learning how to do something complicated would be complicated? This entire sentiment is so elitist and off base that I wonder if you really believe it or are just trolling. Arduino is for people who have never even heard of Atmel. It's an entirely different problem that the Arduino is intended to solve. The vast majority of people using an Arduino will never do anything more complex than a blinkenlights project, but will be thrilled by the whole thing regardless. The folks who end up trying to do complex things and running into road blocks will move on and learn to do things the right way, or say gently caress it and not bother. Arduino was not designed for anyone in this thread. It was designed to get people who have never done anything with embedded electronics in their entire lives started making things. It is the Duplo block of the construction world. Nobody in their right mind is going to try building a shed out of Duplo blocks, but they serve to get young kids building little "houses". Kids that are into it will graduate to Legos and them maybe move on to actually studying engineering. Sure you will run into people who have made their Arduino tweet when they flush the toilet, and think that somehow qualifies them as an embedded programmer, but those people are just stupid. There are stupid people in every area of life.
|
|
#
¿
May 9, 2013 16:38
|
|
|
JawnV6 posted:I'm getting the distinct impression people think more complex things should be possible without an ounce of engineering effort applied. I completely agree - The Arduino was originally designed as an accessible platform for first year electrical engineering students. It exploded in popularity because it was accessible enough that installation artists, theater people, children, and all sorts of other groups (NOT professional computer / electronics engineers) could buy one and do something fun or useful with it. Some of those people will go on to do more complex things, most of them won't. It is definitely attracting more young people towards engineering disciplines though, which I think is a good thing. Slanderer posted:Let me tell you about a project called Ardupilot... If that project lets someone (without the know-how to make such a thing otherwise) spend some money on a glorified quadcopter "puzzle" to assemble, then it will do ok. Maybe that person will have fun with it and decide to learn how the hell it actually works, although probably they won't. How does that make it "bad" though? Robotics professionals don't scoff at toy robots, they buy them for their kids to get them interested in what they do. I just looked up Ardupilot, and $400 gets you a copter with 1kg lift. Some indie movie director is going to strap a goPro to that and use it to film interesting scenes. Would that director build a quadcopter otherwise? Hell no. That is why the Arduino (and some of the myriad followup products / kickstarters) is booming right now. It is accessible to people who don't know Ohm's law, are just trying to teach themselves C, and basically have no idea what the hell they are doing. You guys look at it and see a (negative connotation) toy that can't handle the stuff you do, these other people look at it and see a (positive connotation) toy that they can use to do fun stuff.
|
|
#
¿
May 9, 2013 17:19
|
|
|
That isn't my characterization of you, and I understood your position (and said "I completely agree"). My usage of "You guys" was a poor choice and I apologize, obviously different people in this thread have different opinions.
|
|
#
¿
May 9, 2013 17:31
|
|
|
That I can completely agree with. I see now that you were mostly pointing out that they built this thing out of "Duplo blocks". I can only imagine they did that because of the huge community, figuring that it would get them more exposure. I think the decisions to abstract away "main" and pretend that you weren't writing in C or C++ were poor ones (I have no idea why they did that, or what they thought was gained). Also the Arduino IDE is terrible to anyone who has a preferred development environment (whether command line or full IDE based). As for stuff implemented in software "the Arduino way" - any sufficiently complicated software system written by non-programmers is bound to be a pile of poo poo. Look at all of the VB written by business folks, it solves their problem but any developer who looks at it will cringe and run away screaming. My point is mostly that Arduino is immensely popular for reasons that (and with people who) don't really have anything to do with good embedded system design.
|
|
#
¿
May 9, 2013 17:48
|
|
|
In the grand scheme of the "embedded systems world" I really do think Arduino is kind of like Duplo block. Sure you can do all sorts of stuff with it, but it clearly isn't the right tool for everything. I think my previous comments made it clear that I still think it has merit and is a useful product that fills a slot people clearly wanted. The fact that it is something of a Duplo block means that this stuff is available to a wide audience that otherwise would not be free to tinker. Regarding the "gap" between Arduino and more professional options - I am not really qualified to say much because I don't know the profession. I know that Arduino didn't provide the flexibility or power that I wanted, and so I ended up reading Atmel datasheets, learning some AVR C (I already knew C, but learning what all the registers are and how to use them is a bit confusing), teaching myself to use Eagle, and a whole host of other skills. With all of that, I can just barely make something functional going that route. I feel like after a while, once I know the tools and the landscape better, I will prefer that approach because it gives me more control and robustness for less cost. I am a professional software developer though, with engineering and mathematics degrees. In order to "step up" from Arduino (which I feel is a sort of construction kit/toy) to these other solutions, you really do need a lot of engineering knowledge. armorer fucked around with this message at 21:59 on May 9, 2013 |
|
#
¿
May 9, 2013 21:53
|
|
|
As I've mentioned before, I am trying to teach myself some embedded programming skills. Thus far, that has meant a lot of reading online, fumbling with AVR programming with a Dragon and AVR Studio, and reading of various datasheets. I have a few pretty obvious deficiencies in my skillset that I need to remedy, and so I was hoping you could provide me with some suggestions. The main deficiency is that I don't really know C++. I did a lot of C in college, and have extensive experience in Java from my professional career, but I have never had to do anything meaningful in C++ so all my embedded code just ends up being C. (I know some other languages as well, but I mention C and Java to demonstrate somewhat relevant experience with concepts I expect I would find in C++.) I've looked into getting a good book to help remedy this, but a lot of C++ books seem to make heavy use of the standard library and I imagine embedded C++ tends to be a lot more lean. When I look for recent books on embedded programming, I tend to come up short. Does anyone have any recommendations? The second problem I am running into is that I learn the most by doing. My learning style revolves around picking something that I don't know how to do, and then doing it. To that end, I find myself recreating various interesting things I find online (hackaday, make, etc) and picking up whatever skills I need along the way. This has worked pretty well for me so far, but I've also looked around for a decent project book. Most of the ones I find are either extremely old and dated, or entirely focused on making things with an Arduino (which is what I trying to move past). Are there any particularly good resources people can direct me to in this area? The last problem is that there is a huge wealth of knowledge out there in the embedded world that I would classify under "best practices", "design patterns", and "institutional knowledge". This is an area that I am mostly ignorant of. Stuff like commonalities between different microcontroller architectures (so I might know what skills are transferable from AVR to PIC to others), tradeoffs between SPI and I2C, best practices for embedded debugging techniques (whether JTAG, digital logic analyzer, or other), common ics that I should always have on hand, and a whole lot more. I seriously doubt that there is a good book (or a few good books) that I can read to pick up some of this general knowledge. I don't work in an environment where I can pick this stuff up from professionals either. If there are decent resources that I can go through, please point me to them. I looked through the OP but there really isn't a whole lot there on these topics. Edit: If it's relevant for any potential recommendations, my preferred development environment is Linux, although I am perfectly willing to code on Windows or OSX if there is a compelling reason for it. I am mostly using AVR Studio on Windows at this point because I haven't gotten around to familiarizing myself with the command line toolchain, and my gaming computer (Windows) is right next to my electronics work bench. Edit2: I realize there are a lot of questions in this post, and that it will take me years to develop full operational knowledge of all of this stuff. I am mostly looking for some good reference material to accompany my explorations. armorer fucked around with this message at 02:01 on May 15, 2013 |
|
#
¿
May 14, 2013 19:33
|
|
|
No reason, and thus far I haven't been using C++ since I don't really know it. It just seemed like C++ was more common from some of the stuff I've read. If it's a better idea to stick with C and just use structs, that's great - less to learn!
|
|
#
¿
May 15, 2013 01:57
|
|
|
For some reason I had the impression that C++ was more common in embedded design than C, and that if I wanted to be more "serious" I should learn it. If that is a bogus impression I picked up from somewhere, I am more than happy to cross it off my long list and focus on some other things instead. I am thinking about going through one of these two books next: Making Embedded Systems Designing Embedded Hardware
|
|
#
¿
May 15, 2013 02:38
|
|
|
Sinestro posted:How do I learn to layout real PCBs. I learned my way around Eagle using the youtube videos that this guy put up rpcelectronics. They don't really teach you any design skills, but they do show you how to use the program for basic stuff pretty clearly. If you want to make them yourself via etching, there are a lot of tutorials online. If you want to upload your design to someplace like OSH Park, then I would look online for a design rule check (drc) file for eagle to run before you send them out. armorer fucked around with this message at 13:21 on May 15, 2013 |
|
#
¿
May 15, 2013 13:12
|
|
|
Martytoof posted:Asked this a while back but I think it might have gotten lost. If I want to debug AVR 8bit chips, do I need to shell out for the JTAGICE mk2 or will a Dragon do in circuit debugging as well? I haven't tried to do any in circuit debugging with my dragon yet, but it is an advertised feature. I would volunteer to give it a shot and report back, but I won't have time until probably Monday at the absolute earliest.
|
|
#
¿
May 21, 2013 02:32
|
|
|
Martytoof posted:Oh no rush at ALL. I'm just dabbling in this stuff as a hobby. If you could just try to step through something simple that would be great Likewise - just dabbling as a hobby. This gives me something to try out though, and I like little projects. I will put it on my short list and try to get to it this weekend. I still need to make a case for my Dragon. I wanted to 3D print or laser cut one, but I haven't gotten around to it. I should probably just get a cheap project box from the radio shack down the street for now to stick it in.
|
|
#
¿
May 21, 2013 03:25
|
|
|
movax posted:Did I mention that's its less than $5 and a few hours of your time? Well, OK, so add a few bucks for shipping. Still cheap as balls. I think they bumped the price up to $10. It's not $4.30 anymore unfortunately. Still cheap and all-inclusive though as you say.
|
|
#
¿
May 22, 2013 17:43
|
|
|
Martytoof posted:If possible maybe set a breakpoint on an ISR and see if it lets you step through at that point? So I'm currently planning on getting this up and running on a Windows 7 box running AVR Studio 6, my Dragon, and an atmega1284-PU. Did you mention at some point that you are developing in a VM on OSX? If so, if I get it running without the VM in the mix, I'll have a go at it in a VMWare Fusion Windows 7 instance on my mac laptop. I am planning to keep the code super simple, and just set up an ISR to trigger on a clock timer or button press or something. I will probably just breadboard a minimal circuit to test it out. If I get through all of that, I also want to see what I can do on an atmega328p and an attiny85 with debugWire. I don't know if you have any specific requests, but that's the stuff I have lying around.
|
|
#
¿
May 22, 2013 20:12
|
|
|
Martytoof posted:It's actually a pretty ridiculous request so honestly unless you're interested in seeing it go then I wouldn't even bother. I can't imagine that the Dragon won't debug an AVR properly in Atmel Studio 6 I am very interested in seeing it go! I write code for a living, and make regular use of a number of different debuggers. When you mentioned JTAG support for OCD I realized that I hadn't even tried it yet since the code I was writing was pretty trivial. So it is really just an opportunity to familiarize myself with it, and having someone else that is interested means I'll pay more attention as I go through it. movax posted:e: The Dragon+AVR Studio 6 sure as poo poo will waste 2 hours of your time loving up simple ISP programming when AVRDude+Dragon can get the same thing done instantly, albeit with some libusb fuckery I've done ISP programming via AVR Studio 6 and the Dragon, and it was really simple. A tiny bit of hunting for the right menu icon, and a few clicks, and my code was compiled and loaded. I haven't mucked around with JTAG yet though, for programming or OCD. I personally prefer to code on linux, and I fully intend to learn my way around the gnu toolchain for AVR development. At the moment though I am using AVR Studio because I can only learn so many things at once and I am focused elsewhere. I know it's a bit atypical, but I actually have a MBP for work. When they decide to replace it for me I am going to get a thinkpad too because (a) the MBP keyboard drives me nuts and (b) I would rather just have a linux box.
|
|
#
¿
May 22, 2013 20:28
|
|
|
robot posted:I'm looking to get my feet wet with some embedded stuff after taking a really simplified microcontrollers class which used old PIC boards where we wrote assembly code. It wasn't a very comprehensive class so we didn't really learn too much. I basically just want to get something that is pretty cheap, but where I can learn a bit more in-depth about microcontrollers and maybe use a programmed microcontroller in a circuit or something. The TI Launchpad looks good but the price is $10 now, so I was wondering if there were any better alternatives around that price point. Has anyone heard of Freescale's FRDM-K20D50M ($18)? It says it comes with a 32-bit MK20DX128VLH5 microcontroller which has a 50 MHz ARM Cortex-M4 core while the STM Discovery ($14.55) says it comes with a 32-bit STM32F100RB microcontroller which has a 24 MHz Cortex-M3 core (not really sure how important this is or not). Welcome to the mess! There are a slew of options, and different folks in this thread are tinkering with different platforms. I think even at $10 the msp430 lauchpad is worth playing around with. It comes with everything you need to tinker with it, and if you don't like it it's not like you are out a ton of money. If you already have an STK500 and an AVR Dragon, you could try out a whole host of AVR chips too. The dragon only comes with a USB cable which most people have lying around anyway from an old printer or something. If you need ribbon cables, you can make them pretty easily by ripping the necessary number of strands off an old ATA cable and crimping on new connectors. (If you want to go this route, the connectors can be a bit annoying to search for but digikey has tons of them.) armorer fucked around with this message at 17:51 on May 25, 2013 |
|
#
¿
May 25, 2013 16:38
|
|
|
Brief update on AVR Dragon JTAG debugging in AVR Studio 6: "It just works." (Who would have guessed?) I installed AVR Studio 6.1 in a Windows 7 VM (VMWare fusion) on OSX. I threw an atmega1284-PU in a breadboard, hooked it up to the dragon via JTAG, and stepped through some trivial code in the debugger. I did not set a breakpoint in an ISR yet, but I will on Monday. I'll provide some actually useful details about how to set it up and such on Monday also. I hit a few gotchas when I was putzing around with it, but no real blockers. I haven't been able to attach the debugger when using an external crystal for some reason, but it works fine with the internal oscillator (which the chip is configured to use by default anyway). I will play around with that more on Monday too. One minor thing to note is that you need to set your breakpoints before you begin your debugging session, you can't dynamically add them. The error message implies that you can with certain chips, but I am not sure if that is the case and the 1284 doesn't support it at any rate. I basically only had enough time to get it set up and working, so on Monday I plan to see what I can inspect in terms of registers, variables, and whatnot. It actually lets you step through the generated assembly too, which is pretty cool.
|
|
#
¿
May 26, 2013 04:04
|
|
|
Time for the promised update. I set up some incredibly trivial code (here is a gist), using a button to trigger an interrupt on INT0 which toggles an LED on and off every 5 presses (with no debouncing). The counter was a global int, so that I could see what support there was for inspecting variables. Once again, it "just works" if you set a breakpoint in the ISR. I mentioned some gotchas before, so I will list a few of the things I ran into. First of all, the optimizer will eliminate useless code. Out of laziness I initially tried to set up some code that added some values together in a loop but never did anything with them. The optimizer realized that code was completely pointless and just eliminated it, so my breakpoints didn't actually map to anything in the resulting assembly and thus never fired. That leads to observation 2 which is that you really are debugging the assembly. When you break on a line of C, you are really breaking on a line of assembly and the IDE is just being kind to you and showing you where you are in the context of your C code. This makes more sense with an example, so if you set a breakpoint on "counter++;" in the ISR and then flip over to the "Disassembly" tab you will see this  The filled circle with the right facing arrow is the next instruction to execute. The outlined circle below that is a breakpoint I had set before I started debugging, but later deactivated. When you first set everything up, you need to configure your project correctly in order to use JTAG. In the menu bar there is an area to select your device and your tool. It looks like this:  You should just be able to click each section and select the appropriate entry. If the Dragon is plugged in, it should show up there. (It may prompt you to update the Dragon's firmware when you first select it, or perhaps when you first try to use it. Just go ahead and say yes.) You also have to set the JTAG clock speed, this lives under Project->Properties->Tool. The JTAG clock speed needs to be at least 4 times slower than the device clock. In my case the atmega1284 ships configured to use the 8Mhz internal oscillator, and the CKDIV8 fuse set, for a resulting speed of 1Mhz. I set my JTAG clock to 200kHz and it worked fine. When I programmed the fuses to use an external 16Mhz crystal instead, and unprogrammed the CKDIV8 fuse to get a full 16Mhz, I couldn't get the JTAG debugger to attach for some reason. I plan to spend some more time on this later but off hand I am not sure what the issue was. Fuses (and other chip/tool details) are accessed through the menu item that looks like this  . Clicking it will open a popup window. Select your tool, device, and interface (JTAG in this case), and click apply. I suggest trying this first once you have everything wired up, because if that doesn't work then your debugging is certainly not going to work.Once you have things hooked up, your tool can connect to the device via JTAG, and you've written some code you want to debug, then you can compile/download/debug in one step. There is another menu item that looks like this  . Selecting Debug/JTAG as shown here, and clicking on the "blue arrow/pause" icon will compile, load, and start debugging.Edit: If you actually want to disable optimizations, you can. Those settings (and many others) live under Project->Properties->Toolchain->AVR/GNU C Compiler->Optimization->Optimization Level. Note that the delay library (included here but not used) will not work properly if you disable optimizations. armorer fucked around with this message at 01:13 on May 28, 2013 |
|
#
¿
May 28, 2013 01:10
|
|
|
No problem! It was informative for me to go through. If you are curious, my setup for this was pretty simple: The little protoboard in the center just splits the JTAG pins over the center of the breadboard, and the other little protoboard is just a button with pullup resistor that I soldered together a while back for ease of breadboarding. I know you can't really see where all those wires go, but I mostly wanted to demonstrate that it wasn't really much to breadboard. Setting that up only took 5 minutes or so. I used the pin diagrams here to wire up the JTAG pins, and I am providing 5 volts from an external power supply (comes in to the top right of the breadboard). Also I have a ZIF socket and male header pins soldered on my Dragon. If you buy one it will come with a bunch of unpopulated spots. If I remember correctly, only the ISP, JTAG, and power pins came soldered in.
|
|
#
¿
May 28, 2013 01:31
|
|
|
One other thing: The Dragon documentation states that it doesn't support JTAG OCD for devices with more than 32k flash. That is false. At some point they removed that constraint and you can find numerous people mentioning it around the web. For some reason though they never updated the documentation. Obviously though (since I did this little test with an atmega1284) the limit has been removed.
|
|
#
¿
May 28, 2013 01:59
|
|
|
I'll look for the document that I saw it in and edit it in here, but yeah it appears to have been lifted a long time ago based on everything I read online. Thanks for the webdoc link, I will be sure to use that in the future. As an aside, the html page title on the webdocs shows up as "???TITLE???".
|
|
#
¿
May 29, 2013 19:30
|
|
|
Well after scouring the Atmel site for any mention of the 32k limit, I can't find a datasheet or anything. So I suspect that I found that in some old documentation referenced somewhere. Regardless, now I know to reference the webdoc and info included in AVR Studio, so thanks for that!
|
|
#
¿
May 29, 2013 20:37
|
|
|
When I am using mine to program chips in the ZIF socket, I power the target from the dragon. Otherwise I generally power the target from an external source. I hadn't heard about the USB port vs. hub thing so I can't comment there. I've been running mine from my machines' USB port directly thus far though with no problems. I keep planning on buying or making an enclosure for it, and I keep not doing so. Maybe next week? Edit: Thus far its "case" has been the cardboard box it came in. I haven't been using it entirely bare.
|
|
#
¿
Jun 4, 2013 19:16
|
|
|
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
|
|
|
I have an AVR Dragon and it's been working fine for me. I believe that Marty picked one up as well a while back and has been using it long enough to have formed an opinion. What are you looking for in a dev board exactly? When I tinker with AVR chips I typically am building up a small purpose built board, which keeps the cost way below $30. If you want the dev board to prove out a design, could you buy one or two Arduino Unos (just to use them as a dev board for the atmega328p) and then do your run of 30 devices on a cheaper custom board?
|
|
#
¿
Oct 16, 2013 20:03
|
|
|
There are a LOT of Uno "compatible" boards. I haven't used any of them (because I typically just cobble up something custom) but some of them are in the $10 range. SainSmart has this one for example. If you want an excuse to pick up a programmer and want to use whatever you already have coded up for the arduino, one of the cheap knockoff boards may work fine for you.
|
|
#
¿
Oct 16, 2013 20:23
|
|
|
JawnV6 posted:The first intern prototype was derailed for a week when their cheap arduino knockoff turned out to nonfunctional. Was one of those onion peeling weeks when they finally traced it back to the cheap board not having the right parts on it. So I'm a little wary of going that route Fair enough. As I said I haven't used any of the knockoffs. The whole schematic is freely accessible though, so if the parts are right it ought to work fine. I've had good luck just writing code in AVR Studio and programming the chips with the AVR Dragon. I keep meaning to get a gcc toolchain in place so I can switch over to coding on linux (which I vastly prefer in general), but I have honestly been pretty lazy about it. What I like about the AVR platform is that you have good free development options, and they are pretty easy to work with for a beginner like me. If you are willing to make some boards, that route may be your cheapest option. I have one of the STM Discovery boards you mentioned, but I haven't used it for anything so I really can't speak for it. Another option for a $10 dev board is the MSP430 Launchpad. I think it has more of an online following than the STM Launchpad, but maybe I just haven't found the right forums yet. As far as the MSP430 goes, there are the 43oh forums where you might be able to get more info. On the AVR side there is AVR Freaks armorer fucked around with this message at 02:48 on Oct 17, 2013 |
|
#
¿
Oct 17, 2013 02:45
|
|
|
I use the cardboard box my Dragon came in as the case, and am moderately careful with it. I've modified it a bit from how it comes stock - specifically I soldered in a set of male pin headers and a ZIF socket as shown here. The up-to-date documentation on the dragon is here. I made a few little adapter boards on protoboard like they show in that hackaday article. I only have them for the chips I work with frequently, and they are not nearly are professional looking as the ones there. It keeps me from having to wire up the dragon for each different chip I want to work with, and it also keeps me from mis-wiring it and frying something by mistake.
|
|
#
¿
Oct 17, 2013 19:16
|
|
|
|
| # ¿ Apr 27, 2024 20:20 |
|
|
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
|
|