Back
[04:13:58] <_abc_> Hello. I am under the impression that there is a project by someone to make a PIC programmer based on one of the popular avr programmers. True? I can't find anything now online.
[04:14:09] <_abc_> But I may have seen such a thing in the past.
[04:23:23] <DKordic> _abc_: (USB) PIC based programmers for AVR were mentioned in this channel.
[04:25:47] * l9 yawns morning all
[04:27:28] <_abc_> DKordic: is there a channel log?
[04:29:08] <_abc_> So can we talk on channel about an avr based pic programmer DKordic ? It's not a secret.
[04:30:40] <l9> why would it be a secret?
[04:30:52] <DKordic> :D
[04:31:34] <_abc_> Eastern European privacy reflexes die slowly. It's even harder for non Eastern Europeans to understand. DKordic I'm in .ro .
[04:32:25] <l9> DKordic:
http://paste.debian.net/779941/ the programmer from hell i recond
[04:34:33] <l9> dont think you would be arrested for messing around with avr programming pic, but you never know
[04:36:55] <antto> wat
[04:39:35] <antto> it'd be nice to have something like avrdude for pics, cuz pickit3+pk3cmd is semi-broken and uber slow
[04:40:56] <DKordic> !logs
[04:41:03] <DKordic> -_-
[04:41:22] <DKordic> _abc_:
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23avr/YYYY-MM-DD.html
[04:41:34] <DKordic> !log
[04:42:23] <_abc_> DKordic: you are a better bot than the bot is
[04:42:29] <_abc_> thanks ;)
[04:42:44] <_abc_> antto: pickit3 is not *semi* broken
[04:42:46] <antto> we had a bot?
[04:43:10] <antto> _abc_ pk3cmd is, and pickit3 is uber slow
[04:43:14] <_abc_> Am setting up sdcc + gnupic / gptools for proper work on pics on linux, the usb avr -> pic programmer is part of that picture
[04:43:19] <antto> that combo is semi-useless
[04:43:54] <_abc_> Has anyone got some performance figures on V-USB? Can I hope to sustain say 10kBytes/sec speed with 115200 set as baud speed? With no dropouts?
[04:44:11] <antto> i'm using the same stuff, on windows.. sdcc, code::blocks, pickit3+pk3cmd
[04:44:43] <antto> and i also use code::blocks, avrgcc, olimex avrispmk2+avrdude
[04:44:52] <antto> guess which one "just works" ;]
[04:44:58] <_abc_> :)
[04:45:04] <antto> the difference is night and day
[04:45:15] <_abc_> Anyway a usbasp which can do pics would be welcome, I think.
[04:45:26] <_abc_> Which is the direction I am going into.
[04:45:35] <antto> that be nice
[04:46:01] <antto> as long as it's coupled with a proper commandline app
[04:46:13] <_abc_> usbasp hw at least. But it will have v-usb cdc connectivity in the beginning to the controlling pc because debugging in binary is a chore
[04:46:25] <_abc_> Sure. Probably even operable from a serial terminal.
[04:46:46] <_abc_> And possibly standa-alone too.
[04:47:12] <_abc_> I need that feature. Programming a pile of boards is not pc friendly. Need a handheld tool with a button a beeps.
[04:47:21] <antto> pk3cmd takes ages to even print its name and begin parsing commands
[04:47:27] <DKordic> _abc_: Why on Earth VUSB!?
[04:47:41] <antto> yeah, usbasp isn't very reliable
[04:49:01] <DKordic> NYH2P: “Whenever faced with a problem, some people say `Lets use AWK.' Now, they have two problems.” -- D. Tilbrook, [[USENET]], 1988
[04:49:47] <_abc_> DKordic: that problem was later optimized, they now use Perl for that.
[04:50:01] <DKordic> XD
[04:50:17] <_abc_> DKordic: and in web situations, php5+ and or node or jquery
[04:52:09] <DKordic> 2016-07-07T14:50 <LeoNerd> I'm surprised nobody's done a simple ATmega16U2-based programmer yet, instead of all that VUSB crap
[04:56:45] <_abc_> V-USB is nice because it's a simple one stop solution for starters.
[04:57:08] <_abc_> Later it will move towards hid like control like usbasp and probably on native USB capable mcus.
[04:57:22] <_abc_> But I want the entry level to be at least as open and accessible as usbasp is.
[04:57:33] <_abc_> atmega8a usb cable and a few passives.
[05:00:37] <DKordic> _abc_: Don't You think that some USB-UART bridge (FTDI) would be far easier than VUSB?
[05:03:03] <antto> iirc there was something similar to the FTDI but which doesn't need special drivers (recent OSes would recognize it as serial port immediately)
[05:03:43] <_abc_> DKordic: The project will NEVER contain a ftdi or other usb bridge
[05:03:56] <_abc_> DKordic: Not mine, at least. It will do native usb or v-usb style usb
[05:04:13] <_abc_> Btw it appears that new enhanced arch pics are now fast enough to do v-usb style usb too.
[05:04:27] <_abc_> By that I mean 8 bit small ones.
[05:04:50] <_abc_> Plus there's native usb hw on a few already, they are all <$2.5 in ones retail in Europe.
[05:06:07] <DKordic> antto: IIRC Microchip and Maxim have alternatives. And yes, I would avoid FTDI
https://news.ycombinator.com/item?id=8493849 .
[05:06:20] <antto> _abc_ why usbasp? there are some slightly better programmers available, like the avrisp2 clone, which can run on avr chips which have usb
[05:06:45] <_abc_> As I said, I want the entry level, at least one kind, to be the lowest common denominator.
[05:06:57] <_abc_> Should work in a simple breadboard with dip chip etc.
[05:07:28] <_abc_> I am not interested in competing in speed, feature set, or anything like that. I want a very low entry level bar.
[05:07:47] <antto> DKordic we have a few such FTDI chips, and we had to "fix them" by modifying the driver.. but it's not a permanent solution, so avoiding the FTDI is a better idea
[05:07:51] <DKordic> _abc_: I would rather use a separate breakout board for USB-{SPI,UART} bridge than VUSB.
[05:08:25] <_abc_> No breakout boards, no bridges. $10 maximum parts cost including breadboard cpu and cable.
[05:08:37] <antto> _abc_ entry level, for people that don't know what they're doing yet?
[05:08:54] <_abc_> Maybe.
[05:09:07] <antto> i was at that same state when i picked up a usbasp.. it's terrible, because it semi-worked
[05:09:35] <antto> that, combined with my noobness resulted in bricking an expensive board
[05:10:42] <_abc_> usbasp works great, the only dodgy part is the ZENER DIODES ON USB. Real men only read datasheets when the smoke comes out and sometimes not even then.
[05:11:10] <antto> i thought it didn't work because verification always failed
[05:11:15] <antto> so i kept trying and trying
[05:11:15] <_abc_> Those zeners are a gross usb bus violation, they have very widely spread zener voltages, nowhere near 3.6, and 150pF capacitance each.
[05:11:30] <_abc_> Also the power supply arrangement is beyond dodgy.
[05:11:39] <_abc_> I fixed that and I have good results with stock firmware.
[05:11:42] <antto> turns out, the usbasp was flashing the firmware, but the actual verification was broken
[05:11:52] <DKordic> _abc_: I still don't understand how VUSB can be an option? Do it properly, for example LUFA.
[05:11:55] <_abc_> antto: what actual verification?
[05:11:59] <antto> i didn't know that, so while i kept trying i did random things and bricked it
[05:12:03] <_abc_> DKordic: V-USB is LUFA
[05:12:26] <antto> _abc_ when you flash with avrdude, avrdude verifies by default
[05:12:34] <_abc_> Yes, and?
[05:13:00] <antto> and usbasp doesn't read properly then
[05:13:24] <antto> thus verification fails, thus you think you failed to flash your hex, so you retry..
[05:13:25] <_abc_> I did not see that happen with late version firmware.
[05:13:43] <antto> yes, i'm talking about a few years ago, and chinese usbasp
[05:13:57] <_abc_> Okay, I must do things. DKordic I told you what I want to do, it will be open ended, one can add whatever to it.
[05:14:00] <antto> maybe the usbasp now is great
[05:14:10] <_abc_> DKordic: so we can keep talking from time to time.
[05:14:39] <_abc_> China never bothers to update firmware or such. 1st move after getting a china usbasp is to update the firmware. You get two, and use them on each other.
[05:15:02] <antto> i updated it afterwards
[05:15:20] <antto> with a parallel port ;P~
[05:15:23] <_abc_> It's just like a large copier shop, if you give them a copy of a document with a dead fly squished on it, all 10,000 copies you ordered will have the dead fly image on them.
[05:15:28] <antto> i ain't getting another usbasp
[05:16:00] <_abc_> I didn't "get" an usbasp I did the breadboard thing. It's for developing into the other thing we were talking about.
[05:16:12] <antto> k
[05:49:04] <_ami_> antto: usbasp works pretty great. i even though wrote a bootloader based on usbasp. it works great.
[05:49:39] <_ami_> i hv a usbasp programmer made by an indian company. and it works. i plan to make my own usbasp when i get some free time.
[05:50:14] <_ami_> antto: i bought usbasp from
https://www.robomart.com/
[07:07:41] <dk__> has anybody read this book? Some Assembly Required: Assembly Language Programming with the AVR Microcontroller ?
[07:07:55] <dk__> how is this book/
[07:07:56] <dk__> ?
[07:08:34] <dk__> any pdf link for this book?
[07:22:33] <pepijndevos> How fast/slow is the external RAM interface on Atmega2560, and can this be changed?
[07:24:35] <pepijndevos> I'm wondering if it'd work with a GameBoy cartridge. The GameBoy runs at 4Mhz, so I fear the AVR will be too fast,
[08:02:06] <Lambda_Aurigae> pepijndevos, it's pretty fast but not as fast as internal ram.
[08:02:22] <Lambda_Aurigae> I'm guessing you want to emulate a gameboy on the avr?
[08:22:07] <l9> looks like its not my programmer but avrdude bug #40831
[08:27:50] <l9> usbtiny avrisp mkII lufa programmer
[08:55:46] <Lambda_Aurigae> DKordic, I have a partially functional usbPIC based avr programmer.
[08:58:14] <DKordic> Lambda_Aurigae: Interesting. Where could I see more about it?
[08:58:24] <Lambda_Aurigae> it's not online.
[08:58:57] <Lambda_Aurigae> mostly it's a pic32mx270f256b playing usb-serial adapter and a programmer inside that's serial interfaced.
[08:59:03] <Lambda_Aurigae> based around stk500 protocol.
[08:59:52] <Lambda_Aurigae> I ripped the stk500-ish code out of the avr-doper v-usb reference project.
[09:00:41] <Lambda_Aurigae> having 64K of sram gives me a 48K buffer too if I ever get it implemented.
[09:01:04] <Lambda_Aurigae> all that is in the shed that has no power. I'm never online from over there,,or hardly ever...maybe this winter.
[09:01:33] <Lambda_Aurigae> workshed is 60 feet from the house and generator powered, unfortunately.
[09:03:26] <Lambda_Aurigae> it'll probably end up next to the enc8j60 ethernet interfaced programmer I started building 5 years ago.
[09:03:27] <DKordic> Lambda_Aurigae: What is on PC side?
[09:03:44] <Lambda_Aurigae> breadboarded it, tested the first steps, then forgot it.
[09:03:55] <Lambda_Aurigae> pc side just works with avrdude or anything that works with stk500 in theory.
[09:04:41] <Lambda_Aurigae> it just shows up on the pc as a usb-serial port.
[09:07:06] <Lambda_Aurigae> one of about 30 projects I've started and never finished.
[09:07:52] <Lambda_Aurigae> and,,,gotta go back to making sawdust....putting up lattice around the deck.
[09:18:48] <pepijndevos> Lambda_Aurigae, that's far in the future. First step is just reading the ROM.
[09:19:38] <pepijndevos> Lambda_Aurigae, I'm more worried that a cartridge designed for a 4Mhz cpu will not work when the AVR drives it at 20Mhz. But I can;t find what spped it's driven at.
[09:21:35] <Lambda_Aurigae> so slow it down.
[09:21:52] <Lambda_Aurigae> I doubt the avr ram interface is directly compatible with that cartridge interface anyhow.
[09:22:06] <Lambda_Aurigae> you will likely have to bitbang it.
[09:23:21] <Lambda_Aurigae> how big is the rom on that cartridge anyhow?
[09:24:37] <pepijndevos> Lambda_Aurigae, they both have 16bit address bus, 8 bit data bus, read and write line.
[09:24:55] <pepijndevos> How do I slow it down? Run the AVR at a lower frequency?
[09:25:21] <Lambda_Aurigae> just because they have those busses does not mean the bus protocols are compatible.
[09:26:22] <Lambda_Aurigae> the external ram interface can run down to about 1/5 the main clock speed it seems...more or less...that's not exactly correct as it is only in the wait states that give the ram time to settle, not in the address setup times.
[09:27:35] <Lambda_Aurigae> you can have 1 wait during read/write, 2 during read/write, or 2 during read/write and 1 before driving the new address.
[09:28:23] <Lambda_Aurigae> there are timing tables in there that show exactly what timing is for each wait state setting compared to the system clock.
[09:28:32] <pepijndevos> It seems like a pretty simple interface, so unless some polarity is reversed, I would say it has a chance of working.
[09:28:47] <Lambda_Aurigae> and how big is the rom on that chip?
[09:28:52] <Lambda_Aurigae> how is it mapped?
[09:29:02] <Lambda_Aurigae> on the cartridge, rather.
[09:29:08] <pepijndevos> Ok, so I need to dig in and understand wait states. And dig up info about the cartridge.
[09:29:15] <Lambda_Aurigae> yeah.
[09:29:24] <Lambda_Aurigae> you can't just hook it up and expect it to work...
[09:29:39] <Lambda_Aurigae> you have to configure it...map the rom to the microcontroller's ram space...
[09:29:48] <pepijndevos> Well... it depends. It has a memory bank controller which allow you to page 16kb blocks of rom.
[09:30:07] <pepijndevos> and an additional line to access ram.
[09:30:14] <Lambda_Aurigae> the cartridge does or the original game box?
[09:30:35] <pepijndevos> The cartridge has both the sram, rom and bank controller on it.
[09:31:18] <Lambda_Aurigae> that's gonna be fun to control.
[09:31:30] <pepijndevos> I think the ROM can be up to 2MB, depending on which controller the cartridge has.
[09:32:16] <pepijndevos> Very fun indeed. I'll probably end up bitbanging it, but the external ram option seems very tempting.
[09:33:17] <Lambda_Aurigae> so it appears that on the gameboy, no memory exists on the gameboy itself...it is all in the cartridge, from what I'm seeing.
[09:33:40] <pepijndevos> Pretty much.
[09:33:55] <Lambda_Aurigae> this has already been done on an ardweeny.
[09:34:36] <pepijndevos> The external memory bit? I only know of a bitbanged version using an UNO and shift registers.
[09:35:01] <Lambda_Aurigae> not with external hardware ram interface...just interfacing the cartridge.
[09:36:46] <pepijndevos> The insidegadgets on, right? He/she is using a shift register, which sounds horribly slow.
[09:36:51] <Lambda_Aurigae> it appears to be a z80 type or 8080 type ram interface.
[09:36:58] <Lambda_Aurigae> so,,,you have a good chance of it working.
[09:37:07] <Lambda_Aurigae> kick your wait states way up as high as they will go.
[09:37:25] <pepijndevos> Oh, is that a thing? *googles z80 ram interface*
[09:37:33] <pepijndevos> Awesome.
[09:37:44] <Lambda_Aurigae> the chip is a modified z80
[09:37:49] <Lambda_Aurigae> the cpu on the gameboy that is.
[09:38:12] <Lambda_Aurigae> you are going to have to do some playing with memory mapping though.
[09:38:30] <Lambda_Aurigae> your AVR's internal SRAM is the first 8K of memory.
[09:39:39] <Lambda_Aurigae> which, if you were to directly map that cartridge to the AVR ram interface, will be overlapping the ROM section.
[09:40:31] <pepijndevos> Yes, I read something about masking some high address so it wraps around to access the lower parts.
[09:40:35] <Lambda_Aurigae> http://gameboy.mongenel.com/dmg/asmmemmap.html
[09:41:12] <pepijndevos> It does have internal ram, judging from that.
[09:41:18] <Lambda_Aurigae> open memory on that AVR starts at 0x2000
[09:41:34] <Lambda_Aurigae> which is right smack in the middle of ROM Bank 0
[09:42:19] <Lambda_Aurigae> yes..they have internal ram,,,and cartridge ram...
[09:42:43] <Lambda_Aurigae> so the gameboy has it's own internal memory.
[09:43:02] <Lambda_Aurigae> it seems the cartridge ram might be battery backed up on some cartridges even..to store save game stuff.
[09:43:58] <Lambda_Aurigae> so, if all you want to do is read the ROM, you can shift your entire interface up 8K and start it there.
[09:45:16] <pepijndevos> Yes, sram on the cart is battery backed for saves. Newer carts even come with a clock sometimes, with the downside that if you buy a cart from ebay the abttery is usually dead.
[09:45:49] <Lambda_Aurigae> from the pics, the battery should be easily replaceable.
[09:45:54] <Lambda_Aurigae> never owned a gameboy myself.
[09:47:02] <Lambda_Aurigae> http://www.devrs.com/gb/hardware.php
[09:47:07] <Lambda_Aurigae> lots of gameboy information.
[09:47:14] <pepijndevos> It's doable, but requires soldering. They tend to last a dozen years, so were not meant to be replaceable.
[09:47:40] <Lambda_Aurigae> standard 10 year battery.
[09:47:59] <Lambda_Aurigae> extended by the amount of time during that 10 years that you actually have the cartridge powered on.
[09:49:38] <Lambda_Aurigae> maxim/dallas has some nice NVSRAM chips with built in battery that don't actually turn on the battery until the first time you power the unit up.
[09:49:44] <pepijndevos> There is tons of information on every part of the gameboy of interest to tinkerers. Lots about the software side, less about details like the timing requirements fro the ram bus hehe
[09:50:02] <Lambda_Aurigae> once it's given power one time it switches on a little transistor that keeps the battery connected.
[09:50:46] <Lambda_Aurigae> https://dhole.github.io/post/gameboy_cartridge_emu_1/
[09:50:51] <Lambda_Aurigae> timing diagrams on there.
[09:51:19] <Lambda_Aurigae> you can compare those with the ones in the avr datasheet to see if they are anywhere close.
[09:52:26] <Lambda_Aurigae> 1MHz bus apparently.
[09:54:21] <Lambda_Aurigae> that guy is trying to emulate the cartridge, but the data is still relevant.
[09:57:52] <Lambda_Aurigae> https://dhole.github.io/media/gameboy_stm32f4/cpu_manual_timing.png
[09:58:36] <Lambda_Aurigae> that is the timing diagram you really need for comparison with the AVR timing diagram to see if they will work, logic wise...speed wise, well, only a test will tell.
[09:59:06] <Lambda_Aurigae> you will still need to build in an address latch
[09:59:29] <Lambda_Aurigae> as the AVR multiplexes the 8 bits of data on the same lines as the lower 8 address lines.
[10:00:41] <pepijndevos> Right, I think the datasheet recommends a specific latch.
[10:00:47] <Lambda_Aurigae> yup.
[10:00:58] <Lambda_Aurigae> I've done it with a couple of different ones.
[10:01:09] <Lambda_Aurigae> needs to be fast enough to handle the throughput though.
[10:01:25] <pepijndevos> 9.1.2: 74AHC series latch
[10:01:26] <Lambda_Aurigae> 74AHC latches.
[10:02:08] <pepijndevos> I'll order a few, krank up the wait times and see what I get.
[10:09:35] <pepijndevos> Lambda_Aurigae, Maybe a stupid question, but do you have any idea what's up with the clock line? Neither the AVR nor the Insider Gadget project use it, but the cart does have it.
[10:10:08] <Lambda_Aurigae> no clue.
[10:10:21] <Lambda_Aurigae> I did see something that said some cartridges have a clock.
[10:10:24] <Lambda_Aurigae> that might be it.
[10:12:33] <pepijndevos> They have a real time clock for keeping time, I don;t think that's related to the clock line, but who knows...
[10:12:41] <Lambda_Aurigae> dunno.
[10:12:53] <pepijndevos> There is a register on those carts that contains the current time.
[10:13:18] <Lambda_Aurigae> sorry...my responses will be somewhat limited...am doing online training.
[10:14:35] <pepijndevos> No problem. It's been very helpful.
[10:14:58] <Lambda_Aurigae> and all available online with a simple google search..that's how I learned it just now.
[10:20:04] <pepijndevos> The trick is googling the right things ;) All I got before were fuzzy blog posts.
[10:21:22] <Lambda_Aurigae> yes...learning what to search for is half the battle.
[10:21:37] <Lambda_Aurigae> gameboy cartridge bus interface timing
[10:22:11] <Lambda_Aurigae> game boy cartridge interface
[10:22:32] <pepijndevos> I guess this'll have to do.
http://nl.rs-online.com/web/p/latches/6631326/
[10:22:47] <Lambda_Aurigae> that's the two searches I did.
[10:23:07] <Lambda_Aurigae> and got a dozen pages of useful information.
[10:23:32] <Lambda_Aurigae> I have some of those.
[10:23:45] <Lambda_Aurigae> is your AVR 3.3V or 5V?
[10:23:59] <pepijndevos> Oh shit, out of stock. %v
[10:24:01] <pepijndevos> 5v
[10:24:08] <Lambda_Aurigae> ok..shouldn't be a problem then.
[10:24:51] <Lambda_Aurigae> glub this online training is fucking mind numbing.
[10:25:35] <Lambda_Aurigae> wish they would just give me a PDF with the information and a test to take.
[10:25:43] <Lambda_Aurigae> but noooo...they have to read it to you.
[10:25:57] <Lambda_Aurigae> some people, ME, don't learn well linearly.
[22:08:05] <rue_house> i prefer recursive descent
[22:09:12] <rue_house> what the hell do you need a latch for pepijndevos ?
