|
Does anyone use Studio 6? Even my Atmel reference design comes with EWARM toolchain support instead. I've hacked it around to the point where it's compiling, but some interrupt isn't getting routed and I'm weighing figuring out Studio 6 or just grabbing EWARM if that's what people actually use.
|
#
¿
Apr 9, 2013 08:26
|
|
|
|
| # ¿ Apr 27, 2024 20:24 |
|
|
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
|
|
|
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
|
|
|
Victor posted:When it comes to more complex things (e.g. generating decent quality sound), Arduino just isn't capable. You aren't going to be running too many FFTs on an AVR, and they aren't going to be floats if you want even 100Hz. The code quality of the Arduino community also isn't that great; most if not all of us know how hard it is to foster a high quality and competent community. Victor posted:why must you become a microcontroller whiz and be able to design PCBs in your sleep?
|
|
#
¿
May 7, 2013 21:48
|
|
|
There's a whole spectrum. You're alternating between hating above and hating below. I'm curious how you found yourself on the precise defensible point.
|
|
#
¿
May 7, 2013 22:23
|
|
|
Victor posted:How does one reach out to people who want devices that have features and are optimized? Are there any good examples of this out there? If so, what does the learning curve look like? Why *must* there be something in that gap?
|
|
#
¿
May 8, 2013 20:49
|
|
|
Mechanical engineers I work with without any software training are able to get workable solutions to their problems with Arduino alone, so I'm really having a hard time fathoming what's in the gap. e: like if you know enough to expand the acronym ISR, you can probably work with the Atmel tools I mentioned
|
|
#
¿
May 8, 2013 20:57
|
|
|
If you know what "ISR" stands for, you can use an Atmel. Sorry you missed my edit, they're really great tools and did you even look at them before coming back to post at me again?
|
|
#
¿
May 8, 2013 21:05
|
|
|
edit: I'm just being mean
JawnV6 fucked around with this message at 01:55 on May 9, 2013 |
|
#
¿
May 9, 2013 01:46
|
|
|
armorer posted:Kids that are into it will graduate to Legos and them maybe move on to actually studying engineering. I'm getting the distinct impression people think more complex things should be possible without an ounce of engineering effort applied. Sucks, but past a certain point of complexity you need an engineer. From what I've seen Arduino's covering most of that low end and I don't see the gap between "what's possible with an Arduino" and "what you need an Engineer for". For what it's worth, if we're talking about floats and FFT's, I think you've got an engineer.
|
|
#
¿
May 9, 2013 16:56
|
|
|
armorer posted: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. If that's your characterization of me, have at it dude. I wasn't hating on Arduino, I was doubting a gap between it and pro grade solutions necessarily existed. Guess that makes me an elitist shithead now?
|
|
#
¿
May 9, 2013 17:25
|
|
|
Victor posted:That impression is from your attitude that people must expend as much effort as you had to, in order to get going on something more powerful than an Arduino. I encounter plenty of your type: people who refuse to believe that helping people learn things in less time than it took you to learn them is a good thing. If you had to walk uphill both ways for school, your children ought to as well! It's... character-building! You specifically asked for my learning ramp and I provided it. If I'd known you'd throw this much poo poo at me as a result or so grossly mischaracterized a response to a direct question you asked, I doubt I would've been so forthcoming. You're shilling for your company, and that's great, have at it, but could you back the gently caress up off me?
|
|
#
¿
May 9, 2013 21:36
|
|
|
Victor posted:Pretty sure I haven't grossly mischaracterized you. Need I quote the elitist post you later edited away? Victor posted:My criticism wasn't that you are a really good engineer, it's that you don't think there's a niche between Arduino and requiring ten years of engineering experience, as you stated. Although, I actually do question what those ten years of engineering experience have gotten you, if you think the TWI libraries provided with Atmel Studio 6 are production-ready. Maybe you just haven't done much with TWI, but this also makes me wonder about the other libs provided by Atmel. I'm not interested in giving a history lesson with such an antagonistic student, but let me know if you ever learn why Atmel doesn't say I2C and we could share a laugh about this. If you literally need to see those letters, check out Dimax's USB solution. Victor posted:Part of this may be due to a huge personality difference between folks like Jawn6V and myself. I like to dig into something head-first, learning the various bits and pieces only when I need to. Oftentimes, bad software and hardware design requires you to know far more details than is theoretically required, for a given task. I wouldn't be surprised if Jawn6V doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised. I'd like to characterize your two approaches "dig in, learn as necessary" and "bookworm datasheet analysis". One of these is The Right Way, a slow plodding approach that guarantees safety at the cost of huge up-front investment. The other is demonstrably Worse, with no guarantee of deterministic success and potential for huge delays that could have been avoided. Victor, you're arguing for Worse Is Better. And if either of us has a known history of requiring a 50-page PDF to be read before commencing a task, I believe it's you. I've always been an advocate for Worse Is Better and I can't imagine your bookworm description squaring with that history instead of whatever mythical elitist you've concocted in my place. Victor posted:I definitely have the urge to splurge and use an FPGA to do stuff, but that's quite a bit more expensive, especially if you can't use a free dev environment (in other words, if you want anything more than a very simple design, unless things have changed since I last looked into this).
|
|
#
¿
May 12, 2013 16:20
|
|
|
Victor posted:I'm merely suggesting that you forget what it was like to want to go beyond Arduino, but not really want to get into a more powerful microcontroller from the ground-up. It's pretty typical for people to forget their understanding level and mentality when they were first learning something. My statements are actually based on watching a bunch of mechanical engineers with no coding or EE skills get Arduino up to snuff prototyping things without my help. And seeing them perfectly content with that tool set. No, really, they've done amazing things and haven't needed floats or FFT's that you're totally sure the Arduino really really needs. If you're quite done maligning my good name without cause, we might be able to discuss the gap you see in real terms instead of whipping up yet another false accusation. quote:How did you interpret the following statement as slander? "I wouldn't be surprised if JawnV6 doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised." Color me surprised. I'm not what you're talking about with respect to the 50-page PDF thing. Good grief.
|
|
#
¿
May 13, 2013 14:14
|
|
|
Victor posted:My criticism remains: the TWI libraries you casually referenced in AS6 are not robust. Well, the one for AVRs was third-party and passed its arguments via global variables, so I hesitate to call it a 'library'. Uh, wanna cite your source here? At work now and the tool that I'm actually using, the one that would be in front of a generic user, doesn't look anything like "third party passing global variables." Check it out. I'd hate to think you're using decade-old knowledge to unfairly trash something for the third time in as many posts. But the only other explanation that comes to mind is that you're using cursory google searches to call swaths of competing products "not robust" without ever thinking the problem might be on your end or that the IDE would helpfully link you to the proper docs. For someone claiming to be eager to do the heavy lifting for others, you don't seem all that invested in figuring out what's already out there. Did you even get around to checking out libopencm3 that evensevenone mentioned? Or were you more interested in trashing me than discussing relevant tech?
|
|
#
¿
May 13, 2013 16:08
|
|
|
Just from reading the link, the BFAR register (separate from BFSR) should hold the data address that caused the fault and the return address on the stack frame points to the instruction that caused it. The BFARVALID bit in that register should also be set. Imprecise would mean that a bus error happened, but due to some higher priority process the debug information got trashed and the proc can't be sure what to tell you. Not sure if that helps, but bow howdy I've read/written some fault documentation and that's what it's saying to me. Knowing those two addresses should get you pointed in the right direction, figure out what instruction/code is causing it and how it got the goofy address that caused a fault.
|
|
#
¿
May 25, 2013 01:11
|
|
|
Slanderer posted:I know this is occurring at an inline function that is appending null-terminated strings to a packet, which is called countless times, and is properly checking for overflows in the event that it is passed a string without null termination.
|
|
#
¿
May 25, 2013 14:54
|
|
|
If you can't spare the $50 for the Open Bench Logic Analyzer, maybe you can swing $30 on the Bus Pirate??
|
|
#
¿
Jun 3, 2013 20:26
|
|
|
Victor posted:I think it'd also be a great opportunity to dabble in FPGA-land? quote:I've wanted to make some fairly complex triggers that I could do by just extensive logging, but I think it'd just be plain fun to try them in VHDL or Verilog. (I wish I could use BlueSpec...) Complex triggers are more powerful than "extensive logging" could ever get you. Most real analyzers are able to pipe out data faster than you could ever record it, triggering is built around getting around that limitation and using the small memory you have effectively. For i2c debug you probably want a trigger that controls logging itself to skip over idle. There's also the $10/3 Saleae knockoffs someone (peepsalot?) linked in the magic smoke thread when I asked about the OWLA, but that was a bit odd for me.
|
|
#
¿
Jun 3, 2013 21:23
|
|
|
Malcolm XML posted:What's wrong with bluespec? Oh, nothing at all. It's an amazing tool that lets non-experts write quality collateral without spending hours worrying about constraint logic. Sorry if I came off negative on the tool itself, nothing but good things to say about it in the proper domain. It's absolute overkill for LA triggering.
|
|
#
¿
Jun 3, 2013 22:47
|
|
|
Victor posted:Is it at all standard for there to be a mode where the LA simply gives you the time codes of transitions? I have to imagine this is a way to compress data, but I know very little about LAs. When I think of a difficult triggering condition, it was generally across interfaces or had a long delay built in. Like I knew the failing condition had happened when I saw a particular address/data hit DRAM, but the interesting behavior was likely on PCIe 2 seconds before that. Not 2 seconds on the nose, but ~2 seconds, with '~' more than could be buffered. Add in 24h repro time and it quickly balloons into weeks of debug and horrid analogies about flashlights catching bullet's reflections. Victor posted:Yep, that's just being me wanting to try cool new things. I still don't think triggering, especially if you're not already experienced in it and have some tough cases, is a rich enough domain for BlueSpec to shine. Try writing a PCIe stack with it. The constraints between the TL/DL/PL are a nice fit.
|
|
#
¿
Jun 4, 2013 00:51
|
|
|
Victor posted:Waiting 10s to test a one-line change is tedious. Go ahead and abandon any FPGA dreams you have then. e: on my senior digital project the only sleep I got for a few days was the 15~20 minutes between hitting F5 and hearing the *ding* that P&R/bitfile generation was done.
|
|
#
¿
Jun 4, 2013 22:59
|
|
|
mnd posted:20 minutes to complete PnR? You're living the life of Riley! I could probably get at least a few hours with these designs I'm working with...  There was a bug that I only figured out a couple years later, I had mis-wired one of the 'column' logic blocks and covered it up with a constant shift later. I spent a few hours puzzling it out until I put the half of the bug I'd seen back in and turned in the 'magic' working version. Victor posted:I know it takes a while to do the whole FPGA process; I worked at NASA JPL one summer on getting a MEMS post gyroscope to actually work. More engineering than science, really. That being said, I dislike attitudes about "what we have is good enough, no need to ask for more". Yours kinda smells like it, but perhaps it isn't. Victor posted:I'm used to working on projects small enough that builds can be super-fast. Once you get into the 15-20 minute range, you really can make it 'ding' when it's finished, and get something productive done in the meantime. If you really want to dig at it, someone else made this abomination: https://github.com/stacksmith/fpgasm Quick compile times! At the cost of giving up literally every advantage of HDL's and writing your netlists by hand!
|
|
#
¿
Jun 4, 2013 23:36
|
|
|
I'd start from the known good assembler and build up from there. Hand-write or generate assembly, run it on the core, test against ???. Do you have a simulator? Or a real core you're trying to replicate? It's not clear from your description what the DUT is. I'm guessing you've built something and want to test that your own code is good but having "close" compiler and crt0 makes it seem like you might have real hardware you're trying to puzzle out. As for patterns, have some basic handwritten checkout to make sure it's alive. Then you want to focus on likely buggy areas. Fill up queues, exercise bypasses, cause backpressure, do tricky control flow. If you're doing anything generated, coverage metrics are going to be crucial. I'm much more familiar with the SVTB side of things over VHDL, but there should be some way to easily collect coverage on simulated runs and you can instrument it yourself if you're running on a FPGA. The Verilog Megathread can probably provide more help than this thread, although plenty of us frequently check both.
|
|
#
¿
Jul 8, 2013 17:54
|
|
|
He has a known good assembler. And writing something that can validate a core at the pin IO level is equivalent to writing a full simulator, which he hasn't stated is available and the construction of which is duplicating his VHDL effort in another language. Much easier to run a few ASM snippets through and check for correctness.
|
|
#
¿
Jul 8, 2013 18:20
|
|
|
gcc is a mess, on purpose. LLVM is fantastic and gives you plenty of hooks to see what it's doing. Starting over with LLVM may well save you time in the end despite having a "close" gcc starting point. For quick and dirty coverage, just have a macro that you can slap on a signal that routes any hit to some location in memory. The hardest part is probably going to be getting the results back over to the host PC. I'm handwaving here since I'm not familiar with VHDL and what it offers for something like this, but you get the idea? You want to focus coverage on corner cases like bypasses where any activation of that signal means the test was 'good' and exercised a potentially buggy area. What's your end goal? Matching the documented behavior? Running old programs written for the old core?
|
|
#
¿
Jul 8, 2013 18:46
|
|
|
hendersa posted:Well, what I suggested was this: Best case, he writes the same bugs in the simulator and the duplication of effort is entirely wasted. I'm amazed that you're still pushing this "method" despite his end goal still left unstated and knowing he doesn't have anything to easily compare it to.
|
|
#
¿
Jul 8, 2013 19:09
|
|
|
No Gravitas posted:How well does LLVM handle 8-bit CPUs with some registers used for indexing memories? In the end I'd probably be OK without having C, I just though it may be a shortcut to doing validation. No Gravitas posted:My end goal is having fun with the finished core. I aim for binary compatibility. This thing is probably the last one of this type of core ever designed from scratch without being a derivative of something. The ISA has a lot of things that make me salivate. Very elegant. Unless you try to implement it, that is. It has more bypasses than a hospital full of bacon-addicted cardiac patients... Coverage should be your starting point. If there's a lot of bypasses, watch them and make sure they're exercised. Write a test per bypass if you have to, though I really think randomly-generated assembler is the easiest path to a lot of volume of running code. I'm kinda guessing this is an old game system and the old binaries are games?
|
|
#
¿
Jul 8, 2013 19:15
|
|
|
edit: welp, it DID get posted the first time
|
|
#
¿
Jul 8, 2013 19:15
|
|
|
No Gravitas posted:The bugs I expect in the bypasses and in the address generation unit. I don't have any old binaries. I don't think any exist to speak of. The thing was not popular when it came out, let alone now. But I am pretty close to completion. I ran some trivial code on the gate array and it ran just fine. Like have a 5-instruction sequence that grabs a value from memory, multiplies it, then stores it back. Toss that chunk and a few others that focus on cmov, overflow, clock modification, etc. at the core in a few configurations with different branch types between them. Use coverage to figure out what's getting hit. Write more tests or adjust the randomizer to hit areas that the first random regression didn't hit. Pull some of the test cases that show good coverage back into simulation so you can get a full trace and make sure that your coverage points actually imply interesting behavior is happening on the FPGA. hendersa posted:I only suggested that running a VHDL testbench on the core to prove that it is functioning correctly for each opcode, prior to moving to higher-level testing, would be a good approach. hendersa posted:If he doesn't need that level of verification, or if the testbench that he has already written is adequate for his purposes, then he is already familiar with the spirit of my advice and is past the point where my comment was useful.
|
|
#
¿
Jul 8, 2013 21:45
|
|
|
isr posted:I met a guy at microchip's master's conference who works for some defense contractor. He claimed that the military required that firmware be written in assembly for some laser guided something his company developed. It's a pretty far stretch from there to "every military contract ever uses only asm"
|
|
#
¿
Sep 5, 2013 19:05
|
|
|
Every RTOS I've used came with a configuration tool that enabled/disabled huge chunks of it and only compiled the bare necessities. So yes, they'll have the option to manage a filesystem or virtual memory, but unless you ask for it they're not costing you anything by existing.
|
|
#
¿
Sep 6, 2013 19:01
|
|
|
Otto Skorzeny posted:This sounds like a DIY version of the infrastructure that an RTOS provides for you, with (ideally) shared-nothing tasks that communicate with each other by sending messages via queues, and an efficient preemptive priority scheduler. Is it FreeRTOS that switches tasks with 2 instructions? Pop off the stack, jump to it? I've worked with it, eCos, and a commercial solution and they're starting to blur together. Otto Skorzeny posted:Hot dang this looks nifty.
|
|
#
¿
Sep 7, 2013 01:58
|
|
|
evensevenone posted:If you use an interrupt-style architecture, you can literally have 100% static allocation, and a stack with only a single frame at a time. And you can make explicit performance guarantees rather than trying to worry about your scheduler and thread switching time and preemption and all that poo poo. RTOS literally exist to provide real-time guarantees. It's half of the name. They offer easy hooks for writing ISR's and enforcing guarantees between them. I really don't know which ones you've worked with, but if you think they somehow enforce dynamic memory or a stack frame I'm not sure what to say. Most of them compile down to a static system you can inspect without much trouble if you've got that much skepticism about it.
|
|
#
¿
Sep 7, 2013 07:09
|
|
|
Malcolm XML posted:Stupid question: if you need hard realtime guarantees why go with an rtos on a uc over an fpga where you implement your algorithm in logic? Cost, complexity, validation? I think there are some fpga with hard procs embedded too for convenience. Yeah, cost/complexity/validation. An RTOS can take a collection of C functions and run on a $0.50 part. The sheer count of folks who can write C over HDL makes that cheaper even ignoring the HW side. Embedded libraries are also more plentiful. Try sourcing an software QR code reader, then find one in hardware. I've always thought the fpga's with hard procs were for SoC development. I've never used one though, just pure fpgas. As a side note, any firmware programmers in the Bay looking for work (lol as if) I know a few companies looking (consumer electronics, electric vehicles, etc.) feel free to shoot me a resume.
|
|
#
¿
Sep 7, 2013 15:38
|
|
|
Has anyone worked with the MPR121 capacitive touch sensor chip? I'm building something based on it. I have the arduino library for it and converted those calls to a real platform. It's working great just with aluminum tape. Now I'm having to tune the sensitivity to put a dielectric between it and the actual touch point on the device. I'm going to dive into the datasheet shortly, but any pointers on working with this or other capacitive sensors would be much appreciated.
|
|
#
¿
Oct 3, 2013 17:51
|
|
|
Holy crap, yeah that would be perfect! fake edit: this? http://www.atmel.com/Images/doc10752.pdf It's specific to one of their chips but includes a lot of general purpose information about the theory.
|
|
#
¿
Oct 3, 2013 18:08
|
|
|
* is just your magic wand of dereferencing https://www.youtube.com/watch?v=6pmWojisM_E
|
|
#
¿
Oct 15, 2013 01:27
|
|
|
I need some advice on serial programmers. This is an area I'm extremely weak in since my last company had teams dedicated to solving this. We're building something that will take ~30 micros. It's a dead simple problem (i.e. two analog sense, drive some LED's) but we're trying to keep costs down. So a $30 arduino is overkill. Plus our senior EE has a burning hatred for arduino. I have a SAM-ICE for working with bigger ARM's and wouldn't mind having a programmer for AVR's. I'm looking at getting 30 AVR dev boards and either an AVR Dragon or AVR ISP mkII. Total cost has to be under 900, so the programmer cost of $52 or $37 split over 30 boards + individual board cost has to be under $30. Any recommendation on a cheap AVR board? I'm looking at that or the STM Discovery from the OP, looks like it's $10 and doesn't require any other cost, correct?
|
|
#
¿
Oct 16, 2013 19:31
|
|
|
|
| # ¿ Apr 27, 2024 20:24 |
|
|
Yeah the concept's proven out with Arduino already. A few interns did the coding and mechanical designs. Now that we're blowing it up to "production" we're looking into the low cost board. The biggest impediment to a custom board is our time, so we're hoping to get by with cheap dev kits. I was hoping to have an excuse to grab another tool to keep around, but the STM's looking cheap and easy enough to knock this out.
|
|
#
¿
Oct 16, 2013 20:11
|
|