|
Martytoof posted:Hey Dragon users. Mine finally arrived and it is basically pretty awesome. Do you guys use the board itself to power your target or do you typically run external power to your target and just rely on the dragon to run ISP/debugWire? I read that the voltage regulators on the Dragon are fragile as a teenager's self esteem, and people are recommending using them via a powered USB hub instead of a direct connection to a computer's USB port. Is this a real thing I should be worried about? typically I just make the board I'm going to put the AVR on and get it's power supply working first. Then I just use the dragon for it's ISP or JTAG with an IDC cable. I've had mine for years, and never bothered putting it in a case or anything and it works fine like this.
|
#
?
Jun 4, 2013 19:50
|
|
|
|
| # ? May 9, 2024 23:58 |
|
|
Zaxxon posted:typically I just make the board I'm going to put the AVR on and get it's power supply working first. Then I just use the dragon for it's ISP or JTAG with an IDC cable. I've had mine for years, and never bothered putting it in a case or anything and it works fine like this.
|
|
#
?
Jun 4, 2013 20:30
|
|
|
Why is everything about the Beaglebone so terribly documented, or at least terribly assumptive.
|
|
#
?
Jun 4, 2013 22:02
|
|
|
Ok, I'm sick and tired of waiting for my STM32F4xx to flash just to test a small change in code. Because this ARM chip is von Neumann, why not just load that small bit of code into SRAM—maybe even the core-coupled memory (CCM) which we aren't using at all right now. (We probably should because it has zero wait states, compared to the flash's five.) Why not link individual functions with the currently on-flash code, but locate them at a known location in the CCM? (Really, it can go anywhere in SRAM, but putting it in CCM isolates it especially well from stuff like stack overflows and so forth. Maybe not important, but sometimes I'm paranoid.) The way I imagine this working is to have, at bare minimum, two functions on flash:
How does this all sound? I have to believe someone has tried it before, but perhaps my impatience is greater than average? Waiting 10s to test a one-line change is tedious. I also don't have enough $$$ for a simulator. Ok maybe there is something free like qemu—now that I'm on startup-doesn't-have-money-for-a-few-months leave, I can stop doing critical path work and start making my embedded life better. Anyhow, there are problems that simulators don't solve so this is still a feature I want.
|
|
#
?
Jun 4, 2013 22:07
|
|
|
Victor posted:Ok, I'm sick and tired of waiting for my STM32F4xx to flash just to test a small change in code. Because this ARM chip is von Neumann, why not just load that small bit of code into SRAM—maybe even the core-coupled memory (CCM) which we aren't using at all right now. (We probably should because it has zero wait states, compared to the flash's five.) Why not link individual functions with the currently on-flash code, but locate them at a known location in the CCM? (Really, it can go anywhere in SRAM, but putting it in CCM isolates it especially well from stuff like stack overflows and so forth. Maybe not important, but sometimes I'm paranoid.) Breathe for a moment. How long does it actually take you to program the flash? What method of programming are you using?
|
|
#
?
Jun 4, 2013 22:20
|
|
|
Captain Capacitor posted:Why is everything about the Beaglebone so terribly documented, or at least terribly assumptive. It's made (and therefore presumably documented by) Texas Instruments. All their documentation is like that.
|
|
#
?
Jun 4, 2013 22:41
|
|
|
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
|
|
|
Arcsech posted:It's made (and therefore presumably documented by) Texas Instruments. I thought their StellarisWare stuff was pretty comprehensive and easy to follow, for a beginner v  vOf course that could have been a "blind squirrel" thing.
|
|
#
?
Jun 4, 2013 23:04
|
|
|
Arcsech posted:It's made (and therefore presumably documented by) Texas Instruments. If you think TI documentation is sparse you should check out ST's microcontroller docs. I had a much harder time figuring out STM32F0 versus MSP430 stuff.
|
|
#
?
Jun 4, 2013 23:12
|
|
|
JawnV6 posted:Go ahead and abandon any FPGA dreams you have then.
|
|
#
?
Jun 4, 2013 23:12
|
|
|
Otto Skorzeny posted:Breathe for a moment. How long does it actually take you to program the flash? What method of programming are you using? Furthermore, it isn't just 10s right now, it's "tell the chip to restart, flash, press reset, fire up program to run test". dfu-util can't seem to issue a reset over USB on a Mac. :-( It's just an obnoxious, small-enough-you-can't-do-anything-useful chunk of time that I'd like to eliminate. We do have a XBee onboard and the ability to hook one of its DIO lines to the reset line and I should look into that. I'm all about reducing friction in development, though. Why not make it a bit more pleasant? JawnV6 posted:Go ahead and abandon any FPGA dreams you have then. Silver Alicorn posted:If you think TI documentation is sparse you should check out ST's microcontroller docs. I had a much harder time figuring out STM32F0 versus MSP430 stuff.
|
|
#
?
Jun 4, 2013 23:14
|
|
|
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
|
|
|
Silver Alicorn posted:If you think TI documentation is sparse you should check out ST's microcontroller docs. I had a much harder time figuring out STM32F0 versus MSP430 stuff. Their MSP430 stuff is good, and I've found their general IC stuff is okay. Their DSP and ARM documentation is not as nice in my experience.
|
|
#
?
Jun 4, 2013 23:40
|
|
|
JawnV6 posted:Could you go a week without ascribing ridiculous motives to me? Christ. I'm not going to take the time to defend against these anymore. JawnV6 posted:Go ahead and abandon any FPGA dreams you have then.
|
|
#
?
Jun 4, 2013 23:46
|
|
|
Delta-Wye posted:Their MSP430 stuff is good, and I've found their general IC stuff is okay. Their DSP and ARM documentation is not as nice in my experience. Ok, maybe this is just a common theme with ARM µC documentation. I'll have to see how the STM8 documentation measures up.
|
|
#
?
Jun 4, 2013 23:49
|
|
|
I found Hitex's insider guide to the STM32 to be super invaluable when it came to learning about ST's Cortex stuff. A great companion. NXP has good ARM docs as well. I pored through their LPC1769 manual and it was really comprehensive and well written IMHO. The Hitex guide I'm referring to: http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf
|
|
#
?
Jun 4, 2013 23:53
|
|
|
Martytoof posted:The Hitex guide I'm referring to: http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf
|
|
#
?
Jun 4, 2013 23:59
|
|
|
Delta-Wye posted:Their MSP430 stuff is good, and I've found their general IC stuff is okay. Their DSP and ARM documentation is not as nice in my experience. Yeah, that's the stuff I've been working with lately. The general IC stuff varies a lot based on which IC it is. Their StellarisWare (now TivaWare) libraries are reasonably well-documented as well, at least as far as basic usage goes. The data sheet for the actual chip is pretty impenetrable though.
|
|
#
?
Jun 5, 2013 00:34
|
|
|
JawnV6 posted:Place & Route is a nondeterministic process. Analyzing the entire scope is out of the question, so probabilistic techniques like simulated annealing are used. Slight changes to input logic can cause huge re-jiggering in the backend, so single-line changes often incur the whole compilation process and seemingly trivial changes can cause the process to take huge variations. If you're freaking out over 10 seconds, I am saying that this is a domain where such concerns will cause a great amount of frustration. This has probably been a rumour for ages but I met a guy who used to work at Synopsys who was nuts; math major I think, but long story short, he worked on their synthesis tools and claims on multiple occasions his team was forced to bury work they did that sped up P&R to the point where Synopsys would be hosed as they couldn't make any more speed improvement and thus not sell upgrades. Reeks a bit of bullshit, but the guy was smart as poo poo, and I'd tend to believe it, though I bet his tale was embellished somewhat. Our current FPGA stuff takes ~8 minutes to compile on a single dual-core Westmere Xeon which isn't terrible. One of my larger designs was a good 15 minutes though 
|
|
#
?
Jun 5, 2013 04:36
|
|
|
JawnV6 posted:Place & Route is a nondeterministic process. Analyzing the entire scope is out of the question, so probabilistic techniques like simulated annealing are used. Slight changes to input logic can cause huge re-jiggering in the backend, so single-line changes often incur the whole compilation process and seemingly trivial changes can cause the process to take huge variations. If you're freaking out over 10 seconds, I am saying that this is a domain where such concerns will cause a great amount of frustration. To end on a positive note, I found that thinking in terms of FPGAs rejiggers your brain if you've spent most of your life programming microcontrollers and microprocessors. It was more of a shock to me than the imperative -> functional transition. Definitely worth long compile times for the exposure. I'm not sure I'd want to work at a job where I had to deal with these day in and day out, but I might adapt.
|
|
#
?
Jun 5, 2013 09:05
|
|
|
STM provide IAP examples (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF257903), which accept code over USART, program it into flash and run it. You could modify this to use a different way of getting the data, and making it store the binary and then run from ram wouldn't be a problem either. It might work better than the built in thing.
|
|
#
?
Jun 5, 2013 09:51
|
|
|
Captain Capacitor posted:Why is everything about the Beaglebone so terribly documented, or at least terribly assumptive. Is TI still horrible at the documentation for those things? I've been wanting to get a Beaglebone Black recently, since my original Beaglebone disappeared a long while back. I remember the documentation for the hardware being incomplete at the time, and not all of the basic drivers were done, which was cool.
|
|
#
?
Jun 5, 2013 15:30
|
|
|
Slanderer posted:Is TI still horrible at the documentation for those things? I've been wanting to get a Beaglebone Black recently, since my original Beaglebone disappeared a long while back. I remember the documentation for the hardware being incomplete at the time, and not all of the basic drivers were done, which was cool. It's mostly my noobness with all things embedded. It's all based on Angstrom/OpenEmbedded, which is decently documented. It's just for a newbie it's a bit confusing to get up and running. I've got the Black and I'm enjoying it so far, for what I've been able to make it do so far.
|
|
#
?
Jun 5, 2013 16:44
|
|
|
Slanderer posted:Is TI still horrible at the documentation for those things? I've been wanting to get a Beaglebone Black recently, since my original Beaglebone disappeared a long while back. I remember the documentation for the hardware being incomplete at the time, and not all of the basic drivers were done, which was cool. I would say the actual documentation is decent, I always found the organization lacking. Maybe I'm weird but my favourite documentation is Microchip's, maybe because I used them first for everything. Also Jawn/Victor no need to derail into a flame/snark war please.
|
|
#
?
Jun 5, 2013 17:37
|
|
|
Victor posted:Out of curiosity, how careful of a person are you in general? For example, would you trust yourself with a shiny new iPhone such that you wouldn't put a screen protector on it even though you hate scratches? :-) If I thought the thing was super delicate I'd protect it. I've never had that kind of a problem with an AVR dragon. I might be the weird one, and I certainly don't think it's unreasonable to put the thing in a case, I've just never had to, but I'm also never programming chips powered by the dragon itself.
|
|
#
?
Jun 5, 2013 19:35
|
|
|
I think that's part of what people's problems with it are. Something about USB ports not providing enough current, plus an additional current draw of the target micro makes components on the dragon implode. Which I guess isn't a problem if you have a good USB port that provides the right amount of current and aren't powering the device under test.
|
|
#
?
Jun 5, 2013 20:41
|
|
|
The first-gen dragons were a bit combustible; touching one of the switch-mode regulators could cause it to overshoot and burn itself out. I believe the newer revisions (ones made in the last few years) are much more robust, although you should still take good ESD precautions as they are bare-PCBs.
|
|
#
?
Jun 5, 2013 20:46
|
|
|
Yup. I threw mine in an alum. projectbox and I'm just trying to figure out how to route the headers outside for ease of connecting. I should just make two cables and run those but I like being modular more than I like simplicity I guess.
|
|
#
?
Jun 5, 2013 20:51
|
|
|
I was looking at playing around with the ARM Cortex family of microcontrollers, but I'm not sure of what tool chain and programmer to use. I already have several evaluation boards, but I need to be able to implement the chip on my own PCB and program it via JTAG/SW. Does anyone have any advice on where to get started?
|
|
#
?
Jun 9, 2013 18:41
|
|
|
Krenzo posted:I was looking at playing around with the ARM Cortex family of microcontrollers, but I'm not sure of what tool chain and programmer to use. I already have several evaluation boards, but I need to be able to implement the chip on my own PCB and program it via JTAG/SW. Does anyone have any advice on where to get started? You can use a lot of eval boards to program your own off-board chips via JTAG/SWD as long as they're the same manufacturer (and sometimes even not). What's your budget? If you rule out the free offerings, you can buy Rowley CrossWorks for ARM for fairly cheap as long as you're using it for personal stuff. Then you move up to the more expensive and traditional IDEs like IAR and such. The free ones are typically limited somehow, but they should let you program the same manufacturer's ARM chips off-board: Code Composer Studio for TI's chips, LPCXpresso for NXP's chips, Atmel Studio for Atmel's chips. I forgot what, if anything, ST provides. Unfortunately there's not really a go-to "ARM development for beginners" manual anywhere. You have to piece it together. If you're new to embedded programming altogether then a lot of AVR or other 8-bit tutorials will be helpful. Unfortunately a lot of the other stuff you will have to figure out yourself by reading the docs. If you stick to a specific manufacturer and use their libraries then you'll probably have a lot easier time than if you just try to learn generic ARM development. StellarisWare, for example, seems to be really comprehensive and has a lot of good tutorials on TI's site IMHO.
|
|
#
?
Jun 9, 2013 18:52
|
|
|
I should have said I'm not new to embedded programming. I've been using Atmel microcontrollers up until now with Atmel Studio and programming them with a JTAG cable. I've played around with TI's Code Composer Studio with their Stellaris Cortex-M4 eval board but have not read anything about their ability to program external chips. I just now found that NXP's LPCXpresso can be used to program their own chips which is pretty much what I was looking for. I read that ST has their own programmer device, but the software support for it seems to be deficient. I will probably just go the LPCXpresso route.
|
|
#
?
Jun 9, 2013 19:11
|
|
|
Krenzo posted:I should have said I'm not new to embedded programming. I've been using Atmel microcontrollers up until now with Atmel Studio and programming them with a JTAG cable. I've played around with TI's Code Composer Studio with their Stellaris Cortex-M4 eval board but have not read anything about their ability to program external chips. I just now found that NXP's LPCXpresso can be used to program their own chips which is pretty much what I was looking for. I read that ST has their own programmer device, but the software support for it seems to be deficient. I will probably just go the LPCXpresso route. If it is your first start into microcontrollers, I'd almost suggest against an ARM, to be honest. It's kind of become a recent view of mine, after some talks/discussions with some guys from Freescale, NXP, etc. It stems from the fact that while eval boards might be usable, there's a lot of gotchas / things to be careful of when transplanting it to a PCB of your own design (which is something attainable for hobbyists, EAGLE + OSH Park) because the clocks / edge rates can be quick enough that haphazard (hobbyist) PCB design doesn't cut it. Poor power delivery, bad grounding / coupling can manifest in random instabilities / performance issues that would frustrate the hell out of a guy who just wanted his own board. While some of the families have decent toolchains and cheap eval boards, the chips themselves are fairly complex and not everyone has good sets of libraries that effectively abstract / wrap that functionality. Multiple clock domains (not unique to ARM I guess, even baby PICs/AVRs have them), many different power states, existence of a boot ROM, complex interrupt controllers etc require a bunch of reading/research in the datasheet. If you can get away with it, using a simpler 8-bit/16-bit micro (tinyAVR, PIC, MSP430, etc) I think you will learn more and the amount of material to understand in terms of architecture and peripherals is more manageable. They are also fairly forgiving when it comes to PCB layout, so it should be an easier time translating said design to a PCB of your design.
|
|
#
?
Jun 9, 2013 19:24
|
|
|
You can use the ST-Link with this: https://github.com/texane/stlink and just use gdb. Also, the Discovery boards from ST actually have an ST-Link on them, so if you get those to start out with you don't actually need a programmer.
|
|
#
?
Jun 9, 2013 19:26
|
|
|
movax posted:If it is your first start into microcontrollers It's not. I said I have been using Atmel microcontrollers. movax posted:If you can get away with it, using a simpler 8-bit/16-bit micro (tinyAVR, PIC, MSP430, etc) I have been and want to move up to something more powerful. evensevenone posted:You can use the ST-Link with this: https://github.com/texane/stlink and just use gdb. I didn't know that. I have a Discovery board that I haven't touched yet, so that would be useful.
|
|
#
?
Jun 9, 2013 19:42
|
|
|
I've been using the Linaro Bare-Metal GCC package for playing around with Cortex M0/M3/M4 lately. http://www.linaro.org/downloads/ (Bottom of the page). The compiler works well out of the box, and support M4F floating-point units, but it isn't a complete toolchain. Libraries and linker scripts aren't always easy to find, and might not work out of the box anyway. Stellaris and STM chips haven't been too difficult to get up and running.
|
|
#
?
Jun 9, 2013 20:04
|
|
|
movax posted:If it is your first start into microcontrollers, I'd almost suggest against an ARM, to be honest. Before I knew better I tried to make an STM32 board using a breakout board, protoboard, and random wire that I had available. It had an usd reader, 320*240 color display and touch input. I didn't even bother with any decoupling caps. Somehow it worked perfectly. https://www.youtube.com/watch?v=plgntYl4coU I currently use my own STM32 PCB, st-link and eclipse. I started with with a STM32 development board and atollic truestudio. I found using a devboard and commercial IDE a nice easy way to get started with ARM. Once you are comfortable with them you can swap out the board and IDE with what you want. Like I mentioned above the STM32 chips seem quite tolerant of poor PCB design and are quite robust, which might make them a good ARM chip to try. I haven't tried any of the other ARM chips so I can't offer a proper comparison.
|
|
#
?
Jun 9, 2013 20:32
|
|
|
Krenzo posted:I've played around with TI's Code Composer Studio with their Stellaris Cortex-M4 eval board but have not read anything about their ability to program external chips. I recently used the TI Stellaris M4F on a custom PCB, and the Launchpad can definitely be used to program it. I'm on my phone right now but I can post a sort of how to later if you or someone else is interested.
|
|
#
?
Jun 9, 2013 23:16
|
|
|
Victor posted:I'd rather you not mischaracterize me, either; I wasn't 'freaking out'. What annoys me is when I know something can be done better—including faster—and isn't. If I know there currently exist no better solutions and I can't think of how I would implement better solutions, I'm not going to complain. Hey, maybe you saw this already (or are the one behind it  ) but this just popped up on the libopencm3 mailing list: http://libopencm3.org/wiki/Run_From_RAMSo actually, it looks like it's 100% possible.
|
|
#
?
Jun 11, 2013 04:17
|
|
|
Heh, I didn't do that. I know about that particular feature; it allows you to just put everything in SRAM. What I'm planning to do is put an attribute on a single function, or at least a subset of the code, and put just those bits in the core-coupled SRAM. I think that's actually the general intention—put only some of your code in the CCM, which has no DMA access. Then you can have 0-wait-state code. It's only 64KB on the STM32F4xx, compared to the 1MB of flash. I'm pretty sure what I want to do is possible; the question is how hackish would I have to make it. Theoretically, if I always locate the 'entry' function in CCM at the same place, I can simply use arm-none-eabi-objcopy to pull out a specific code section. I already do that for the AQ32Plus project, as they use the second 16KB flash sector to simulate an EEPROM, meaning that I have to flash the ISR section and main code section separately. At some point I'll figure out how to make dfuse files.
|
|
#
?
Jun 11, 2013 05:50
|
|
|
|
| # ? May 9, 2024 23:58 |
|
|
Martytoof posted:Hey Dragon users. Mine finally arrived and it is basically pretty awesome. Do you guys use the board itself to power your target or do you typically run external power to your target and just rely on the dragon to run ISP/debugWire? I read that the voltage regulators on the Dragon are fragile as a teenager's self esteem, and people are recommending using them via a powered USB hub instead of a direct connection to a computer's USB port. Is this a real thing I should be worried about? We've been using one in my lab and it's been getting man-handled by undergrads for a year and is still working, so, apparently we got lucky with a slightly more durable one.
|
|
#
?
Jun 15, 2013 00:47
|
|