Back
[00:23:31] <OdinYggd> Oh there is a channel for AVR people
[00:24:06] <OdinYggd> Excellent. Who here is familiar with setting the clock on the ATTiny85? I've heard that they don't necessarially make their full 20Mhz rating when running from the internal clock- you have to use a crystal to go over 8mhz or so
[00:24:27] <OdinYggd> ATTINY85-20PU is the part number I'm working with
[00:26:37] <Tom_itx> the internal osc is more than likely 8Mhz
[00:26:52] <Tom_itx> if so you need an external crystal to get the full 20Mhz
[00:27:02] <Tom_itx> the data sheet will tell you this
[00:27:18] <OdinYggd> I can make 8Mhz work in this application, and I have some 4 8 and 16mhz crystals on the way just in case since I have a few pics that lack internal oscillators
[00:27:31] <OdinYggd> Just wasn't sure on that if I was limited to one speed on the internal oscillator
[00:27:50] <Tom_itx> unless it's got a CKDIV8 fuse you are
[00:27:59] <Tom_itx> in which case it would run at 1Mhz
[00:28:01] <Tom_itx> default
[00:28:35] <OdinYggd> ckdiv8 fuse preprogrammed, see page 30
[00:28:39] <OdinYggd> Okay, back to rtfm I guess
[00:28:42] <Casper> OdinYggd: don't that one have a pll?
[00:28:51] <OdinYggd> It has an internal oscillator, that's why I picked it
[00:28:55] <Casper> I think it's the x5 tjay does
[00:29:00] <OdinYggd> but I wasn't sure what speed it would run at using that
[00:29:21] <OdinYggd> I need 2 digital IO and 1 analog IO for my application, so losing two pins to a crystal is not a serious issue
[00:29:49] <OdinYggd> Just a little inconvenient, since I was hoping to have enough pins free to i2c to a large MCU for stats gathering
[00:30:05] <OdinYggd> Could always DIY a 1-wire library for it to do that anyway since it'll only have one pin left
[00:30:27] <Tom_itx> if 12Mhz is enough the attiny10 (SOT23-6) would do
[00:30:39] <Casper> OdinYggd: as I said, check the manual for a PLL mention... if so look at it for the system clock
[00:30:44] <OdinYggd> I've already ordered the ATTiny85 though
[00:30:46] <OdinYggd> Ships monday
[00:31:13] <OdinYggd> Originally I was going to use a PIC16 at 4Mhz for this, the avr's abundance of registers makes it easier to code for I think
[00:31:17] <Tom_itx> it doesn't have i2c though
[00:31:33] <OdinYggd> It says it is one of the options for the universial serial interface
[00:31:42] <OdinYggd> Does SPI or I2C
[00:32:12] <OdinYggd> Pin 5 = SDA, pin 7 = SCL
[00:32:18] <OdinYggd> iirc those are the i2c signals
[00:33:02] <OdinYggd> Right now I'm hoping to code it in assembly in order to keep the cycle time of my interrupt handler to a minimum
[00:33:17] <OdinYggd> I might end up using C++ for the bulk of the code though and just injecting the Interrupt assembly into an existing program
[00:33:21] <apo_> OdinYggd: Do yourself a favour
[00:33:25] <apo_> OdinYggd: Don't use the USI
[00:33:36] <OdinYggd> Oh?
[00:33:47] <apo_> 03:05:02 < abcminiuser> USI is an ungodly mess
[00:33:47] <apo_> 03:05:13 < abcminiuser> "Here's a shift register and half a counter, have fun"
[00:33:54] <OdinYggd> I see.
[00:34:02] <OdinYggd> I'd be better off running a DIY 1-wire protocol then
[00:34:07] <apo_> I poured 15 hours into it, trying to make it work as an I2C multi-master implementation
[00:34:13] <OdinYggd> ugh
[00:34:15] <apo_> if you still want to try it, I can give you my code
[00:34:23] <OdinYggd> I2C multimaster is literally what I was hoping for the ultimate goal to be
[00:34:24] <apo_> It's mostly working :p
[00:34:47] <OdinYggd> But in my case it would sense the I2C pins on bootup, if they were not pulled down it would be the I2C master, if they were it would be a slave
[00:34:54] <apo_> http://p.0au.de/977ed9ab/i2c.h
[00:34:58] <OdinYggd> Changing from master to slave while running would not happen
[00:35:39] <OdinYggd> In theory if no other MCUs were present it would assume it was the master and control an i2cmem, but if another MCU was present I would pull down the I2C pins at power on and it would boot up as an I2C slave
[00:37:09] <OdinYggd> You're using C though
[00:37:13] <OdinYggd> I'd be doing this in assembly
[00:37:19] <apo_> enjoy
[00:37:30] <apo_> I'm off to bed, it's after 700 ~_~
[00:37:30] <OdinYggd> Unless I get annoyed implementing an I2C library in assembly and just do it in C to use an existing one
[00:37:32] <apo_> Good night
[07:53:44] <apo_> This is nice! The organ pedal I got for the midi project is here, and not only does it have two additional controls (you can move your foot to either side to activate switches), but the position's not calculated with a potentiometer. There's an LED and a photodiode, and something inbetween that transmits light based on how much you push the pedal. And everything's without any digital logic of any sort, so I can hook it up to an AVR ...
[07:53:50] <apo_> ... super easily :)
[07:55:23] <apo_> https://imgur.com/zpE2Cnw :)
[08:00:50] <Lambda_Aurigae> apo_, that's not a photodiode.
[08:00:56] <Lambda_Aurigae> that's a CDS photocell.
[08:01:10] <Lambda_Aurigae> light activated variable resistor.
[08:01:32] <Lambda_Aurigae> old school.
[08:10:17] <Lambda_Aurigae> apo_, so, in effect, it is a pot,,,kindasorta...a light controlled pot.
[08:10:48] <ecilop> photo-transistor?
[08:10:51] <Lambda_Aurigae> no
[08:10:54] <Lambda_Aurigae> CDS photocell.
[08:11:02] <Lambda_Aurigae> cadmium sulphide photocell.
[08:11:16] <Lambda_Aurigae> CdS
[08:11:29] <Lambda_Aurigae> also known as a photoresistor
[08:11:44] <Lambda_Aurigae> http://en.wikipedia.org/wiki/Photoresistor
[08:14:27] <apo_> Lambda_Aurigae: fair enough
[08:14:30] <apo_> Lambda_Aurigae: end result's the same
[08:14:31] <apo_> :)
[08:15:15] <Lambda_Aurigae> works a bit different from a photodiode but yeah, effectively the same.
[08:52:18] <hetii> HI :)
[08:52:29] <apo_> Lambda_Aurigae: heh, it's patented:
https://www.google.com/patents/US3119890
[08:52:49] <apo_> oh, wait
[08:52:50] <Lambda_Aurigae> yup
[08:52:53] <Lambda_Aurigae> as is vibrato
[08:52:55] <apo_> I think this is different
[08:53:31] <Lambda_Aurigae> yeah..yours is somewhat different from that.
[08:53:44] <Lambda_Aurigae> still uses the CdS photocell.
[08:53:58] <apo_> Leslie sure liked their photocells
[08:54:45] <Lambda_Aurigae> they were cheaper than photodiodes or phototransistors way back when.
[08:54:54] <apo_> could've used a poti :p
[08:55:44] <Lambda_Aurigae> this way is more stable and less prone to dust and dirt in the wipers.
[08:55:53] <Lambda_Aurigae> and less prone to wearing out.
[08:56:07] <Lambda_Aurigae> I've seen buttons done the same way.
[08:56:18] <Lambda_Aurigae> LED and photocell with an interrupter.
[08:56:27] <Lambda_Aurigae> buttons and switches.
[08:56:41] <apo_> Yeah, I wasn't serious
[08:57:59] <apo_> this thing is quite dusty, though
[08:58:18] <apo_> Wonder if that's why they sold it, because it got worse and they didn't know how to fix it <_<
[08:58:25] <Lambda_Aurigae> there was even a scifi story where all the buttons and switches and knobs on a multi-generation starship were done with long duration lights and photo sensors with interruptors.
[08:58:42] <Lambda_Aurigae> just blow the dust out, clean it up, and it'll work like new.
[08:59:17] <robb1985> PART #hackell
[08:59:31] <apo_> yup
[08:59:54] <robb1985> Hi everybody
[09:00:47] <Lambda_Aurigae> hello robb1985
[11:00:14] <hetii> How much will cost me if I will use structure with pointer to function instead call directly the function ?
[11:02:04] <LeoNerd> A couple of cycles more I think
[11:03:09] <hetii> \hmm
[12:30:32] <Rickta59> seems like it might cost nothing depending on what you are doing hetii
[12:31:18] <Casper> I don'T see a difference between sending a variable pointer or a structure pointer
[12:31:33] <Casper> the code do not care what the pointer point to...
[12:31:39] <Casper> it pass a pointer only...
[12:31:55] <Rickta59> the compiler seems to completely optimize this:
[12:32:17] <Rickta59> http://dpaste.com/0WRBSPZ
[12:33:10] <Rickta59> http://dpaste.com/0PRYGJF
[12:33:26] <malinus> Casper: huh?
[12:58:12] <LeoNerd> Well, this is an important moment for me. I'm about to deconstruct my breadboard circuit, from which I eventually built my first PCB..
[12:58:17] * LeoNerd holds a moment's silence
[12:58:25] <LeoNerd> OK that's long enough.
[13:00:02] <OdinYggd> Take pictures first
[13:00:06] <OdinYggd> might be too late
[13:00:27] <LeoNerd> It's OK. I know it works now.
[13:00:45] <Rickta59> led with a resistor?
[13:01:12] <LeoNerd> Not quite ;) ST662-based charge pump for HVSP, plus circuit to attach bus pirate to a ZIF socket
[13:01:42] <LeoNerd> https://twitter.com/cpan_pevans/status/537743304008683522 this is the PCB it became
[13:04:34] <hetii1> re
[13:06:08] <hetii1> Rickta59: I consider to use structures as a Api where I split logic of my application from hardware specyfic interface
[13:06:35] <Rickta59> so it really compile time stuff?
[13:06:49] <hetii1> could be.
[13:06:55] <Rickta59> if that is the case it probably wouldn't cost anything
[13:11:08] <hetii1> Yep I suppose just configuration function where will assign all pointers could be additional stuff
[13:20:58] <LeoNerd> N1njaneer: Any feedback yet about the XML files?
[13:51:58] <LeoNerd> Offhand does anyone know if the IRQ pin on an nRF24L01(+) is pushpull or open collector? The data sheet just says "digital output, active low", with no clear indication
[13:53:16] <Fleck> should be pushpull
[13:53:27] <LeoNerd> Hrmmm
[13:53:36] <Fleck> IMO
[13:54:11] <LeoNerd> So.. I have a program/circuit that used to work fine.. Ardunino Nano board (mega328p), running a plain C program I wrote, to talk to nRF module, using interrupts
[13:54:29] <LeoNerd> Having swapped to a bigger module with a power amp, I have a new cable. That new longer cable at least appears to be causing lots of spurious interrupts
[13:54:41] <LeoNerd> I do note that the MISO line is right next to
[13:54:54] <LeoNerd> I do note that the MISO line (pin 7) is right next to the IRQ line (pin 8), and doesn't have a pullup on it.
[14:49:34] <Shavik> What are the differences between half duplex RS-422 and standard (half duplex) RS-485. I had someone tell me they use half duplex RS-422 and I was just under the impression that that was just RS-485 but I've found I'm wrong. Can't really tell much more than that.
[14:49:36] <Shavik> Thanks
[14:53:29] <Tom_L> http://electronics.stackexchange.com/questions/69887/different-rs485-full-duplex-with-rs422
[14:53:45] <Lambda_Aurigae> have you actually looked the two up and looked at what they are and how they are different?
[15:04:32] <Tom_L> http://www.analog.com/static/imported-files/application_notes/AN-960.pdf
[15:07:52] <Tom_L> RS-422 is single driver
[15:08:14] <Tom_L> RS-485 is multi point
[15:08:52] <Shavik> So "Full Duplex RS-422" is two drivers technically?
[15:09:41] <Tom_L> that pdf should explain it quite well
[15:09:44] <Shavik> RS-485 can have many drivers but only one at a time
[15:09:46] <Shavik> Yea I'm reading through it
[15:09:52] <Shavik> Just trying to fully understand
[15:10:30] <Tom_L> Normally RS-485 drivers have a common mode range (422 driver do not)
[15:10:33] <Tom_L> because in a multi drop situation a driver that does not allow a negative common mode would compromise the signal
[15:11:17] <Tom_L> the trade off is that RS-485 compatible drivers normally have diodes in series with their outputs so they have a smaller swing (so lower noise immunity)
[17:11:28] <hetii1> I cannot decide myself :( What will be better. Use static struct for each of my driver that will have pointers to hardware specyfic functions or use some preprocesor macros instead ?
[17:12:09] <Casper> what make the code easier to debug? and what make the code more compact?
[17:12:28] <malinus> especially the former ^
[17:12:53] <malinus> 32kB is a lot of space :)
[17:16:02] <hetii1> hmm debuging in both case should not be hard.
[17:16:50] <malinus> not using preprocesors sounds more modular and OP-ish
[17:16:54] <malinus> no?
[17:16:55] <hetii1> using structure there`s more work at coding and suppose can generate bigger hex file.
[17:17:52] <hetii1> yes indeed,
[17:18:10] <malinus> more object-based, so to speak
[17:19:44] <hetii1> the point is that i really want to have it more like module`s
[17:21:16] <hetii1> I wonder how other people handle such topic
[17:21:37] <malinus> hetii1: most arduino code, is simply c++.
[17:21:52] <malinus> don't hate on the example ;)
[17:22:17] <hetii1> True but C++ is not the best for small mcu
[17:23:06] <hetii1> thats why I try find some other way in C
[17:24:46] <malinus> well people write objected based C
[17:24:51] <malinus> if that's what you mean
[17:25:38] <hetii1> I wonder how other professional embended programmers play with it cause its hard to belive that on each project they repeat their work all the time
[17:26:03] <malinus> hetii1: also in theory, as far as I understand, the overhead of using c++ is almost non-existing. It's the libraries.
[17:26:07] <Lambda_Aurigae> you write libraries.
[17:26:19] <Lambda_Aurigae> or modules.
[17:26:23] <Lambda_Aurigae> and reuse them.
[17:26:47] <Lambda_Aurigae> same as any decent programmer for any platform.
[17:27:26] <hetii1> ok, but how they glue each layers ?
[17:28:04] <Lambda_Aurigae> #include
[17:28:12] <malinus> Lambda_Aurigae: beat me to it, haha
[17:28:20] <Lambda_Aurigae> or linking a compiled lib and using #include for a header file.
[17:28:50] <Lambda_Aurigae> the same way you do it for x86 or arm or 68000 or any other processor platform you write C or C++ for.
[17:29:01] <malinus> Z80?
[17:29:14] <Lambda_Aurigae> if there is a C compiler for it, sure.
[17:29:20] <malinus> what about powerPC?
[17:29:40] <malinus> okay, time to go to bed ;P
[17:29:50] <Lambda_Aurigae> hell, if you are using C to program for AVR you are already using precompiled libraries and header files if you use the avr-libc.
[17:30:03] <Lambda_Aurigae> or, the interrupt set or whatever.
[17:30:37] <hetii1> ok but then you propably need keep in mind to include a lot of headers files
[17:30:46] <hetii1> also is another aspect
[17:30:50] <Lambda_Aurigae> you are doing that already.
[17:31:02] <Lambda_Aurigae> do you ever do an #include<stdio.h> ?
[17:31:13] <hetii1> sure
[17:31:36] <Lambda_Aurigae> that's just a header file for a pre-compiled library package.
[17:31:56] <Lambda_Aurigae> it's part of the standard libc package(I think.)
[17:33:51] <Lambda_Aurigae> you can make your own libraries, compile them, add them to the linker script, and add the header file in with an #include
[17:33:52] <hetii1> ok, all that is true, but stuff in stdio.h is something that you can linked everywhere without trouble, the names of its symbol is uniqe and you can easly use it.
[17:34:26] <hetii1> but what in the case where let said I have two spi in my board and want to glue one of it with my sensor
[17:34:37] <Lambda_Aurigae> there are books and tutorials out there on making your own precompiled libraries...there are suggested standards by which to name things in libraries and such.
[17:35:21] <Lambda_Aurigae> that's a totally different subject.
[17:36:35] <Lambda_Aurigae> you have to know the specifics of your board, how things are hooked up, and write the code to do it.
[17:36:53] <hetii1> you see but that`s the point, in OOP i can make an instance of object and pass to constructor all configuration things like pinning etc.
[17:37:20] <hetii1> and then use the same api to play with my sensor
[17:37:39] <Lambda_Aurigae> ok..now we are talking about yet a third thing.
[17:37:55] <Lambda_Aurigae> that is all about how you implement the software.
[17:38:15] <Lambda_Aurigae> everything done in OOP can be done without OOP...but if you want to use C++ and classes, go for it.
[17:38:16] <twnqx> you don't need oop to do that.
[17:38:24] <twnqx> damn he was faster :P
[17:38:51] <Lambda_Aurigae> there really is no extra overhead for C++ over C in the instance of the AVR because it gets cooked down to much the same thing.
[17:38:52] <twnqx> but you shoul dbe aware of the side effects. like storage space and overhead, especially on something as slow as an AVR
[17:38:57] <Lambda_Aurigae> twnqx, 75wpm.
[17:38:58] <hetii1> That`s why I ask about how other`s people do it in C
[17:39:12] <Lambda_Aurigae> hetii, the same way we have for(in my case) 20 years.
[17:39:19] <Lambda_Aurigae> or longer...
[17:39:21] <twnqx> Lambda_Aurigae: there is none if he passes pins/ports into a constructor?
[17:39:30] <hetii1> I just figure out that could do that by static structure in each of my driver.
[17:39:40] <twnqx> that alone would force indirect IO
[17:39:48] <Lambda_Aurigae> I use structs and arrays...or arrays in structs...or arrays of structs..
[17:40:06] <Lambda_Aurigae> whatever I need to get the job done.
[17:40:54] <malinus> sometimes one use array of pointers to array of pointers to functions, if that's what it takes. Then you keep adding * and & until it works.
[17:40:58] <twnqx> hetii1: my personal approach to that is to keep the pin info in a header and compile the same source every time with different results
[17:41:34] <hetii1> ok I will describe what
[17:41:38] <hetii1> I try to do
[17:42:18] * twnqx tries to keep any form of abstraction layer as flat as possible
[17:42:33] <twnqx> you only have a handful of MIPS on a micro :/
[17:43:44] <hetii1> 1. I want to use C. 2. I play with different arch AVR/NXP etc... 3. when I write some driver for avr than I should easly use it on other platforms.
[17:44:07] <Lambda_Aurigae> step 1...learn the difference between then and than.
[17:44:21] <Lambda_Aurigae> step 2...learn the different platforms.
[17:44:47] <twnqx> for that to work you'd need a common API across your hardware
[17:44:56] <Lambda_Aurigae> step 3...look at source code for other multiplatform applications and libraries and learn how they did it.
[17:45:18] <hetii1> twnqx: exactly thats why I ask about the best way how I can do it in C
[17:45:45] <malinus> ^ but mostly something like #if __AVR__ thisSPIsetup() #elif NXP thisOtherSPIsetup()
[17:46:08] <twnqx> well, you'd need your own lowlevel APIs
[17:46:09] <Lambda_Aurigae> you write code that is common to all and you write code that is different for each platform and use the pre-processor for conditionally including things that need to be included by processor type.
[17:46:27] <twnqx> or do it like malinus says, and wrap up different hardware access libs
[17:46:31] <malinus> what I said, but more correct and longer ^
[17:46:40] <Lambda_Aurigae> really, the same way you would in C++.
[17:46:47] <malinus> yeah
[17:46:54] <Lambda_Aurigae> or in java
[17:46:57] <Lambda_Aurigae> or in perl
[17:46:59] <Lambda_Aurigae> or in pascal
[17:47:03] <malinus> hetii1: look at some windows vs linux specific code, if you want examples of that
[17:47:20] <malinus> I think that's easier to find than avr/STM or w/e.
[17:47:30] <hetii1> so by preprocessor at the end of the day
[17:47:44] <twnqx> you'd use the preprocessor in c++ as well
[17:47:55] <twnqx> or build system
[17:47:55] <malinus> yes, that's also what you do, to make your code work on different AVR's
[17:48:56] <Lambda_Aurigae> look at how #include<avr/io.h> works.
[17:49:03] <malinus> ^ that's a good idea
[17:49:20] <Lambda_Aurigae> it grabs your processor definition, generally done from the makefile, and includes the specific avr processor i/o file.
[17:50:43] <Lambda_Aurigae> building a system based on specific processor with different necessities for different processors is NOT a C++ thing...it is much older than that.
[17:50:49] <Lambda_Aurigae> it is not an OOP thing...
[17:50:51] <hetii1> yes, this is one of the way that I could use it also.
[17:51:01] <hetii1> yes i know.
[17:51:18] <Lambda_Aurigae> OOP languages just wrap things up differently.
[17:51:29] <hetii1> but there is other aspect like pinning or using the same code to play with different devices.
[17:51:43] <hetii1> eg. have soft spi library that handle two sensors
[17:51:48] <Lambda_Aurigae> but you would still need to use the preprocessor to pick the specific code and/or files for each processor even in an OOP language.
[17:52:19] <Lambda_Aurigae> the soft spi library would still need processor specific stuff, no matter what language you write it in...
[17:52:43] <Lambda_Aurigae> otherwise how would it know how to access the underlying hardware to toggle the pins on and off?
[17:54:03] <Lambda_Aurigae> you can create an API package that presents one common interface to the user
[17:54:03] <hetii1> true, thats why I wrote about pinning, you need somehow glue softspi layer with hardware.
[17:54:17] <Lambda_Aurigae> but you still have to write the underlying software for each processor type
[17:54:40] <hetii1> by preprocesor I could just assing one hardware specyfic functions or pins and control just one sensor
[17:54:42] <Lambda_Aurigae> and that will require you use the preprocessor,,in C, C++, Java, or whatever.
[17:55:02] <Lambda_Aurigae> if you want it transparent anyhow.
[17:58:48] <malinus> arduino does exactly that
[17:59:03] <malinus> it works with many different avr's. And even some 32-bit mcu's
[17:59:25] <Lambda_Aurigae> there is even the pinguino which is a pic version of the arduino..uses the same codebase.
[17:59:33] <Lambda_Aurigae> and presents with the same api.
[17:59:37] <malinus> you just digitalWrite(pinNumber), so the user has no idea of all the other abstractions
[17:59:51] <malinus> yeah
[17:59:55] <hetii1> You know i`m not against preprocessor, the underlying things have it already but just consider how can I easly exchange my modules.
[18:00:55] <Lambda_Aurigae> hetii, look at how other code does it and learn.
[18:01:00] <Lambda_Aurigae> or, take a programming class.
[18:02:30] <hetii1> Well I look inside many codes and have feeling sometimes that there is no standard :)
[18:03:10] <hetii1> btw is there some repository for different chip drivers ?
[18:03:36] <hetii1> like sensors/displays etc..
[18:04:39] <hetii1> would be nice to have one place for it and grab just what is needed in current project.
[18:05:57] <Lambda_Aurigae> not really.
[18:06:11] <Lambda_Aurigae> well,,yeah, kinda...it's called GOOGLE
[18:06:39] <twnqx> lol
[18:06:59] <twnqx> but i guess since you'd need a common API first, before you can build such drivers
[18:07:02] <hetii1> ye, this one I know already....
[18:07:11] <twnqx> there can't really be such a thing
[18:07:15] <twnqx> and even then
[18:07:23] <twnqx> i tried other people's libs multiple times
[18:07:37] <twnqx> only to discard them and start over because they were.... not fitting into my code
[18:09:01] <hetii1> twnqx: you see, and thats a problem, all the time everybody need to do the same work. Go to Google, find it and adopt or write own.
[18:09:14] <hetii1> and by that for one chip you have planty of drivers.
[18:09:44] <twnqx> so what
[18:09:50] <twnqx> chip drivers are normally so little code
[18:10:03] <twnqx> that i rather write my own than force my program around some library
[18:10:43] <Lambda_Aurigae> hetii, if you don't like it, change it...write the code, put it together, gather it up, whatever...but don't complain that someone else hasn't done it for you already.
[18:11:37] <hetii1> Lambda_Aurigae: I don`t complain that somebody hasn't done it for me. That`s not my point.
[18:11:50] <twnqx> also, a chip driver always needs an underlying API
[18:11:55] <twnqx> an abstraction layer
[18:12:11] <twnqx> that must be identical across all micros
[18:12:29] <twnqx> so you either shrink the features you rely on down the the smallest common
[18:12:41] <twnqx> or your driver doesn't work any more
[18:13:19] <twnqx> i even had to write a software+hardware SPI api for AVR
[18:13:26] <twnqx> onthe same hardware pins, inside the same project
[18:13:41] <twnqx> since there were some issues with using hardware spi inside an interrupt context
[18:14:18] <hetii1> Lambda_Aurigae: I just notice some problem where everybody waste a time and do the work twice.
[18:14:48] <hetii1> twnqx: true I know it`s not a real world and always you will have such trouble
[18:14:57] <twnqx> i don't call it trouble
[18:15:05] <twnqx> i'd say that 90% of libraries are misdesigned
[18:15:11] <twnqx> or not suitable for one way or the other
[18:15:23] <twnqx> it's different if you have an abstraction layer such as the linux kernel
[18:15:30] <twnqx> or windows, or bsd - whatever
[18:15:39] <twnqx> then you have a common SPI api, for example
[18:15:50] <twnqx> you implement users of the API - chip drivers
[18:16:07] <twnqx> and you implement drivers for the API - on avr, nxp, whatever
[18:16:21] <twnqx> but before you have such a common API, you can't build a family of drivers
[18:17:35] <Lambda_Aurigae> well, we have linux on the AVR!
[18:17:42] <twnqx> on the avr32
[18:17:53] <Lambda_Aurigae> on the avr 8bit!
[18:18:13] <twnqx> lol
[18:18:17] <Lambda_Aurigae> http://dmitry.gr/index.php?r=05.Projects&proj=07.+Linux+on+8bit
[18:18:20] <Lambda_Aurigae> I am NOT joking.
[18:18:26] <Lambda_Aurigae> it only takes 3 hours to get to a command prompt.
[18:19:19] <twnqx> lol
[18:19:26] <Lambda_Aurigae> it does run.
[18:19:44] <Xark> Lambda_Aurigae: Yeah, but only a minute or so to get a reply from a command typed at a prompt. :)
[18:19:48] <Lambda_Aurigae> it's an arm emulator running on an atmega1284p with an external 30pin simm for memory.
[18:20:07] <Lambda_Aurigae> and an sd card for program storage!
[18:20:23] <Xark> Totally useless - except for major hack cred. :)
[18:20:29] <Lambda_Aurigae> yeah.
[18:20:43] <Lambda_Aurigae> but, we have linux! we have our common API interface for hardware!
[18:20:43] <twnqx> also not the same.
[18:20:47] <twnqx> and not related.
[18:22:15] <Xark> I kind of liked AVR32 architecture (although my board did not run Linux).
[18:22:50] <Xark> Is that still a viable MCU? Seems Atmel has gone over to the ARM side...
[18:23:02] <hetii1> Lambda_Aurigae: I see your point :)
[18:23:05] <Lambda_Aurigae> yes...atmel has gone to the dark side.
[18:23:24] <Lambda_Aurigae> avr32 still exists but it has fallen far behind the arm world.
[18:23:52] <Lambda_Aurigae> avr32 never made the speed increases that arm did...otherwise it might be a viable alternative.
[18:25:52] * Xark played a bit with http://www.aery32.com/ (IIRC, ran pretty nicely at 66Mhz - I was able to toggle GPIO at 33Mhz).
[18:29:17] <aandrew> interesting, it's like an avr32 arduino
[18:30:06] <twnqx> yuck
[18:30:15] <twnqx> does it have bad software with it, too?
[18:31:01] <Xark> twnqx: No, it has a whole new framework that was nicely designed (IMHO). See
http://aery32.readthedocs.org/en/latest/
[18:32:09] * twnqx notices cpp files
[18:32:25] <Xark> twnqx: Yep
[18:32:44] <twnqx> so how do you use it with C?
[18:33:08] <Xark> twnqx: IIRC, the C++ stuff is just high-level interface (there are lower level C interfaces).
[18:34:01] <twnqx> aery::gpio_set_pin_high(AVR32_PIN_PC04); <- makes you wonder how they get the port / pin out of that
[18:34:27] <twnqx> i would hope that it's not with a huge switch() statement :P
[18:34:40] <malinus> twnqx: how else would you do it?
[18:34:52] <malinus> that's probably most efficient
[18:34:58] <twnqx> using that
[18:35:00] <twnqx> and efficient
[18:35:02] * Xark finds a quote "Notice that Aery32 Framework is a C/C++ framework and thus you can write your code in both C and C++. Just put the C code in .c files and C++ code in .cpp files."
[18:35:04] <twnqx> in the same sentence
[18:35:22] <twnqx> first of all, it would turn into a linear iteration
[18:35:41] <malinus> no, a modern compiler should make a jump table, no?
[18:35:43] <twnqx> unless the whole code it in the header file, and the compiler can eliminate it
[18:36:12] <twnqx> depends
[18:36:17] <Xark> twnqx: What are you saying? I don't see why that wouldn't bake down to a single "set port bit N high" instruction?
[18:36:51] <Xark> twnqx: I strongly suspect it is all in a header...
[18:37:10] <twnqx> then it could work out okish
[18:38:28] <Xark> An example of a "bad" design would be digitalWrite() <- very silly, see
http://pastebin.com/dSRSxgax
[18:41:25] <twnqx> that's what this would turn into if it's not in the header and the compiler can't use jumptables
[18:42:13] <Lambda_Aurigae> http://dangerousprototypes.com/2014/12/08/atmel-releases-new-low-power-mcus/
[18:43:19] <twnqx> malinus: and given the 8bit avr's a harvard arch, i think it's kinda hard to generate effective jump tables
[18:43:42] <twnqx> though hm
[18:44:31] <twnqx> probaby could shit the operand, lpm the base of the jump table, add both, and do an indirect jump
[18:44:34] <twnqx> shift*
[18:45:20] <malinus> Xark: idk. if it's bad. Sure it takes about 2200% longer time to complete, but people using the arduino library don't care about that.
[18:45:54] <specing> Are there any opensource tools for these Xplained boards?
[18:45:55] <Xark> malinus: It is bad because it is gratuitous waste (especially with constant pin number). :)
[18:45:59] <specing> *debbuger?
[18:46:22] <twnqx> specing: gdnb + that jtag bridge? ;)
[18:46:25] <twnqx> gdb*
[18:46:33] <malinus> Xark: but that's like saying python is bad. It's also "waste".
[18:46:40] <twnqx> well, python is bad.
[18:46:41] <Xark> malinus: It is. :)
[18:46:46] <malinus> I knew it, haha
[18:46:47] <twnqx> and scripting language is
[18:46:49] <twnqx> any*
[18:47:24] <specing> twnqx: gdb can do it?
[18:47:26] <twnqx> i put them into the gratitious string operations & regex point of programming
[18:47:32] <malinus> That's false though. Each thing has their own use. Arduino is great for kids/learning, scripting languages are great for scripting.
[18:47:34] <specing> Sorry, I haven't done AVRs for like a year
[18:47:35] <twnqx> there's a debug bridge to jtag
[18:47:44] <twnqx> i forgot the name though
[18:47:50] <specing> twnqx: Is there a software setup howto somewhere?
[18:47:57] <specing> 9$ is really cheap
[18:48:12] <Xark> malinus: I do understand it is a time to develop vs time/energy wasted using equation. However, no reason to be pointlessly slow. Python is good for some purposes, slow digitWrite helps no one (even if tolerated).
[18:48:12] <twnqx> avarice.
[18:48:13] <specing> almost as cheap as the 5$ stellaris boards ;)
[18:48:17] <twnqx> was the name of the thing
[18:48:42] <malinus> Xark: I would argue that digitalWrite helps 1000's of people get into embedded
[18:49:01] <malinus> one might argue that's a bad thing though :P
[18:49:32] <Xark> malinus: Yes, and it would help even more if written correctly. I will mention it used to be efficient, but they F-ed it up when they added Leonardo compatibility (with run-time lookup table).
[18:49:54] <malinus> heh
[18:50:10] <malinus> is that the 32-bit board?
[18:50:15] <twnqx> no
[18:50:20] <twnqx> 32u2
[18:50:23] <twnqx> and 32u4
[18:50:34] <malinus> ah
[18:50:34] * twnqx has 4€ leonardos from last china trip
[18:50:46] <twnqx> AND THEY ARE THE FUCKING WORST DEVEL BOARDS EVER
[18:50:47] <malinus> china trip = ebay?
[18:50:57] <twnqx> no, shenzhen
[18:51:07] <twnqx> really
[18:51:21] <malinus> they actually have electronics markets there with ebay-prices?
[18:51:36] <twnqx> whoever designed that board in a way that pin 8 of both 8bit ports is driving the LEDs
[18:51:48] <twnqx> so you end up guaranteed to not have a single complete 8bit port on the IO
[18:51:51] <twnqx> should be shot
[18:52:07] <twnqx> sure
[18:52:14] <malinus> don't shoot the poor undergrad indian boy
[18:52:16] <twnqx> and they have taobao (chinese ebay)
[18:52:24] <malinus> pls
[18:52:32] <twnqx> no, he deserves it
[18:52:44] <malinus> no, he needed money for family of 12 :(
[18:52:49] <twnqx> doesn't matter
[18:52:59] <twnqx> if you don't have enough braincells to do it right, don't do it
[18:53:10] <malinus> it was a well-paying job. He only had to work 250hours, in two weeks.
[18:53:30] <twnqx> if you need 250h to design that pile of shit, you already failed at it
[18:53:39] <twnqx> that's more like a 2h job
[18:54:03] <specing> he had to design 500 of those shits in 250h
[18:54:17] <twnqx> there are 500 different arduinos? god
[18:54:49] <malinus> yes, there were also arduino-relay pcb's, and arduino-LED pcb's, and many others
[18:55:57] <specing> Is there a way to make atmel store estimate shipping cost?
[18:56:07] <Xark> twnqx: Are you sure he didn't just copy Leonardo reference design to break up ports? :)
[18:56:15] <specing> ... without actually signing up?
[18:56:21] * Xark doesn't see any full ports http://1.bp.blogspot.com/-t_ur-MRJgJg/UtoqQQDkJ0I/AAAAAAAAAok/YRxCyzg9EaA/s1600/ArduinoLeonardo_PinOutDiagram.png
[18:56:25] <twnqx> yes
[18:56:27] <twnqx> of course
[18:56:30] <twnqx> it's a copy of that
[18:56:38] <twnqx> i said leonardo is shit, no?
[18:56:47] <twnqx> i mean, even states "made in italy"
[18:57:33] <Xark> twnqx: Ahh, I thought you were picking on the cloner. :)
[19:04:07] <specing> lol @ made in italy
[19:04:19] <specing> that board will surely fail twice
[19:04:31] <specing> fail/capitulate
[22:15:57] <apo_> huh
[22:16:38] <apo_> mega32u4: ADMUX = 0; ADCSRB = 0; ADCSRA = (1<<ADEN) | (1<<ADSC) | (1<<ADATE) | (7<<ADPS0); PORTF = 0; DDRF = 0;
[22:16:59] <apo_> Did I forget anything to do continuous ADC reads on ADC0?
[22:17:02] <apo_> 'cause I keep getting 1023
[23:13:12] <Tom_itx> apo_
[23:13:13] <apo_> -.- forgot to set the proper reference. Need AVCC, not AREF ~_~
[23:13:29] <apo_> Tom_itx?
[23:13:35] <Tom_itx> also the bitshift ADPS0 should be 1<< not 7<<
[23:13:42] <Tom_itx> and aref
[23:13:51] <apo_> no, 7 is correct
[23:13:57] <apo_> I want a prescaler of 128
[23:14:11] <apo_> ADPS[2:0] are continuous
[23:14:13] <Tom_itx> mmm ADPS0 isn't a bit register?
[23:14:15] <Tom_itx> ok
[23:14:25] <Tom_itx> i would have shown them individually
[23:35:29] <apo_> It's working! Guitar effects! :D
