Back
[01:59:05] <Haohmaru> would it be a dumb idea to wrap a pointer to a PORT_t in a struct, together with a uint8_t pinN and make overloaded operators = ^= and such?
[02:00:32] <Haohmaru> i'd like to define/declare what stuff i got on each pin, in one place, and be able to use it simply like LED1 ^= 1;
[02:01:42] <Haohmaru> i can't think of a way to do it with macros (maybe cuz i'm not too familiar with macros), i can do it with C++ structs, but i'm afraid if that would cost in performance
[02:02:11] <Xark> Haohmaru: It is probably pointless, but you can make a struct with a bitfield that will work like that (and don't even need to write your own operators).
[02:03:08] <Xark> Haohmaru: E.g., struct myreg { uint8_t mode:2; uint8_t count:6; }; will make a 1 byte struct with a 2 bit and a 3 bit unsigned int member.
[02:03:11] <Haohmaru> btw, i'm already using C++ for other reasons, so my concern is not whether the rest of the stuff is slow, but specifically if overloading = and ^= when i really just want PORTX.OUTSET = mask;
[02:03:41] <Xark> er, 2 and 6 bit unsigned int. :)
[02:03:48] <Xark> (packed into 8-bit byte)
[02:04:06] <Haohmaru> okay, but how does that help?
[02:04:24] <Haohmaru> oh, i see
[02:04:28] <Xark> Well then you can do myreg.count = 3; or myreg.mode ^= 2;
[02:04:52] <Xark> (i.e., pretty much anything you can do with ints)
[02:05:07] <Haohmaru> so that i can have my own version of PORTD as a struct with named variables for each pin, yet this whole struct would take 1 byte
[02:05:32] <Haohmaru> pic's registers are defined like that
[02:06:29] <Haohmaru> but.. that would be my copy of a port in a variable, whatever i do with it won't be automagically applied to the actual port
[02:06:45] <Xark> Then you make a volatile * to the actual port.
[02:07:09] <Haohmaru> i don't think i have access to the actual 8 bits of the port
[02:07:19] <Haohmaru> i'm not sure
[02:07:36] <Haohmaru> i can set/clear/toggle
[02:08:04] <Xark> struct regdef { uint8_t bits:4; uint8_t modebits:4; }; volatile regdef* myreg = (volatile regdef*)0x003f;
[02:08:18] <Xark> Then myreg->modebits = 3;
[02:09:17] <Xark> Haohmaru: If you make a bitfield of the port bits, the compiler will load /mask /or/store (to preserve the other fields when only one modified).
[02:09:36] <Haohmaru> uh
[02:09:40] <Haohmaru> i don't want that
[02:10:01] <Xark> Haohmaru: That is all C can do. Same as PORTD &= ~(1<<3); e.g.
[02:10:21] <Haohmaru> ehm
[02:10:33] <Haohmaru> i should have mentioned that i'm talking about xmega
[02:10:38] <Xark> However, if it is only a single bit, avr-gcc will generally turn it unto SBI or CBI (set or clear bit instruction).
[02:10:43] <Haohmaru> where PORT_t is a whole structure
[02:11:12] <Xark> Haohmaru: I see. Well, if it is already a struct, then what are you trying to acomplish?
[02:11:25] <Haohmaru> which has OUTSET, OUTCLR, OUTTGL, and such, which are 8bit each
[02:11:48] <Xark> IMHO, you really should just use the standard definitions AVR provides and be happy. Coming up with your own "clever scheme" is unlikely to be a "win".
[02:12:05] <Haohmaru> that's what avr provides
[02:12:16] <Xark> Haohmaru: Okay, and what is your problem with it?
[02:12:18] <Haohmaru> and i'm currently using it
[02:12:43] <Haohmaru> PORTB.OUTTGL = PIN3_bm;
[02:12:48] <Haohmaru> this blinks a LED
[02:13:01] <Haohmaru> but.. maybe it doesn't
[02:13:08] <Haohmaru> it's not very clear, is it?
[02:13:13] <Xark> Seems fairly reasonable...
[02:13:21] <Xark> What would you prefer?
[02:13:22] <Haohmaru> it surely toggles some pin3 on some portB
[02:13:45] <Haohmaru> i would like to have LED1 ^= 1; or LED1.toggle(); or so
[02:13:58] <Haohmaru> which again should turn into PORTB.OUTTGL = PIN3_bm;
[02:14:28] <Xark> Haohmaru: Well, you can wrap that in a class like your 2nd example if you want. The first is possible too, but would need more trickery.
[02:14:29] <Haohmaru> i can do it by wrapping a pointer to a PORT_t in a class
[02:14:56] <Haohmaru> i can do the ^= thing with operator overloading
[02:15:19] <Haohmaru> and thus my question: is that a dumb idea
[02:15:29] <Haohmaru> maybe LED1.toggle() is enough
[02:15:30] <Xark> Yeah. Effectively if LED1 is a class, that is a function call to LED1.operator^(1);
[02:16:02] <Xark> I would advise against the operator overloads vs normal function.
[02:16:22] <Xark> toggle() is instantly clear
[02:16:32] <Haohmaru> how about setting it?
[02:16:43] <Xark> LED1.set(onoff)?
[02:16:46] <Haohmaru> crap, i still need an IF there
[02:17:06] <Xark> Yes or ? : however, of onoff is a constant the compiler will bake it out.
[02:17:14] <Xark> if*
[02:17:33] <Haohmaru> i'd have to have an IF inside the set() function
[02:17:55] <Xark> Or LED1.on() LED1.off() (but you still need a IF for variable onoff)
[02:18:04] <Haohmaru> because i have to use port->OUTSET = mask; or port->OUTCLR = mask; depending on the value
[02:19:05] <Haohmaru> and if all those functions can be inlined into the equivalent code as if i just wrote PORTB.OUTTGL = PIN3_bm; it would be nice
[02:20:47] <Haohmaru> and if they are classes, i would simply declare them either in the global scope or at the top of main() with constructor arguments
[03:46:19] <Haohmaru> well, it seems to work:
http://pastebin.com/eBtqPM33
[03:47:35] <ThatDamnRanga> does seem a little complicated
[03:48:03] <ThatDamnRanga> like, I can see why you're doing it, I just wouldn't personally
[03:48:20] <Haohmaru> the point is, in main.cpp i'd have only the pin declarations
[03:49:17] <ThatDamnRanga> I tend to just #define STATUS_LED 5, etc. and use _BV()
[03:49:42] <Haohmaru> well, i guess something equivalent can be done in another way, perhaps with some uber clever preprocessor macro magic, but i don't know how ;]
[03:49:45] <ThatDamnRanga> but I like to try and keep the risk of wasting CPU cycles as low as possible without outright resorting to assembler
[03:51:06] <Haohmaru> now i can put one-line declarations of all pins, sorted by actual pin number on the chip, and it'll look very clear what's where
[03:51:48] <ThatDamnRanga> but will it be efficient?
[03:52:00] <Haohmaru> no idea
[03:52:10] <ThatDamnRanga> you're not exactly dealing with a multigigahertz machine here that can spare a few cycles to do some stuff
[03:52:37] <Haohmaru> if it really gets inlined, as i hope.. on() and off() might be equivalent to the normal way
[03:53:10] <ThatDamnRanga> if you're working 'near capacity' with a device, you can cause all kinds of timing issues by making code easy to read. it does suck, but c'est la vie.
[03:54:43] <Haohmaru> it really makes life easier if you can just swap the roles of two pins without destroying your code ;P~
[03:59:25] <ThatDamnRanga> there's simpler ways to do that though
[05:25:21] <Palsson> Have someone here tried running 921600 baudrate on a 8 MHz atmega without hardware flow control? It should be possible to do that without missing data if i create a minimal ISR that just puts the data in a struct or something, right?
[05:25:34] <Palsson> I'm just worried that it is too fast for the atmega to keep up on 8 MHz
[05:26:41] <Haohmaru> struct? i'd think a fifo
[05:28:16] <ThatDamnRanga> yeah, use a FIFO implementation when handling fast data on the ATMega
[05:28:29] <ThatDamnRanga> it's a shame there's not a terribly good standard one
[05:29:11] <ThatDamnRanga> I use an ISR to push to a 16 byte buffer usually
[05:29:18] <ThatDamnRanga> longer may be needed but it does the job for me
[05:31:53] <Palsson> I know that i'm not going to be handle more than one command at a time so i will for sure be done with a command before the next one comes, that's why i though a struct should do.
[05:32:15] <Palsson> That should do for this case, right?
[05:32:56] <Palsson> Fifo would be great if i didn't know the amount of data that is going to be received and i want to handle data at the same time i want to receive more.
[05:33:13] <ThatDamnRanga> struct not necessarily necessary
[05:33:30] <ThatDamnRanga> a char array would do, with a flag you can set when there's a command ready to be processed
[05:34:03] <ThatDamnRanga> input onto rotary buffer-> look for cmd termination char -> if match, set flag, copy buffer to cmd var
[05:34:06] <Palsson> Yeah i get your point. How ever, it should be possible to receive 921600 if i do a slim ISR, right ?
[05:34:10] <ThatDamnRanga> reset flag, process cmd
[05:34:14] <ThatDamnRanga> maybe
[05:34:21] <ThatDamnRanga> if you're efficient about your code
[05:34:25] <ThatDamnRanga> it's not just about the ISR
[05:34:36] <ThatDamnRanga> it's also about the code that checks if it is ready, etc
[05:34:51] <ThatDamnRanga> because you're going to have to cli() then sei() at some point while you're handling things
[05:35:23] <Palsson> But if i never get more than one command at a time, and never process the data until i've gotten a whole command, it should only be dependent on the ISR?
[05:35:39] <ThatDamnRanga> how are you going to know if you've got a full command, or only a partial?
[05:35:45] <Palsson> Or rather i never get a new command until i've processed the last command
[05:35:55] <ThatDamnRanga> and how will you know if you've sent the next command before you've finished processing?
[05:35:58] <Palsson> It consist of a length byte
[05:36:24] <Palsson> A new command will never come until i've sent a respons
[05:36:31] <Palsson> response*
[05:36:39] <ThatDamnRanga> sure, but what if one does?
[05:36:52] <ThatDamnRanga> i.e. the thing sending the command crashes before it gets a response
[05:36:56] <ThatDamnRanga> and has to be restarted
[05:38:34] <Palsson> The messages has CRC so sooner or later it will be recognized as a bad command.
[05:39:00] <Palsson> I have a very specific case where the person sending command will not send more than one command until they get a response
[05:39:09] <Palsson> So i don't have to handle those cases
[05:39:34] <ThatDamnRanga> okay
[05:39:42] <ThatDamnRanga> I would still recommend you /did/, but it's your code
[05:41:34] <Palsson> The thing is that i have a project that already works and solves these kind of things, i've been asked to maximize the baud and they hav e pretty slow ISR since they call some functions that is not inline and so on. So i basically wanna know if there is any need for me to try to achieve 921600 if we don't have hardware flow control.
[05:42:33] <ThatDamnRanga> you're going to have to optimise all the things to be honest
[05:42:39] <ThatDamnRanga> that's a pretty crazy baud rate
[05:42:45] <ThatDamnRanga> close to 1/8th the clock
[05:43:05] <ThatDamnRanga> you have to be able to recieve and process a byte roughly every eight clock cycles
[05:43:16] <Palsson> Yeah, that's what i'm worried about.
[05:44:50] <Palsson> So if i have a scenario where everything is processed only when a full command is received and i can assume that now command is going to be sent while i process a command. I should be able to optimise it alot. Just worried it's not gonna be enough.
[05:44:58] <Palsson> no*
[05:45:32] <ThatDamnRanga> depends how good your optimisation skills are
[05:46:02] <ThatDamnRanga> because you do have to account for clock cycles in checking if it is a full command, and if it is, memcpy()ing it to the variable to be processed
[05:46:02] <Palsson> Challenge accepted :D
[05:46:26] <ThatDamnRanga> working out how to save clock cycles can be a fun challenge :P
[05:47:06] <Palsson> Yeah, for sure, i'm not familiar with the instruction set of the atmega so i guess i better read up to see how comparisons are made fastest.
[05:50:24] <Palsson> ThatDamnRanga i have a rather interesting challenge connect to this project, the project is not made for avrgcc, it's made in a IDE that has it's own (worthless) compiler. So i can't really trust it's optimizations to be correct.
[05:50:38] <ThatDamnRanga> lol wow
[05:50:48] <ThatDamnRanga> BASCOM? xD
[05:51:46] <Palsson> ICCAVR
[05:52:16] <Palsson> It has all these cool features like entering both #ifdef and #else for some defines
[05:52:39] <ThatDamnRanga> I've never heard of it
[05:52:44] <Palsson> exactly!
[05:52:49] <ThatDamnRanga> if it isn't GCC, it can gtfo
[05:53:13] <Palsson> The IDE is Code::Blocks with their compiler and debugger.
[05:53:18] <Palsson> Worst IDE possible.
[05:53:21] <Palsson> kinda
[05:54:41] <Palsson> I think the guy that started the project was studying at a university and just tried that one out. Now we're stuck with it, i'm gonna convert it to avrgcc when i've got time.
[05:54:52] <Palsson> It does also cost money.
[05:56:06] <ThatDamnRanga> 'technical debt'
[05:57:16] <Palsson> For sure. "It's not working properly but at least it costs money" must have been the argument back in the day.
[05:57:35] <ThatDamnRanga> it's 'enterprisey'
[05:57:41] <ThatDamnRanga> because you can buy support for it :P\
[05:57:42] <Palsson> haha
[06:21:44] <Haohmaru> wat >:(
[06:21:50] <Haohmaru> i'm using Code::Blocks
[06:22:33] <Haohmaru> but with avrgcc (as well as sdcc, mplab xc8, mingw, etc..)
[06:30:31] <osteri> use qt creator, C::B is out of horror movie
[06:31:18] <Palsson> osteri are you using qt creator for avr ?:o
[06:31:38] <osteri> sometimes
[06:31:46] <Palsson> That was unexpected
[06:31:50] <Palsson> At least for me :D
[06:32:12] <Palsson> I like to use eclipse for everything that needs an IDE.
[06:33:05] <osteri> i don't really use IDE with AVR's because the projects are so simple
[06:34:12] <osteri> https://github.com/Osteri/avr-qt-template
[06:34:30] <osteri> that is quite bad template, has redundant files, but yeah
[06:34:37] <ThatDamnRanga> I think I'll just stick with studio personally :P
[06:34:46] <ThatDamnRanga> even if it is just Visual Studio 7 or whatever now
[06:35:00] <osteri> VS is actually very good IDE
[06:37:15] <Palsson> Dependent on what project i'm working on and whether i'm developing on my laptop or not at the moment is switch between OSX, Arch Linux and Windows so try to use IDE's that works for all of them.
[06:39:54] <osteri> you can always have .sln .creator files, best dev env is when IDE doesn't matter
[07:08:33] <LeoNerd> I want 16 GPIOs ideally in two neat clean 8bit ports, one SPI + one SS line, perhaps a UART, perhaps a couple more IO pins for buttons and the like. A mega328P doesn't -quite- have enough. Anyone any suggestions?
[07:09:02] <LeoNerd> My current plan is actually to note that my 16 main GPIOs are just low-speed sense lines so I was going to shove them out onto an MCP23S17 GPIO expander on SPI
[07:09:50] <LeoNerd> At which point all I'd need is the 3pin SPI port, two SSes, the UART, and some spare IO lines for buttons/LEDs, at which point even a little ATtiny can do that
[07:10:03] <LeoNerd> But that's two chips
[07:20:22] <sabor> LeoNerd: ATmega1284?
[07:22:47] <LeoNerd> Hmmmm, giant 40pin monster, but maybe that'd work yeah
[07:22:50] <sabor> or ATmega8515 or ATmega8535
[07:23:13] <sabor> bigger is better ;)
[07:33:17] <LeoNerd> mega644 also
[07:33:55] <LeoNerd> I wonder what's cheapest; I don't need much code space, RAM, any analog, fancy timers,...
[07:35:59] <LeoNerd> Ugh, £6 each
[07:36:23] <LeoNerd> I can get an ATtiny841 + MCP23S17 pair for half that
[07:37:41] <LeoNerd> In probably abnout the same board area, all told. Though board space isn't at a premium here as I'm driving an 8x8 LED matrix and lots of IO pins so there's lots of space
[08:09:09] <LeoNerd> Youknow it looks like I really can't beat the tiny841+MCP combo here. I might post to eevBlog forum and see what folks think
[08:40:21] <mrx1_> if I want to change baud rate of serial port later in runtime, do I have to do anything more than just change contents of UBRR register?
[08:40:32] <mrx1_> i.e. reinitialization of uart or something like this?
[08:41:34] <sabor> changing UBRR is enough
[08:41:57] <mrx1_> ok, thanks
[08:42:39] <LeoNerd> https://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart <== this is a really handy comparison chart of ATtiny chips. Does anyone know of a similar good one for ATmega?
[08:50:01] <Flutterbat> LeoNerd: you know the official comparision tool on atmels homepage?
[08:50:21] <LeoNerd> The parametric thing?
[08:50:23] <LeoNerd> Yah.. I just found that
[08:50:25] <Flutterbat> yeah
[08:52:56] <LeoNerd> Oooh.. The ATmega{4,8,16,32}PB series... that B makes them interesting
[08:53:02] <LeoNerd> They have a few more IO pins as compared the non-B
[08:54:04] <Flutterbat> isnt the atmega8 discontinued for ages?
[08:54:42] <LeoNerd> er.. {4,8,16,32}8PB even
[08:56:05] <Tom_itx> you'd think they would go away some day ehh?
[08:56:10] <Tom_itx> i keep hoping
[08:56:22] <LeoNerd> Ahh Isee
[08:57:20] <LeoNerd> The PB variants are basically the same as the P / PA, but they've added a 4-bit PE port, which gives it a few extra IO pins. The PE0/1 are where there used to be duplicate power pins, and PE2/3 are where the analog-only ADC6/7 were
[08:58:52] <LeoNerd> And also has a new pin called ACO; analog comparator output
[08:58:55] <LeoNerd> I wonder why you'd need that
[08:59:25] <Tom_itx> someone did
[09:00:19] <LeoNerd> Ugh... ATmega88PB is also around £6/chip
[09:00:39] <LeoNerd> Honestly I don't think I'm going to beat £2.20/chip pair for a tiny841 + MCP GPIO expander
[09:01:50] <Tom_itx> post your drawing here and this time next week they'll be for sale in china for $1 free shipping
[09:02:05] <LeoNerd> Hehehe
[09:02:21] <LeoNerd> Istill don't understand those LM27... mumble... chips. The buck-mode power converter
[09:02:47] <LeoNerd> The chips that sell for £3 each in bulk, or you can buy them on a board with the inductor/flyback diode/2xfilter caps for £2/board
[09:03:26] <LeoNerd> I'm actually pondering buying a bunch of boards and heatgunning the parts off that board, to mount them on my own board. Just because that's a bit neater than mounting it as a daughterboard
[09:05:42] <mrx1_> hmm... i'm experimenting with higher baud rates on uart, currently i'm on 1M. I can receive bytes on PC without any errors, but avr seems to not getting anything from pc
[09:05:46] <mrx1_> any ideas?
[09:06:26] <mrx1_> i'm using 16 MHz oscillator and datasheet states that at 1M baudrate there should be 0.0% errors
[09:06:50] <LeoNerd> 1M baud isn't a standard rate.. maybe the PC end is having troubles?
[09:07:08] <LeoNerd> I'd suggest applying LA to watch the lines
[09:07:46] <mrx1_> LA? if you mean osciloscope or something like this, i don't have it :)
[09:08:13] <mrx1_> standard multimeter only, but it won't help much with analyzing transmissions with 1M baud :)
[09:08:24] <sabor> maybe your code is too slow to handle all those bytes flying into the avr?
[09:08:32] <LeoNerd> Logic Analyser
[09:08:45] <LeoNerd> If you're doing any kind of digital logic you verymuch want one of those.. they're suuuuperhandy
[09:08:52] <mrx1_> sabor: for tests, I have only `echo code` (replay back to PC what avr got from it)
[09:09:05] <mrx1_> and it's completely not responding on that baud
[09:09:15] <rue_house> realize that the avrs hardware may be able to recieve characters at whatever speed you want, but that dosn't maen the code you have can deal with them as a stream of successive characters
[09:09:34] <sabor> mrx1_: on which baudrates is it responding?
[09:10:16] <rue_house> or set up a flag in your code, so the character recieve interrupt can turn an led on if the main loop hasn't finished dealing with the last recieved character
[09:10:19] <mrx1_> 38400, it was my basic baud before any optimizations, i have complex communications both ways on this baudrate
[09:11:04] <mrx1_> rue_house: as I said, currently receiving interrupt just sends that character back to PC
[09:11:20] <rue_house> I was in the shower
[09:11:39] <Tom_itx> with who?
[09:11:53] <rue_house> just I, me, and myself
[09:12:42] <rue_house> Tom_itx, are we sure the red/pink string thing acutally happened? I'm going thru the logs,
[09:13:09] <rue_house> kat is slowing down on progress on the cnc drill, but there has been nothing critisizing about anything
[09:13:46] <rue_house> katsmouw:well, you missed out on the avi i made then
[09:13:53] <rue_house> 2006-11-08.html
[09:13:58] <rue_house> Nov 2006, I'm close
[09:19:16] <mrx1_> sabor: ok, my mistake, my echo code wasn't called properly
[09:19:23] <mrx1_> now it works and avr responds properly
[09:28:04] <rue_house> now you just need code that can deal with the characters within 1us
[09:28:14] <rue_house> er, 10us
[09:28:22] * rue_house tries to wake up
[09:28:47] <mrx1_> rue_house: actually, avr is only sending data with that speed
[09:29:03] <rue_house> ah
[09:29:06] <mrx1_> i think that pc will be able to handle this, or at least buffer it in ram
[09:29:34] <rue_house> unless its using a microsoft thread manager, I'm sure it can
[09:30:33] <mrx1_> i'm currently transmitting some long strings to my app / putty and no errors so far, of course my real transmission has crc32, so we will see
[09:31:06] <mrx1_> but 1M should be feasible, people on forums achieve 2M
[09:32:21] <rue_house> /character, sure
[09:41:41] <LeoNerd> Huh. Seems my original research sucked. I can get a mega48PB on mouser.co.uk for £1.10/chip. Which is about the price of the tiny *or* the MCP chip, whereI'd need one of each. So maybe this is best after all
[09:42:25] <LeoNerd> ...plus £12 delivery charge. Bah.
[09:43:01] <rue_house> the arduino pro mini is a mega328 on a board with a votlage regulator, reset pullup resistor, crystal osc, programming header, for $1.50ea free shipping
[09:43:29] <rue_house> in wide dip format
[09:44:05] <rue_house> get the ones with the dual row of pins on one end
[09:44:29] <LeoNerd> The 328P doesn't *quite* have enough IO pins for me
[09:45:10] <LeoNerd> I need 2x8 "clear run" GPIO ports, plus the three SPI and an SS for it, a UART, and a few odd pins for LEDs/buttons. The 328P comes a few short
[09:45:11] <rue_house> k, if you dont mind adding usb, the larger arduios still dont cost much
[09:45:24] <LeoNerd> The PB variants are juuuust big enough for me, with those four new PE pins
[09:45:33] <rue_house> how many leds and buttons do you have?
[09:46:30] <LeoNerd> Mm.. "as many as I can get away with" ;) I can analogmux a few buttons on a single ADC input pin, and I can charlieplex LED outputs, so I don't need too many of those
[09:46:55] <rue_house> hmm, well, that would be all my suggestions
[09:46:59] <rue_house> 9 leds on 3 io
[09:47:09] <LeoNerd> A 328P has 8 + 8 + 6 IO pins total, though. So once I've taken away the 16 raw GPIOs, 4 SPI and 2 UART pins, Ihave... preceicely zero spare
[09:47:15] <rue_house> I dont know I'd go past 16 buttons on an adc pin
[09:47:15] <LeoNerd> 6 LEDs
[09:47:28] <LeoNerd> Hah; I don't think I'd need anywhere near 16. Probably 3 or 4 buttons is sufficient
[09:47:38] <rue_house> charlieplex... right 6
[09:48:23] <LeoNerd> If I was really that short on LEDs I'd just use one more GPIO pin as another SS line for a 74'595 with LEDs on
[09:48:34] <LeoNerd> ... actually most projects of mine end up sprouting a 595 to drive LEDs anyway :)
[09:49:06] <LeoNerd> The SPI port is intended to drive a MAX7219 with an 8x8 LED matrix on it, so even more LEDs over SPI is easy
[09:49:12] <LeoNerd> ... actually I should just stick the '595 on the end of that
[09:49:17] <LeoNerd> zero extra pins :)
[09:50:06] <rue_house> http://ruemohr.org/~ircjunk/projects/wallclock/p1070508.jpg
[09:50:13] <mrx1_> rue_house: lol, just for the lulz i changed whole protocol to use baud 1M (and it's based on circular buffer, custom headers and crc32)
[09:50:16] <mrx1_> rue_house: and it works
[09:50:18] <rue_house> the drivers didn't have base resistors, SURPRISE!
[09:50:53] <mrx1_> so avr can process that characters quite fast, but it's thanks to clever design of my protocol :) because crc32 is checked at the end of processing whole frame
[09:51:17] <rue_house> cool stuff, datalogger?
[09:51:46] <mrx1_> yep
[09:51:53] <rue_house> http://ruemohr.org/~ircjunk/projects/wallclock/p1070506.jpg
[09:52:19] <rue_house> http://ruemohr.org/~ircjunk/projects/wallclock/p1070511.jpg
[09:53:37] <Flutterbat> LeoNerd: shiftregisters :x
[09:54:12] <LeoNerd> Flutterbat: Yes, but that's more chips
[09:54:24] <Flutterbat> makes it look better
[09:54:31] <LeoNerd> If I wanted a multichip solution I've already got the MCU + GPIOexpander
[09:54:37] <rue_house> I used nonstrobing display on the clock...
[09:54:39] <LeoNerd> Other ways to slice that don't help it
[10:20:39] <mrx1_> rue_house: now I have whole protocol running at 2M baud
[10:21:43] <mrx1_> and datasheet was right, there are no binary errors (every frame has crc32 and i would see on PC if there were retry attempts, and there are none so far)
[13:50:24] <ackpacket> When we talk about an in system programmer, is the intention literally to reprogram a chip without removing it from the system?
[13:50:54] <ackpacket> If so, how do we avoid powering up the circuit and making it do things it's not intended to do, when toggling the pins on the avr and applying power to vcc?
[13:51:51] <ackpacket> Might crosspost into #electronics, fyi
[13:53:58] <LeoNerd> You generally don't worry about that kind of thing
[13:54:10] <LeoNerd> If that would be a problem, then you don't want to do ICSP like that
[14:20:52] <Casper> ackpacket: one way is to make sure that the stuff connected to those pins won't cause issues
[14:21:03] <Casper> like you can use those pins for leds
[14:21:23] <LeoNerd> AVR pins all go to hiZ mode in ICSP also, so you can take advantage of that
[14:21:25] <Casper> so you don't really care if they go crazy, it won't do anything bad
[14:21:40] <ackpacket> Casper: I figured that might be the case, was just wondering if I was misunderstanding
[14:21:42] <LeoNerd> E.g. SS lines or similar of attached SPI devices can just be pulled high by a moderate pullup resistor
[14:21:49] <LeoNerd> So then everything will ignore you
[14:22:13] <ackpacket> Is my code 100% safe on an avr?
[14:22:33] <LeoNerd> Since ICSP operates over the SPI port anyway on most devices, it's likely that will be fine. Usually you'd have other SPI devices on the board attached there
[14:22:44] <LeoNerd> Without an asserted SS line they'll just sit idle and aaaalll will be fine
[14:23:01] <LeoNerd> Safe? Safe from what?
[14:23:03] <Casper> you mean undumpable? if you set the lockbit right, then it can't be read in the normal way
[14:23:13] <ackpacket> Casper: yes, that
[14:23:19] <ackpacket> LeoNerd: from people trying to examine it
[14:23:25] <LeoNerd> Eh.. a sufficiently determined attacker can always get at it somehow
[14:23:43] <Casper> however, considering that they can clone hightly securised chip by uncaping them and plugging wires inside... then 100% is no
[14:23:49] <LeoNerd> Yeah, that
[14:24:18] <LeoNerd> Pick a number of zeroes on the budget your hypothetical attacker would have to spend
[14:24:18] <ackpacket> Casper: uncaping and plugging wires inside is sufficient to clone?
[14:24:40] <Casper> it's flash memory
[14:24:43] <LeoNerd> Sure. If you decap the chip you can just connect a new flash controller directly onto the memory
[14:24:47] <LeoNerd> Then you can just read it out
[14:24:59] <LeoNerd> That's not a *cheap* or easy thing to do, however...
[14:25:01] <Casper> just need to cut them from the uC then connect and read the data
[14:25:34] <LeoNerd> Who are you trying to defend your code against, and how much do you think they'd want to spend obtaining it?
[14:25:39] <Casper> YAY! my glasses from zenioptical got finally shipped! whoot!
[14:27:37] <Casper> so might be here before xmas
[14:32:15] <ackpacket> You know, while I'm not a fan of the abstraction on an arduino, I do like that I can buy a board already setup with some USB debugging/serial capabilities, built in programmer, etc. Is there something like that for the avr? But where the code is written in just c?
[14:32:54] <LeoNerd> You can just use arduino boards
[14:33:07] <LeoNerd> Hardware-wise, it's just a mega328 or 32U4 or whatever, mounted on a convenient breakout board
[14:33:13] <LeoNerd> I use them all the time, but write my own C code for them
[14:33:30] <ackpacket> They're not doing anything fancy with the usb? avrstudio can use it just fine?
[14:33:48] <LeoNerd> So, the 32U4-based boards connect the USB port /directly/ to the AVR chip, so that's all fine
[14:34:05] <LeoNerd> Any of the USB-offloaded boards are just using some standard USB-UART bridge connected to the chip's UART pins
[14:34:13] <LeoNerd> avrdude et.al. can talk to that just fine
[14:34:17] <ackpacket> if the port is directly connected to the chip, where does the ISP logic come in?
[14:34:33] <LeoNerd> Additionally, you'll find almost all Arduino boards come with ISP headers as well.. that's what I usually use
[14:34:40] <LeoNerd> Then I can use the onboard UART directly as a debugging console
[14:35:15] <LeoNerd> ISP is a native ability of the hardware chip directly
[14:35:16] <Casper> arduino come with a bootloader
[14:35:36] <Casper> which might be usb enabled, or use the usb-uart
[14:35:38] <LeoNerd> Yes - the chip on the Arduino boards is preprogrammed with the bootloader, but usually I just vape that and do ISP instead
[14:35:45] <LeoNerd> Then I get instant startup time :)
[14:36:27] <Casper> now, I'm stuck at work, with no job left to do... what shall I do in the next 4 hours?
[14:36:37] <ackpacket> LeoNerd: What do you mean ISP is a native ability of the chip directly? At what point does the data coming out of the usb port get turned into serial data?
[14:36:53] <LeoNerd> One tiny word of warning: there is an Arduino board that tries to be pinout-compatible with the mini/nano arrangements but is based on a 32U4 chip, called the Arduino Micro. This is a /terrible/ board. You don't get access to about 4 of the 32U4's IO pins, and the remaining ones that are, are mapped in a /bizarrely/ odd way to the ports on the board
[14:37:11] <LeoNerd> Adafruit make a very nice 32U4 breakout board.. I have one of those. much nicer, though it does cost £18
[14:37:27] <LeoNerd> ackpacket: ISP isn't done over USB, it's done over a 2x3 header that carries power and an SPI-like signal
[14:37:46] <LeoNerd> You talk to that via some USB-ISP adapter; you can get those for like £5 off eBay/Amazon
[14:37:52] <ackpacket> LeoNerd: then again I ask how a chip get's programmed when it's connected directly to the usb port lol
[14:38:01] <LeoNerd> You don't. :) unless it's a 32U4 chip
[14:38:24] <LeoNerd> That's where you usually get an ISP adapter. You should get one if you're intending to do any kind of serious AVR developemnt. They're dirtcheap
[14:40:23] <osteri> arduino doesn't offer schematics, which you might want. i think there is a teensy board with 32u4, i would buy that instead
[14:40:44] <osteri> and afaik arduino gives only bootloader.hex
[14:40:51] <osteri> not the source
[14:40:54] <LeoNerd> Ohyeah... it took me a lot of effort to find the actual board schematic for the micro
[14:41:04] <LeoNerd> so I could translate device pin names into weenie numbers
[14:41:14] <LeoNerd> I think they just rolled a dice to invent that mapping
[14:41:38] <LeoNerd> The Adafruit board is nicely labeled with the actual device pin names, so no confusion there.
[14:42:03] <osteri> so basically arduino doesn't contribute anything to the open source, all the thing they have implemented are closed source ;)
[14:42:21] <LeoNerd> Oh, I did find it eventually. was just some work ;)
[14:43:23] <osteri> i could find for my leonardo
[14:43:34] <LeoNerd> Hah.. those things are huge though
[14:43:47] <osteri> couldn't
[14:43:49] <osteri> *
