Back
[04:47:28] <pewpau> do AVRs have MMUs and support for operating system development? I suppose there's nothing like that in the 8-bit chips :P
[04:47:52] <pewpau> or do you have to do it it like you did it in the dos era?
[05:03:27] <tkoskine> You do it dos-style.
[05:04:03] <tkoskine> Except that you have even less memory etc. :)
[05:04:55] <tkoskine> Check how some existing operating systems (like FreeRTOS) for AVR are doing things.
[05:20:41] <jacekowski> pewpau: no MMU
[05:21:11] <jacekowski> pewpau: and AVR is a harvard architecture
[05:21:18] <jacekowski> pewpau: not von-neuman like x86
[05:41:32] <pewpau> oh right
[05:47:09] <pewpau> jacekowski: wait, does that mean that I can't do JIT on an avr?
[05:47:59] <DKordic> :D Of course not.
[05:48:07] <jacekowski> pewpau: if you are very desperate you could use AVRs ability to self program to do something almost like it
[05:48:18] <pewpau> loool
[05:49:50] <pewpau> but you could run DOS-games on an AVR after some "minor" hacking :). Replacing the syscalls with jumps and other things
[05:52:43] <jacekowski> pewpau: actually, someone did x86 emulator on avr
[05:53:04] <jacekowski> and then ran linux on it iir
[05:53:12] <jacekowski> http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/
[05:53:17] <pewpau> nice, that's way smarter
[06:09:44] <ali1234> four hours to boot ubuntu is pretty good
[06:09:56] <ali1234> i've seen an actual PC take over an hour
[06:11:24] <Lambda_Aurigae> it was an arm processor emulator on an avr wasn't it?
[06:11:58] <Lambda_Aurigae> yeah..that's the arm one...I've never seen an x86 emulator on an avr...have seen one on an 8052 though.
[06:13:45] <Lambda_Aurigae> I built one here...is fun to play with sometimes.
[07:14:13] <twnqx> Lambda_Aurigae: qemu works in every direction ;)
[08:51:34] <LeoNerd> GAH.. so many chips that are *close* to what I want but none that are
[08:52:07] <LeoNerd> I can find programmable-direction level shifters that allow any of 1.8-5.5V on each side with no restrictions, *but* the entire chip is unidirectional at any one time with a 'DIR' pin
[08:52:48] <LeoNerd> I can find autodetecting truely bidirectional chips that work out per pin which way to go, that allow 1.2-3.6V on one side and 1.8-5.5V on the other *but* the high side must be higher than the low side.
[08:59:46] <LeoNerd> This doesn't feel a lot to ask for.. 3.3V in one side, anything from 1.8V to 5V in the other; bidirectionally like the TXB0108 does. Just without that stupid "VccB >= VccA" restriction
[11:09:37] <Quantumcross> sorry back, my internet disconnected
[11:09:58] <Quantumcross> did anyone answer my question?
[11:11:35] <Lambda_Aurigae> dunno.
[11:11:39] <Lambda_Aurigae> what was the question?
[11:13:26] <Quantumcross> quick question, what's the difference between pin change interrupt PCINT and external interrupt INT0/1
[11:13:50] <Quantumcross> is the only difference that PCINTs are shared per port?
[11:14:26] <Quantumcross> whereas INT0/1 are single pin interrupts tied to their own functions, and configurable for rising/falling/both edges?
[11:14:51] <LeoNerd> INT<n> can also be level-based, whereas PCINT are just pin-change; i.e. only on edges
[11:14:52] <Lambda_Aurigae> pin change interrupt triggers on a pin status change and triggers in groups by port...
[11:15:24] <LeoNerd> So e.g. if you have a bunch of open-drain/open-collector interrupt sources all muxed on INT0 and you set it to level-trigger mode, then all works out just fine
[11:16:24] <Quantumcross> so that's perfect, I have an optical rotary encoder that I want to trigger on any level change between them, I can put them on any pin and use PCINT to handle both of them in one interrupt handler?
[11:16:38] <Quantumcross> between them being 2 photodiodes
[11:18:32] <LeoNerd> PCINT is best for that, yup
[11:22:40] <Jartza> Quantumcross: also, INT0 has usually higher priority than PCINT
[11:22:56] <Jartza> s/INT0/INTx/
[11:26:43] <gorroth> Really interesting read:
http://jlouisramblings.blogspot.com/2012/08/getting-25-megalines-of-code-to-behave.html
[11:27:15] <gorroth> that's for getting 25 M LOC (C) to work properly on a rover and not fail from blowing the stack or doing weird things with pointers and memory allocation
[11:28:35] <Quantumcross> I plan on using V-USB so I'm leaving INT0 free :)
[12:25:01] <Lambda_Aurigae> Quantumcross, be very very careful running interrupts of any kind with v-usb..it is very timing critical and a large interrupt can totally hose your usb comms.
[12:43:08] <Quantumcross> Lambda_Aurigae: Thanks for letting me know, my interrupt is super short so hopefully it won't cause any problems, just looks at the 2 rotary encoder pins and ++-- a counter
[12:53:31] <Lambda_Aurigae> make sure your counter is declared volatile.
[12:53:39] <Lambda_Aurigae> otherwise it might not get updated properly.
[12:54:05] <Lambda_Aurigae> v-usb is a fun toy but for anything serious I would recommend real usb hardware or an external usb bridge.
[12:54:25] <LeoNerd> Definitely
[12:54:50] <Lambda_Aurigae> I use cheap pic microcontrollers for usb bridge to avr.
[12:55:03] <Quantumcross> I'll have to look up the volatile keyword. This is my first project, just playing around with it :)
[12:55:04] <LeoNerd> I quite like the 32U4
[12:55:08] <Quantumcross> ooh
[12:55:32] <Lambda_Aurigae> volatile is NECESSARY when updating variables inside interrupt routines.
[12:55:47] <Lambda_Aurigae> like, gotta have or you will be pulling your pubic hair out trying to figure out why it don't work.
[12:56:32] <Lambda_Aurigae> LeoNerd, I recently got some nifty little 14 pin pic chips that can do usb with no external components.
[12:56:41] <LeoNerd> Onboard osc.?
[12:56:49] <Lambda_Aurigae> yup..syncro to the usb clock.
[12:57:11] <Lambda_Aurigae> https://hackaday.io/project/6258-two-component-usb-temperature-data-logger
[12:57:47] <Lambda_Aurigae> pic16f1455, pic16f1454.....and a slightly larger pic16f1459 with more features.
[12:57:51] <Lambda_Aurigae> all in the same base family.
[12:58:11] <Lambda_Aurigae> and they work with the open/free m-stack.
[12:58:29] <Lambda_Aurigae> you are supposed to have a cap on the 3.3V outfeed but it works without.
[12:58:54] <Jartza> evening
[12:58:57] <Lambda_Aurigae> they make a great little substitute for an ftdi chip.
[12:59:03] <Lambda_Aurigae> morning Jartza
[12:59:27] <LeoNerd> Oh.. PLL it from USB?
[12:59:30] <LeoNerd> cunning
[12:59:31] <Jartza> hi there
[12:59:32] <Lambda_Aurigae> yeah.
[12:59:42] <Lambda_Aurigae> just like v-usb does on the attiny85 with no external crystal.
[12:59:42] <LeoNerd> Lovely
[12:59:46] <Lambda_Aurigae> only in hardware.
[12:59:55] <Lambda_Aurigae> the pic32mx chips can do it too.
[13:00:37] <Lambda_Aurigae> lots of modern pic chips with usb can do it in fact.
[13:00:43] <Lambda_Aurigae> surprised avr hasn't done it yet.
[13:00:59] <aandrew> Lambda_Aurigae:
https://www.mixdown.ca/redmine/projects/picjug?jump=welcome
[13:01:12] <aandrew> that's one of my projects which has none of my time :-(
[13:01:19] <Lambda_Aurigae> kewl.
[13:01:37] <Lambda_Aurigae> bookmarked for later use.
[13:01:48] <Lambda_Aurigae> kinda like a buspirate almost there.
[13:02:14] <LeoNerd> Ugh.. the bus pirate is really annoying me lately
[13:02:23] <LeoNerd> It has *some* nice properties but it's tied up in more bad ones
[13:02:26] <Lambda_Aurigae> hehe..haven't touched mine in months.
[13:02:56] <aandrew> LeoNerd: that's exactly how I feel about the bus pirate too
[13:03:00] <Lambda_Aurigae> aandrew, you the one who put me onto mstack?
[13:03:12] <aandrew> don't think so. I intend on using it but haven't yet
[13:03:15] <Lambda_Aurigae> I did build a logicpirate though.
[13:03:22] <aandrew> that particular project needs some help to get mstack ported to that specific PIC
[13:03:49] <Lambda_Aurigae> aahh...it's running on the 1455..should work on the 1454.
[13:06:23] <Lambda_Aurigae> ok...gotta go load up a truck...gotta take a demo copier out this afternoon.
[13:06:26] <Lambda_Aurigae> have fun.
[13:54:28] <Quantumcross> omg it works!!!
[13:54:39] <Quantumcross> got this rotary encoder to move my mouse around
[13:54:57] <Quantumcross> now I need to figure out how to debounce the thing without introducing much latency
[13:56:23] <Tom_itx> debounce an encoder?
[13:56:49] <Tom_itx> shouldn't need much if any
[13:56:59] <Quantumcross> it's 2 photodiodes and it seems to be bouncing around a bit at the transitions? I'm not sure, I don't have a scope :(\
[13:57:11] <Tom_itx> schmitt trigger
[13:57:47] <Tom_itx> or is it just noise from poor grounding
[13:58:07] <Tom_itx> or open collector outputs on the encoder which would require pullups
[13:58:13] <Quantumcross> oh wait I think it's a code error heh
[13:58:15] <Quantumcross> one sec
[13:58:38] <Quantumcross> mixed a -- and ++
[13:58:57] <Quantumcross> oh MAN it's smooth now!!!
[13:59:15] <Quantumcross> like woah
[13:59:35] <Quantumcross> this is fun :)
[14:07:18] <gorroth> tonight, i need to do a little bit of soldering
[14:07:25] <gorroth> i'm going to put together my xbee explorer board
[14:07:32] <gorroth> then i can start working getting long range comms working
[14:08:40] <gorroth> i think i'll also go ahead and write that ISR version of the uart code using some ring fifo buffering
[14:42:49] <orzel_> hello. I'm playing with a stk-600 (using provided atmega2560). There's really no way to get a stream through the usb cable back to the pc to be able to printf ? I understand you can use the rs232 on the card / USART (lot of documentation on internet about this). but nothing is done to use the already existing usb connection ?
[14:43:56] <RafiX> orzel_, no
[14:44:50] <orzel_> :-( I dont have any serial cable, even less a computer with such an old connector....
[14:49:01] <RafiX> orzel_, a lot of new computer have serial, or you can use rs232 to usb cable
[14:51:14] <orzel_> I have 2 laptops and 3 desktop computers here. None has serial (or //), i've double-checked :-(
[14:51:23] <orzel_> i haven't started minicom for... 20 years ?
[14:51:32] <orzel_> does it even still exists ? :)
[14:51:45] <orzel_> yes, available in gentoo!
[14:53:29] <Casper> orzel_: usb is a complex protocol
[14:54:08] <Casper> first, the speed at which the device communicate with the pc have to be some fixed speed, then it need to identify itself and all
[14:54:44] <Casper> there is, however, some code that you can put on the avr to be able to simulate a usb-serial cable, but it take lots of ressources on the avr
[14:55:09] <Casper> unless, you use an usb native one, then the code is smaller, but still complex
[15:45:13] <orzel_> Casper: i was not thinking about direct usb (it's already used by the stk-pc communication. But i thought the stk-600 firmware would provide a (simplistic, uart-based) communication channel to the UC.
[15:45:26] <orzel_> that's what I would have done, anyway.
[15:45:31] <orzel_> serial is just, so... well, you see
[15:45:59] <orzel_> seems like my motherboard has some internal serial connector
[15:46:03] * orzel_ digging
[15:57:56] <orzel_> Ok, done (and hotplugged :-)
[15:58:29] <orzel_> anybody here using linux ? What's the last trend for a modern terminal to hook to serial port ?
[16:00:27] <orzel_> dterm/minicom/picocom/screen/serialclient
[16:00:30] <Quantumcross> I havn't done much serial but I thought the standard was minicom?
[16:00:55] <orzel_> it was very very long ago, that's for sure
[16:01:13] <orzel_> CuteCom is a serial terminal, like minicom, written in qt <- sounds great :)
[16:01:50] <orzel_> last release 2009, webpage looks like not-even 80's... <- looks a lot less great :/
[16:01:51] <Quantumcross> ah, well I like to keep it CLI :)
[16:02:00] <orzel_> i'm gonna keep it cli as well :)
[16:03:31] <orzel_> screen /dev/ttyS0 <- great
[16:07:57] <Bushman> ave
[16:09:08] <Bushman> heh
[16:09:18] <Bushman> orzel_: i still use minicom
[16:09:38] <Bushman> i even added one line with it to my make file
[16:10:17] <Bushman> after i compile and flash the chip, i run minicom on the same serial port to talk to the µC
[16:10:34] <Bushman> the
[16:10:37] <Bushman> ups
[16:10:50] <Bushman> (missclick)
[16:17:53] <orzel_> Bushman: not sure to understand, you don't have a terminal with minicom started all the time ? Your make rule start a terminal with minicom ?
[16:18:39] <Bushman> yes. because the µC is flashed AND communicated with via the same USB cable
[16:18:42] <Bushman> :P
[16:19:11] <Bushman> and running minicom placec lock on /dev/ttyN
[16:19:46] <Bushman> i flash using tarduino bootloader as my programmer
[16:20:07] <Bushman> not very elegant but very handy.
[16:20:43] <Bushman> especially when i can buy cheap arduino knockoffs for the price of the bare chips :P
[16:21:07] <Bushman> already assembled, soldered and flashed with bootloader ;]
[17:28:39] <gorroth> i like using minicom over screen, because it provides more options
[17:31:22] <gorroth> Bushman: which arduino knockoffs are you talking about? i've seen arduino mini pro at about the same price as the bare chip, but they weren't soldered already
[18:42:17] <|DM|> how do I find what baudrate avrdude is using with a set programmer
[18:42:42] <|DM|> and also how do I let avrdude know what clockrate the target board is at, so that it can use the correct baudrate
[18:43:14] <|DM|> I'm asking this cause after switching my attiny to the 8mhz internal clock, I had to manually pick a baudrate so that avr wont fail after initiating contact
[18:53:11] <Tom_itx> In general, the clock frequency should be at least 4 times larger than the target clock frequency.
[18:53:43] <Tom_itx> 1Mhz clock 250khz program rate
[18:57:32] <Jartza> |DM|: you sure you didn't leave "divide clock by 8" fuse active?
[18:58:25] <Jartza> 8MHz should program fine with 2MHz programmer speed
[18:58:45] <|DM|> Indeed, I had to manually set the baud rate to 19200
[18:59:27] <|DM|> But programming fails if I just do "avrdude -P /dev/ttyUSB0 -p attiny45 -c avrisp -U flash:w:blink.hex
[18:59:41] <|DM|> adding -b 19200 fixes it
[18:59:58] <|DM|> specifically , it fails after it connects to the attiny
[19:02:46] <Jartza> sounds weird
[19:23:22] <ferdna> just wanted to share this with you guys:
[19:23:22] <ferdna> https://www.youtube.com/watch?v=SDqooP5XQHo
[19:28:06] <Bushman> gorroth: nano
[21:58:24] <Quantumc1> Is 4.3V on an aruino nano... ok? That's what I'm getting over usb
[21:59:37] <Tom_itx> what's the chip specs?
[21:59:42] <Tom_itx> that will tell you
[21:59:46] <Tom_itx> it probably is ok
[22:00:15] <Tom_itx> ppl keep forgetting they're just avr chips
[22:02:00] <Quantumc1> yeah I'm getting weird flip-flipping logics though
[22:02:04] <Quantumc1> I think it might be software though
[22:03:26] <Quantumc1> because the flops are follwing a weird pattern
[22:06:16] <Casper> Quantumc1: AVR can work from like <2.7V up to 5.5V, however at reduced voltage you may need to use a slower clock than the max one, will be ok with internal RC oscillator
[22:06:18] <Casper> and...
[22:06:27] <Casper> investigate on why you only have 4.3V
[22:06:38] <Casper> it is abnormal unless a diode is present
[22:27:47] <tchebb> Hey all! I'm in the process of learning AVR assembly, and I had a question about the interrupt vector table size defined in the libc headers. My device is an ATMega32U4, and the datasheet says that there are 43 interrupt vectors, each two bytes long. However, in avr/iom32u4.h, VECTORS_SIZE is defined to be (43 * 4), suggesting that each vector is four bytes long. Is this an error, or am I just misunderstanding something?
[22:32:41] <Casper> I forgot.. if it is 2 bytes long or 2 words long...
[22:33:04] <Casper> if it's 1 word, then it is most likelly wrong...
[22:41:44] <gorroth> Bushman: thanks; i'll check them out
[23:42:18] <tchebb> Casper: Just did some testing; looks like the datasheet addresses are in words, so VECTORS_SIZE is correct. Thanks for the clarification!
[23:43:15] <Casper> yeah it's confusing that they talk about words and address...
[23:43:20] <Casper> and bytes..
[23:46:46] <Xark> Makes some sense because Flash is 16-bit memory (and not byte addressable for code - other than LPM).
[23:47:24] <Xark> (but yeah, I found the datasheet a bit confusing too) :)
[23:54:24] <Casper> it make sense, but they should talk more about the address being words... specially when they mix bytes with words and dwords
[23:55:08] <Xark> No argument. :)