Back
[01:36:38] <ferdna> what does LC means in a "LC Meter"
[01:36:40] <ferdna> lol
[01:38:31] * Casper throws an inductor and capacitor at ferdna
[01:39:30] <ferdna> auch!
[01:40:03] <Casper> did that answered your question? :D
[01:40:56] <ferdna> no
[01:41:25] <Casper> what is the letter used for inductor and capacitor on a board?
[01:41:54] <ferdna> no idea
[01:42:00] <ferdna> but let me guess
[01:42:01] <ferdna> L
[01:42:36] <ferdna> https://en.wikipedia.org/wiki/Reference_designator
[01:44:09] <Casper> now you have your answer I guess?
[01:44:26] <ferdna> i think so... but not sure yet...
[01:45:01] <Casper> L is inductor, C is capacitor
[01:45:10] <Casper> you will also see some LCR meter
[01:45:28] * Casper pokes the slowpoke :D
[01:47:49] <ferdna> i know i know... lol...
[01:47:59] <ferdna> i made you say it! hehehe
[01:48:31] * Casper throws glitters at ferdna
[05:57:15] <Emil> Can anyone recommend an i2c/spi memory chip?
[05:58:27] <Emil> 2Mbit should be enough
[05:58:52] <Emil> Even 1Mbit would do
[05:59:58] <Lambda_Aurigae> ram or flash?
[06:01:22] <Lambda_Aurigae> 23LC1024 or 23LCV1024 for spi serial sram
[06:01:47] <Lambda_Aurigae> LC can do spi, spi dual or spi quad
[06:01:48] <Emil> Ram
[06:02:02] <Lambda_Aurigae> lcv can do spi or spi dual and has an option for battery backup making it nvsram.
[06:02:11] <Lambda_Aurigae> 20MHz interface.
[06:02:32] <Lambda_Aurigae> http://www.microchip.com/wwwproducts/en/23LC1024
[06:02:40] <Lambda_Aurigae> http://www.microchip.com/wwwproducts/en/23LCV1024
[06:03:07] <Emil> It is for storing a 800x600 eink pic
[06:03:17] <Lambda_Aurigae> there ya go then.
[06:03:24] <Emil> And also to do wireless updating
[06:03:43] <Lambda_Aurigae> I've used them for generating 800x600 vga...did some interlace magic with two of them.
[06:04:01] <Lambda_Aurigae> and with 8 of them at once for color.
[06:04:51] <Emil> sounds interesting
[06:06:07] <Lambda_Aurigae> lots of external bits to get things working..it was too unwieldy.
[06:06:35] <Lambda_Aurigae> have since shifted from avr to pic32 and things went a bit smoother.
[06:09:08] <Emil> Id love to transition to arm
[06:11:23] <Lambda_Aurigae> ARM is another level of complexity I'm not ready to jump to yet.
[06:11:59] <Lambda_Aurigae> pic32 is complex enough being a MIPS32/M4K core with pic peripherals slapped on.
[10:36:44] <carabia> Lambda_Aurigae: not being too familiar with pic32, but ARM isn't really that complex once you get into it
[10:37:34] <carabia> well, at least m0,3,4,7
[10:38:54] <carabia> you just wanna prepare to calculate clocks for buses and enabling/disabling them. After that it's smooth sailing
[10:39:48] <Lambda_Aurigae> that and I just don't feel like buying arm stuff and making boards to solder them to.
[10:39:59] <Lambda_Aurigae> not when I have plenty of pic32 samples from microchip to play with
[10:40:04] <Lambda_Aurigae> and can breadboard them.
[10:42:28] <carabia> yeah, but for example st's nucleos go for next to nothing. Just a thought.
[11:00:26] <_ami_> twnqx: have you implement custom IRQ for GPIO pins in Linux kernel?
[12:53:07] <twnqx> _ami_: lolno
[12:56:19] <_ami_> twnqx: i have been trying to write driver for a usb based gpio i/o expander. i able to create gpio at host side.. the only issue is to attach irq to these pins. i know i need to create irq_chip for the gpio_chip.
[12:57:05] <_ami_> i called gpiochip_irqchip_add() and on call to request_irq, i can see entry of new irq in /proc/interrupts.
[12:59:42] <_ami_> but the ISR in not getting called when event occurs
[12:59:49] <_ami_> what could be the reason?
[13:00:03] <_ami_> my hardware is based on avr (vusb)
[13:00:12] <_ami_> i wrote a demo driver which emulates GPIOs :
[13:00:24] <_ami_> https://github.com/amitesh-singh/ldd/blob/master/platform/gpio-irqchip/gpio-irqchip.c
[13:00:38] <_ami_> gpio access device:
https://github.com/amitesh-singh/ldd/blob/master/platform/access-gpio-modern/access-gpio.c
[13:00:52] <_ami_> i just wonder why irq handler is not called whenever i do echo 1 > or o > value in /sys/class/gpio/gpio<N>/ ?
[13:01:00] <_ami_> on cat /proc/interrupts
[13:01:11] <_ami_> 36: 0 0 0 0 irq-gpio 0 platform-gpio-device
[13:01:20] <_ami_> but the IRQ functions nver get called on setting gpio state to 0 or 1
[13:21:20] <twnqx> wouldn't you normally need the hardware to trigger the irq through some mapping`
[13:35:25] <_ami_> twnqx: even in case of usb i/o expander, its not possible. i do need to wait for usb msg from device whenever interrupts happens at avr pins.
[13:35:37] <_ami_> may be i should use soft interrupts
[13:36:02] <_ami_> do you know how to raise interrupt explicitly?
[13:37:49] <twnqx> theoretically, you call "int xx" - an asm instruction :P
[13:50:03] <_ami_> twnqx: just checked,, msi is only for pci :/
[13:50:27] <_ami_> softirq is the only way, i guess
[18:12:55] <rdvonz> I'm having verification errors when trying to set fuse bits on an amtega328p. I've been able to write programs to the atmega fine, but I got it as a blank chip intending to replace the original atmega on an arduino board. I have an avrispmkii programmer from olimex and had to use this patch to get it to program:
http://savannah.nongnu.org/bugs/?40831 and here's the output when I try to change the fuse bits:
http://pastebin.ubuntu.com/
[18:12:56] <rdvonz> 23184150/
[18:13:37] <rdvonz> *Full link without the last bit cutoff for the avrdude output:
http://pastebin.ubuntu.com/23184150/
[18:18:36] <Lambda_Aurigae> rdvonz, normal.
[18:18:40] <Lambda_Aurigae> look at your fuses.
[18:18:51] <Lambda_Aurigae> I bet several of them are reserved
[18:19:12] <Lambda_Aurigae> what you are setting is probably 0 but they read as 1 and don't verify properly.
[18:20:12] <Lambda_Aurigae> or maybe it reads 0.
[18:20:14] <Lambda_Aurigae> I forget.
[18:20:34] <Lambda_Aurigae> but it's one way or the other. what you are setting and what you are reading are different in the efuse.
[18:20:50] <Lambda_Aurigae> check out the efuse and see if there are any reserved bits.
[18:21:02] <Lambda_Aurigae> looks like those are reading 1 but you are writing them as 0...
[18:22:27] <Lambda_Aurigae> as I suspected
[18:22:35] <Lambda_Aurigae> efuse only has the lower 3 bits you can set.
[18:22:43] <Lambda_Aurigae> the upper 5 are reserved and will always read 1.
[18:23:42] <Lambda_Aurigae> so, 0xFD is 0x05 ORed with 0xF8
[18:25:39] <Lambda_Aurigae> so, in the end, it is doing exactly right....you need to send 0xFD instead of 0x05 to get it to verify correctly...and should always write unused bits as 1 anyhow.
[18:34:41] <Lambda_Aurigae> rdvonz, make sense?
[18:44:47] <rdvonz> Lambda_Aurigae: oh! Makes sense. thanks!
[23:19:42] <jesseg> Howdy Folks!!
[23:20:27] <jesseg> hey does anyone know of a similar channel except for Microchip mcu topics?
[23:23:14] <_ami_> jesseg: ##pic
[23:24:48] <jesseg> oh thanks!! I'd tried without the extra ## so that was the key. Thanks!