#avr | Logs for 2015-10-05

Back
[00:58:05] <Jartza> apo__: that's vga-adapter :D
[05:51:54] <FrankD> hey
[05:51:59] <FrankD> is there a channel for ATSAM devices?
[05:53:07] <apo__> Jartza: what's on the other end, though?
[05:53:25] <FrankD> and is anyone here familiar with SPI on ATTiny using the USI?
[05:55:04] <LeoNerd> FrankD: Many of us here I'm sure. If you have a question, just ask it
[05:56:02] <FrankD> just to make sure I 100% understand this, USIDR is shared between send and receive somehow?
[05:56:18] <LeoNerd> Correct
[05:56:20] <FrankD> so i send a byte and it will have a byte ready for me the clock after im done sending?
[05:56:27] <FrankD> or would that be a collision?
[05:56:33] <LeoNerd> Yup. It;s a double-ended shift register
[05:56:38] <FrankD> ie device is sending at some time as me
[05:56:46] <LeoNerd> So tx bits leave one end as rx bits arrive in the other
[05:56:54] <FrankD> ah i see
[05:57:05] <FrankD> so its not a byte by byte thing, its a bit by bit thing
[05:57:10] <Tom_itx> bidirectional magic
[05:57:12] <LeoNerd> After 8 shifts (16 clock ticks) you've now got a full rx byte in the right place
[05:57:22] <FrankD> got it, that clears a lot up
[05:57:24] <FrankD> thanks!
[05:57:50] <LeoNerd> Yes - the USI is a bit lower-level than the full SPI periph on a mega, but it's a lot more flexible
[05:57:54] <FrankD> that was SO helpful :D
[05:58:06] <LeoNerd> E.g. you can do 7/6/5/,..-bit transfers by just short counting
[05:58:14] <FrankD> right
[05:58:21] <LeoNerd> You can do 9/10/... bits by extra transfers
[05:59:20] <FrankD> thats great, im actually doing 32 bit transfers
[05:59:26] <FrankD> but i wanted to understand how it actually worked
[05:59:34] <apo__> LeoNerd: and such a pain in the ass =P
[05:59:50] <LeoNerd> OK, then you'll just have to do your four bytes individually
[06:06:52] <FrankD> yup
[06:06:58] <FrankD> code i wrote should work based on that
[06:27:19] <Jartza> apo__: anything that outputs TTL UART at 9600bps
[06:27:48] <Jartza> it supports ansi-escapes (subset) and displays 32*14 characters with 8 colors
[06:29:19] <Jartza> apo__: https://drive.google.com/file/d/0B2dTzW9TMeBxWV9LSjZBRmliVkU/view
[06:36:04] <Jartza> LeoNerd: or you can output VGA pixels with it ;)
[06:36:16] <Jartza> (USI)
[06:36:58] <LeoNerd> Well, /you/ can
[06:37:37] <Jartza> I can, too
[07:57:12] <StevenM_> hi
[07:59:04] <StevenM_> i have an attiny85 currently connected to a light sensor. i would like to communicate with it using I2C but i do not know what is the best way to do it
[07:59:28] <StevenM_> i've found a bunch of libraries, some use bit banging, others use USI.
[07:59:46] <StevenM_> any suggestions on what is the recommended way to have i2c on attiny85?
[07:59:53] <Emil_> Usi is best, bit banging fastest to implement
[08:00:31] <LeoNerd> USI makes it borderline-easier to imple,ent, and maybe a little less object code then raw bitbanging
[08:00:42] <StevenM_> okay cool
[08:00:52] <LeoNerd> Though the difference with I²C is fairly minimal, as you have to do so much of it manually anyway; like signalling start/stop conditions
[08:01:07] <StevenM_> so i have V-USB as well implemented. would either of those methods cause any issues with v-usb's processing?
[08:01:23] <LeoNerd> Hah.. Whoknows
[08:01:28] <LeoNerd> V-USB is terrible
[08:01:40] <StevenM_> agreed lmao!
[08:02:25] <StevenM_> i just thought other ic's with proper USB were overkill for such a small project
[08:02:47] <Emil_> eh
[08:02:56] <Emil_> Having usb is awesume
[08:03:06] <StevenM_> essentially getting RGB data from a light sensor and sending it to a host pc
[08:03:25] <LeoNerd> If I felt that *needed* USB I'd probably use a 32U4
[08:03:35] <LeoNerd> Failing that, if it's just "some data comms", stick it on a USB-UART bridge.
[08:03:50] <StevenM_> it is, but those ics came with a plethora of pins and functions and features that seemed uncesseary
[08:03:55] <StevenM_> that would never get used
[08:03:55] <StevenM_> etc
[08:04:04] <LeoNerd> Eh.. there's some pretty small simple ones around
[08:04:14] <LeoNerd> I've seen a few SOIC8 sized ones too.. just USB, power, TX/RX
[08:05:19] <StevenM_> oh really?
[08:05:25] <StevenM_> anything that can do i2c
[08:05:56] <StevenM_> ?
[08:05:58] <LeoNerd> FTDI probably make a USB-I²C bridge, but honestly I doubt it'll be worth the cost
[08:06:09] <StevenM_> ya exactly
[08:06:17] <StevenM_> thats why i went with the basic attiny85
[08:06:18] <LeoNerd> Cheaper (and nicer) is to avoid FTDI entirely, get something like a CPL USB-UART and stick a tiny85 on it
[08:06:45] <LeoNerd> Or an 841 if you actually want real hardware UART, which can be a lot nicer than a softserial on '85
[08:06:53] <StevenM_> that still feels like overkill for me
[08:07:07] <StevenM_> all that to avoid using v-usb which (i haven't tested yet) but could work
[08:52:03] <Jartza> well. if people won't spit on pic, they have some soic-14 chips with usb & i2c
[08:52:11] <Jartza> umm, soic-12 maybe
[08:52:39] <Jartza> no, soic-14
[08:58:56] <Jartza> like PIC16F1454
[09:03:04] <zulusbg> hello
[09:03:36] <zulusbg> i have strange problem with writing on eeprom .. i store value in eeprom on atmega 328
[09:04:09] <zulusbg> i use unsigned long j=1;
[09:04:24] <zulusbg> i have problem when counter goes more that 1024 and that counter starts from begining
[09:04:35] <zulusbg> any idea how to go over that ?
[09:05:39] <xrlk> how do I learn about UART
[09:06:04] <xrlk> I do not know the hardware involved
[09:07:46] <zulusbg> you need FTDI cable
[09:07:56] <zulusbg> also known as TTL shifter
[09:09:02] <xrlk> ok
[09:09:09] <xrlk> ur problem sounds like a buffer overflow
[09:09:29] <xrlk> idk tho
[09:09:36] <xrlk> that seems pretty small for a ulong
[09:09:43] <xrlk> idk much about embedded stuff tho
[09:48:46] <Jartza> it would be beneficial to learn about stdint.h
[09:49:05] <Jartza> and use those, then you know for sure how many bits variable has
[11:24:43] <gorroth> Jartza: HOW DARE YOU BRING UNTO THIS CHANNEL THE ABOMINATION KNOWN AS "PIC"? YOU SHALL BE SMITED FROM THE FACE OF THE EARTH FOR YOUR INSOLENCE!!!
[11:24:54] <gorroth> j/k
[11:39:05] <gorroth> i agreee that stdint.h is a good file. it is "the bomb"
[11:44:28] <antto> STDINT.H OR DIE! ;P~
[11:45:36] <antto> it's the best *.h!
[11:45:44] <LeoNerd> also stdbool
[11:46:05] <antto> yeah, and signed bool
[11:46:10] * antto sneaks out..
[12:52:58] <Jartza> gorroth: yeah, some people are believers of certain cpu core
[13:36:53] <zulusbg> i have strange problem with writing on eeprom .. i store value in eeprom on nano i use unsigned long j=1;
[13:36:53] <zulusbg> i have problem when counter goes more that 1024 and that counter starts from begining
[13:36:53] <zulusbg> any idea how to go over that ?
[13:39:48] <Chillum> would have to see the code
[13:41:44] <Jartza> yeah, pastie.org the code
[13:42:32] <zulusbg> actualy i start thread in avrfreaks
[13:42:32] <zulusbg> http://www.avrfreaks.net/forum/arduino-eeprom-problem
[13:45:57] <grey> What's the best way to get an avr talking over wifi, one of those esp chips yeah? But there's like 30 versions of those?
[13:46:32] <Jartza> zulusbg: well, arduinos EEPROM.write only writes uint8_t (byte)
[13:46:52] <Jartza> not unsigned long
[13:49:32] <Jartza> so actually it should roll over after 256 presses
[13:53:36] <Jartza> also, EEPROM.update() is more recommended
[14:00:48] <zulusbg> Jartza you suggest to change the library
[15:24:06] <Jartza> zulusbg: no, I just stated that writing to eeprom happens byte at a time with that method (write), but if you want to make eeprom live longer, you should use update (which only writes if data changes)
[15:25:02] <Jartza> I'm suggesting you use as big integer you need from stdint.h (16bit, 32bit) first and then think how to write that as bytes
[15:50:30] <zulusbg> Jartza what i see most of people suggesting to combine two eeprom memory locations
[16:06:30] <Jartza> well, that's exactly what you need to do
[16:06:36] <Jartza> but how big counter value you need?
[16:06:41] <Jartza> that's the first thing to consider
[16:06:50] <Jartza> each eeprom location stores exactly one 8-bit byte :)
[16:13:18] <Bushman> apo__: you are nitpicking.
[16:13:29] <Bushman> he clearly was using libraries
[16:13:43] <Bushman> arduino is one bigass library
[16:14:38] <LeoNerd> One big ass-library
[16:15:01] <Bushman> the point is he claimed to do that in a simple way but didn't post it so he could as well tell me he did that in 1 line of code. it still doesn't matter if he won't post the code.
[16:15:14] <Bushman> LeoNerd: heh. yea that too :D
[16:23:29] <zulusbg> Jartza i dont think to count more that 5000
[16:25:19] <zulusbg> sorry guys im trying to move out from arduino and im currently using atmega328 standalone
[16:25:26] <zulusbg> just im trying to implement my current code
[16:25:51] <theBear> don't be sorry, yer making a good move
[16:26:17] <zulusbg> yeah .. im trying to make ultra low voltage
[16:26:24] <zulusbg> currently is working on 1.5 volts
[16:32:03] <Jartza> zulusbg: oh, so you only need 16bit uint
[16:32:12] <Jartza> two eeprom bytes
[16:32:21] <zulusbg> yes
[16:33:11] <zulusbg> im uploading new for testing
[16:33:14] <zulusbg> i think i made it
[16:42:57] <zulusbg> yeap i made it
[16:43:18] <Bushman> zulusbg: wha'choo building? ;>
[16:43:36] <zulusbg> Bushman Counter for barrier
[16:44:15] <Bushman> like optical barier to count people or other stuff that comes through?
[16:44:35] <zulusbg> no no .. that is how many times barier goes up = cars get in
[16:45:40] <Bushman> http://www.maxautomation.in/ImgProd/Parking%20&%20Traffic%20Control%20Boom%20Barrier1.jpg
[16:45:50] <Bushman> for thing like this?
[16:46:10] <zulusbg> well they already build the barrier ..i make the additional stuff
[16:46:11] <zulusbg> yes
[16:46:17] <zulusbg> looks almost like that
[16:47:46] <zulusbg> they use that to cross check with parking tickets .. because in some point money are less that cars get in
[16:48:54] <Bushman> cool
[16:49:18] <Bushman> good luck with your project mate ;]
[16:49:30] <Bushman> mine is almost finished
[16:50:36] <Bushman> still need to add few switches or IFs here and there to drive a relay, and also need to enable watchdog and fine a nice place for it in my code, but the hard part is done
[16:51:55] <Bushman> i have 2 remote control inputs coming from hobby RC reciever and need 2 voltage outputs to drive 0-4V input in a mobility scooter (joystick emulator)
[16:52:22] <Bushman> but the joystick has a hardware center-switch
[16:53:01] <Bushman> it starts and stops the power inverters in the mobility scooter
[16:53:34] <Bushman> so i need to add a relay output and decide if it's on or off based on input value
[16:53:53] <Bushman> sort of hardware deadband on the joystick but emulated with software
[17:17:54] <DKordic> xmega192
[17:18:23] <DKordic> -_-
[17:18:54] <Tom_itx> it's of the xmega decent of AVR
[17:19:29] <zulusbg> Bushman what is the purpose of the project ?
[17:51:56] <apo__> Bushman: of course I am