Back
[10:42:53] <wondiws> I'm using the AVRA assembler for a bootloader, is it possible to set the memory offset?
[10:44:55] <Thrashbarg> the location the code is assembled to?
[10:45:01] <wondiws> yeah
[10:45:03] <Thrashbarg> org
[10:45:26] <Thrashbarg> meaning origin. It's an assembler pseudo-op
[10:46:52] <wondiws> yes tnx, it works
[10:46:59] <Thrashbarg> good
[10:54:05] <jhn> When flashing a 3V3 operated AVR, what must I take care of when I am using a USB powered 5V flasher?
[11:10:26] <Tom_itx> uh huh
[11:10:55] <Tom_itx> mine has a buffer to allow for programming down to 1.75v or so
[11:11:29] <Tom_itx> especially for the xmegas
[11:12:17] <Tom_itx> more than likely if it's a regular 8bit avr and nothing on the board will blow if you give it 5v you will be ok
[11:12:42] <Tom_itx> if you have other chips on the board that are 3v only you may be in trouble
[11:18:27] <jhn> Affirmative other 3V3 chips present. Is there any recommended approach to that?
[11:21:12] <Tom_itx> program it a 3.3v
[11:21:22] <Tom_itx> at*
[11:21:37] <jhn> Never seen USB run at 3V3… :-)
[11:21:48] <Tom_itx> mine does
[11:21:54] <Tom_itx> the USB side is 5v
[11:22:02] <Tom_itx> the programmer side varies
[11:22:52] <Tom_itx> it probably would have worked lower than 1.75v but i could hardly see the led blink at that point so i called it good
[11:23:04] <jhn> Looking for a solution that self-adapts to the target voltage - kind of idiot-proof (the idiot beeing me forgetting to switch prog voltage and thus frying a valuable system)
[11:23:23] <Tom_itx> avrisp mkii probably does
[11:23:34] <Tom_itx> mine does.. it's an avrisp mkii clone
[11:23:53] <Tom_itx> just don't forget...
[11:23:54] <Tom_itx> :)
[11:54:55] <N1njaneer> jhn: The new ATMEL ICE will do that, and is replacing the ISP MKII right now.
[11:55:35] <Tom_itx> costs quite a bit more too doesn't it?
[11:56:19] <N1njaneer> $35 USD for doing ISP, SingleWire, JTAG, and full JTAG for all ARM devices. Not bad :)
[11:56:45] <Tom_itx> for jtag ice ii?
[11:56:52] <jhn> Ok, merci. I was looking how to retrofit a given programmer, as it does what it must.
[11:56:52] <N1njaneer> $35 for the raw PCB, $54 for the enclosure, $93 for both plus full cables.
[11:57:27] <N1njaneer> Tom_itx: Correct. Atmel merged support for all of their programmers in to a single programmer, lowered the cost significantly, and is EOL'ing the others.
[11:58:00] <N1njaneer> The fact that the single box now does what would have cost you several hundreds dollars for three seperate boxes a couple years ago is great :)
[11:58:05] <jhn> Fair enough - and wise from an inventory/support point of view.
[11:58:07] <Tom_itx> when did they do that?
[11:58:19] <N1njaneer> Plus that it will target AVR and SAM parts - no more SAM ICE Segger rebrands.
[11:58:40] <Tom_itx> no more avrone?
[11:59:12] <N1njaneer> Tom_itx: It was a roll-out in the last month or two. I got the notice from our suppliers the ISP-MKII was being EoL'd, so I asked our Atmel FAE about it and he'd sent me two of the new ATMEL-ICE's
[11:59:29] <N1njaneer> Part number is "ATATMEL-ICE" if you want to search for it. DigiKey has all three variations in stock.
[11:59:38] <jhn> Ah, so you spare one! Here is my addresss....
[12:00:12] <N1njaneer> Tom_itx: Not sure if they are discontinuing that one, but the MKII is quite old. This new one replaces the JTAGICE3 as well - LESS expensive and does way more :)
[12:00:57] <Tom_itx> maybe they're finally catching on...
[12:01:44] <jhn> How does it identify on your host? Regular serial connection via FTDI or SL chip?
[12:02:12] <Tom_itx> mine idents as an avrisp MKII
[12:03:26] <N1njaneer> jhn: It's all USB.
[12:03:49] <N1njaneer> Works with Atmel Studio and their command line utilities.
[12:04:32] <jhn> Totally. But some USB requires strange drivers - I am neither Windos nor Linux.
[12:06:31] <N1njaneer> Not sure what to say. I would imagine support should filter out (or just run a USB packet analyzer) for helping people to write custom drivers, but that's really not Atmel's focus. Their focus is on delivering an entire development toolchain which is easy to use and costs less than $100 in order to develop on the AVR and SAM series of parts.
[12:09:04] <Tom_itx> jhn, check out crosspak for osx
[12:09:10] <Tom_itx> avrdude
[12:09:32] <Tom_itx> http://www.obdev.at/products/crosspack/download.html
[12:11:47] <jhn> I have the toolchain up and running. If the new ICE identifies as serial device I am a happy camper.
[12:12:09] <Tom_itx> likely USB
[12:13:42] <N1njaneer> I don't believe it will. Serial on USB is kind of a hacked legacy item these days and makes developing and programming stuff over USB a major pain in the ass for the programmer, so unless there's a compelling reason to do it (or the application is rolled in to legacy support, or the developer is lazy or using a microcontroller that has no USB support) then generally they are either HID devices,
[12:13:42] <N1njaneer> or devices that require drivers loaded.
[12:14:38] <N1njaneer> FTDI/serial devices are annoying to me, since when you have multiple connected they then go to a randomly assigned COM port which you then STILL have to associate to the software. :(
[12:15:06] <myself> they only assign a random port if you've got a cheap one without an eeprom serial number
[12:15:17] <myself> genuine FTDIs have serials and the port number follows the hardware
[12:15:29] <N1njaneer> This is why I do all of our USB devices typically as HID's where possible -- no drivers necessary, but you still get a unique VID/PID assigned to each so the software can individually identify and bond to the devices it needs to connect to.
[12:16:01] <N1njaneer> myself: Yes, but it still puts the COM port in the middle unnecessarily, that you then need to tell the software which one to use.
[12:16:05] <jhn> I 1000% agree to all your reasoning. (Still mine always gets the same number as long as I plug in tio the same port.)
[12:16:15] <myself> Sure, I agree.
[12:16:29] <N1njaneer> jhn: Oh yes, those numbers stay the same. But you still have to figure out which COM device is which.
[12:17:13] <N1njaneer> We needed to put Arduino(!) bootloaders on stuff for a client. My COM ports were climbing in to the upper COM20's by the time I was done loading them all :)
[12:18:08] <Tom_itx> i'm sorry for you :(
[12:18:24] <Tom_itx> having to deal with ardweenie n all...
[12:19:02] <N1njaneer> Thankfully I have gotten them to move away from Arduino, but they pay exceptionally well so who am I to argue what bootloader they want loaded? I don't have to deal with any of the software, either, just make sure the bootloaders talk and the hardware board excercises all functionality.
[12:19:05] <jhn> As you said USB requires a driver - that is the REAL problem: Multiple platforms - multiple drivers! Going to use my old programmer until we get eth connected programmers. That will do away with all the woes of driver development.
[12:19:43] <N1njaneer> jhn: Unless the USB implementation is as HID or implemented as a generic class driver - then no OS-specific drivers required.
[12:20:16] <jhn> Send me your spare one and I will be your happy tester… :-)
[12:21:06] <N1njaneer> All in use, sorry!
[12:21:23] <jhn> I never understood the hype about USB apart for keyboard/mice/camera/sticks.
[12:21:54] <Tom_itx> i got a usb DVD burner the other day
[12:21:56] <N1njaneer> Because it replaces all other forms of casual peripheral interconnect with a standard.
[12:22:00] <jhn> But well, who am I to rule the world, plenty of times an inferior design won the market. Rember VHS?
[12:22:19] <N1njaneer> Thank god 1394 Firewire is finally nearly dead.
[12:22:21] <Tom_itx> once everyone buys new hardware for USB they'll switch to something else
[12:22:29] <Tom_itx> yeah i got one of those too
[12:22:49] <N1njaneer> USB is not going away any time soon
[12:22:54] <N1njaneer> FAR too much money in it
[12:22:56] <Tom_itx> USB6 FTW
[12:22:58] <myself> I don't understand the "no driver" thing when I still need software to talk to it somehow. Yeah, I'm not popping a dialog box to install a system-level driver, but still, when I connect my HID-profile weather station, I can't just open notepad and have it type in weather data, or open minicom and get the data or something. I've still got to have specific stuff to talk to it, isn't that a driver?
[12:23:19] <N1njaneer> myself: That isn't a driver, that's the application.
[12:23:27] <N1njaneer> myself: Strictly speaking.
[12:23:30] <myself> I mean, to me, HID means it should appear as a keyboard or mouse, shouldn't it? Where's my disconnect?
[12:23:34] <Casper> jhn: oh it's easy... before USB, the only 2 ways to connect an high speed device was to open the computer case to insert a card, which is far from being user friendly. The other way was firewire. Firewire is a daisy chain bus, meaning it go from one device to the other to the other... want to remove the first device? need to disconnect all, remove the first, connect the second back....
[12:24:30] <Casper> jhn: usb fixed both issues: no need to open the case, so anybody can connect the stuff safelly. And no need for that stupid chain, so you don't have to disconnect anything else...
[12:24:37] <N1njaneer> myself: HID is a generic driver class, just like mass storage devices (hard drives, flash drives, etC) but there are still sub-layer drivers that operate inside of that. So HID contains generic implementations for things like keyboards, mice, etc. that the OS already has implemented drivers for.
[12:25:18] <Casper> sadly... they somewhat fucked up with usb by using 5V 500mA and a too slow bus speed initially...
[12:25:33] <N1njaneer> Casper: Not to mention higher speeds and running out of ISA/PCI/PCIe slots in your case, plus the nightmare of compatibility testing and making sure the shared bus doesn't completely halt the PC when something goes wrong.
[12:25:55] <N1njaneer> Casper: Gotta start somewhere! But that was ages ago. :)
[12:26:14] <Casper> with usb3.1 I'm very worried... they made it so the device can request 5, 12 or 19V....
[12:26:17] <N1njaneer> The genius in execution was that USB1.0 devices will still work fine in USB3.0 bus ports :)
[12:26:25] <myself> But I mean, if I plug in a mass-storage device, it'll appear as a drive letter, period. I don't need special software for certain mass-storage devices. But if I plug in a HID device, not all of 'em just fire data in as keystrokes or mouse moves, right? What's happening there, where's that data go? Why's it called HID when it's not the same as other HID devices? I'm sorry I know this must sound like an incredibly stupid line of questioning but ...
[12:26:31] <myself> ... something just doesn't work at all in my understanding.
[12:26:48] <jhn> Yes, I agree there are upsides to USB. Downside: It is only as ubiquitous as drivers are available.
[12:27:09] <N1njaneer> myself: "HID" is a generic class name. A HID device still needs to be a keyboard, or a mouse, or a something.
[12:27:27] <myself> N1njaneer: So the majority of my HID devices are, in fact, "somethings"?
[12:27:43] <Casper> N1njaneer: yes, but why didn't they listened to all of those that said that the 5V 500mA was far from being enought? and cited external hard drive as an example? they suggested 12V 1A since mostly all devices would use a smps reg anyway
[12:27:46] <myself> And the OS doesn't have a default way of processing input for somethings, like it does for keyboards and mice
[12:28:18] <N1njaneer> HID simply means that a higher-level driver can be loaded by the OS inherently. So if you plug in a device that is a HID keyboard, it is identified as such and then since the OS knows how to talk to a HID Keyboard, it generally then pipes the input straight to wherever the OS desires keyboard input to go. Same with a mouse.
[12:28:42] <myself> So when I write software that opens a HID something, my software is not a driver?
[12:29:11] <Tom_itx> no it's a layer above that
[12:29:18] <Casper> the driver is the "hid driver"
[12:29:21] <N1njaneer> myself: Yes, that is the point of generic class drivers, and why you can plug in any of a zillion different kinds of USB memory sticks or hard drives from different manufacturers, and the OS can set it up and talk to it appropriately without "please insert driver disk" before you can use it.
[12:29:28] <Casper> if you talk to the hid, then you talk to the driver
[12:30:41] <N1njaneer> myself: If you make a HID device, but it does not use a sub-class type like a keyboard or mouse or such, the OS will load only the generic HID device class driver in order to talk to it, but then the responsibility of opening the specific device and talking to it is up to you. But in this case YOU (the application) are talking to the OS's HID-class driver, and that driver does all the low-level
[12:30:42] <N1njaneer> stuff to communicate with the endpoints of your device.
[12:31:29] <N1njaneer> So your software application is "kind of" a driver in a way, but it is not a "driver" in the strictest since of the definition since "driver" generally refers to a chunk of code that works in deeper parts of the OS.
[12:32:24] <N1njaneer> If you make a device that IS NOT implemented as a generic class driver, the OS will complain that it can't find a driver match, and then no application software will ever be able to communicate with it because the middle bit in the OS (the "OS driver" for your device) is not preset.
[12:33:46] <N1njaneer> It's a bit complicated, but most of the complication generally comes from understanding the teminology and the model. I promise that it's actually pretty simple stuff, but it *sounds* way more complicated if you're not familar with the terms.
[12:33:49] <jhn> Huh, I started something here.
[12:34:15] <myself> but I can't write my shit to simply talk directly to the device, because I can't sign my own drivers or something, so I have to have a driver do it for me? I mean, in DOS, I could open COM1 and use the OS's serial port driver, or I could manually twiddle the UART chip's bits using I/O instructions, but that manual twiddling isn't allowed anymore, so I have to have something to do the lowlevel thing for me..
[12:36:25] <N1njaneer> myself: You CAN do that by using generic class drivers. You can also write drivers just fine without having to sign them. The purposes of all of that are several-fold, but some of it has to do with more modern security rights management. When you have a billion devices out there now and OS's which are miles of complex machinery behind the scenes, everything and everyone will not always be "good"
[12:36:25] <N1njaneer> -- without management of those mechanisms stuff can go off the rails really quick - either by people with malware intentions, or simply people who know enough how to write a driver, but not write a GOOD driver.
[12:36:59] <myself> I guess what I don't understand is, back in the DOS days, I could plug a serial mouse into the port, and load a mouse driver, or I could plug a serial something into the port, and just open COM1 to talk to it. But with HID, if I plug in a USB HID something, I can't just open procomm to talk to it. There is no generic USB HID "terminal program" that I can bash bits to talk to it.
[12:37:44] <N1njaneer> Part of the point of driver signing (at least on Windows) is forcing driver code to go through actual 3rd party testing to validate that it is correct and, more importantly, that it WILL NOT intefere with other OS functions by virtue of being written incorrectly. This is for quality reasons across the board. You don't want a hard drive getting corrupted data because someone didn't know how to
[12:37:44] <N1njaneer> write the sound card driver correctly, etc.
[12:38:03] <myself> ....is there such a thing as generic USB HID terminal program that I could use to open any HID device and see what it's sending, send my own stuff to it, etc? Analogous to procomm but for HID instead of COM?
[12:39:29] <N1njaneer> myself: Technically yes, you CAN do that with HID very easily, but there's no good reason to unless you were the one who designed the hardware and know how to talk to it. Just like opening a serial mouse (provided you know the baud rate and comm parameters) you'll just see a string of garbage on the screen as you move it around. You need to know how to parse the protocol. The same is true of USB
[12:39:29] <N1njaneer> devices. Generic class drivers ARE the standard protocols, so they can be talked to commonly. If you have a proprietary thing, you need to know how to talk to it.
[12:39:30] <Casper> myself: only and only if there is a driver loaded
[12:39:39] <jhn> I think USB sniffers exist.
[12:39:41] <Casper> there is some usb sniffing tools
[12:39:51] <myself> Well, point is, it's a HID device, so the driver's already loaded. It's HID.
[12:39:52] <N1njaneer> myself: Yes, software USB packet monitors do exactly that, and are very useful for development.
[12:40:28] <N1njaneer> Some of them will allow you to arbitrarily fire things to endpoints, but you'd better know what the protocol is if you're going to do that. Else what's the point?
[12:40:48] <myself> But sure, opening a serial mouse isn't the most useful things ever, but opening a serial modem is incredibly handy. I don't always want dial-up networking to do things for me. Maybe I want to open my HID barcode scanner, for which I don't have application software, and see if I can interpret the data by hand so I can write that software.
[12:40:52] <N1njaneer> At that point you are generally developing an application anyhow.
[12:41:36] <N1njaneer> Or just get a HID barcode scanner which appears as a keyboard. All of ours here do when set in keyboard mode. Then we just scan a barcode and it emulates the keystrokes. Done. :)
[12:41:50] <N1njaneer> If you are a hammer, all of your problems start looking like nails.
[12:41:59] <myself> Thing is, I can figure out and *write* software that'll open COM1 and interpret a serial mouse. I don't know where to start to write something that'll open HID-1234 and interpret my barcode thing, because there is no HID-1234 pseudo-device for me to open.
[12:43:05] <N1njaneer> That's exactly how people have written drivers for Linux for closed-source products. Using a USB packet monitor and reverse engineering it. But you need a working device with working software to have any kind of shred of hope whatsoever to do it.
[12:43:43] <N1njaneer> You NEED to see how the device is configured and talked to under normal working conditions, then try to figure out what all is what. It's exceedingly non-trivial and only sometimes successful.
[12:43:45] <myself> Which isn't the case with a serial mouse or something. Huh. Okay, so that has actually changed, it's not just a gap in my understanding.
[12:46:47] <myself> So the term is "USB packet monitor". I'll do some digging. Because I have a whole pile of barcode and magstripe and touchscreen hardware, just new enough to be USB, but for which there are no modern/sane/available drivers to be found. I suspect some of it may just be a vid/pid/inf hack away from working with some other driver, but I'll need to see what it's sending to make that determination.
[12:47:27] <N1njaneer> Hopefully the explanation helps. It's of significant benefit to try to make your hardware use a generic class driver wherever possible since it makes a LOT less work for you, and suddenly a product that "just works" on multiple OS's without you doing any software. Happier customers and you sell more. But if you need to make something that there is no generic class driver for, you either need to
[12:47:27] <N1njaneer> use HID and then write your custom software, or you need to write a full OS driver and then write your custom software :)
[12:48:50] <N1njaneer> myself: Any good modern USB barcode scanner will allow keyboard emulation as a HID. Most times barcode scanners are reprogrammed by physically scanning configuration codes which are specially escaped. Look up the manual from the manufacturer. There should generally be a few barcodes which are scanned to factory-reset the device, then other barcodes which will configure operation.
[12:50:00] <N1njaneer> We run multiple 2D barcode scanners here that are usef for managing serial numbers and data matrix codes on our PCBs and products. Picked then up on eBay for maybe $30-$40 each. We just run them in keyboard mode, and then have them configured to add a CR to the end of each scanned piece of data.
[12:50:25] <N1njaneer> It's great fun scanning commercial barcodes like FedEx labels to see what they contain. Generally it's a large mix of binary and plaintext ifo.
[12:50:26] <N1njaneer> info
[12:51:22] <N1njaneer> The better barcode scanners that use a camera instead of a resonance scanning laser will scan barcodes from the PDF manuals on the screen just fine, which is handy because it saves you having to print pages :)
[12:51:43] <myself> ninI'm well familiar with scantags and configuration. :) These are not that, I assure you. Mostly I'm looking at stuff that's not even OPOS-supported. Weird, custom NCR stuff that you' d have to run RSM/LE to read, and I've had no luck yanking drivers out of RSM.
[12:52:01] <myself> (Laser-based ones will read an e-ink display just fine, btw.)
[12:52:21] <N1njaneer> Of course.
[12:52:54] <N1njaneer> myself: Then just spend $30 on eBay and get a nice 2D Symbol barcode scanner. Done! :)
[12:53:00] <myself> No fun!
[12:53:22] <N1njaneer> Depends on what you are doing. If your fun is had by hacking on the devices, then by all means do so!
[12:53:28] <myself> Mostly it's the MSR on the side of the VGA touchscreen, which is soooo cute. I've gotten it working in RSM/LE so I should be able to sniff it and do something more sane.
[12:53:39] <myself> Oh yeah. Fun and github.
[12:53:47] <N1njaneer> For me, I need devices working and working quickly so I can make money by keeping clients happy :)
[12:55:31] <myself> Right, right. Hobby, not busines. Sorry. Hi. Hackerspace. o/
[12:56:50] <N1njaneer> Is all good!
[12:57:33] <N1njaneer> I just like to make sure people aren't making more effort for themselves by taking the round-about methods, but if that exploration is the whole point then my reccomendations are invalid :)
[12:57:34] <myself> Hehe. Thanks much for the dose of USB clue, though. I missed like a decade where things got un-simple, and I feel I understand it a bit more now.
[12:58:35] <N1njaneer> myself: Sure, no problem. Dean has a lot of great AVR USB stuff up at
http://www.fourwalledcubicle.com/ and is often logged in to here. Also ALL of the USB specs are avaliable free from usb.org
[12:58:55] <N1njaneer> The latter makes for great bathroom reading.
[12:59:08] <N1njaneer> Print out a copy and drop it in the bathroom of your hackerspace. People will love you for it!
[12:59:34] <myself> Hehe. Not the worst idea.
[14:48:34] <vsync1> N1njaneer: software-docs in bathroom, aka. toilet paper
[14:48:54] <vsync1> but i'm sure they will love it