Back
[00:01:50] <anonnumberanon> You don't make it easy for Arduino people to evolve into Avr only people.
[00:04:07] <_ami_> anonnumberanon: yes, arduino ide annoys me :)
[00:04:28] <_ami_> https://github.com/amitesh-singh/amiduino/tree/master/avr/ami-arduino-cmake
[00:04:44] <_ami_> i able to compile arduino lib for Arduino Uno architecture.
[00:04:58] <_ami_> trying to make things work for Atmega16A
[00:05:28] <_ami_> Casper: :)
[00:05:33] <anonnumberanon> lol
[00:05:37] <anonnumberanon> you must be crazy
[00:05:47] <_ami_> yeah :) crazy :D
[00:06:49] <_ami_> anonnumberanon: took me atleast 4 hrs to setup that. did that few days back!
[00:06:54] <_ami_> it was tiring.
[00:07:07] <anonnumberanon> oh, then didn't waste too much time!
[00:07:11] <_ami_> probably i need to understand how arduino ide compiles things internally.
[00:07:56] <_ami_> anonnumberanon: i hate arduino ide. but i think arduino libs are cool? :) there are so many actually. :)
[00:08:14] <anonnumberanon> im the opposite haha
[00:08:38] <_ami_> btw, i just started learning avr programming. mugging that "make: avr programming" these days :)
[00:08:44] <anonnumberanon> the libs are cool, yes, to some extent, but I always end up having to learn the science behind it to do serious things
[00:08:52] <_ami_> True!
[00:08:52] <_ami_> :)
[00:08:53] <anonnumberanon> but the IDE is pretty good for me
[00:09:38] <anonnumberanon> I don't need to start using the command line right now to compile each program.
[00:09:47] <anonnumberanon> and send it...
[00:10:41] <anonnumberanon> I'll try doing that after I'm done solving actual scientific problems.
[00:11:10] <anonnumberanon> Or..more like engineering problems.
[00:17:58] <_ami_> anonnumberanon: i will share the results if i able to solve :)
[00:18:14] <_ami_> although it seems like some macro definitions i need to pass to avr-gcc
[00:18:28] <_ami_> probably -D_AVR_Atmega16A_
[00:18:32] <_ami_> to avr-gcc
[00:18:57] <anonnumberanon> _ami_, good luck!
[00:19:23] <anonnumberanon> I'm making a biped robot. That's why I need a good clock on my chip.
[00:20:08] <_ami_> cool! :)
[00:21:28] <anonnumberanon> I'll show you a video of it if you want.
[00:21:47] <_ami_> love to see it. on youtube?
[00:22:25] <anonnumberanon> yeah
[00:22:29] <anonnumberanon> lemme get
[00:23:05] <anonnumberanon> https://www.youtube.com/watch?v=JQdXDg9PtzY
[00:29:13] <flyback> Casper, BMCC
[00:31:29] <Casper> hell low flyback
[00:32:37] <flyback> hi
[01:26:35] <_ami_> anonnumberanon: it turns out that SoftwareSerial library is dependent on Pin change interrupts and Atmega16A does not have support PCINTs
[01:27:01] <_ami_> i unchecked softwareserial lib for atmega16A
[01:27:05] <_ami_> it works well ;)
[01:27:31] <_ami_> although i need to check the binary on target ;)
[01:27:38] <cehteh> huh i didnt know that any AVR has no pcints
[01:28:01] <_ami_> cehteh: it does not have. check
http://www.atmel.com/images/atmel-8154-8-bit-avr-atmega16a_datasheet%20summary.pdf page no. 8
[01:28:18] <cehteh> does it have a input capture unit?
[01:28:36] <cehteh> yes it has
[01:28:52] <_ami_> cehteh: which register value signifies that?
[01:29:10] <cehteh> using capture instead pinchange is often the better alterative, but iirc capture can only trigger on one edge
[01:29:39] <_ami_> cehteh: GICR?
[01:29:57] <cehteh> read timer1 docs
[01:30:11] <cehteh> aaand you have a usart, why softserial
[01:30:33] <cehteh> and 3 INT sources
[01:30:42] <cehteh> thats better than PCINT too
[01:31:10] <_ami_> INT* are external interrupts
[01:31:13] <_ami_> but can be used
[01:31:38] <_ami_> do u think SoftwareSerial library should use INT* if PCINT* are not supported?
[01:31:45] <_ami_> i think it should support.
[01:32:04] <cehteh> when it works, yes
[01:33:28] <cehteh> actually INT's are more powerful than PCINT because you can select which edges trigger and some are able to wake the µC from deeper sleep
[01:34:32] <cehteh> input capture may not work for softserial since you can only tryigger on one edge, but mhm .. i havent tried but it should be possible to flip the edge bit on interrupt
[01:34:52] <cehteh> then it might do for softserial too
[01:35:37] * _ami_ remembers quotes from a x86 asm book. " interrupts are like SOS call to superman for rescue help ;) ~
[01:35:48] <cehteh> lol
[01:36:18] <cehteh> actually i prefer hardware capabilities and interrupts over software implementations
[01:36:44] <cehteh> never used softserial
[01:37:05] <_ami_> i used once just for testing
[01:37:09] <cehteh> when you need more than one serial then pick a avr with more usarts
[01:37:22] <_ami_> ya!
[01:40:47] <_ami_> can't wait to finish this book. "Make: Avr programming". it has a chapter on hardware interrupts. nice!
[01:41:05] <_ami_> don't get much time to read because of daily office job etcs :/
[01:41:27] <cehteh> heh
[01:41:36] <cehteh> i only read datasheets :D
[01:42:25] <_ami_> cehteh: you might have studied MCUs during graduation :)
[01:42:37] <cehteh> no
[01:43:34] <cehteh> btw i wonder why you put so much efforts into cmake for arduino
[01:43:48] <cehteh> there are some plain makefile projects around arduino
[01:43:55] <cehteh> these work
[01:44:08] <_ami_> cehteh: i want to mix AVR and Arduino SDK together. :)
[01:44:17] <_ami_> and i am a command line guy
[01:44:27] <cehteh> but then again its only arduino, ok for some quick'n'dirty tasks but for more serious stuff you want to use something else
[01:44:52] <cehteh> not a good idea about that mixing
[01:45:18] <cehteh> i may rip out some drivers and arduino code for my mµOS ... but mixing, no interest
[01:45:50] <_ami_> may be i realize this mistake later :)
[01:45:55] <cehteh> many arduino libs have some C+ bloat and doubtful quality .. and the better ones are most likey derrived from some plain AVR lib alerady
[01:46:27] <cehteh> arduino/wireing does too much things in a too obscure unfriendly way
[01:46:55] <cehteh> n00b friendly, but not flexible/generic/resource conserving and robust
[01:47:17] <cehteh> see the constant abuse of floats :D
[01:47:37] <cehteh> low level libs return floats when there is no need for that
[01:47:59] <cehteh> (reading sensors which produce integers anyway)
[01:48:30] <_ami_> ah! its bad then.
[01:48:50] <_ami_> raise patches then. they will listen. :)
[01:48:52] <cehteh> thats only one thing
[01:48:59] <cehteh> patches to what?
[01:49:23] <cehteh> i am doing my own thing and pick up things that work when possible
[01:50:01] <cehteh> for examle the float return: there is a library for one wire temperature sensors in arduino which returns floats
[01:50:05] <_ami_> patches to Arduino core lib
[01:50:24] <cehteh> i just used the bare onewire lib and made my own temperature sensor functions on top
[01:50:59] <cehteh> i tihnk in that respect arduino is broken beyond repair, they intentionally want it this way, patches wont get heared
[01:51:18] <cehteh> because its made to be easy for beginners, not resource friendly or robust
[01:51:34] <_ami_> :)
[01:51:56] <cehteh> and also such patches would break existing software
[01:52:29] <_ami_> Yup. won't be backward compatible.
[01:52:39] <_ami_> thats one problem though
[01:52:46] <cehteh> bad design .. or rather different goals, arduino works for what it was intended for
[01:53:04] <cehteh> giving non programmers and artists something easy to use to make some leds blink
[01:53:30] <cehteh> its ok for that
[01:53:53] <_ami_> :)
[01:54:40] <_ami_> btw, i can see your creation.
https://github.com/cehteh/muOS
[01:57:21] <_ami_> it compiles
[01:58:59] <cehteh> the github isnt the primary repository, i only push there once a while
[01:59:34] <cehteh> but currently i am working on the documentation system, being back on it soonish
[02:05:35] <cehteh> added a description there pointing to upstream
[02:05:58] <cehteh> can one make github to sync automatically from a upstream repository?
[02:07:37] <_ami_> you can.
[02:08:24] <_ami_> Add two remotes and respective local branches
[02:08:58] <_ami_> and merge one (your working remote) to another (github)
[02:10:27] <_ami_> e.g.
[02:10:52] <_ami_> git remote add gb
http://github.com/../
[02:10:55] <_ami_> git fetch gb
[02:11:49] <_ami_> git remove add dev
http://something.com/...
[02:12:00] <_ami_> remote*
[02:12:47] <cehteh> mhm?
[02:13:34] <cehteh> how does that make github syncing automatically?
[02:13:57] <_ami_> git merge ?
[02:13:59] <cehteh> or rather when i add a remote here, github doesnt know that, remotes are local
[02:14:05] <cehteh> automatically
[02:14:10] <_ami_> need to write a script which does that for you?
[02:14:11] <cehteh> i know how to merge
[02:14:28] <_ami_> is there any git commit post script for that?
[02:14:30] <cehteh> i want github poll my server merging automatically
[02:14:43] <cehteh> yes i can do that
[02:14:55] <cehteh> just wonder about the other way around
[02:15:24] <_ami_> cron job?
[02:15:28] <cehteh> maybe i can add a hook to my server
[02:15:56] <cehteh> but actually i didnt wanted to put efforts into supporting github :D
[02:16:20] <_ami_> what git management server u run locally?
[02:16:24] <_ami_> gitosis?
[02:16:26] <cehteh> none
[02:17:19] <cehteh> makes no sense for one user :D
[02:17:28] <_ami_> yeha
[02:17:31] <_ami_> :)
[03:34:15] <skz81> <anonnumberanon> Is Arduino incompatible with changing the prescaler? I'm debugging my timer interrupt program. Just won't do what I want. >> If you use timing methods of API (delay(), millis() and micros() and delayMicroseconds()) => You should not mess with timer0, even prescaling
[03:35:59] <anonnumberanon> skz81, That's interesting that you say that because I've been stuck at 2.5us with timer 0. Trying timer 2 may reduce that. Can you explain why I shouldn't mess with timer 0? I use no Arduino functions or libraries btw.
[03:36:36] <anonnumberanon> Writing my own better micros().
[03:37:50] <skz81> You will get wrong result or even unpredictable behaviour if mixing both. But If using home-brew function for timing, it should be OK :)
[03:39:30] <skz81> I have a doubt on what happend to ISR vector, that said. Arduino declares one, at least, for timer0... But if you have no conflict error at link time, I guess it is "dropped" and yours is linked instead.
[03:40:34] <anonnumberanon> I don't care what Arduino uses it with but I think something like attachinterrupt() or something
[03:41:31] <cehteh> timers in arduino are screwed :D
[03:42:29] <cehteh> but you may look at the source, its certainly bound to the prescaler somehow, i never looked at the details
[03:43:04] <skz81> _ami_, have a look on this, it may help you :
https://github.com/sudar/Arduino-Makefile/blob/master/Arduino.mk
[03:43:44] <skz81> BTW, I would have guess that passing -mmcu=atmega16 would imply -D_AVR_Atmega16A_ "automagically"
[03:44:30] <anonnumberanon> Do you know how to get a better method to time things accurately than Arduino micros()? It does 4 us time steps and I can do 2.5 us time steps already so that's better but I'm looking to achieve 1us.
[03:45:48] <anonnumberanon> I'm using prescaler 1 already that's why I'm kind of weirded out by this.
[03:46:19] <anonnumberanon> My timesteps should be about 0.5 us right now.
[03:46:52] <cehteh> mµOS can run timers at prescaler /1 .. ticks are 0.0625µs then, of course querying the timer takes longer but you can get few µs accuracy
[03:47:15] <anonnumberanon> I am at few us though already.
[03:47:15] <cehteh> (@16MHz)
[03:47:51] <anonnumberanon> I wonder if I could do better using assembly.
[03:47:58] <anonnumberanon> I've never done it.
[03:48:01] <cehteh> possibly
[03:48:05] <skz81> anonnumberanon, you can dedicate timer1 (16bit) for that.
[03:48:07] <cehteh> but what do you want to do?
[03:48:17] <cehteh> i mean a single instruction takes a tick then
[03:48:52] <cehteh> even when you can query the timer that fast, you possibly need to get some things done too
[03:49:11] <skz81> Set it running, at TOP call an ISR to increment a "hi-weigth" counter.
[03:49:45] <skz81> When calling micros() equivalent, result is hi_counter << 16 + TCNT1
[03:49:47] <cehteh> that works even with a 8bit counter .. but you get a lot interrupt load at /1 prescaler
[03:50:10] <cehteh> and dont forget that you need to handle race conditions on querying the counter
[03:50:22] <skz81> calling an ISR take a lot of CPU cycle, sadly
[03:50:46] <cehteh> you can make naked ISR's for that, they are a bit faster
[03:55:47] <anonnumberanon> <anonnumberanon> skz81, Can you say more about "hi-weight" counters? I understand the rest.
[03:55:48] <anonnumberanon> <anonnumberanon> Gonna look into this guy's work
http://www.electricrcaircraftguy.com/2014/02/Timer2Counter-more-precise-Arduino-micros-function.html
[03:55:49] <anonnumberanon> <anonnumberanon> 0.5us
[03:55:50] <anonnumberanon> disconnected..
[03:56:35] <cehteh> just have a "volatile uint16_t counter;" outside
[03:56:56] <anonnumberanon> sigh ah okay...I have that
[03:56:57] <cehteh> and ISR(TIM0_OVR) {++counter;}
[03:57:38] <anonnumberanon> That's what I have. It's not enough to make it fast.
[03:57:47] <skz81> anonnumberanon, cehteh has well summarized my idea :)
[03:58:04] <cehteh> querying it is a bit tricks
[03:58:08] <anonnumberanon> Instead of incrementing the counter I just turn on a pin and then look at that pin on the oscilloscope.
[03:58:12] <cehteh> tricky
[03:58:28] <cehteh> hi_counter << 16 + TCNT1 is not enough, because its racy
[03:59:17] <anonnumberanon> That is a line I didnt understand either. I know TCNT1 but
[03:59:28] <cehteh> and querying from inside interrupts need to include the timer overflow bit (i have a pending bug there too iirc)
[04:00:32] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/clock.h;h=bdd804445eb5a5fcdb7c6ab1c904b59c0d7192c8;hb=refs/heads/doc
[04:01:16] <cehteh> one could disable interrupts while reading .. i just read twice in case of overflow (happens rarely)
[04:02:05] <cehteh> that adds a bit on the time when querying the timer
[04:02:10] <cehteh> but correctness first :D
[04:02:26] <skz81> cehteh, yes your right, was not thinking of it.. I would try to detect overflow to "compensate" hi_counter value, I guess.
[04:02:58] <cehteh> as i saied there is another problem i havent addressed yet...
[04:03:00] <skz81> rather than cli()
[04:03:31] <cehteh> when you query the time while interrupts are disabled (inside cli() blocks or inside other interrupt handlers)
[04:04:07] <cehteh> a overflow my have occured, but the overflow interrupt incrementing counter hasnt been called yet
[04:04:22] <skz81> ha, because you can't detect the overflow in those case ? Or something else ?
[04:04:30] <cehteh> for that you have to add the timers overflow bit to your calculation as well
[04:04:44] <cehteh> basically any timer has a bit more than adverzized :D
[04:04:59] <cehteh> 8 bit timers are really 9 bit and 16 bit are 17 bit :)
[04:06:00] <skz81> So this is the exact same problem, with the exact same solution : detect overflow to "compensate" hi_counter value
[04:06:07] <cehteh> no
[04:06:18] <skz81> ha ?
[04:06:33] <anonnumberanon> Huh.. I just gained 500 ns by enclosing the ISR in cli/sei.
[04:06:40] <cehteh> one is the race condition in hi_counter << 16 + TCNT1
[04:07:07] <cehteh> the other is interrupts disabled and thus there was a overflow not handled yet
[04:08:22] <cehteh> imagine your high counter is 10 and TCNT1 is 65535 ... now the compiler may first read TCNT or first read hi_counter, order isnt defined in C
[04:09:03] <cehteh> at that instant TCNT overflows .. and, if interrupts are enabled, calls the interrupt and increments hi_counter
[04:10:06] <cehteh> but if you read tcnt at 65535 .. overflow.. then hi_count at 11 you get the wrong value
[04:10:22] <skz81> Hey, don't write hi_counter << 16 + TCNT1 AS IS and compile it.... It's only the wanted result... If read order controlled => Then overflow bit is enough I believe (may be wrong, did n't try it)
[04:10:29] <cehteh> if you disabled interrupts you still get the wrong value
[04:10:47] <_abc_> Hello, does anyone know if avrdude still requires a patch to work with PCI io cards, as seen in this 2008 posting?
https://www.mail-archive.com/avrdude-dev@nongnu.org/msg01566.html ... I have a system with linux and a PCI io card recognized as parport0 at 0x400 but avrdude does not see it when invoked with parport0 (can't open port)
[04:11:20] <_abc_> The manual is not clear on this at all.
[04:11:55] <cehteh> skz81: iirc thats not enough
[04:12:15] <anonnumberanon> Actually never ask my code to read tcnt. I do however set it to 248 right after it overflows (at 255).
[04:12:30] <cehteh> because you only shift the race condition to reading overflow bit vs reading the timers value
[04:13:10] <cehteh> reading overflow bit may result in 0, then overflow happens, then reading tcnt
[04:13:40] <cehteh> as i saied, things get somewhat tricky in corner cases there
[04:13:51] <_abc_> So, anyone, please, PCI io cards and avrdude?
[04:14:00] <cehteh> _abc_: just try it
[04:14:12] <cehteh> i dont know
[04:14:30] <cehteh> anonnumberanon: why do you set tcnt?
[04:14:40] <_abc_> It does not work. Please follow my posts before answering. I spent some time on it before asking, including googling. Do I have to read avrdude sources to see what is going on?
[04:14:50] <cehteh> that completely wrecks your timing
[04:15:10] <skz81> cehteh, ok, I trust you. Sounds like an intresting challenge finally :)
[04:15:36] <anonnumberanon> That was the only way that I found to let the timer tick only about 16 times (15 * 62 ns at /1 prescaler == 1 microseconds) until it overflows and throws an interrupt.
[04:15:48] <cehteh> _abc_: as is saied, i dont know, i am not on windows and it works for me do i never needed to care
[04:16:06] <cehteh> anonnumberanon: sounds very wrong to me
[04:16:17] <_abc_> I never said windows, I said and implied linux.
[04:16:22] <cehteh> besides your interrupt might be delayed
[04:16:39] <skz81> anonnumberanon, Fast PWM (reset on OC match), OCRxn = value,
[04:16:46] <cehteh> still dunno
[04:16:49] <skz81> nope i'm wrong
[04:16:54] <anonnumberanon> cehteh, well i also tried the timer compare way but that was worse
[04:17:05] <cehteh> then you doing something wrong :D
[04:17:25] <cehteh> but getting high speed timers correct has its issues
[04:17:41] <cehteh> either way: never ever touch a running timer
[04:17:53] <skz81> anonnumberanon, CTC mode (toggling), OCRxn = value
[04:18:19] <cehteh> anonnumberanon: still for millis or some wakeup thing?
[04:18:23] <skz81> will toggle you pin each value (prescaled) cycle
[04:18:24] <cehteh> (micros)
[04:20:06] <cehteh> muOS uses compare match for wakeups, main loop schedules a comparematch when nothing is to do and goes to sleep, but for very short time (the time it would take to setup the comparematch) it does a busy wait instead
[04:20:08] <anonnumberanon> no it's not for sleeping or wakeup I don't know about that stuff
[04:20:18] <cehteh> otherwise it would miss the comparematch
[04:21:16] <_ami_> skz81: thanks but i solved my problem.
[04:21:27] <anonnumberanon> It's for the clock of my robot's real time .
[04:21:55] <cehteh> just keep it spinning, never change prescaler, TCNT etc once you started it
[04:22:18] <_ami_> skz81: Software Serial lib is not gonna work on Atmega16A since it does not have PCINTs
[04:22:31] <anonnumberanon> So only read it. Okay. Now I'm not sure what skz81 meant above.
[04:22:48] <cehteh> thats really a nono .. when you have some clock drift (aka realtime) then better compensate that otherwise along that
[04:24:13] <anonnumberanon> It works better than anything else so far, though.
[04:24:42] <anonnumberanon> And there is a dimension in this that I cannot see yet.
[04:25:08] <cehteh> i dont get it :)
[04:25:24] <anonnumberanon> this doesn't have ISR:
http://git.pipapo.org/?p=muos;a=blob;f=src/muos/clock.h;h=bdd804445eb5a5fcdb7c6ab1c904b59c0d7192c8;hb=refs/heads/doc
[04:25:50] <cehteh> thats just querying the clock
[04:25:56] <cehteh> the ISR is somewhere else
[04:26:28] <cehteh> ISR is just ++muos_clock_count_;
[04:26:34] <cehteh> nothing else
[04:26:40] <anonnumberanon> download all files, do a large grep
[04:27:28] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/hw/atmel/clock.c;h=dd3957bf882b4a6df0fbe09fd715e7904103fe86;hb=9db3468e9828c60dc331972d9a81a16a94b6b24d#l28
[04:27:36] <cehteh> some debugging led blinking along :D
[04:27:44] <anonnumberanon> I found it.
[04:27:49] <anonnumberanon> Oh you too?
[04:28:53] <cehteh> of course
[04:29:40] <cehteh> http://public.pipapo.org/pulseview2.png
[04:30:10] <anonnumberanon> Okay I don't see anything special in this.
[04:30:11] <cehteh> channel 3 are these overflows
[04:30:21] <anonnumberanon> in the .c
[04:30:38] <cehteh> channel 2 are the mainloop wakeups, you see the compmatch there too
[04:31:01] <cehteh> channel 5 is a led blinking at 0.5hz or so
[04:31:07] <cehteh> err 2hz
[04:31:35] <cehteh> the first file was the interesting part where it queries the timers
[04:31:54] <cehteh> (still missing the overflow bit, i have a note there to fix that)
[04:31:54] <anonnumberanon> the c file or what?
[04:31:59] <cehteh> yes
[04:32:16] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/clock.h;h=bdd804445eb5a5fcdb7c6ab1c904b59c0d7192c8;hb=refs/heads/doc#l64
[04:32:26] <cehteh> the muos_clock_now() functions etc
[04:36:09] <anonnumberanon> Can't find anything that would help a noob like me.
[04:36:38] <cehteh> what are you trying to do?
[04:36:48] <cehteh> generating servo signals?
[04:36:54] <anonnumberanon> yeah
[04:37:06] <cehteh> didnt we talked about that some days ago?
[04:37:23] <cehteh> dunno if it was you
[04:37:23] <anonnumberanon> I've never talked to you before.
[04:37:36] <cehteh> ok someone else came here with the same thing
[04:37:50] <cehteh> how many servos?
[04:38:12] <anonnumberanon> more than 17 would be great
[04:38:23] <cehteh> thats really tricky
[04:38:28] <anonnumberanon> ebay sells boards that do 32
[04:38:45] <cehteh> have you considered to add a dedicated pwm controller IC to each servo
[04:38:46] <anonnumberanon> not sure what processor pretty sure Arm Cortex
[04:39:04] <cehteh> and then talk to this controllers via i2c spi or whatever?
[04:39:21] <anonnumberanon> Yes I have considered that.
[04:39:27] <cehteh> or some attiny85 or so
[04:39:44] <anonnumberanon> But that makes it less portable as a solution for robot enthusiasts.
[04:39:45] <cehteh> spi in .. 3 servos out
[04:39:53] <cehteh> why that?
[04:40:06] <cehteh> or sbus servos :D
[04:40:20] <anonnumberanon> Because they'd need to buy their servos and them modify each one and that's hard(relatively speaking).
[04:40:43] <cehteh> anyway .. generating a lot servo signals has its challenge, i sketched some days ago how i would do it, but i actually never implemented that
[04:41:36] <cehteh> that is: you have a 20ms timeframe right? .. the first 2ms matters ... actually from ms 1 to ms 2 ....
[04:42:44] <anonnumberanon> I think I was able to use 12 pins out of the 328 for signals, jitter and lack of precision were quite high because of the algorithm and i got a better algo in mind that should reduce that jitter by a lot, also the jitter from the Arduino micros() function was compounding and stuff.
[04:43:11] <cehteh> so you schedule a interrupt early, like at 950µs in that timeframe, and from then you serve the servos in a tight interrupt loop for approx 1ms with busy waits .. not the prettiest solution but your µC is only locked for 5% of the time handling servos
[04:43:35] <anonnumberanon> That's exactly what I'm doing.
[04:43:53] <anonnumberanon> Then out of the rest of the time, send it servo positions via UART.
[04:44:05] <anonnumberanon> And do more if time is left.
[04:44:19] <cehteh> there should be plenty time left :D
[04:44:38] <anonnumberanon> servos would be 10 % of each frame
[04:45:00] <cehteh> that would be the very worst case
[04:45:12] <anonnumberanon> yeah
[04:45:14] <cehteh> i think 5% is doable .. even less
[04:45:33] <anonnumberanon> no if all the servos are in max positions you cannot
[04:45:44] <cehteh> with some clever stuff only the servo with the lowest and the one with the highest value matter
[04:47:06] <anonnumberanon> I see where you're going.
[04:47:21] * anonnumberanon tries to focus on the challenge at hand
[04:47:34] <cehteh> also you can calculate sorted array for timings/positions before outside of the servo controller
[04:47:57] <anonnumberanon> Okay that was actually my solution to some of the terrible jitter.
[04:48:12] <cehteh> then your servo controller becomes very simple just going through that array as time advances and sets the outputs
[04:48:14] <anonnumberanon> With the following question: what if 4 servos are exactly the same value.
[04:48:28] <cehteh> no problem in my idea
[04:48:32] <anonnumberanon> Why not do them all instead of turning 22 22 22 22 into 22 23 24 25
[04:48:56] <cehteh> i'd have an array for output ports and time
[04:48:57] <anonnumberanon> Which requires some kind of flag for each servo.
[04:49:00] <cehteh> yes
[04:49:08] <anonnumberanon> So struct?
[04:50:14] <anonnumberanon> an array of structs yes, before leaving the loop it checks the next one, if the next one's flag is on, do it too.
[04:50:18] <cehteh> struct todo {time_t time; uint16_t outputs_to_change}[max_servos];
[04:50:23] <cehteh> something like that
[04:50:47] <cehteh> (for 16 servos .. if you want 17 you have to stuff in a bit more)
[04:50:59] <cehteh> uint32_t for 32 servos haha _:D
[04:51:34] <cehteh> or actually using uint8_t [3] then each uint8_t related exactly to one PORT of the AVR
[04:52:21] <cehteh> then recording the time where to *toggle* the output, and write that into PINx = ....
[04:52:29] <anonnumberanon> pos is from 560 to 2412 iirc
[04:52:45] <cehteh> thats quite a lot normally you have 1000-2000
[04:53:01] <cehteh> depends on the servos, some have more travel, but thats out of spec
[04:53:19] <cehteh> either way that doesnt really matter
[04:53:25] <anonnumberanon> Mine go about 190 degrees for this range.
[04:53:35] <cehteh> could be
[04:53:40] <cehteh> servos differ
[04:53:52] <cehteh> be careful that you add some safety marigin
[04:54:16] <cehteh> servos running into their mechanical limits will destroy themself
[04:54:53] * cehteh now almost feels like he wants to build a robot too :D
[04:55:11] <cehteh> maybe i do a servo lib for mµOS someday ..
[04:55:48] <cehteh> i have already a CPPM parser for receiving RC signals
[04:56:02] <anonnumberanon> Yeah it's just for the sake of completeness. Also you may want to puposefully go to the limit.
[04:56:40] <anonnumberanon> Have you seen my beginnings on video for the robot?
[04:56:41] <cehteh> well with that sketch above you can drive almost any reasonable number of servos
[04:56:50] <anonnumberanon> I pasted it earlier.
[04:56:54] <cehteh> i just glanced on it
[04:57:10] <anonnumberanon> Ah okay so yeah that's what I'm building.
[04:57:17] <anonnumberanon> It's a fighter for Robo-One.
[04:57:36] <cehteh> there are some people comeing here infrequently who are at the same things :)
[04:58:50] <anonnumberanon> I think it is a very hard project that is also rewarding because it is a toy. That's what I like about it.
[05:02:15] <cehteh> quite a lot for a beginner at least
[05:06:47] <anonnumberanon> that avr OS, it's yours? what does it do?
[05:07:17] <cehteh> yes
[05:07:57] <cehteh> it shall become general purpose, but still in infant state
[05:08:16] <anonnumberanon> Ah that's good.
[05:08:30] <cehteh> scheduling function calls, not threads, its very lightweight
[05:08:54] <cehteh> when configured down it needs only a few bytes ram and less than 1k flash
[05:09:28] <cehteh> i primary making it for myself, getting projects quickly done
[05:09:38] <cehteh> some other people showed interest too
[05:13:53] <anonnumberanon> It's pretty much sky is the limit at this stage.
[05:14:17] <anonnumberanon> Whatever makes you have fun but challenge you as well (or only fun).
[05:14:35] <anonnumberanon> neural networks
[05:15:01] <anonnumberanon> people looove things that learn
[05:15:06] <anonnumberanon> tech that learns
[05:15:32] <anonnumberanon> because it feels more human
[05:21:03] * twnqx remembers skynet and shudders
[05:41:37] <cehteh> hehe
[05:42:13] <cehteh> AVR's for world domination
[05:56:55] <_ami_> is n't microchip bought Atmel? :) avr might die in future? :)
[06:08:25] <WormFood> I can't change the system clock in software, can I? Like changing the multiplier, for example.
[06:08:45] <WormFood> _ami_, I guarantee that PIC will die
[06:08:49] <WormFood> and Atmel
[06:08:58] <WormFood> and everything.
[06:09:10] <WormFood> Given enough time. ;P
[06:11:03] <cehteh> nooooo 8051 will stay there forever!
[06:23:55] <_ami_> :-D
[07:16:41] <_abc_> pic32 > arm
[07:17:43] <_abc_> fyi PCI io card with parallel serial etc at non standard addresses work fine with avrdude in linux, but one has to create he parport0 dev if it does not exist on some systems, and add the user to lp group and to dialout for serial
[08:05:48] <WormFood> avrdude: ERROR: Cannot handle "calibration" memory region from ELF file ;)
[08:06:08] <WormFood> WTF Dude?
[08:06:44] <twnqx> WTF avrdude? <- FTFY
[08:06:45] <twnqx> :P
[08:08:50] <WormFood> I imagine that should be easy to add to avrdude
[08:09:08] <WormFood> But, it's not worth the time/effort for me to do it. I was just playing around.
[08:09:45] <WormFood> I didn't expect it to work, because the C compiler doesn't have direct support for it. I figured out how to create my own region in the ELF file, so I figured I'd give it a shot. ;)
[08:33:01] <Haohmaru> guyz, has anyone managed to build avr-gcc for win32?
[08:34:45] <Haohmaru> i tried with mingw/msys, cygwin, and now from ubuntu and a mingw crosscompiler but i'm failing even in the very beginning with the gmp/mpfr libs
[09:09:34] <inflex> umm... brain fade... what -p / -P model do I use for the AVRISP mkII?
[09:09:56] <inflex> sorry, -c
[09:10:17] <inflex> ah, avrisp2
[09:10:18] <LeoNerd> I've often wanted a ~/.avrdude.conf wherein I can just remind it what programmer I have
[09:10:23] <LeoNerd> so I don't have to tell it eeeeevery time
[09:11:35] <Haohmaru> make yourself a bat file
[09:12:59] <LeoNerd> I use Makefiles to drive my projects
[09:13:06] <LeoNerd> I just end up copypasta'ing the avrdude line around
[09:13:37] <Haohmaru> can't you still make an avrdude.bat?
[09:16:54] <lorenzo> I have a build.sh and a flash.sh
[09:16:59] <lorenzo> because I'm too lazy to use a proper Makefile :D
[09:34:14] <yids> would it be somehow possible to extend the memory of a atmega328 with for example something like this
http://www.microchip.com/wwwproducts/en/23K256 ? and by extend i mean that it works like it would have more sram
[09:34:48] * `z uses an alias
[09:35:32] <LeoNerd> You can't have more transparently-accessed RAM, no. But you could use external storage via application support
[09:36:48] <yids> so that would mean i would have to re-write the code so that it uses external memory?
[09:45:33] <cehteh> yes
[09:45:55] <cehteh> why do you run out of memory?
[09:46:53] <cehteh> tried other optimization things? put stuff in PROGMEM, optimize datastructures etc?
[09:50:56] <Haohmaru> uhm, why do i have the impression that this can be done on xmegas?
[09:51:42] <Haohmaru> but.. you need it for atmega328.. meh
[09:52:32] <cehteh> in many cases one can optimize the ram usage
[09:53:23] <cehteh> dunno what he already did, if nothing then no wonder
[10:05:11] <yids> cehteh: i did not do any memory optimizations i will look into that but since the code im trying to use is normally used on a at90usbxxxx which has 8kb of mem i could imagine that this much memory is actually needed, the atmega328 only has 2
[10:06:40] <cehteh> yids: with proper optimization one can save truckloads of ram on havard architectures
[10:12:10] <yids> kk im gonna look into it
[10:15:45] <cehteh> sometimes it also need some more or less clever programming tricks :D
[10:36:02] <bss36504> I have a bitbang interface to drive some LED drivers, they basically look like 16-bit shift register. I have two of them chained together. The issue is, even with no delays, my 32-bit transmission takes somewhere on the order of 500 - 600us, which is much too slow. The micro is running at 8Mhz. Anybody have suggestions on how to speed this along? Is writing the function in assembly worth it?
[10:36:30] <liwakura> bss36504: assembly - yes
[10:36:36] <bss36504> That
[10:36:41] <bss36504> that is what I figured
[10:36:41] <liwakura> but uhm, you can't use the SPI Hardware?
[10:37:07] <bss36504> I can, but I made the decision to use separate pins and bit bang it on this PCB. I wanted the SPI hardware free for ISP
[10:37:21] <liwakura> ah okay.
[10:37:34] <liwakura> maybe it would be enough just to refactor your c code
[10:37:36] <LeoNerd> You know you can do ISP over the pins and still use them for SPI as well, yes?
[10:38:06] <liwakura> LeoNerd: yea, but having such a constellation on my pcb would make me feel uncomfortable
[10:38:16] <LeoNerd> I do it on every one of mine
[10:38:22] <bss36504> Yes, i know that, but there will be bus contention during programming unless you are able to disconnect (or otherwise isolate) the mcu's slave device
[10:38:23] <LeoNerd> It's a solid reliable design
[10:38:39] <LeoNerd> Oh.. the AVR MCU is being an SPI /slave/?
[10:38:43] <LeoNerd> OK.. so that's a harder one to mux :)
[10:38:47] <liwakura> LeoNerd: but then the LED's would go insane?
[10:38:48] <bss36504> no the AVR is the master
[10:38:53] <LeoNerd> The LEDs would be fine
[10:38:58] <LeoNerd> That's why you have an SS line
[10:39:08] <LeoNerd> Every device on the SPI bus will ignore the bus while SS is not asserted
[10:39:23] <LeoNerd> The MCU is not going to assert the SS line of any attached device while in ISP mode, as it hiZs all the pins
[10:39:26] <LeoNerd> For this very reason
[10:39:27] <bss36504> Sure, thats assuming these are true SPI devices
[10:39:29] <bss36504> which they are not
[10:39:44] <liwakura> bss36504: the shift registers don't have an ss?
[10:39:58] <LeoNerd> Normal shift registers (e.g. 74'595) will be just fine
[10:39:58] <bss36504> there is no such concept of slave select on these LED drivers. Their Slave-out pin will not be tri-state ever, and that would cause issues programing
[10:40:16] <liwakura> okay
[10:40:17] <bss36504> they are not normal shift registers, they are 16 channel constant-current LED drivers
[10:40:24] <LeoNerd> Ah.. in that situation I usually attach the return data from the slave via a 741G'125
[10:40:33] <LeoNerd> I have a tape full of those things. Lovely little SOT23-5 chips
[10:40:54] <LeoNerd> Useful for the case where people don't implement SPI correctly; i.e. exactly this
[10:41:12] <bss36504> Yes, as would I, however board space is tight tight tight. If I cant get the bit bang fast enough I may be able to rework and just leave the slave-out pin unused by the drivers. It's not strictly necessary.
[10:41:28] <bss36504> ...and instead use the SPI hardware
[10:41:48] <bss36504> It would require another board spin, but thats not so bad I guess.
[10:41:58] <LeoNerd> Most LED drivers I've seen like that only use the return channel for giving information about open- or closed-circuit LED detection
[10:42:02] <LeoNerd> So you can detect failures
[10:42:30] <bss36504> Correct. It's possible I made a headdesk mistake in thinking that I couldnt use the SPI port
[10:42:36] <bss36504> would have made routing a tad easier too haah
[10:42:56] <bss36504> I've been known to make mistake before :)
[10:43:19] <LeoNerd> There's plenty of devices around that claim to be SPI but aren't...
[10:43:54] <LeoNerd> Much to my annoyance I still haven't found a parallel-to-serial shift register that's true SPI compatible. And many devices, like you observe with your LED driver, don't do hiZ output when deselected
[10:44:45] <bss36504> But, for now I'll write some assembly, see if that fixes it, otherwise I'll have to use the SPI port. It still wont be super clean, since I have to manually operate the clock line a couple of times to sync some other signals to the drivers, but that's no biggie. Still much faster than 500us
[10:45:45] <bss36504> The overall brightness of the array can be controlled by PWMing the out-enable pin on the drivers. But to create individual dimming, you need to send packets of data and keep track of the PWM, and the LED states, in software.
[10:46:03] <bss36504> Thus, I need a fairly speedy packet send in order to avoid flickering
[10:50:19] <bss36504> Now that I think about it, I may be able to do some creative cutting and jumping to make the hardware SPI module work...It would be ugly but it would get it going at least while I wait for new boards. I already fixed one problem, so I need new ones anyway.
[10:50:41] <LeoNerd> Mm.. scalpel and kynar patches... I have many such boards :)
[10:52:41] <bss36504> Yeah, the really great error was transposing the Vout and one of the ground pins on a regulator. Made a wonderful $1.50 wire between vcc and ground. Whoops.
[10:52:54] <bss36504> I really shouldnt try to do layout at 1am.
[10:53:23] <LeoNerd> :)
[10:53:25] <LeoNerd> Best time
[10:53:30] <LeoNerd> I do all my best boards around that time
[10:55:48] <bss36504> Didn't help that it was super-awkwardly shaped
https://644db4de3505c40a0444-327723bce298e3ff5813fb42baeefbaa.ssl.cf1.rackcdn.com/04fa900743d0f6042accfc9ee715a537.png
[10:57:57] <lorenzo> https://github.com/lcafaro/avr-hdc100x/
[10:58:00] <lorenzo> aaand it's done
[10:58:33] <LeoNerd> Mmm... not using WS2812s or APA102s?
[10:58:44] <LeoNerd> Also you seem to have some silkscreen collisions
[10:58:56] <LeoNerd> And silk-on-copper
[10:59:52] <liwakura> wow
[11:00:11] <liwakura> > SP = 0x8FF - 4; asm("ret");
[11:00:20] <bss36504> Yeah, I dont try very hard on my silkscreening haha. And I considered those, but I need only one color (red) and as much brightness as possible. Motorcycle brake light with integrated turn signals, flash on brake, etc.
[11:00:36] <LeoNerd> Ahhh OK.. Yes; fairly pointless for monochrome stuff
[11:00:38] <liwakura> i think this is the rudest thing I've ever done with an avr
[11:02:24] <bss36504> I went for some Cree LEDs, MLESRD-A1-0000-000W01. Really nice, they put out 24 lumens at 30mA and 9.6Vf. The high voltage drop was critical also, as this will be in a 12V system and I dont have space on board for a 2A buck regulator. So in order to keep the power dissipation lower in the drivers, I need the led forward voltage to be close to 12V.
[11:02:54] <LeoNerd> 9.6V forward on an LED? That must be multiple junctions in one package
[11:03:02] <bss36504> yeah its four in series
[11:03:05] * LeoNerd nod
[11:03:06] <bss36504> in a single package
[11:03:10] <LeoNerd> Cute.. in a 5050 it seems
[11:03:12] <bss36504> Really really bright
[11:03:37] <LeoNerd> Why individually connected, by the way? Are you doing fancy animation effects across it?
[11:03:40] <LeoNerd> Or is it just for current spread?
[11:04:23] <bss36504> I only soldered two of the LEDs on so far - one in each corner - and it's uncomfortably bright too work on. And the answer is both current spreading and for a "step effect" turn signal indicator.
[11:04:37] * LeoNerd nod
[11:04:38] <bss36504> bright to*
[11:04:50] <LeoNerd> Yah.. I'm currently working on some LED-based stage effects
[11:05:02] <LeoNerd> Fortunately mine are dimmable, so I work on them at around 10% brightness ;)
[11:05:26] <LeoNerd> I need to fire up the smoke machine next week.. then we'll have some fun :)
[11:05:38] <bss36504> Well, if my packets sent faster, they would be dimmable too. Unfortunately now they flash at "seizure inducing"Hz
[11:06:10] <LeoNerd> Mmmm :)
[11:06:19] <LeoNerd> Do these drivers not do PWM themselves?
[11:07:30] <bss36504> Well they have a global output enable (which can be PWM'd), but If you want per-led dimming, you need to do it via the serial register. unfortunately it's not 16 PWM channels connected to constant current sources. The register value just turns the corrospoding current source on or off.
[11:08:05] <LeoNerd> Ah.. that's a shame
[11:08:38] <LeoNerd> You might consider a TLC5940 for that next time. 16 PWM'ed channels. SPI attached
[11:09:08] <LeoNerd> Well, "SPI" attached. Its serial output pin is never hiZ :( But that's what the 74'125 is for
[11:09:29] <bss36504> I did consider that, but the paltry current rating is not good enough for these LEDs, not to mention the packaging isnt designed for thermal dissipation. This thing comes in a HTTSSOP
[11:09:47] <LeoNerd> In unrelated news: my latest stencil arrived, for my board with a QFN32 chip on. Tiiiiny little thing. I might try and build that tonight.
[11:09:50] <bss36504> TLC5926
[11:09:55] <LeoNerd> Ah OK
[11:10:12] <bss36504> Those are fun, I have soldered a few with just hot air and syringe-paste
[11:10:23] <LeoNerd> My last attempt was just hand-applied paste. It failed
[11:10:47] <LeoNerd> On that entire QFN32 chip I think there was.. hmm.. maybe 2 pins that weren't bridged to the thermal pad. Hard to measure.
[11:11:35] <LeoNerd> Turns out that hand-applied paste is fine for 0603s, SOT-23s, even little USB microB footprints. but QFN is just Too Damn Small
[11:11:39] <bss36504> Oh yeah, the thermal pad sucks. I found that unless you actually need heat dissipation, make the pad super small and stick some vias in the middle. And whatever you think an appropriate amount of paste is for that pad, it's too much, use half that
[11:12:08] <LeoNerd> This is a mega88 spending 99% of its time asleep. I don't need the thermal
[11:13:06] <bss36504> yeah so if it's just an electrical connection, who cares how big the pad is. Probably don't need it for mechanical stability either.
[11:13:33] <LeoNerd> I'd prefer a bit of connection, otherwise the tiny little pads are all that's holding the chip in place
[11:13:44] <LeoNerd> Hrm,.. I should have via-stiched it
[11:14:29] <bss36504> Honestly I think four vias close together, like those little 13mil vias I had in my layout, are probably more than enough mechanically speaking
[11:14:52] <LeoNerd> On the thermal? Or the signal pins?
[11:15:36] <LeoNerd> Ohwait I remember why I didn't want to via this. It's a touchpad controller, with the actual pads on the back of the board
[11:15:43] <LeoNerd> So I'd like to keep that side neat
[11:24:52] <bss36504> Oh fair enough. Then yeah if the stencil doenst help just make the thermal pad smaller I guess.
[11:31:12] <Tekkkz> when I have a battery with 2.8Ah and wanna set its lifetime to 10 minutes, would it be possible to get 17A out of it then?
[11:33:06] <cehteh> barely
[11:33:28] <cehteh> rather not
[11:33:46] <Jartza> depends
[11:33:54] <cehteh> also if its lithium, they like flat discharge cycles
[11:34:04] <Jartza> some 18650 batteries have been specced up to 25A discharge current
[11:34:14] <Tekkkz> why not? isn't the calculation: Ah/h=A ?
[11:34:18] <Jartza> unfortunately not the chinese ones
[11:34:20] <Tekkkz> ahh
[11:34:24] <cehteh> from my caclulation you get 16.8A and then its completely flat in 10 minutes
[11:34:30] <Tekkkz> so from the theory it would work
[11:34:32] <LeoNerd> Capacities are.. curious beasties
[11:34:32] <Jartza> or at least not the cheap chinese ones
[11:34:38] <cehteh> that means you rather kill it
[11:34:43] <Tekkkz> but in realistic not because they have discharge rates?
[11:34:53] <Jartza> yes they do
[11:34:55] <Tekkkz> okay
[11:34:57] <LeoNerd> Ah is a nebulous value; really what you're looking at is Wh of the battery.. which is a measure of energy
[11:35:18] <Jartza> and if you suck more than their discharge rate is, you warm them up either killing them fast or even worse
[11:35:26] <Jartza> like total meltdown or even fire
[11:35:33] <Tekkkz> oh yeah nice :D
[11:35:35] <LeoNerd> But you can't really draw a constant amount of energy regardless of the rate. In practice, if you draw a very low current out, you'll find you can extract more of the energy than if you'd pulled a higher current
[11:35:37] <cehteh> oversize the battery by 50% or more
[11:35:54] <Tekkkz> whats the name of the physical value of Wh?
[11:36:04] <LeoNerd> "energy"
[11:36:09] <Jartza> though the more expensive 18650 batteries have protection circuit inside them
[11:36:13] <LeoNerd> A Watt-hour is 3600 Joules
[11:36:20] <cehteh> the batteries i use for the copters can deliver 100A from 1000mah cells .. but thats not healty
[11:36:29] <Tekkkz> je
[11:36:31] <Tekkkz> i understand
[11:36:34] <dave0x6d> Jartza: some do, but it's usually pretty pointless
[11:36:46] <dave0x6d> Wastes space
[11:37:22] <Jartza> and costs more
[11:37:45] <Tekkkz> so how much amps delivers a AA alkaline with 2.8Ah when i do a short circuit?
[11:38:22] <Jartza> try Sony VTC5A 18650
[11:38:27] <cehteh> really depends on the exact cell type/brand/batch .. internal resistance
[11:38:46] <cehteh> also age
[11:39:00] <Tekkkz> or better to ask: I wanna calculate the speed of a homopolar motor (such one with jsut a battery and some copper cable) ... how to do that? I can't find a good physical calculation ...
[11:39:31] <Tekkkz> i think i need to work with the lorentz force ... but how?
[11:39:57] <cehteh> you need the physical properties of the motor .. friction, air resistance of the stator
[11:39:59] <Tekkkz> F = Q v B where Q = I t and v = l / t .... right?
[11:40:31] <cehteh> and they have a terrible efficiency :D
[11:40:46] <Tekkkz> cehteh: just in theory, like i would do it in a class 10 physics lesson
[11:41:00] <cehteh> dunno about exact calculations, thats possibly very complex
[11:41:23] <Tekkkz> F = Q v B where Q = I t and v = l / t so we get F = I l B
[11:41:31] <Tekkkz> and F also is m * a
[11:41:40] <Tekkkz> so m * a = I * l * B ?
[11:42:34] <cehteh> with very complex i dont mean 3 formulas you can post here :D
[11:42:58] <Tekkkz> cehteh: school class 10 is just so simple without resistance etc.
[11:43:17] <cehteh> try it .. i dont know
[11:43:27] <Tekkkz> or better: F_lorentz = F_radial ?
[11:43:41] <cehteh> maybe test it on a lab power supply then you get good estimates, know voltage and current ...
[11:43:41] <Tekkkz> cause the circle movement of the copper stuff?
[11:43:49] <Tekkkz> have none q.q
[11:44:04] <dave0x6d> Jartza: If you want to see how to design a 18650 pack properly, read the Tesla battery pack patents.
[11:44:36] <cehteh> does tesla still use 18650 even for the newer cars?
[11:44:49] <dave0x6d> afaik the model s still does
[11:44:54] <cehteh> wow
[11:45:06] <dave0x6d> The model x probably does since it's based off the same platform right?
[11:45:06] <Tekkkz> cehteh: when i power 17Amps through it, are also going all the 17Amps through it? is it using maximum?
[11:45:31] <dave0x6d> cehteh: I think the giga factory is still in the designing stages?
[11:46:10] <cehteh> Tekkkz: current is always the same in a closed circruit path (w/o parallel things)
[11:46:14] <cehteh> at any point
[11:46:27] <dave0x6d> Also, the market for 18650 is pretty big, so it'd make sense to sell any surplus batteries to other industries if the giga factory meets Tesla demand.
[11:46:32] <Tekkkz> ok so always the maximum what is accessable? and at F=I*l*B .. is the length l only the length of the copper clsoe to the magnet or the whole copper cable?
[11:46:36] <cehteh> *but* the current will heat up the battery by its inner resistance for example
[11:46:57] <cehteh> and i really dont know / being not interested in this formulas :D
[11:47:08] <Tekkkz> mhhh
[11:47:09] <LeoNerd> I also think you're *massively* simplifying things
[11:47:11] <dave0x6d> Oh, apparently the giga factory is up now.
[11:47:17] <Jartza> dave0x6d: I'm not THAT interested of batteries :)
[11:47:17] <learath> is it?
[11:47:21] <LeoNerd> If you want to be simple for school stuff, just make up some random numbers
[11:47:23] <cehteh> i saied it :)
[11:47:23] <Tekkkz> man, please, this is the last question ... i have no clue what length is meant
[11:47:28] <learath> I didn't realize the gigafactory was already up
[11:47:29] <LeoNerd> In reality very few things are simple multiplications
[11:47:53] <dave0x6d> learath: I think it's very limited production, probably mostly testing the assembly line.
[11:47:55] <LeoNerd> The force due to a moving current in a magnetic field is not "current times length times field strength". It's a complex volume integral
[11:47:58] <cehteh> in reality its all a lot additions :D
[11:48:06] <cehteh> but not so simple
[11:48:12] <dave0x6d> Jartza: neither am I, but it's still a good read.
[11:48:17] <Tekkkz> LeoNerd: can I pm?
[11:48:19] <LeoNerd> The magnetic field isn't going to be dead-constant the entire length of the current-carrying conductor. It'll vary
[11:48:39] <LeoNerd> So you'll have to integrate it. The current flowing through the conductor also isn't a point - the real conductor has real diameter
[11:48:47] <LeoNerd> So suddenly you're at a 3-dimensional volume interaction
[11:48:48] <cehteh> how much force can such a motor produce?
[11:49:02] <cehteh> i never tried to build one
[11:49:13] <LeoNerd> Next you have to consider that in reality the magnetic field isn't perfectly parallel.. it'll bend
[11:49:23] <LeoNerd> So now your lorentz force isn't all uniform either
[11:49:31] <LeoNerd> So now you're into a 3-dimensional vector cross-product
[11:49:36] <LeoNerd> Have fun with that :)
[11:49:50] <cehteh> not to mention that air resistance is quadratic to speed
[11:49:56] <LeoNerd> Oh well quite
[11:50:07] <cehteh> (for subsonic speeds ... but i guess thats ok for you :))
[11:50:18] <LeoNerd> I haven't even *started* thinking about the dynamic effects. I was just thinking about the static effect of the total lorentz force at one instant in time
[11:50:19] <dave0x6d> When an AVR's protection fuses are set and it's using an internal clock, is there any tricks to single step it or at least slow it down?
[11:50:40] <LeoNerd> dave0x6d: "protection fuses are set" - which fuses would they be? There's quite a few
[11:51:14] <dave0x6d> LeoNerd: Let's say all of them.
[11:51:16] <cehteh> slow it down by a few ppm .. heat it up :)
[11:51:34] <cehteh> also vary voltage
[11:51:36] <LeoNerd> Hah.. "all of them"
[11:51:46] * LeoNerd has little patience for stupid questions today
[11:52:03] <cehteh> anyway .. no there isnt anything practical you can do
[11:52:30] <cehteh> maybe, depending on the program you can make a Denial of service by somehow trigger interrupts
[11:52:31] <LeoNerd> Single step suggests debugWire; but if that's fused off then no
[11:52:32] <dave0x6d> LeoNerd: ...is there an issue with asking hypothetical questions here?
[11:52:48] <LeoNerd> Well-formed, well-defined meaningful and tractible hypotheticals are totally fine
[11:53:08] <cehteh> dave0x6d: what do you want to accomplish?
[11:53:22] <dave0x6d> Anyway, I was just curious in general. Sorry for upsetting you with 'stupid' questions.
[11:53:32] <cehteh> there are certainly some attack vectors if you are designing some kind of security device
[11:53:33] <LeoNerd> The stupidness was the "all of" part
[11:53:38] <LeoNerd> That's not well-defined
[11:53:49] <LeoNerd> Do we have SPI or JTAG or dW or...?
[11:53:55] <cehteh> but if you got a security device and want to hack it .. but have to ask here, then this task is over your head
[11:54:15] <liwakura> curiousity!
[11:54:18] <dave0x6d> LeoNerd: If the protection fuses are set, I'd hope that JTAG is locked out lol
[11:54:27] <cehteh> when you do the software you can add some debug things
[11:54:33] <LeoNerd> "the protection fuses are set" <-- there you go again
[11:55:07] <dave0x6d> LeoNerd: Please type /ignore dave0x6d into your IRC client, you'll feel better ;)
[11:55:30] <cehteh> dave0x6d: did you even read what i asked?
[11:56:07] <liwakura> seriously guys
[11:56:14] <liwakura> do you don't know what curiousity is?
[11:56:32] <dave0x6d> cehteh: Yep. I've played around with PIC and not AVR, so I'm not familiar with using the proper terms to avoid upsetting people like LeoNerd.
[11:57:00] <LeoNerd> liwakura: "curiosity" is fine. If I was sat with one of these and fancied it, I just unlock dW and then use that for single-stepping
[11:57:06] <LeoNerd> But then I'd not have "all the fuses set"
[11:57:13] <cehteh> curiosity is also about finding out by yourself, not asking on IRC
[11:57:22] <liwakura> ugh
[11:57:26] <cehteh> and "all fuses" is pretty vague
[11:57:29] <LeoNerd> So this leads to the interesting question of why dave0x6d has a device with all those fuses set anyway and still wants to debug it
[11:57:34] <LeoNerd> And that too :) That was my core objection
[11:57:40] <dave0x6d> I don't have a device like that.
[11:57:43] <liwakura> LeoNerd: its an hypothetical question
[11:57:44] <cehteh> because even if they are for security they serve different purposes
[11:57:47] <LeoNerd> There's lots of different fuses, on different devices. It's not well meaningful to say "all the fuses set"
[11:57:59] <liwakura> So
[11:58:02] <dave0x6d> Hence why my question was vague, because this device you're referring to doesn't exist.
[11:58:16] <liwakura> Let me rephrase that shit
[11:58:29] <LeoNerd> Right. Then I'll be generally vague also: without SPI/dW/JTAG/PDI/similar, you won't be able to manage a singlestep.
[11:58:33] <liwakura> "How much is it possible to lock down an AVR so you can't debug it"
[11:58:49] <cehteh> pretty much
[11:59:00] <LeoNerd> If you don't have an acid-bath decapping machine and an SEM, it can be fairly secure
[11:59:14] <cehteh> but that counts for 'intentional debugging' only
[11:59:22] <dave0x6d> LeoNerd: There we go. That's all I wanted to know.
[11:59:30] <LeoNerd> OK but I didn't really say anythin
[11:59:36] <LeoNerd> "fairly secure".
[11:59:37] <dave0x6d> [12:32] (LeoNerd) Right. Then I'll be generally vague also: without SPI/dW/JTAG/PDI/similar, you won't be able to manage a singlestep.
[11:59:48] <dave0x6d> Vague questions should be given a vague answer.
[11:59:51] <cehteh> if someone wants to hack some security information from your device then there might be tricks to reach that goal by other means
[12:00:10] <dave0x6d> cehteh: indeed, but I don't expect anyone here to walk me through that =)
[12:00:19] <cehteh> right
[12:00:44] <cehteh> i just tell you that your firmware wont be secure/safe just because you set all the bits
[12:01:22] <liwakura> i think if a skilled professional has physical access to your device, you should assume we will be able to read out everything.
[12:01:30] <liwakura> s/we/he
[12:01:30] <LeoNerd> Yup
[12:01:30] <dave0x6d> I haven't checked, but are string format errors pretty rampant here too?
[12:01:40] <LeoNerd> maybe
[12:02:10] <dave0x6d> I figured that'd be the easiest way if there's some serial communication
[12:02:31] <liwakura> buffer overflows and stuff?
[12:02:35] <cehteh> anything
[12:02:55] <cehteh> its just C programming on somewhat bare metal
[12:03:17] <LeoNerd> -slightly- trickier than some things because of being Harvard
[12:03:20] <cehteh> you dont even have a MMU which lets your program segfault on illegal access
[12:03:28] <LeoNerd> So there's whole categories like "putting code on the stack" which don't work on an AVR
[12:03:36] <dave0x6d> LeoNerd: yeah, buffer overflows are a pain here
[12:03:49] <dave0x6d> That's why I went to printf first
[12:03:56] <cehteh> its not pain, its bugs .. programmers fault
[12:04:03] <cehteh> i dont use printf
[12:05:33] <dave0x6d> Do you print formatted strings ever?
[12:06:47] <LeoNerd> I do a fair amount
[12:11:45] <cehteh> just view printf formatting as DSL which needs a small interpreter
[12:12:01] <cehteh> you can do that all ad-hoc without this interpreter
[12:12:16] <LeoNerd> Yah.. you -can- but it's often very inconvenient in the C synta
[12:12:18] <LeoNerd> syntax
[12:12:29] <LeoNerd> C++ makes people use the >> notation for it. Which is an *interesting* choice
[12:12:58] <cehteh> for now i have single functions in mµOS for printing different types and add formatting thereof
[12:13:19] <cehteh> i may add a printf style interpreter someday
[12:13:22] <LeoNerd> Yah.. having a collection of specialcase print functions can do that
[12:13:28] <cehteh> but thats low on the priority liust
[12:13:42] <LeoNerd> It would be nice to have a printf-like behaviour specified that says the compiler /might/ interpret static format strings
[12:13:59] <cehteh> also by this i can take the advantage of the tagged transmission queue, which saves a lot ram
[12:14:08] <cehteh> and its typesafe
[12:14:27] <cehteh> output_uint8("foobar") goes BOOOM
[12:15:04] <LeoNerd> mmm
[12:15:09] <cehteh> printf("%d", "foobar") needs compiler support to go BOOOM, gcc does that but its inflexible
[12:15:41] <LeoNerd> Yah
[12:16:02] <LeoNerd> There's things I want to do in AVR code that I don't think I can get gcc to help me with also
[12:16:18] <cehteh> i can add functions for whatever type i like output_my_fancy_struct( ...)
[12:16:26] <LeoNerd> For example, I want a single array of structs, where each member struct in that array is actually assembled from elements across several different .c files
[12:16:37] <LeoNerd> These are my toplevel "tasks"
[12:16:46] <cehteh> i do that with the preprocessor
[12:16:51] <cehteh> but its really ugly
[12:16:56] <LeoNerd> I'm not sure it could help me
[12:18:10] <LeoNerd> The really tricky part is that I want to be in control of the order of elements in that array. only I'm not quite sure how I'd specify it
[12:18:20] <LeoNerd> CurrentlyI just build the array in one of the .c files, so I get to set it exactly.
[12:18:40] <LeoNerd> It's useful, except that most of the elements in that array mostly relate to things in different .c files, so suddenly I have to make things nonstatic. and also it's harder to -find- them
[12:19:49] <cehteh> i prefer to #define such things all at on .h file and expand them differently on each place (enums, stucts, dispatcher functions)
[12:20:14] <LeoNerd> That's not really what I have
[12:20:23] <LeoNerd> This is the toplevel list of tasks for the core schedulre
[12:20:24] <cehteh> #define foobars foo(one) foo(2) foo(another)
[12:20:26] <LeoNerd> scheduler
[12:21:15] <cehteh> enum foobar_enums{ #define foo(x) foo_##x, \n foobars };
[12:21:48] <cehteh> gives enum foobar_enums{ foo_one, foo_2, foo_another };
[12:21:51] <cehteh> for example
[12:22:35] <cehteh> i use this pattern a lot, in different variations
[12:23:04] <LeoNerd> Yes I don't see at all how that helps.. ;)
[12:23:09] <LeoNerd> Helps me, anyway
[12:23:14] <cehteh> const char* foonames[] = { #define foo(x) #x, \n foobars };
[12:23:38] <cehteh> i think it may help you .. but i havent understood your problem exactly yet
[12:23:59] <cehteh> anyway you can do crazy tricks with the preprocessor and its really messy pretty soon
[12:24:21] <LeoNerd> So an example. My UART driver has a task that the scheduler needs to be aware of, because that task is responsible for managing the line buffer, looking for EOL markers, etc...
[12:24:29] <LeoNerd> and ultimately invokes the application logic for line handling
[12:24:46] <LeoNerd> So currently, if you use that in your code, in the toplevel of the application you have to remember to add the uart driver's task to the task array.
[12:24:48] <cehteh> well wait a bit, i have a similar problem i think
[12:25:01] <LeoNerd> So that's more lines of code in the toplevel just to babysit some referenced driver module
[12:25:06] <cehteh> aka muos_init() has to call initialization for each subsystem
[12:25:19] <LeoNerd> I would love that the UART driver .c file could somehow declare "oh yes and this element needs adding to the main tasks array"
[12:25:31] <cehteh> i want to generate the muos_init() function depending on what subsystems are configured
[12:25:40] <LeoNerd> I would love that e.g. three different .c files could each provide three different elements of the /same/ eventual array that gets generated
[12:25:45] <cehteh> yes you cant do that this easily
[12:25:50] <cehteh> you need to do some tricks
[12:26:04] <LeoNerd> Right. Soyeah, I'm aware I don't think I can. I just couldn't see how your preprocessor trick at all relates to it ;)
[12:26:28] <cehteh> well i come back to you when i fixed my itches
[12:26:57] <LeoNerd> Also ignoring any technical issues of implementation, I'm not sure what the developer UX of this solution would look like anyway
[12:27:01] <LeoNerd> The developer needs to have control over the order somehow.. because sometimes it matters what order tasks run in
[12:27:12] <LeoNerd> If order didn't matter, then I could just use linker magic to od it
[12:27:30] <LeoNerd> Each .c file would make its own 1-element array and shove that in a special linker section, and ask the linker to concatenate them all
[12:27:41] <LeoNerd> But the order the linker does that isn't well-defined
[12:27:47] <LeoNerd> Or at least, arbitrarily controllable
[12:27:48] <cehteh> at worst i can be something like: array[] = { #define GIVE_ME_TASKS \n #include "allfiles.c" .....}
[12:27:57] <cehteh> (simplified)
[12:28:09] <LeoNerd> Hmm... So I -could- be tempted by some sort of generation solution, indeed
[12:28:18] <cehteh> yes the facility you want isnt doable that easily
[12:28:21] <LeoNerd> make tasklist.inc and #include that
[12:28:23] <cehteh> i'd go for preprocessor
[12:28:33] <cehteh> but you can do some tricks with linker scripts
[12:28:40] <cehteh> equally messy
[12:28:50] <LeoNerd> Well, also the linker alone doesn't help me
[12:28:55] <cehteh> like define a task which is put into a 'section'
[12:29:04] <LeoNerd> See, often tasks want to refer to other tasks. I do that currently with an enum
[12:29:05] <cehteh> and the linker then puts all things in this special section into an array
[12:29:16] <LeoNerd> So at compiletime I know the array index of each task, so that others can schedule it
[12:29:35] <cehteh> that would be the closest to what you want .. but i dont know how to implement that in detail
[12:30:03] <cehteh> and linker scripts are not portable between compilers either
[12:30:04] <LeoNerd> I suspect a preprocessor to generate the missing code is probably close to what would work
[12:30:19] <cehteh> what i could imagine to make it work
[12:30:54] <cehteh> the linker script could be the 'ideal' solution when one want to put some efforts into it *and* want to stay on a single development platform
[12:31:06] <cehteh> once done its less messy
[12:31:46] <LeoNerd> Eh... I think a bunch of the avr-libc library already relies on gcc-specific things
[12:31:56] <cehteh> yes
[12:31:56] <LeoNerd> I don't mind being gcc-specific
[12:32:09] <cehteh> well .. read the ld docs .. gl;hf :D
[12:32:19] <cehteh> i tried to avoid that as most i can so far
[12:32:34] <LeoNerd> Hah
[12:32:52] <LeoNerd> Yah.. I avoid that currently. I decided that no AVR is so big for a modern computer that it needs incremental compilation
[12:33:03] <LeoNerd> I just throw all my .c files at one gcc invocation and get the target ELF image direct
[12:33:07] <LeoNerd> No ld for me :)
[12:33:11] <cehteh> haha
[12:33:25] <cehteh> i have plenty .c files and -flto
[12:33:34] <cehteh> works pretty well
[12:34:29] <cehteh> another idea, maybe not applicable to avr's ..
[12:35:13] <cehteh> on PC's i have a error handling system where errors are defined as literal string, and no integer is used a error number but the address of that string
[12:35:44] <cehteh> thats guranteed to be unique and works even if different .c files define their own errors without a central registry
[12:36:14] <LeoNerd> Hah
[12:36:17] <LeoNerd> "guaranteed"
[12:36:24] <LeoNerd> You've never worked with large C++ things have you? ;)
[12:36:25] <cehteh> now one may think about if its possible to generate a linked list
[12:36:39] <cehteh> yes thats used in a biggier C++ project
[12:37:29] <LeoNerd> At $work we've had crazy situations where C++ libraries don't realise that two objects are the same type, because the two happen to have different vtable pointers that point to differnet areas of memory contianing the same table
[12:37:43] <LeoNerd> because the same "type" was constructed by two different libraries at two different occasions
[12:38:00] <cehteh> yes that can happen
[12:38:26] <cehteh> but the revers you can never have 2 different constant strings at the same address
[12:38:42] <cehteh> i only rely on that property
[12:39:45] <cehteh> const char* foo="foo"; const char* bar="bar"; assert (foo!=bar);
[12:41:20] <cehteh> const char* foo="foo"; const char* bar="foo"; assert (foo!=bar); << this may fail, the compiler can (and does) merge literal strings with the same content
[13:22:05] <methuzla> I'm trying to get an attiny85 to work as i2c slave. I'm working on an Ubuntu machine with avr-gcc using code from here
http://www.atmel.com/images/AVR312.zip modified to work with gcc.
[13:22:32] <LeoNerd> Hah. I've never once had any luck with any of the actual C code in any of the AVR appnotes
[13:22:43] <LeoNerd> I just read the description in a vague handwavy way and then reïmplement it
[13:23:00] <methuzla> I've got it somewhat working using this simple test code:
http://pastie.org/10796619
[13:23:24] <LeoNerd> I think I²C slave on the USI is one of the trickier modes; because newer 'tiny chips added a dedicated I²C slave module on top of it
[13:23:28] <LeoNerd> So Good Luck :)
[13:24:36] <methuzla> The problem I'm having is that the returned value wraps at 127
[13:24:48] <LeoNerd> .. wraps at?
[13:26:05] <methuzla> I've got it attached to a raspberry pi for reading. I've used i2cget, i2cdump, and smbus in python.
[13:26:34] <methuzla> With multiple reads, it returns: 0 10 20 ... 120 then back to 0
[13:26:38] <cehteh> when something wraps at 127 then there is some signed byte snugged in
[13:26:47] <methuzla> so like a signed/unsigned issue
[13:26:52] <LeoNerd> Oh.. perhaps the top bit is missing you mean
[13:27:06] <LeoNerd> That's usually because of a misalignment between shifting and clocking
[13:27:21] <LeoNerd> Check carefully the ordering of operations between reading/writing the data register, and clocking a bit
[13:27:26] <cehteh> missing byte would return 120, 3 or?
[13:27:36] <cehteh> bit
[13:27:38] <methuzla> I'm doing +10 in the code
[13:27:47] <LeoNerd> I've not implemented a USI I²C slave before, but I have a master that took some fiddling to get right
[13:28:03] <methuzla> so it never actually gets to 127, just 120, next should be 130, but it's not
[13:28:28] <cehteh> (120 + 10) & 0b1111111 == 2 (not 3 my bad)
[13:28:30] <methuzla> sorry not actually zero, but uhhh, 2? whatever the wrapped value would be
[13:28:59] <cehteh> so
[13:29:12] <cehteh> either bit missing or signedness
[13:29:55] <LeoNerd> methuzla:
http://pastie.org/10796633 <== if it's any help, here's my I²C master. Probably some bits of that could be inspirational for the slave
[13:30:42] <LeoNerd> (since send and receive are symmetric there)
[13:35:42] <methuzla> LeoNerd, thanks, will look at that
[13:36:11] <LeoNerd> Thinking about it, it's unlikely to be directly useful because a slave is probably entirely interrupt-driven, whereas this master is blocking
[13:36:22] <LeoNerd> But there might be bits and pieces you could steal
[13:36:44] <methuzla> cehteh, yep, that's the behavior, but can't find where/why it's happening
[13:49:55] <methuzla> so i just tried this - i originally had the CKDIV8 bit in lfuse unprogrammed (i was trying to make it run faster)
[13:50:24] <methuzla> i just reset the fuse back to having CKDIV8 programmed, and now it seems to work
[13:50:37] <LeoNerd> Mmmm
[13:51:13] <LeoNerd> Sounds plausible; if the I²C slave's internal clock is too slow for what the master is sending, I'd imagine issues could happen
[13:52:47] <methuzla> currently testing it with 'i2cget -y 1 0x23 0' over and over and if i try too fast i get a 'Error: Read failed'
[13:53:12] <methuzla> but otherwise, getting returns up to 0xff
[13:54:09] <methuzla> LeoNerd, but as I understand it, what I did was actually slow it down to make it work
[23:46:56] <anonnumberanon> cehteh, I'm on to something with the race condition stuff thanks for bringing that up, can't dev right now but can at least read about it, .. atomically
