Back
[09:05:29] <bss36504> Anybody know a way to get small quantities of EDBGs that isn't alibaba? I'd only ever want to buy 50-100 at a time, if that
[14:05:31] <bss36504> Ok, let me try a different question: anybody know of an embeddable debugger that I can easily bake into a custom board? Doesnt have to be atmel. I've been tinkering with Qualcom/NXP/Phillips/Freescale/Motorola dev boards that have an OpenSDA debugger on board. Is that an ARM thing or a Freescale thing? How hard is it to "instantiate" one in a desi
[14:05:31] <bss36504> gn?
[14:07:05] <cehteh> gn?
[14:07:18] <LeoNerd> wrapped message
[14:07:21] <LeoNerd> "design?"
[14:07:27] <cehteh> ah :D
[14:07:52] <bss36504> LeoNerd: What now?
[14:08:05] <LeoNerd> I have no idea. I was just clarifying the formatting of your question
[14:08:08] <cehteh> what do you mean by debugger?
[14:08:18] <cehteh> there are different ways of debugging a program
[14:09:04] <bss36504> I asked earlier about buying an Atmel EDBG chip, like in the Atmel ICE or Arduino Zero. I want to make a dev board that has true debugger support built in
[14:09:05] <cehteh> instruction stepping, breakpoints etc often need hardware support
[14:09:14] <bss36504> Yes, thats what I mean
[14:09:46] <cehteh> smaller avrs have debugwire, bigger ones have jtag
[14:10:24] <bss36504> No, cehteh, I understand how AVRs are debugged. I want to make a "debuggable" board of my own with the debugger embedded into the design
[14:10:28] <LeoNerd> Some have both
[14:10:29] <bss36504> Like all the xPlain boards have
[14:10:37] <LeoNerd> Infact Idont' think I've seen an AVR chip without dW
[14:10:43] <cehteh> what does that have to do with the board?
[14:10:44] <LeoNerd> Even the huge ones with JTAG also have dW
[14:10:45] <bss36504> Right, the target right now is irrelevant
[14:11:03] <bss36504> has dW been emulated/cracked?
[14:11:16] <cehteh> except that you need to route the debug pins out somehow and being compatible as in not using this pins for other purposes
[14:11:22] <LeoNerd> bss36504: It's partly known in public
[14:11:32] <LeoNerd> me/RikusW have been playing with it
[14:11:43] <LeoNerd> I keep meaning to get around to playing with it more
[14:11:45] <cehteh> i never cared for debugging on that low level, never needed that
[14:11:49] <bss36504> cehteh: I don't really care about the loss of pins. This would be for a dev platform
[14:11:50] <LeoNerd> It's quite far down the depstack
[14:12:02] <LeoNerd> Also, yah.. usually Ihave better debug setup
[14:12:35] <cehteh> isntrumentate your program somehow, unit/function tests
[14:13:05] <cehteh> gives far better results for fixing real problems than low level debugging
[14:13:05] <bss36504> I mean, I have an AtmelICE. But I'd like to make a small dev platform for teaching a class with a true, embedded debugger in it. The ICE is more expense than I'd like to impose if possible
[14:13:32] <LeoNerd> My "embedded debugger" is usually printf to the UART
[14:13:38] <LeoNerd> or some LEDs on spare GPIO lines
[14:13:49] <cehteh> leds and logic analyzer yes
[14:13:49] <bss36504> Well I'm trying to be at least a step above an arduino.
[14:13:57] <bss36504> Humor me, guys :P
[14:14:05] <cehteh> above?
[14:14:14] <bss36504> in terms of debugging capability
[14:14:14] <cehteh> sounds more like below :D
[14:14:26] <bss36504> anyone can printf over uart, I /like/ single stepping
[14:14:38] <cehteh> for what?
[14:15:11] <LeoNerd> single-stepping sounds rediculously tedious for embedded
[14:15:26] <cehteh> i mean in most cases you program in C .. you dont even know which assembler instructions where generated and why for some C code unless you carefully inspect that
[14:15:44] <bss36504> You can single step/set breakpoints at the C level...
[14:15:51] <cehteh> yes and singlestepping wont help you fixing realtime stuff and timing problems
[14:15:58] <LeoNerd> Which is usually what mine are :)
[14:16:03] <bss36504> Right I'm aware
[14:16:56] <cehteh> when i have to debug a complciated algorithem i write it in portable C and make it work on linux, with all lore of tests, printfs, valgrind, debuggers etc
[14:17:28] <bss36504> Sure, like I said, there are benefits to both. I personally find a true debugger to be invaluable. I can also get by just fine with uart. But this is for students who arent as experienced as we are, and sometimes, they need that close look at something in particular.
[14:17:30] <cehteh> thats waaay easier than debugging on the embedded thing
[14:17:34] <bss36504> So just humor me please, is there an easy way to embed a Hardware debugger?
[14:17:36] <LeoNerd> The point I'm trying to make is that I do a lot of AVR development. I do technically have the ability to do things like single step debugging on the chip and I just /don't/.
[14:17:49] <LeoNerd> I genuinely don't find it that useful as compared "just shove a printf in there"
[14:17:54] <LeoNerd> or make an LED flash. or whatever
[14:18:26] <cehteh> printf could be argueable as it generates interrupts and timing issues, but toggle a led is cheap enouh
[14:19:26] <cehteh> also years ago i've written a debugging libray for C on linux, some ideas might be ported to embedded platforms, but it is intrusive so beware of space it needs
[14:19:31] <cehteh> http://nobug.pipapo.org/
[14:19:44] <cehteh> basically assert() on steorids
[14:20:26] <bss36504> Alright well nevermind then I guess. I'll just give them a serial bootloader and we'll use FLIP/avrdude and not have debugging.
[14:20:56] <cehteh> btw afaik the arvs dont have special debugging support in the cpu core, debug wire and jtag can inspect some things, but for breakpoints the flash is programmed on the fly
[14:20:58] <bss36504> I expected more from this channel, really. It's not like this is one of those bullshit artificial design problems like the dude that wanted 16 cycle-accurate PWMs on his 328
[14:21:17] <LeoNerd> Oh breakpoints reflash it?
[14:21:23] <cehteh> iirc
[14:21:26] <LeoNerd> Heh.. then I won't feel so bad about my printf'ing :)
[14:21:31] <cehteh> there is no breakpoint register
[14:21:37] <cehteh> yeah
[14:22:18] <cehteh> bss36504: i just dont get your point and as saied before you need some hardware support which isnt very featureful and not open on avrs
[14:22:47] <cehteh> otherwise for a development board wont be much more needed than routing the debug ports out
[14:23:57] <cehteh> i once was thinking about adding a isr (int0 or pc) going into a debugging mode which halts the system bitbangs infos and lets one inspect registers and memory etc
[14:24:19] <cehteh> *but* i turned that idea mostly down because it would be way to bloaty and have too little benefit
[14:24:21] <bss36504> My "point" is that I want it. I'm not concerned about the physical connection, I'm more interested in aquiring Atmel PN:AT32UC3A4256HHB-C1UR or something similar in single quantities, which is what is used in the AtmelICE as the host processor.
[14:24:43] <bss36504> cehteh: THATS WHAT A DEBUGGER DOES.
[14:25:43] <bss36504> Like, i realize if I can aquire a AT32UC3A4256HHB-C1UR I can make it work with a slave processor (the debugging target) cause the schematics are available on how to connect it. But guess what, you cant buy it in qtys less than 4K.
[14:25:50] <cehteh> yesm but with debugwire closed, i thought about some open source alternative
[14:26:05] <LeoNerd> Eh...
[14:26:08] <LeoNerd> we have partial support ;)
[14:26:12] <LeoNerd> I'll write something up properly oneday
[14:26:17] <bss36504> right, well then I guess the answer to my question is "no, there does not exist a solution for embedded debug support"
[14:26:23] <LeoNerd> The tricky part is relying on any suitable hardware to connect from the PC to the chip
[14:26:33] <LeoNerd> We need an opencollector shared bus UART with a custom frequency
[14:26:36] <cehteh> LeoNerd: that makes a software solution even less interesting
[14:26:41] <LeoNerd> This suggests: another AVR
[14:26:57] <cehteh> yes
[14:27:06] <bss36504> LeoNerd: Why not just follow Atmel's lead and architect a debugger after theirs?
[14:27:32] <bss36504> All the ICE programmers used an AVR32 as far as I know
[14:27:41] <LeoNerd> Ya, probably
[14:27:45] <bss36504> even the ISP mkII
[14:27:53] <bss36504> though, that didnt support dW
[14:28:03] <bss36504> as an aside, I fking hate dW
[14:28:26] <LeoNerd> It's... interesting ;)
[14:28:38] <bss36504> "lets disable ISP in order to debug. Oh what's that, something went wrong and ISP is disabled and so is dW, guess you're out of luck!"
[14:28:41] <LeoNerd> opencollector UART bus == nice.
[14:28:51] <LeoNerd> UART clocked at a power-of-2 division of fCPU == less nice
[14:29:18] <bss36504> Well with a AVR32 running at a higher frequency, I imagine you could bit bang it pretty easily
[14:29:19] <LeoNerd> There's a dW command to switch on ISP again
[14:29:32] <bss36504> Yeah, but I've literally had my processors get stuck in between
[14:29:48] <bss36504> Maybe it was atmel studio's fault, maybe it was the Dragon's fault
[14:29:50] <LeoNerd> Most ISP hardware can't send it because it requires bitbanging the RESET# line quickly enough
[14:29:51] <bss36504> either way, I was pissed
[14:31:02] <bss36504> At this point I'll probably just go with a NXP/Freescale openSDA implementation. The students can continue to use the IDE they are used to, and I'll get a chance to learn some new stuff.
[14:31:58] <bss36504> Just sucks that all the dev boards I've found are bloated out to be arduino shield compatible. I want something like two postage stamps with castellated pads (or headers, idk) that can be embedded into something else as a complete system
[14:32:04] <cehteh> bss36504: if you want it for teaching, have you considered to use a avr simulator instead? these have debug ports and you can inspect whats going one on a sub-instruction level
[14:32:21] <bss36504> Well, we would be building hardware to use this dev platform as part of the class
[14:32:30] <cehteh> with less pita than real hardware in this case
[14:32:35] <bss36504> true
[14:32:56] <bss36504> The emphasis of the course isnt really even on microcontrollers, hence why I'm trying to find ways to make it as painless as possible
[14:33:15] <cehteh> whats the course about?
[14:33:24] <bss36504> the focus is really more on the "system" as a whole; power supply, controller, IO
[14:33:36] <bss36504> It's a course I'm developing
[14:34:38] <bss36504> Systems Engineering. Essentially a guided project class. I lay out a set of end requirements for the students, then week by week we learn about different sub systems (in a general sense), and the students deliver to me their designs for that block.
[14:34:39] <cehteh> external hardware is notoriously hard to debug, esp on realtime/microcontrollers, for example if you drive a 3 phase motor with 3 pwm lines you cant just single step
[14:35:14] <bss36504> half way through the semester we get hardware built and we spend the rest of the time making it work and working on a test methodology, as you would in a real world situation
[14:36:03] <bss36504> right, I thought of that. you wouldnt be single stepping for something like that. Like I said, I "want" a debugger, it's not a showstopper without it.
[14:36:47] <bss36504> The goal would be that while they are waiting for boards to come back from fab, they could tinker with the MCU dev board and make it do shit and debug and really get a feel for it before they write the code for the final product.
[14:37:03] <bss36504> Again though, we could certainly make due with uart/printf
[14:37:10] <cehteh> i am tihnking about testsuites who talk about uart and flashed onto real hardware, of course running such a testsuite would wear the flash, but with that you can have some confidence that things really work on the real part
[14:38:16] <bss36504> It's interesting that you mention a 3phase motor driver, that was actually one I was contemplating as the "guided project"
[14:39:05] <bss36504> It's good cause it encompasses analog+sensors+control algorithms but still isnt sooooo complex to set up
[14:39:41] <cehteh> oh there is a lot complex stuff with motor drivers even if the theory is not too complex
[14:40:28] <bss36504> Well the idea would be some stuff would be given, some stuff would be self discovered. Obviously I'd have to assemble a curriculum around this first and flesh out the gotchas. Im not married to the motor driver idea either, though
[14:41:59] <cehteh> heh make the implementation of a test/debugging setup the course :D
[14:43:17] <bss36504> lol I probably could
[14:44:27] <bss36504> The thing is, I've found it's hard to engage students sometimes. It's easy for us now to be excited about learning things, but obviously we all like this stuff and are ready to learn. When youre in school though, it's easy to think it's a chore.
[14:44:28] <bss36504> I want my students to be interested but also successful, so that they have something to show at the end
[14:45:41] <bss36504> So maybe a motor controller isnt the right project, but maybe I can make it work. I'd be helping them throughout by checking the designs ahead of time to try and minimize issues, so that hopefully the debugging phase is mostly painless and any problems are fixable.
[16:28:29] <lochs> h-bridge driver cause there's nothing like the smell of cooked fets in the morning
[17:25:00] <LeoNerd> http://paste.debian.net/891535/ <== this is basically what weak symbols are for, right?
[17:25:20] <LeoNerd> Defining little hook points in libraries (e.g. sched.c) that programs (my main.c) could override if they wanted to
[17:26:10] <specing> bss36504: could make something that doesen't yet exist in open hardware form and then publish the design
[17:26:32] <specing> I haven't found any open hardware vfd boards in kilowatt+ range