|
I've got an AVR project coming up (making a Larsen scanner clone for a con) with the ATTiny2313A; anyone ever use TSB as a bootloader? What's the best AVR programmer / debugger to use? Similar to Microchip Real ICE and/or PICKit 3. The Dragon?
|
#
?
Apr 9, 2013 14:38
|
|
|
|
| # ? Apr 28, 2024 01:28 |
|
|
evensevenone posted:That doesn't sound like an IDE issue. Studio 6 just uses avr-gcc which should be pretty solid. Not sure what EWARM uses. I don't think it's an "IDE issue" I'm asking what's the more common tool out of the two. I honestly haven't looked into it since I hit that snag and know that between a pushbutton prepackaged solution and something nobody actually uses in practice and isn't worth learning it's a dead simple choice.
|
|
#
?
Apr 9, 2013 16:04
|
|
|
Oops, you're probably talking about ARM. I don't actually know. For the AVR 8-bit micros, everyone uses either Studio or a gcc toolchain with avr-gcc and avrdude. At work we use STM ARM and we just use gcc-arm-embedded, but we're 100% linux and just use gcc/make/etc rather than the fancy proprietary packages. But I didn't set up the toolchain and we have our own bootloaders and flashing tools. I would think something similar would be possible for the AVR stuff.
|
|
#
?
Apr 9, 2013 17:08
|
|
|
I'm currently looking for an interface to run large numbers of sub-controllers (they will be controlling heterogeneous devices) from a single point of connection to a main computer. The bandwidth requirements are likely to be extremely low: In the order of 100 bytes/s at peak. The architecture that I've come up with involves a USB interface to a multiplexer, which can connect to other multiplexers and then to the final devices in a tree-like manner (number of endpoints needs to scale to 100s). Ideally, the endpoints would be left to do their thing and then report back to their master with an interrupt. I'll be using xmegas for this so I have about 34 pins for IO and would quite like to be able to run about 8 devices per multiplexer. The architecture I have in mind would therefore benefit from having device-select and interrupt share a line and then have a data bus shared between all sub-devices, with a similarly common clock. Questions: 1. Is this a stupid way of designing a scalable system. It really does need the ability to just bolt on more and more devices over time: Hence the tree architecture. 2. Is there any kind of interface standard that would fit the bill? Given the limited number of in-built com subs on each chip, I'm quite open to bit-banging, which should be ok given the low bandwidth requirements.
|
|
#
?
Apr 10, 2013 23:03
|
|
|
Disnesquick posted:I'm currently looking for an interface to run large numbers of sub-controllers (they will be controlling heterogeneous devices) from a single point of connection to a main computer. The bandwidth requirements are likely to be extremely low: In the order of 100 bytes/s at peak. The architecture that I've come up with involves a USB interface to a multiplexer, which can connect to other multiplexers and then to the final devices in a tree-like manner (number of endpoints needs to scale to 100s). Ideally, the endpoints would be left to do their thing and then report back to their master with an interrupt. I'll be using xmegas for this so I have about 34 pins for IO and would quite like to be able to run about 8 devices per multiplexer. The architecture I have in mind would therefore benefit from having device-select and interrupt share a line and then have a data bus shared between all sub-devices, with a similarly common clock. Questions: So if I understand correctly you have: Computer -> USB -> Bridge Device -> "Master Nodes" --> "Sub Nodes"? First thing that jumps to mind would be RS-485 or a CAN/LIN combination. But, you say you want each of the sub-devices to share a data bus, how far are they from their master? With the data rate as slow as you say it is, it's possible you could share SPI data lines among the sub modules and use chip-select to control whichever one you're talking too. I don't think it's a terrible way of a scalable system; you have some master nodes each of which can support x number of baby nodes. As long as you're OK with the cost of a master node, it shouldn't be a problem. How far apart are all of these nodes?
|
|
#
?
Apr 12, 2013 15:22
|
|
|
movax posted:I've got an AVR project coming up (making a Larsen scanner clone for a con) with the ATTiny2313A; anyone ever use TSB as a bootloader? What's the best AVR programmer / debugger to use? Similar to Microchip Real ICE and/or PICKit 3. The Dragon? OK, so I discovered the existence of the micronucleus bootloader, used on the ATTiny85 that's on the Digi-Spark. I'm thinking now I might do the USB connector on PCB thing, switch to a 20-pin ATTiny85 and figure out a way to cheaply have 5V USB input not destroy a coin cell battery when that is also plugged in. (Probably a Diode OR, and see how bad parasitic from power dissipation is) Anyone know if the micronucleus-85 bootloader is easily portable to the 2313A? movax fucked around with this message at 17:21 on Apr 12, 2013 |
|
#
?
Apr 12, 2013 17:13
|
|
|
movax posted:So if I understand correctly you have: Not sure if you're on the same wavelength so I'll clarify: Computer -> USB -> Root master -> sub masters 1..8 -> "Sub nodes" 1..64 (assuming 8 of the mulitplexers/sub masters) Each master node / multiplexer would cost peanuts, since I intend to use a cheapo Uc for each one and IDC connections. From what I understand, SPI doesn't allow the slave to initiate a data-frame, which would necessitate poling. I guess that would be ok but interrupts would be preferred. CAN/LIN does look the business however, it seems to be pretty much what I'm looking for and there seem to be a few AVRs with hardware support. Cheers.
|
|
#
?
Apr 12, 2013 19:01
|
|
|
Disnesquick posted:Not sure if you're on the same wavelength so I'll clarify: Ah, OK. Yeah, I think CAN/LIN would work; you could use LIN to talk from sub nodes to sub masters (you'd need 4 LIN buses though), and then CAN within the sub-masters / to root master. Or, you could calculate all the capacitance / cable length values and just make everything a CAN node.
|
|
#
?
Apr 12, 2013 21:31
|
|
|
Disnesquick posted:CAN/LIN does look the business however, it seems to be pretty much what I'm looking for and there seem to be a few AVRs with hardware support. Cheers. You might want to use the 2515 + 2551 or similar with a regular AVR rather than the 2551 (or some other CAN transceiver) with a CAN-capable AVR . They're pretty easy to use and it's more cheap poo poo to blow up if something is miswired instead of blowing up your micro 
|
|
#
?
Apr 12, 2013 21:40
|
|
|
JawnV6 posted:I don't think it's an "IDE issue" I'm asking what's the more common tool out of the two. I honestly haven't looked into it since I hit that snag and know that between a pushbutton prepackaged solution and something nobody actually uses in practice and isn't worth learning it's a dead simple choice. IAR is the devil - I would avoid it at all costs. That said I'm somewhat biased since their crappy copy protection keeps breaking our ASF validation builds (yes, our servers are licensed) and I get to eat lunch with the tools team that actually develops Atmel Studio.
|
|
#
?
Apr 12, 2013 23:22
|
|
|
Otto Skorzeny posted:You might want to use the 2515 + 2551 or similar with a regular AVR rather than the 2551 (or some other CAN transceiver) with a CAN-capable AVR . They're pretty easy to use and it's more cheap poo poo to blow up if something is miswired instead of blowing up your micro This is perfect. I had hoped to use the xmega architecture (familiarity more than anything) but I don't think there is a CAN-enabled xmega available. This should solve that little problem. Thanks. movax posted:Or, you could calculate all the capacitance / cable length values and just make everything a CAN node. I really want to go with something scalable. Having something so monolithic doesn't fit well with the plan to eventually have hundreds of sub-devices. The hierarchic modular approach should allow quite a bit of positional flexibility too, since each 'plex is acting as a repeater too (The final apparatus will likely be spread over multiple fume-hoods in a chemical laboratory.) Active Quasar fucked around with this message at 03:58 on Apr 13, 2013 |
|
#
?
Apr 13, 2013 03:55
|
|
|
EpicCodeMonkey posted:IAR is the devil - I would avoid it at all costs. That said I'm somewhat biased since their crappy copy protection keeps breaking our ASF validation builds (yes, our servers are licensed) and I get to eat lunch with the tools team that actually develops Atmel Studio. Thanks, good feedback. I'm sure I'll get this thing chugging along with enough time on it if people can get by with a cmdline gcc solution. Right now I'm neck deep in other new code and this has to wait.
|
|
#
?
Apr 15, 2013 17:28
|
|
|
This seemed as good a place as any here to ask about some control systems stuff, since that's a common enough reason to use a microcontroller. I'm sorry if there's a better place for it, but I didn't get anything at all on SA searching for "impulse response" or "transfer function." I'm trying to figure out how I might model a discrete system for doing some testing. Particularly, it's a thermal environment where I have a quiescent temperature that things would stay at if not adjusted, and a controller that needs a little help hitting a temperature. If I set my controller to that quiescent temperature, it's as if nothing is happening. So I just assume that as my zero point. I was seeing some odd behavior that I don't model, so I was thinking instead it was time to get an impulse response. I just figured if I soaked at the quiescent temperature and then shot up the controller uncompensated for, say, half of a sampling period, I'd get a rough impulse response. It's been years since I did any of this in school and the professor seemed to know a lot, but most of it didn't really stick. So I know the terms, but I didn't really get all the techniques down and I've long lost all the mathematical muster. I'm trying to figure out how I might model the system based on it's measured discrete impulse response. Then I'm wondering if I could relatively safely apply this to other temperatures, or if I'm just asking for serious trouble trying.
|
|
#
?
Apr 25, 2013 00:27
|
|
|
Rocko Bonaparte posted:This seemed as good a place as any here to ask about some control systems stuff, since that's a common enough reason to use a microcontroller. Do you have a closed feedback loop? Can the microcontroller actively read the temperature and compensate? It might help to know what your input/output is (how are you controlling the temperature, for instance). I was talking with my controls prof (pretty famous old-rear end engineer with tons of experience) about how to model something like a quadcopter (the project I was poking at the time) and he kind of looked at me like I was stupid. In class, we work with equations - you get an equation, and you apply whatever technique we were covering that class to said equations. We didn't really cover where these loving equations come from, they were just provided. Clearly they are describing the behavior of the system, and you can work out why this is proportional to that, etc, but with a complicated system? Meh! Anyways, he looked at me like I was stupid and said he had no idea how you would model one and didn't care to find out, but he had seen youtube videos of kids tuning PID loops to control theirs and he was confident I could figure it out without modeling. "Confident I could figure it out" was said with a great deal of disdain - I did say he was an old rear end engineer, right? What I'm trying to say is sometimes you don't really need to know anything, you just slap in a generic PID loop and tune your coefficients. Without knowing much about the system, I would guess that would solve it but you would need closed-loop feedback, at least, for that to be a doable approach.
|
|
#
?
Apr 25, 2013 01:04
|
|
|
Delta-Wye posted:Do you have a closed feedback loop? Can the microcontroller actively read the temperature and compensate? It might help to know what your input/output is (how are you controlling the temperature, for instance). The thermal controller is in an open loop. I am closing the loop through a regular old PC, but I figured this was my kind of thread for control systems kind of problems regardless of that. There's an option for trying to close the loop to the thermal controllers in hardware, but it opens new problems such as the slew rate being so rapid that it can break something. Delta-Wye posted:What I'm trying to say is sometimes you don't really need to know anything, you just slap in a generic PID loop and tune your coefficients. Without knowing much about the system, I would guess that would solve it but you would need closed-loop feedback, at least, for that to be a doable approach. Right now I'm using a fuzzy-logic approach because I haven't been able to get a PID formula that works in all situations. Yeah, if you have this specific model in the current conditions it's experiencing, I can make an algorithm that will take it from one specific temperature to another, but that's it. If I'm trying different temperature ranges, or somebody farts on the environment, it all would go to hell. I've found out that's the crux of most undergraduate controls courses. 
|
|
#
?
Apr 25, 2013 05:51
|
|
|
Edit: Somehow I double posted a quote of myself. 
Rocko Bonaparte fucked around with this message at 16:41 on Apr 25, 2013 |
|
#
?
Apr 25, 2013 05:51
|
|
|
There's only one formula for PID. I would think for a thermal system it shouldn't be too hard to find gains that work for a variety of conditions. You don't really need to bother modeling anything to use PID, you just tweak the gains.
|
|
#
?
Apr 25, 2013 06:41
|
|
|
evensevenone posted:There's only one formula for PID. I would think for a thermal system it shouldn't be too hard to find gains that work for a variety of conditions. You don't really need to bother modeling anything to use PID, you just tweak the gains.
|
|
#
?
Apr 25, 2013 16:43
|
|
|
Rocko Bonaparte posted:I still am hoping to get a model of the system so I can run automatic tests against it. That is my main issue right now. Some of the units I'm using have less consistent behavior. They'll overshoot, but only if they've been jerked around certain ways. It's too complicated for me to derive just by looking at it. What kind of system are you using that a PID loop can't correct for? It sounds more like a terrible implementation when you tried it than a poor fit to your problem. It's usually not terribly difficult to control overshoot by tuning your gains.
|
|
#
?
Apr 25, 2013 17:09
|
|
|
Delta-Wye posted:What kind of system are you using that a PID loop can't correct for? It sounds more like a terrible implementation when you tried it than a poor fit to your problem. It's usually not terribly difficult to control overshoot by tuning your gains. I have to deal with different models of thermal controls installed in various different ways. Furthermore, the controllers are moderating different items, and those items can change their behavior at any point in operation. I have to expect to go from any temperature to another temperature within the range of, say, -30C to 100C. When I tried to tune a PID one day, I got it to go from one temperature to another fine enough. A day later, they had to change the environment, including how it was seating, and that PID developed a steady-state error. Everybody is obsessing over the PID. That's not the thing. Whatever I come up with, I'd like to be able to test across a variety of different models that have given me problems in the past. I'm currently dealing with one with some very odd behavior so the convergence time is longer than I consider acceptable. I do still converge. So I'd like to be able to reproduce it's behavior in a simulation since I can't perpetually sit in front of the gear. Later I want to be able to run regressions against that to make sure I can still handle it. So I'm trying to construct a model of it. That is my preoccupation.
|
|
#
?
Apr 25, 2013 19:18
|
|
|
Rocko Bonaparte posted:I have to deal with different models of thermal controls installed in various different ways. Furthermore, the controllers are moderating different items, and those items can change their behavior at any point in operation. I have to expect to go from any temperature to another temperature within the range of, say, -30C to 100C. When I tried to tune a PID one day, I got it to go from one temperature to another fine enough. A day later, they had to change the environment, including how it was seating, and that PID developed a steady-state error. What the gently caress are you building? Christ you are cryptic.  I can't help you model "different models of thermal controls installed in various different ways."We're fixated on a PID as a solution because it is a generic one-size-fits-all approach to control problems - there are certainly better approaches available for certain situations (sliding mode control and a few other approaches I've seen work miracles) but they require more information specifying the system. Literally all we have to go on is "I have a system with a control output and a control feedback sensor, how can I make it stable?" Of course we're going to be talking about a generic PID approach - it's a good match for your generic problem!
|
|
#
?
Apr 25, 2013 21:08
|
|
|
Make sure there are no poles in the right hand side of the s-plane. Boom, stable 
|
|
#
?
Apr 25, 2013 21:19
|
|
|
I need to write a rather simplistic firmware to replace a fried AVR chip in a student-built board that runs some lab equipment. I'm not really familiar with the AVR infrastructure but it doesn't seem too difficult. AVR Studio looks like a nice IDE. I'm mostly curious about what sort of programmer I should pick up. I'd like something that I can use to debug on chip, if that's possible. Do the more expensive official programmers support something like JTAG? I presume the $5 hong kong ones on eBay probably won't.
|
|
#
?
Apr 25, 2013 21:34
|
|
|
Martytoof posted:I need to write a rather simplistic firmware to replace a fried AVR chip in a student-built board that runs some lab equipment.
|
|
#
?
Apr 25, 2013 21:46
|
|
|
mnd posted:I am not current on AVR stuff, so there may be something better or newer, but for a programmer, I think you want an AVR Dragon. I've used a dragon and it is fine. They do seem to have a tendency to blow up though, I've had to (and had some enterprising students have to) replace parts on one when it kept smoking things. Admittedly, it was being used by students while I wasn't around to supervise so who knows what happened to it, but ideally a dev tool should be protected against most stupid-developer tricks. God knows I've done enough miswiring or accidental shorting during late-night rush jobs to realize it is inevitable something gets plugged in wrong.
|
|
#
?
Apr 25, 2013 22:49
|
|
|
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
|
|
|
Yeah I just started using a Dragon as well, and while it's a bit clunky, it's certainly usable and the software isn't awful for it. Today though I have like 8 hours to get a working USB bootloader running on the ATTiny4313; trying to port the micronucleus-85 one over 
|
|
#
?
Apr 26, 2013 14:20
|
|
|
The AVR Dragon is a beautiful board, and those stencils are pretty classy. I use one in my lab and yes it is a pain in the but having to manually wire up all of the JTAG pins every time :-(
|
|
#
?
May 2, 2013 23:52
|
|
|
The startup I work for recently made a Kickstarter project called 'AshimaCore': AshimaCore can be seen three ways:
As I briefly mentioned above, an ultimate goal of my startup is to design a hexacopter 'puck'. Here's a picture of the puck, as well as the puck next to our existing quadrotor:   We decided that it would be a good idea to first release the avionics board that we'll be using for a hexacopter precursor to the puck. We looked around for sub-$200 IMUs and didn't find much that was good. There's a $125 IMU from SparkFun, but it has a 16MHz, 8-bit processor with no FPU. If you want logging or wireless ability, you'll be spending more. We give you the sensor + hefty MCU + µSD slot for $129, and adding WiFi is $35. If our board becomes popular enough to hit 1000 units, that $129 price could drop appreciably as well. Ok this seems very sales-pitchy so far. First, I'm excited about providing a cheap IMU that has a sufficiently beefy processor to do high quality state estimation with plenty of cycles to spare. Second, I'm excited about fostering a community around the STM32F4xx processors, analogous to Arduino but appealing to people willing to write more rigorous code and get the advantages that come with more powerful libraries. Arduino, for example, doesn't have an asynchronous I2C library and it only recently added asynchronous UART. Third, I look forward to helping write open-source multicopter code under a non-GPL license (so far we've settled on MIT Expat) that can assume a hefty microcontroller, and benefit from a few years' experience with writing multicopter code. I don't want to come down too hard on what's out there, but let's just say that the code has a long history of evolving from something simple; cruft inevitably accumulates, especially when nobody is being paid full-time to work on the code base. Finally, I look forward to using C++11 in an embedded context, from the libraries on up. Certain bugs just won't be possible, and one gets benefits like lambda functions. If anyone here wants to pledge to the Kickstarter, that'd clearly be awesome, but I'd also appreciate comments and suggestions. Any funds go to support a company committed to open-sourcing much of what they do. (We may not open-source our IMU code, because we need to make a profit somehow and a services-only model isn't guaranteed to work, here. Others would be welcome to write their own IMU code, of course.) It would be neat if there could be one more success story of a company which open-sourced much of what it did, proving that this is a viable model. Stuff that you can build with IMUs is also freaking cool, whether it's a multicopter or something else. Note on ST hyperlinks: ST likes to change their URL structure a lot, so please let me know if they break.
|
|
#
?
May 3, 2013 23:36
|
|
|
So... "please buy our IMU, oh and no, we won't give you the IMU software to make it work"?
|
|
#
?
May 4, 2013 00:36
|
|
|
Delta-Wye posted:So... "please buy our IMU, oh and no, we won't give you the IMU software to make it work"? Edit: asking a company to open-source everything it does isn't always a practical thing. Not everyone can work on a pure-services basis.
|
|
#
?
May 4, 2013 00:44
|
|
|
I did give Victor the go-ahead to post that, and discussion is good just try to keep it civil is all. Looks like Victor is willing to answer questions honestly/openly which is nice!
|
|
#
?
May 4, 2013 00:46
|
|
|
And to rebreathe some life into this thread... Question re: IMU board, is that a 2-layer PCB still? And re: AVR Studio, fuckin' ugh. Wasted like four hours of life trying to use it to flash some chips via ISP, and it just kept loving it up. Some cobbled-together version of avrdude + libusb managed to get the job done with no issues whatsoever. And that doesn't include the time it took to find some F/F jumpers and get the AVR Dragon rigged up for HVSP to un-gently caress bogus fuse settings AVR Studio wrote (bonus: unless I'm missing something, the current version of Studio is bugged and can't flash program code using HVSP, just fuses). I'm really beginning to hate everything remotely related to Atmel and the AVR. PICs 4 Lyfe
|
|
#
?
May 6, 2013 20:36
|
|
|
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. I'm actually kind of looking forward to this thing: http://www.sparkdevices.com/. Cortex M3 Arduino + WiFi onboard. Use Wiring or use the JTAG headers to write low level stuff to the chip. some kinda jackal fucked around with this message at 20:45 on May 6, 2013 |
|
#
?
May 6, 2013 20:42
|
|
|
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. Once you do enough "low-level" stuff, you generally end up with a library of code you can take from project to project anyway, which is basically what Arduino sits on (though admittedly their libraries are probably better tested simply by virtue of having a shitload of users). That said as long as you don't turn into the typical Arduino user and understand the limitations/relative (dis)advantages of each approach, it's all good in my book. e: not you specifically, duh
|
|
#
?
May 6, 2013 20:56
|
|
|
movax posted:Question re: IMU board, is that a 2-layer PCB still? quote:And re: AVR Studio, fuckin' ugh. Wasted like four hours of life trying to use it to flash some chips via ISP, and it just kept loving it up. Some cobbled-together version of avrdude + libusb managed to get the job done with no issues whatsoever. And that doesn't include the time it took to find some F/F jumpers and get the AVR Dragon rigged up for HVSP to un-gently caress bogus fuse settings AVR Studio wrote (bonus: unless I'm missing something, the current version of Studio is bugged and can't flash program code using HVSP, just fuses). I'm really beginning to hate everything remotely related to Atmel and the AVR. PICs 4 Lyfe 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.
|
|
#
?
May 6, 2013 22:55
|
|
|
Victor posted:My last experience with AVR Studio was in 2003; it worked then, but a lot can change in ten years. Have you had issues using GCC tools and avrdude, or do you just prefer an IDE? I'm partial to Visual Studio, which it apparently wraps around now, but no, I was OK doing the development with Notepad++ + gcc, that was fine (mostly because I didn't any crazy debugging for this). I was only using Studio to drive the AVR Dragon since I figured, hey, Atmel dev tool + Atmel software == everything works!
|
|
#
?
May 6, 2013 23:00
|
|
|
Victor posted:Hey that's a pretty cool Kickstarter. I don't know why yours should be a frowned-upon opinion; why must you become a microcontroller whiz and be able to design PCBs in your sleep? Yeah I tried to not link directly to the kickstarter to avoid clashing with your project, but it's the perfect board for my little pet project (basically a clone of the Budweiser goal light). Will let me hop on the nearest wifi, and I'll just hook up an SD card to store the goal horn audio. All I have to do is write the parser to scrape the actual scores from an online source, which will likely run on an endpoint at my house anyway. There's actually no reason it should be frowned upon, but I like to pride myself on learning something by going all out and learning every little thing about it, down to the nuts and bolts. So basically I like to abstract as little as possible. Which I guess is fine if you're just learning and toying around, but if you want to get something done in a reasonable amount of time it's best to just use the tools you've got available. I don't even want to imagine implementing a TCP/IP stack and WiFi without third party libraries though, so I would probably have gone down that route anyway.
|
|
#
?
May 6, 2013 23:02
|
|
|
movax posted:I'm partial to Visual Studio, which it apparently wraps around now, but no, I was OK doing the development with Notepad++ + gcc, that was fine (mostly because I didn't any crazy debugging for this). I was only using Studio to drive the AVR Dragon since I figured, hey, Atmel dev tool + Atmel software == everything works! I think the big change with AVR Studio 5(?) and later was the inclusion of their own compiler, as well as the Visual Studio shell switch. The version of AVR Studio I have only has an assembler; I use WinAVR to compile.
|
|
#
?
May 7, 2013 04:45
|
|
|
|
| # ? Apr 28, 2024 01:28 |
|
|
Martytoof posted:Yeah I tried to not link directly to the kickstarter to avoid clashing with your project, but it's the perfect board for my little pet project (basically a clone of the Budweiser goal light). Will let me hop on the nearest wifi, and I'll just hook up an SD card to store the goal horn audio. All I have to do is write the parser to scrape the actual scores from an online source, which will likely run on an endpoint at my house anyway.
|
|
#
?
May 7, 2013 05:53
|
|