#avr | Logs for 2016-07-19

Back
[02:40:32] <pepijndevos> What is the simplest way to add a screen with a framebuffer to an AVR? I found the AVR on my Arduino Mega has an external memory interface, so maybe I could attach some RAM and a controller to that?
[03:00:59] <_ami_> pepijndevos: whats the display size?
[03:01:22] <_ami_> pepijndevos: is it a colored TFT?
[03:03:11] <pepijndevos> _ami_, tbd. I'd like a small colour tft.
[03:04:21] <pepijndevos> I looked at a couple of controllers, and almost all of them seem to use this 8 bit 8080 bus.
[03:06:17] <pepijndevos> I have one of those SPI shields from Adafruit, but they are much to slow to do animations, which is why I'm looking into implementing a framebuffer, which also seem much more convenient than sending bytes over SPI.
[03:10:08] <pepijndevos> I'm also a bit confused why datasheets call it an 8080 compatible bus. From what I've seen the 8080 uses the same 16 bit address line and 8 bit data line. Those screens just use 8 bits and some command structure.
[03:11:55] <_ami_> pepijndevos: i recently bought this. http://www.aliexpress.com/item/1-8-inch-TFT-LCD-Module-LCD-Screen-Module-SPI-serial-51-drivers-4-IO-driver/32580365136.html?spm=2114.13010608.0.67.atOfLA although it will take time to reach my doorsteps.
[03:12:27] <_ami_> Does it going to work with any microcontroller? like i have atmega16a and m328p
[03:12:28] <_ami_> ?
[03:15:05] <_ami_> pepijndevos: http://w8bh.net/avr/AvrTFT.pdf
[03:18:55] <pepijndevos> reading...
[03:21:22] <pepijndevos> _ami_, like I said, SPI displays are too slow. I tried, I tried very hard, and optimized the shit out of it, with this as the result: https://www.youtube.com/watch?v=QvVO6pY9WNY
[03:51:28] <_ami_> pepijndevos: zooming :P
[03:51:46] <_ami_> looks slow
[04:16:04] <pepijndevos> _ami_, right, so I'm looking for a way to drive a display much much faster.
[04:30:50] <carabia> pepijndevos, yeah, like an ili9341 (iirc) has multiple different buses you can use
[04:31:05] <carabia> BUT, for a fast screen what you want is a bigger micro with proper DMA
[04:32:28] <carabia> fast, and well convenient.
[04:32:45] <carabia> your options are pretty much to go for an xmega, pic, or an arm
[04:32:45] <_ami_> carabia: which mcus? Xmegas?
[04:32:50] <_ami_> aha
[04:32:51] <_ami_> ok
[04:33:18] <_ami_> carabia: any pic would do better jobs than atmegas?
[04:33:43] <carabia> well, a lot of PICs provide DMAs
[04:33:58] <carabia> and they come with a lot of RAM too
[04:34:12] <_ami_> ok
[04:34:21] <carabia> but, i'd recommend an arm, really
[04:35:00] <carabia> CM3's come with an external memory interface
[04:35:27] <carabia> use it as a buffer and then dma transfer from memory to the lcd
[04:36:05] <carabia> well, tft lcd, semantics
[04:36:38] <carabia> cm3's come with all kinds of nice goodies, like SDIO, too
[04:37:00] <carabia> Wow. abcminiuser is it really you?
[04:37:14] <abcminiuser> Yep, in the pseudo-flesh
[04:37:27] <carabia> Woah. What are you up to nowadays
[04:37:29] <abcminiuser> I've had a migraine all day and had very, very little sleep, but I'm alive and kicking
[04:37:45] <abcminiuser> Working at blackmagic now (www.blackmagicdesign.com) and yes, it's awesome
[04:37:47] <carabia> last I remember you were doing some shizzle with rgb leds
[04:38:17] <abcminiuser> Ah yeah, LIFX
[04:38:26] <abcminiuser> That was certainly...an experience
[04:38:32] <carabia> Yeah, like wi-fi controlled lighting
[04:38:33] <_ami_> abcminiuser: i was just googling abt dma and spi and guess who answered there! :)
[04:38:35] <carabia> How so?
[04:38:42] <_ami_> abcminiuser: http://www.avrfreaks.net/forum/xmega128a1-dma-and-spi
[04:39:14] <abcminiuser> TL;DR don't work for start-up companies, they are full of people seeking to be top of the hill rather than make cool stuff.
[04:39:52] <abcminiuser> Hah _ami_ neat, I haven't been on 'Freaks for a while
[04:39:54] <carabia> yeah, I know exactly what you mean
[04:40:26] <abcminiuser> To be honest, with me working on random ARM and soft-core FPGA processors from multiple vendors over the last two and a bit years, the AVR stuff's half fallen out of my brain
[04:40:37] <abcminiuser> Past-me sounds like he knew what he was talking about tho
[04:40:52] <abcminiuser> My latest project just got released last week: https://www.blackmagicdesign.com/media/release/20160715-01
[04:40:55] <_ami_> abcminiuser: indeed, it is. :)
[04:41:12] <_ami_> you knew what you were talking abt then. :)
[04:41:18] <abcminiuser> I did visit Atmel two weeks ago though, as part of my honeymoon
[04:41:27] <abcminiuser> It was freaking awesome to see everyone again, I really miss them all
[04:41:37] <abcminiuser> (they seemed to tollerate me OK, so that was nice)
[04:41:43] <carabia> norway?
[04:41:59] <abcminiuser> Yeah, went to Denmark, Sweden and Norway
[04:42:08] <abcminiuser> (Copenhagen, Stockholm and Trondheim)
[04:42:30] <carabia> so how was it now that they finally sold out
[04:42:38] <carabia> for the lack of understanding business... :)
[04:42:57] <carabia> they holding onto their seats?
[04:45:17] <abcminiuser> I'm under NDAs and gentleman's agreements not to spill the beans, but I did leave much happier than when I went in
[04:45:31] <abcminiuser> Doesn't look like it will be the huge calamity I expected it to be
[04:46:00] <abcminiuser> I'll never say I'm happy they sold, but they could have gotten a worse buyer
[04:47:37] <carabia> I'll just read between the lines, then
[05:02:49] <_ami_> carabia: CM3 comes in DIP pkg too?
[05:03:16] <_ami_> possible to program an ARM on the breadboard?
[05:04:58] <carabia> of course not. If you want high-performance in DIP, PIC's your only choice, then
[05:05:08] <carabia> Well, actually that's not true. IIRC NXP has some arm-cores in DIP
[05:05:16] <carabia> or maybe *a core*
[05:05:21] <carabia> just can't remember what.
[05:05:44] <carabia> probably it's a cm0+
[05:06:22] <carabia> of course if you really want to do things the wrong way, you can buy a qfp-dip adapter... :)
[05:06:30] <_ami_> :)
[05:06:52] <carabia> But I think nxp is the only vendor that has any arms in dip
[05:08:14] <_ami_> By googling a bit, it seems quite a big leap to ARM from 8bit mcu :P so i think i would require a fair bit of learning/time spent on the way.
[05:08:41] <_ami_> carabia: which should be first arm for a beginner?
[05:09:06] <_ami_> probably i should buy a arm board first
[05:09:28] <_ami_> STM32 Cortex-M3 ?
[05:09:35] <carabia> I started with an atmel cm0+, which was a total pain
[05:09:49] <_ami_> i would like to avoid the pain :P
[05:10:03] <carabia> this was more due to ASF than the actual architecture, though
[05:10:33] <carabia> so I guess the real argument is that ASF is a pain to begin with. Obviously you can bypass it completely but, I was just starting out with them
[05:10:56] <carabia> STM32's library for cm3 is really nice
[05:11:02] <carabia> STM's rather
[05:11:25] <carabia> I can wholeheartedly recommend that. Also stm's dev boards are super cheap compared to, say atmel
[05:11:51] <_ami_> carabia: http://www.aliexpress.com/item/Free-Shipping-1pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduin0/32498344057.html?spm=2114.30010308.3.1.YAakt6&ws_ab_test=searchweb201556_8,searchweb201602_2_10057_10056_10055_10049_10017_405_404_10059_407_10058_10040,searchweb201603_1&btsid=7affb67d-6fd8-4152-a9b3-9755810b6f05
[05:12:26] <carabia> For example, yes
[05:13:00] <carabia> Bare in mind that mcu does not have an external memory interface, just by looking at the pin count.
[05:13:15] <carabia> But then again, if you want external memory interface, you really want it on the board itself.
[05:13:22] <carabia> The memory chip, that is
[05:13:53] <carabia> There was a cheap chinese board that had flash and ram on-board, with an stm cm3
[05:15:24] <carabia> Regardless, in addition to the board get a cheap st-link v2 clone also while you're at it. Costs $5 or so, programming and debugging via swd
[05:15:46] <_ami_> ok, noted down
[05:15:48] <_ami_> thanks
[05:16:28] <carabia> Or, stm's own nucleo boards have a built-in st-link on them, with tabs so you can actually break it off the board if you want.
[05:18:34] <carabia> for programming i use eclipse and gnu-arm with openocd for debugging, KEIL (= ARM) has a free-version of their ide, with their proprietary compiler, comes with a 32K code-size limit
[05:20:26] <carabia> and then there's IAR EWARM, which doesn't have a free version, licences for both keil and ewarm are both measured in thousands of dollars. ~$5-6k
[05:21:36] <_ami_> :O
[05:22:29] <carabia> oh and rowley crossworks also has a code-size limited free edition. So far gnu arm and eclipse has been working out okay. The gurus say it produces debatable code, and that for instance KEIL's compiler produces much smaller footprints (would make sense, since keil IS arm)but I have no experience nor interest to start paying that much money for a license...
[05:59:14] <pepijndevos> carabia, are there any beginner friendly CM3 boards that you'd recommend?
[06:00:35] <pepijndevos> It does make me wonder how the GameBoy does it. I mean, that runs at 4MHz, and I can't do it with an AVR at 4 times the speed.
[06:01:39] <pepijndevos> ARM can obviously do it at a hundred times the speed. PIC with DMA sounds more in line with what the GameBoy would do I guess?
[06:22:44] <Lambda_Aurigae> pepijndevos, I bet the gameboy has a video controller chip.
[06:22:46] <carabia> not saying you can't do it
[06:23:20] <carabia> and nintendo's a big enough corporation so they could even roll a specialized chip for it, I assume
[06:23:36] <carabia> that said, it probably has a video driver chip yeah
[06:23:54] <Lambda_Aurigae> as for your earlier question on the 8080 bus...the bus interface has 16 bits of address and 8 bits of data...they can be multiplexed together or not..and a device really doesn't need all those address lines, just enough to support it's own registers...usually 2 to 4.
[06:24:19] <carabia> I'm not saying you couldn't somehow do it. I'm saying doing it with a buffer in ram and dma is probably the most convenient way of doing it
[06:25:03] <carabia> though, for example the ili9341 (used to drive those 240x320s for example) has a buffer of it's own
[06:25:05] <Lambda_Aurigae> that AVR external memory interface is fun to play with and very powerful...but it is kinda picky.
[06:26:10] <Lambda_Aurigae> and the AVR really isn't made for doing video although it is done quite often. People have come up with multiple ways to generate video from the AVR.
[06:26:44] <Lambda_Aurigae> playing a video? that's going to need lots of storage and high speed access to it...like an SD card.
[06:27:16] <carabia> Lambda_Aurigae, yeah, preferably 4-bit
[06:27:31] <Lambda_Aurigae> or 1-bit monochrome.
[06:27:43] <carabia> well yeah but I think he was talking about doing color
[06:27:50] <Lambda_Aurigae> yup.
[06:28:24] <Lambda_Aurigae> and since he is talking arduino gear, I'm guessing only programming in the arduino environment which is going to slow down any code horribly.
[06:28:47] <Lambda_Aurigae> most people who do any kind of useful video generation on an AVR do it in assembly.
[06:29:47] <Lambda_Aurigae> not saying it can't be done in C, just,,,it gets ticky with the timing stuff.
[06:30:11] <Lambda_Aurigae> if you are using an external video controller chip with its own memory then it gets considerably easier.
[06:30:45] <carabia> Or, get one of these, for example. http://www.hotmcu.com/hystm32f1xxcore144-coredev-board-p-2.html?cPath=1_20
[06:31:19] <carabia> Though initing an arm can be quite a shocker if you're coming from an arduino perspective, I imagine... :)
[06:31:44] <carabia> But it's not really that bad
[06:32:13] <Lambda_Aurigae> I have managed to get 800x600 16 color from an avr, kindasorta.
[06:32:27] <Lambda_Aurigae> I used external SQI interfaced serial srams.
[06:32:29] <carabia> yeah, keyword kindasorta
[06:32:46] <Lambda_Aurigae> it was actual 800x600 vga,,full res.
[06:33:17] <Lambda_Aurigae> but the AVR was only providing the timing pulses really...an external clock circuit drove the whole thing and just clocked data out of the srams.
[06:33:22] <pepijndevos> Lambda_Aurigae, I don't have a problem with assembly or an external chip, but I have not found anything that would allow me to do more than one frame per second.
[06:33:55] <Lambda_Aurigae> pepijndevos, get an old ISA vga card.
[06:34:07] <carabia> Lambda_Aurigae, so it was kindasortamaybe like dma, yea?
[06:34:20] <Lambda_Aurigae> well,,
[06:34:29] <pepijndevos> My problem is that the ili9341 does not seem to be an 8080 bus as you describe it. There are no address lines at all.
[06:34:41] <Lambda_Aurigae> more like an external framebuffer that I wrote to during the vertical blanking interval.
[06:35:01] <carabia> well yea
[06:35:51] <Lambda_Aurigae> pepijndevos, D[17:0] for data bus...IM[2:0] for address bus.
[06:36:05] <Lambda_Aurigae> kindasorta.
[06:36:49] <Lambda_Aurigae> it seems to have 4 addresses...
[06:36:57] <Lambda_Aurigae> page 27 of the datasheet from adafruit.
[06:36:59] <Lambda_Aurigae> it's there.
[06:37:39] <Lambda_Aurigae> 8080-II interface is on page 30.
[06:38:48] <Lambda_Aurigae> it can also do a 3/4 line serial...basically SPI with modifications.
[06:40:01] <Lambda_Aurigae> so, yes, it has 2 address lines...
[06:40:16] <Lambda_Aurigae> IM1 and IM0
[06:40:34] <Lambda_Aurigae> hence, IM[2:0]]
[06:41:03] <Lambda_Aurigae> other addressing interface would require some external hardware decoding.
[06:41:24] <Lambda_Aurigae> http://tinyvga.com/avr-isa-vga
[06:41:25] <pepijndevos> Uhm, so it's not like it exposes the GRAM, but rather some registers you can write to.
[06:41:27] <Lambda_Aurigae> you could do that.
[06:41:31] <Lambda_Aurigae> yeah.
[06:41:38] <Lambda_Aurigae> just like most memory mapped peripherals.
[06:41:47] <Lambda_Aurigae> it's in the datasheet
[06:42:04] <Lambda_Aurigae> you use registers to write to the memory.
[06:42:11] <pepijndevos> So what does memory mapped mean in this context? Hmmm
[06:42:25] <Lambda_Aurigae> you are mapping the registers to the host CPU's memory interface.
[06:42:49] <pepijndevos> I see.
[06:43:01] <Lambda_Aurigae> same as it has meant for,,,oh,,,,35+ years that I've been programming and doing hardware interfaces to computers.
[06:45:09] <Lambda_Aurigae> done it with 6502, 68000, 8080, 80186 and newer x86 chips, and a couple of AVRs with external sram interface.
[06:50:47] <Lambda_Aurigae> anyhoo, time to go to work.
[06:50:55] <pepijndevos> thanks
[06:52:41] <pepijndevos> I was confused by the fact that it memory maps the registers and not the memory itself.
[12:50:51] <_ami_> LeoNerd: did you ask this q mate? http://electronics.stackexchange.com/questions/121249/how-to-put-a-74hc165-on-an-spi-bus/128220 :D
[12:52:22] <LeoNerd> I believe I did yes
[12:55:31] <_ami_> LeoNerd: just one q, in case of using 74hc165 on spi bus, the avr mcu would be slave?
[12:55:42] <LeoNerd> ??
[12:55:43] <LeoNerd> No
[12:56:24] <_ami_> data pin would be MISO?
[13:00:16] <LOMAS> hello there .. I really got confused about the memory inside a st7920 based 128x64 glcd
[13:01:07] <LOMAS> I just know that CGRAM for charactor generator RAM and DDRAM is for display data ram
[13:01:22] <LOMAS> but there are lot more different things in here http://imgur.com/zWen17X
[13:01:54] <LOMAS> can someone suggest according to those features in the figure ?
[13:02:08] <LOMAS> lets have a cool discussion :D
[13:03:16] <_ami_> LeoNerd: https://github.com/amitesh-singh/amiduino/blob/master/avr/atmega16a/shiftreg/hc165/spi/spi.c
[13:03:23] <_ami_> this should work fine
[13:03:24] <_ami_> ?
[13:05:10] <LOMAS> actually I just interfaced 128x64 glcd with mega32 using u8glib, but it is much slower.. refrase rate is about half a second
[13:06:16] <LOMAS> so thought to write my one simple and fast kind of code of glcd.. but really don't know about all those memories and thought to create a dissussion and make myself clear
[13:44:38] <LeoNerd> _ami_: please actually read my text
[13:47:38] <Lambda_Aurigae> read?!?!!
[13:47:43] <Lambda_Aurigae> blasphemy!
[13:54:13] <_ami_> As compare to hc595, hc165 did not get much attention on internet. i don't find much link abt it :P
[13:54:51] <LeoNerd> Read the actual text of the actual question that I posed. that you actually linked to
[13:57:33] <_ami_> LeoNerd: i understood ur question. i know its not abt what i asked
[14:01:05] <LeoNerd> Right
[17:40:04] <Lambda_Aurigae> http://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[17:40:09] <Lambda_Aurigae> good read for all.
[19:12:38] <kre10s__> I'm reading the atmega48 datasheet. The MEMPROG section speaks of lock bits that can be used to disable "Further programming and verification of the Flash and EEPROM in Parallel and Serial Programming mode"... So if I set these I can no longer write the flash? can I do a chip erase and reset these fuses?
[19:13:43] <Lambda_Aurigae> yes
[19:13:56] <Lambda_Aurigae> chip erase wipes the lock bits along with the data in the flash.
[19:14:10] <Lambda_Aurigae> but that makes the data unusable.
[19:14:29] <kre10s__> Nice. that's exactly what I want.
[19:14:55] <kre10s__> So I can protect my code but still make the devices flashable.
[19:15:14] <Lambda_Aurigae> keeps you from writing to the flash...AND...being able to read it.
[19:16:40] <Lambda_Aurigae> I think you can still rewrite it with a bootloader though.
[19:16:44] <Lambda_Aurigae> pretty sure you can.
[19:20:27] <kre10s__> yea. SELFPRGEN allows you to enable/disable SPM.
[19:20:51] <kre10s__> But I'm more interested in making the code not readable while still allowing you to flash the chip.
[19:21:00] <kre10s__> via SPI that is.
[19:22:57] <Lambda_Aurigae> then the lock bits are your friend.
[19:23:00] <Lambda_Aurigae> that's what they are for.