Back
[01:04:31] <clixx_IO> just putting a html5 interface on my attiny85
[06:10:32] <Jartza> oh well
[06:10:46] <Jartza> got my parts today
[06:10:59] <Jartza> next thing is to try to make pcb for sot23-5 parts
[06:11:03] <Jartza> and then solder them :)
[07:00:34] <Tom_itx> Jartza, not so difficult
[07:01:29] <Tom_itx> http://tom-itx.ddns01.com:81/~webpage/temp/tiny/tinyTPI1.jpg
[07:02:54] <viz> Programming
[09:02:48] <nullset> Jartza: kicad!
[09:02:51] <nullset> it's easy
[09:03:02] <nullset> then go over to #hackvana to get your boards made ( or oshpark )
[09:03:12] <nullset> get stencils from oshstencils ( or hackvana if you want stainless )
[09:03:15] <nullset> and you're ready to og
[09:03:50] <ivanshmakov> nullset: Which country are they based?
[09:04:16] <nullset> hackvana is in australia
[09:04:22] <nullset> but his fabs are in china and ship anywhere
[09:04:23] <nullset> oshpark is in the us
[09:04:27] <nullset> and fabs in the us
[09:05:06] <ivanshmakov> nullset: I guess if it ships from China directly, then it may be a thing worth considering for me. Thanks.
[09:05:19] <nullset> he's making some boards for me right now
[09:05:25] <nullset> pop over to #hackvana or check hackvana.com
[09:05:37] <nullset> i'm surprised he's not in here right now :)
[09:07:08] <ivanshmakov> nullset: He surely is.
[09:11:39] <hackvana> ivanshmakov: nullset: Hi!
[09:46:09] <Jartza> :)
[10:00:25] <Jartza> but anyway, if someone has idea how to get kicad running well on osx (mavericks), then I'm happy to look at it
[10:00:42] <Jartza> last time I checked, it was pain in the arse and crashed a lot and had some UI bugs
[10:01:00] <Jartza> so currently I'm using eagle
[10:01:53] <Jartza> and I've only designed one board so far, simple one
[10:01:59] <Jartza> so I can't say I'm that pro yet
[10:02:14] <Jartza> https://www.dropbox.com/s/wpm0ozlcppqx86j/20140713_001.jpg
[10:39:27] <twnqx> what, a c64 emulator on LCD?
[10:39:33] <twnqx> neat.
[10:39:33] <N1njaneer> Well, when you at least have SOMETHING on the display, life can't be all bad right? :D
[10:41:14] <twnqx> anyway, bedtime. overslept this morning already (damn customers who want to start at 9am, can someone tell them to be more relaxed...)
[11:49:12] <nullset> Jartza: i'm using it
[11:49:20] <nullset> on os x
[12:30:07] <sabesto> anyone experimented with using IR and a bootloader to upload code?
[12:37:19] <ivanshmakov> sabesto: Is that “IR” as in “infra-red”?
[12:39:40] <N1njaneer> IR is feasible, but typically unidirectional and subject to inteferrence, so you'd have to take appropriate precautions to checksum and/or error correct the data. If you can do bi-directional it's fairly trivial to implement. Something like XMODEM would handle most of your higher-level payload transfers automatically.
[12:40:05] <sabesto> IR as in infra-red, yes
[12:40:24] <ivanshmakov> N1njaneer: Is there any physical medium that’s /not/ subject to interference?
[12:41:03] <sabesto> i think i will just try without any error checking first
[12:41:31] <sabesto> this product will be submerged in silicon oil, messy to get out
[12:41:34] <N1njaneer> IR is explicitly moreso - flourescent lighting alone can introduce significant errors.
[12:42:40] <N1njaneer> At very least you want to have checksums. If you are only going unidirectional I would highly suggest implementing some kind of forward error correction, even if that's just transmitting every packet 2-3 times
[12:42:56] <sabesto> it will be bidirectional
[12:43:33] <sabesto> these guys did it:
http://krazatchu.ca/2012/05/07/superduplex-an-infrared-bootloader-for-arduino/
[12:44:53] <sabesto> shielhaving to shield the unit from light during upload is ok
[12:45:01] <sabesto> *having to shield ...
[12:55:12] <nullset> sabesto: IR will have errors
[12:55:16] <nullset> and a fairly low data rate
[12:55:30] <nullset> you definitely need checksums
[12:55:32] <nullset> at the least
[13:01:46] <sabesto> nullset: is this from experience?
[13:02:03] <nullset> i've done a lot of work with bootloaders
[13:02:04] <nullset> and with IR
[13:02:12] <nullset> there is absolutely no reason NOT to add a checksum of some sort
[13:02:36] <nullset> especially with optics. IR is incredibly noisy and slow, depending on frequency
[13:02:44] <nullset> what protocol are you planning to use to transmit the data?
[13:04:51] <sabesto> my intention was to use an stk500 compatible bootloader
[13:08:09] <nullset> how do you plan to translate that to IR?
[13:08:25] <sabesto> http://krazatchu.ca/2012/05/07/superduplex-an-infrared-bootloader-for-arduino/
[13:08:33] <sabesto> something like that
[13:09:49] <nullset> then do that
[13:09:54] <nullset> they seem to have the problems solved.... :)
[13:12:13] <sabesto> it should be stk500 compatible, so very portable
[13:13:15] <sabesto> got to run
[13:23:21] <N1njaneer> sabesto: Sorry, got pulld away for a bit. And yes, IR is finnicky. I've been doing massive IR communications roll-outs (covering literally acres of space) for the past three years, so intimately familiar with the challenges. Thankfully you should have an easier go being close proximity rather than dozens of meters away :)
[13:23:53] <N1njaneer> Oops guess I missed him :)
[13:27:34] <N1njaneer> Sending critical things like firmware updates without checksums is kind of asking for trouble :D
[13:29:08] <RLa> i'm trying to read two channels with adc alternatively, should i use interrupts and select channel every time adc conversion ready interrupt happens and start new measurement?
[13:29:46] <RLa> but i wonder maybe that loads mcu too much with adc interrupt handling code?
[13:29:59] <RLa> i also need to do some other things
[13:32:32] <RLa> my ADC clock is 93.75kHz
[13:39:36] <RLa> hm, conversion takes 13 adc clock cycles, that gives about 7k measurements/sec
[13:39:41] <RLa> feels too much
[13:43:33] <ivanshmakov> RLa: I guess you won’t be able to use the free-running ADC mode if you have to change ADMUX settings between measurements.
[13:43:46] <RLa> yes
[13:44:42] <ivanshmakov> RLa: There’re some subtleties as to the (ADMUX change, actual measurement) timing; be sure to check the applicable datasheet for that.
[13:44:57] <kastein> heh. funny story
[13:45:04] <kastein> I did that on one of my first can128 designs
[13:45:26] <kastein> using an ISR for the ADC, round robin cycling through ADC inputs, in free running mode
[13:45:30] <kastein> lemme look up the code
[13:46:01] <RLa> nvm, i will use timer1 to start measurements
[13:46:22] <kastein> it is really pretty easy
[13:47:38] <kastein> alright, so
[13:47:54] <kastein> in the AT90CANxxx datasheet at least, the section you want to read is 21.5.1 ADC Input Channels
[13:47:57] <kastein> specifically:
[13:48:06] <kastein> * "However, the simplest method is to wait for the first conversion to complete, and then change the channel selection.
[13:48:06] <kastein> * Since the next conversion has already started automatically, the next result will reflect the previous channel selection.
[13:48:06] <kastein> * Subsequent conversions will reflect the new channel selection."
[13:49:09] <kastein> the way I did it, I have free running conversions going, every time one completes it executes the ADC ISR, the ADC ISR knows what order it selects channels in so it always just writes the conversion results into the variable for the LAST channel it had selected
[13:49:22] <ivanshmakov> RLa: Just watch for your ADC /request/ rate being lower than that 7 kHz maximum ADC rate you’ve mentioned earlier.
[13:49:27] <kastein> then moves to the next channel, since the ADC is already doing the next conversion for the CURRENT channel
[13:49:33] <sabesto> N1njaneer: well, you can verify progmem after
[13:49:58] <kastein> and I'm getting reasonably accurate data out, and no sample source confusion, so it is pretty stable this way
[13:54:45] <RLa> ivanshmakov, kastein, my current code:
https://gist.github.com/rla/81ac2fe699884de12b96
[13:55:10] <RLa> kastein, that still fires lots of adc completion interrupts
[13:55:23] <kastein> yes, this is true
[13:56:04] <kastein> in my app that doesn't really matter much, I have way more CPU available than I need. if that affects yours, it probably won't work for you or will need some rethinking
[13:56:14] <RLa> hm, comes out i'm not storing adc result at all
[13:56:47] <RLa> yes, i need to poll some inputs periodically and would not like to disrupt that much
[13:57:27] <RLa> uint16_t assignment is atomic or should i protect them somehow?
[13:59:47] <ivanshmakov> RLa: To an immediate value? I guess not.
[14:14:02] <RLa> when sending multibyte integers over 232, should i send low or high bytes first?
[14:15:46] <aandrew> 233 still fits in a byte
[14:15:54] <aandrew> oh you mean RS232
[14:16:07] <aandrew> well if you want to follow convention, use network byte ordering which is MSB first
[14:16:22] <aandrew> but there's no requirement, both sides just have to agree to use the same ordering
[14:24:01] <Jartza> doh
[14:24:02] <Jartza> https://www.dropbox.com/s/lehw75n0uvkt1t9/Screenshot%202014-07-16%2022.05.11.png
[14:24:33] <Jartza> &
https://www.dropbox.com/s/qrlib1j1m9wv97o/Screenshot%202014-07-16%2022.05.52.png
[14:25:47] <Jartza> if my supply voltage is 3.3v, how do I calculate the resistor values for r, g and b? and if the leds share the common anode, how on earth the red uses different voltage? :)
[14:25:52] <Jartza> (sorry stupid questions)
[14:26:26] <ivanshmakov> RLa: And how are you going to synchronize sides?
[14:27:15] <ivanshmakov> RLa: Is, by a chance, your intent is to send ADC samples, BTW?
[14:30:22] <RLa> ivanshmakov, yes
[14:30:39] <RLa> and i can send when i know that adc is not doing conversion
[14:32:22] <ivanshmakov> RLa: Care to check the code at
https://ru.wikiversity.org/wiki/Архитектура_AVR_в_примерах/Осциллографическая_приставка?
[14:34:01] <ivanshmakov> RLa: Basically, if your ADC is 10-bit wide (or anything less or equal to 14 bit), it’s possible to send that as two 8-bit bytes /of different ranges,/ – one being for lower half of the value and the other for the higher.
[14:34:18] <ivanshmakov> RLa: That provides for synchronization in case any bytes are lost in the way.
[14:34:42] <ivanshmakov> RLa: For 10-bit samples, it’s possible to encode both parts as ASCII printable characters, too.
[14:36:57] <RLa> hm, i do not need ascii
[14:37:20] <RLa> i convert them back into integers on the client side
[14:37:30] <RLa> thanks for the code
[14:37:42] <RLa> i see i could use watchdog timer too
[14:38:23] <RLa> anyway, i already use 16-bit timer with overflow period of 1.4s, i use this to start measurements
[14:38:39] <RLa> adc should complete its work in first 1ms
[14:39:03] <RLa> anyway, i will use adc values before i start conversion
[14:39:30] <RLa> then i can be sure i get intact values
[14:59:36] <ivanshmakov> RLa: I use both timer overflow and ADC conversion complete interrupts. The first one wakes the main loop to start a conversion; the second is when I send the data. Then it repeats.
[15:00:05] <ivanshmakov> RLa: ASCII is handy from the point of debugging, so given that it comes at no cost, I see no reason to avoid it.
[15:01:06] <RLa> everything works well here now :)
[15:01:17] <RLa> i even got byte order right on the first try
[15:01:34] <RLa> but i have some ugly switches in code to send data
[15:03:22] <RLa> https://gist.github.com/rla/70f18abd730ef1029bff
[15:03:27] <ivanshmakov> RLa: If you have any improvements (readability-wise, etc.) to suggest to the code I’ve referenced above, feel free to post them onto the “talk” page there.
[15:03:47] <ivanshmakov> (That is:
https://ru.wikiversity.org/wiki/Talk:Архитектура_AVR_в_примерах/Осциллографическая_приставка.)
[15:04:05] <RLa> hm yeah, there might be better way to keep track of bytes and current operation
[15:06:25] <ivanshmakov> RLa: ?
[15:06:46] <RLa> no really, debugging ascii is the last thing i want to do
[15:08:55] <RLa> uart_putc <- not seen that function before
[15:10:03] <ivanshmakov> RLa: That’s from Peter Fleury’s UART library.
[15:10:30] <ivanshmakov> RLa: I don’t seem to understand what you mean by “debugging ASCII.”
[15:11:07] <ivanshmakov> RLa: My point was that as long as the stream is pure-ASCII, any “terminal emulation” software could be used to look at it, or log it.
[15:11:33] <ivanshmakov> RLa: Even $ cat < /dev/ttyS5 > mylog, then $ less < mylog will do, for instance.
[15:12:29] <RLa> hm
[15:12:40] <ivanshmakov> RLa: Having anything in the 0–31 ASCII control range (sans 8, 10, 13) mixed in makes that a bit harder.
[15:12:51] <RLa> that makes some things easier indeed
[15:13:03] <ivanshmakov> (And the same goes for 127–255.)
[15:13:15] <RLa> tho i already have scripts to decode data
[15:14:07] <ivanshmakov> RLa: The other nice point of that specific approach is that textual messages could be mixed with data with relative safety.
[15:15:19] <RLa> true
[15:15:37] <RLa> i will think about switching my protocol
[15:15:52] <ivanshmakov> RLa: The key feature of the encoding I use is that it looks like hElLo_wOrLd, which is something hardly possible in the plain text.
[15:16:10] <ivanshmakov> RLa: I’m yet to post my Perl decoding code, alas.
[15:16:41] <RLa> hm, i decode in js
[15:16:49] <RLa> been using it long time
[15:18:20] <ivanshmakov> RLa: Perl 5 is, like, one of the first “real” high-level languages I’ve learned, back in 1999 or so.
[15:18:48] <ivanshmakov> s/learned/started to learn/, as I’m yet to finish.
[15:21:27] <Kev> perl is a great language
[15:22:37] <Jartza> hmmh
[15:23:23] <Jartza> don't know if I calculated correctly, but if I'm right, the resistors for the led should be 150 ohm for red, 27 ohm for blue and 33 ohm for green....
[15:23:33] <Jartza> I mean, based on this:
https://www.dropbox.com/s/qrlib1j1m9wv97o/Screenshot%202014-07-16%2022.05.52.png
[15:23:36] <Jartza> ?
[15:23:41] <Jartza> using 3.3v supply
[15:23:41] <ivanshmakov> Jartza: That’s, like, depends on the voltage.
[15:24:12] <Jartza> yes, I'm trying to figure out the calculations :)
[15:24:40] <ivanshmakov> Jartza: R = U / I.
[15:24:54] <Jartza> yes
[15:24:56] <RLa> (3.3 - led voltage) / (led current)
[15:25:29] <RLa> hm, mcp9700 give me weird results
[15:26:07] <Jartza> so I guess that's about right values then
[15:26:27] <ivanshmakov> Kev: In Russia, a mother would sometimes explain to a troubled child: “Oh, you my woe of onion.” Also, there’s a joke of one guy asking another: “why is the camel’s neck crooked?”, and the latter replying: “why, does it have /anything/ straight?”
[15:27:03] <ivanshmakov> Kev: I believe both to be surprisingly applicable to Perl.
[15:27:13] <ivanshmakov> It has CPAN, though.
[15:27:51] <RLa> room temp is 25C, mcp9700 gives out 1.3V
[15:28:03] <RLa> datasheet says 0.5V at 0C
[15:28:23] <RLa> and 0.01V/C
[15:28:26] <Kev> i use cpan mostly for docs, but since i'm using windows both a home and a work, i use activestate's ppm more :)
[15:28:48] <RLa> by that my mcp output should be 0.75V
[15:29:18] <ivanshmakov> Jartza: Unless I be developing some street lights, I’d rather be limiting the LED current to 5 mA or so.
[15:29:31] <ivanshmakov> (Or some another outdoor application for that matter.)
[15:31:24] <Kev> RLa, did you triplecheck the wiring ? :D
[15:31:40] <RLa> yes :)
[15:35:27] <Jartza> ivanshmakov: well actually I want to control the r, g and b using pwm in the end
[15:35:48] <Jartza> but I just want to get resistors for testing, as I don't want to burn the leds
[15:35:56] <Jartza> they are actually a backlight of an lcd display
[15:36:06] <Jartza> so not that easy to replace either
[15:36:32] <Jartza> although I'm not sure now how to use pwm as the leds seem to have common anode
[15:36:54] <Jartza> so attiny pins need to sink current, right?
[15:37:51] <jonored> Usually microcontroller pins are a bit better at that, at least.
[15:39:01] <ivanshmakov> Jartza: Yes.
[15:39:50] <Jartza> but using attiny pins as pwm, they don't sink current?
[15:40:21] <RLa> hm, i get 0.75V without mcu connected
[15:40:39] <RLa> it's somehow causing sensor go wrong
[15:41:00] <RLa> Jartza, afaik the sink and supply (push-pull)
[15:41:14] <RLa> but are not open-collector/drain that you might want
[15:41:18] <Kev> maybe an internal pullup or something
[15:41:45] <RLa> Kev, i thought they are disabled by default
[15:42:12] <Jartza> so I need to play with timers and fiddle with port myself
[15:42:36] <RLa> Key, i have pull-ups configured but not for those inputs
[15:47:42] <RLa> Kev,
https://gist.github.com/rla/ae84236771c35776a6df#file-init-c-L18-L22
[15:53:19] <Kev> did you measure 1.3v with a multimeter or was that a value you got from an adc ?
[15:53:58] <RLa> multimeter
[15:53:59] <Kev> (also i'm assuming that you're using PC0 or PC1 ?)
[15:54:10] <RLa> on both channels
[15:54:11] <ivanshmakov> RLa: If that ends up being ADC, watch for the signal source’s series resistance to be low enough.
[15:54:26] <ivanshmakov> RLa: As in: a few kΩ at most.
[15:55:03] <RLa> there is a 10k/10nF low-pass filter
[15:55:05] <ivanshmakov> RLa: My understanding was that the Jartza’s LED currents are pretty low, so OD (OC) isn’t really necessary.
[16:00:05] <Jartza> yes, I calculated them with 10mA current
[16:00:13] <Jartza> and that would be the max.
[16:00:46] <Jartza> I'll try first with pwm
[16:00:53] <Jartza> if it doesn't work, I'll make SPWM
[16:28:33] <Jartza> ahh, running 3 pwm-pins needs two timers
[16:28:38] <Jartza> but I can only use one
[16:28:42] <Jartza> so I guess spwm it is then
[16:35:12] <RLa> you do not have two timers?
[16:38:47] <Kev> you can hack something with only 1 timer
[16:39:50] <Jartza> I do have more timers, but already in use for other purposes
[16:40:02] <Jartza> but I can hack spwm with one timer yes
[16:40:15] <Tom_itx> where to find GLIBCXX_3.4.15
[16:40:26] <Tom_itx> or GLIBC_2.15
[16:43:36] <ivanshmakov> Tom_itx: As in: $ objdump -x -- /where/is/lib/debug/libc.so?
[16:44:07] <RLa> looks like mcp becomes unstable on long wire
[16:44:16] <RLa> 100nF cap at it resolved it
[16:44:36] <RLa> tho it makes sensors way bulkier and hard to mount
[16:51:32] <RLa> maybe it's just my computer psu that causes issues
[16:55:33] <Kev> maybe use a digital sensor
[17:01:16] <N1njaneer> Put a scope on and check for noise? :)
[17:22:09] <RLa> fcking supply is badly off from 5V too
[17:22:11] <RLa> 5.41V
[17:22:25] <RLa> cause -5C error
[17:22:27] <RLa> causes
[17:23:26] <RLa> meaning that adc reference is badly off too
[17:23:32] <RLa> that's almost +10%
[17:26:09] <RLa> prolly have to switch to internal reference
[17:44:43] <Jordan_U> We're having a problem with a board that we seem to be able to program (though sometimes even that is giving us problems) but when it comes time for my code to start, it doesn't seem to. If I load code that does nothing, while(1) {}, then when I turn on the chip I see a 1 hz signal on the MISO pin. If I load the program that is supposed to go on the chip, and was on the chip about an hour ago working fine, that's still all I get. None o
[17:45:06] <Jordan_U> MISO toggling between high and low at 1 hz.
[17:46:31] <N1njaneer> Any bootloader?
[17:46:44] <Jordan_U> N1njaneer: The one that came with the chip.
[17:46:56] <Jordan_U> ATMEGA 64 M1
[17:46:57] <Lambda_Aurigae> chips don't come with bootloader from the factory.
[17:47:05] <N1njaneer> Lambda_Aurigae: The USB ones do
[17:47:10] <Lambda_Aurigae> true.
[17:47:11] <Jartza> N1njaneer: any opinion of the "sk10 flux" for coating the homemade pcbs?
[17:47:14] <N1njaneer> Hence why I asked :)
[17:47:16] <Jordan_U> Sorry, then I guess no.
[17:47:51] <Lambda_Aurigae> is reset pulled high with a pullup resistor?
[17:48:15] <Lambda_Aurigae> what is the clock source? is it configured properly?
[17:59:44] <Jordan_U> Lambda_Aurigae: Just the internal pullup, unless the programmer also pulls it up. The clock source is the default clock the chip came with, the internal RC oclillator.
[18:02:14] <N1njaneer> Jordan_U: Is it known-good code that will do something simple and predictable?
[18:03:24] <N1njaneer> Some things to watch out for on the bigger chips are items like bootloader / bootreset vector fuses, and disabling JTAG if you aren't using it. The latter is particularly insidious since you wonder why four pins don't respond :)
[18:04:10] <N1njaneer> And the clock souces like Lambda_Aurigae suggested, though the clock is assuredly running if the ISP interface works - the chip requires valid clock to be programmed through SPI.
[18:04:44] <N1njaneer> A pull-up resistor is not required on the reset pins for AVRs - doesn't hurt to have one, but not required. You can always check to make sure something isn't pulling it down, etc.
[18:05:48] * N1njaneer orders SMT parts, goat supplies, and CNC tooling - an odd combination.
[18:08:15] <RLa> goat supplies?
[18:10:52] <RLa> btw, what's the main use case of bootloaders?
[18:11:34] <Jordan_U> N1njaneer: Yes, known good code, and yes simple and predictable. And it can't get much simpler than "main (){ while(1){}; }", which should do nothing but is instead toggling the MISO pin.
[18:11:42] <Tom_itx> arduino
[18:12:32] <Lambda_Aurigae> RLa, main use case?
[18:12:38] <Tom_itx> arduino
[18:12:41] <Jordan_U> N1njaneer: This chip doesn't support JTAG, and I've never made any changes to any fuses. I've just been loading my program onto the chip using atmel studio. I've even been sure to never even attempt to use debugwire.
[18:13:12] <Lambda_Aurigae> you use a bootloader to load a program onto the chip without a programmer device...like, through usb or usart on the chip.
[18:20:46] <RLa> damn, my computer psu cables emit fm frequencies
[18:20:52] <RLa> and disturb radio
[18:30:48] <Jordan_U> Selecting "Erase entire chip" instead of "Erase only programming area" in Atmel Studio seems to have unbroken things.
[18:33:18] <RLa> hm, i'm still stuck with binary protocols
[18:33:44] <RLa> what you guys think of protocol where each command ends with specific byte
[18:34:09] <Lambda_Aurigae> like a ;
[18:34:14] <Lambda_Aurigae> hmm,,like C!!!
[18:34:24] <Lambda_Aurigae> or
[18:34:25] <Lambda_Aurigae> maybe
[18:34:28] <Lambda_Aurigae> a CR
[18:34:42] <Lambda_Aurigae> like, a plethora of text based interfaces use.
[18:35:58] <ivanshmakov> Lambda_Aurigae: Even better: CR LF.
[18:36:07] <RLa> i'm using 0 :D
[18:36:41] <RLa> it's almost like text-based except i have binary data
[18:37:28] <ivanshmakov> RLa: Why?
[18:41:26] <RLa> with true text i would have to parse text
[18:42:26] <RLa> i think i should also add message checksums
[18:42:57] <Lambda_Aurigae> look at how the lego RCX communicates via IR.
[18:52:04] <RLa> why use existing protocol when you can invent your own :)
[18:53:01] <Lambda_Aurigae> I didn't say use it..just look at it.
[18:53:13] <Lambda_Aurigae> might can give you some ideas on how to screw up royally.
[18:54:39] <RLa> oh :)
[18:59:29] <RLa> is that open protocol at all?
[19:01:27] <N1njaneer> Jordan_U: Yeah, generally you want to erase the entire chip every time when doing development work, however assuming you are running a verify operation after the programming operation that will validate correct programming.
[19:01:56] <Jordan_U> N1njaneer: Why?
[19:02:28] <N1njaneer> Because you can only erase everything to 0xFF, then program it. So any region already programmed cannot be reprogrammed without being erased to 0xFF first
[19:03:36] <N1njaneer> Usually the only purpose for not doing a full erase is if you are loading two seperate hex files on individually - like a bootloader and then the application, because you are developing the application portion but relying on a bootloader also being present, etc.
[19:04:16] <N1njaneer> Obviously you can also just concatenate the binary images together (as for production programming so it's a single go) but there are rare useful times when it comes in handy :)
[19:04:24] <Jordan_U> N1njaneer: Any idea why erasing entirely isn't the default in Atmel Studio then?
[19:04:39] <N1njaneer> It generally is.
[19:04:44] <Lambda_Aurigae> because someone set it that way.
[19:04:55] <N1njaneer> Or what Lambda_Aurigae said :)
[19:05:08] <N1njaneer> But out of the box installed Atmel Studio should have that checked for the programmer.
[19:05:20] <N1njaneer> It should also have auto-verify checked as well
[19:05:35] <twnqx> maybe not for chips that ship with a bootloader out of the box?
[19:05:54] <N1njaneer> Because the verify phase would catch an error like that as well. Most chips from Atmel are shipped blank, so it would at least work the first time :)
[19:06:13] <Jordan_U> N1njaneer: I don't see auto-verify as an option anywhere.
[19:06:13] <twnqx> are the mega usb chips the only exception?
[19:06:27] <N1njaneer> twnqx: I don't believe those settings are differentiated based on the chip ID type selected, else I would agree that might be the case. But the only ones with a factory bootloader standard are the USB ones.
[19:06:52] * twnqx plans to use one in his next projects if that ever takes shape
[19:06:52] <N1njaneer> And there are some variations of those even that don't have them - I believe there is a different ordering code if you specifically want them blank without DFU on them.
[19:07:37] <N1njaneer> I've used USB on the MEGA32U2 and MEGA32U4 numerous times - they are very nice and easy to work with, especially if you are doing relatively simple stuff like HID.
[19:08:39] <twnqx> i would want to port the vusb based usb tiny i2c software (as part of it), and to tell my system if it's running on high power or low power (100mA/500mA)
[19:10:36] <N1njaneer> You could, though the MEGA32U2 has the full USB peripheral in it so it's a lot easier to use without having to do bit-bang USB and risk potential incompatibility problems if timing is off.
[19:10:59] <twnqx> exactly that's what i want to do :) just want to give it the same ABI
[19:11:18] <twnqx> or whatever you call it in USB speak
[19:11:43] <N1njaneer> The descriptors?
[19:11:56] <twnqx> yeah, even go so far as to steal the VID!
[19:12:04] <twnqx> VID/PID
[19:12:24] <N1njaneer> Who's VID?
[19:12:24] <twnqx> so the linux kernel module just accepts it
[19:12:33] <twnqx> vusb one :P
[19:12:46] <twnqx> it's a private project, not for resale, so noone will care
[19:12:49] <N1njaneer> VID/PID is just for auto-matching the device drivers on the OS side and positively identifying the device. :)
[19:12:57] <twnqx> exactly that is what i want
[19:12:59] <N1njaneer> But yeah, if they have a software suite probably useful
[19:13:20] <twnqx> they have it for both windows through libusb and linux kernel driver
[19:13:21] <N1njaneer> That was an annoying $1600 USD check to have to write a few years back to USB.org
[19:13:33] <N1njaneer> $125/bit
[19:13:35] <twnqx> is that a one-time thing?
[19:13:40] <N1njaneer> I wanted to just pay for the 1's
[19:14:23] <twnqx> friend of mine and i were thinking about getting one for his stuff (which i'd then blatantly use)
[19:14:32] <N1njaneer> Yep, if you just need to register for a VID. Then there are multiple other levels of renewing membership depending on what you need, voting rights, etc. And above and beyond that for logo compliance testing ,etc
[19:14:58] <N1njaneer> There is technically an alternative that falls in to a slightly gray area, but would work according to the spec
[19:15:13] * twnqx waits for the USD to crash and burn so he can pick one up for cheap
[19:15:49] <N1njaneer> Sorry, $2K USD not $1600
[19:16:24] <twnqx> i wonder why they designed it with just 64k IDs :/ sounds like they will run out sooner rather than later
[19:16:54] <N1njaneer> Nah, nowhere near that number of vendors registered.
[19:17:40] <N1njaneer> You can pull the current list of all of them off usb.org - still well less than a thousand I believe, though the VID ordering is pretty scattered all over numerically.
[19:17:57] <N1njaneer> twnqx: Trying to get you a URL, website being slow.
[19:18:09] <twnqx> i have to go anyway
[19:18:15] <twnqx> time to head over to the customer
[19:18:33] <twnqx> be back in an hour or so, given umts works a tad better than yesterday
[19:19:45] <N1njaneer> twnqx:
http://goo.gl/is1eUv
[19:20:16] <N1njaneer> Read the fine print as to why this DOES work. It's slightly clandestine, but from a technical standpoint is 100% valid for obtaining a unique VID/PID pair.
[19:21:11] <twnqx> thanks, will take a look later
[19:21:12] <twnqx> bl
[19:21:14] <twnqx> bbl
[19:31:51] <Valen> N1njaneer: lol nice
