|
Post by spiff on Feb 16, 2007 11:29:53 GMT -5
Define buggy. Mine in running flawless. I tuned OSCCAL before I actually started playing with it. Buggy, as in sometimes it just stops during transfer. I haven't done any tuning of the RC oscillator, but I have been discussing the issue with Lars. I will do some more testing, both with tuning the various timings in the IEC routines and perhaps even try to drop in an X-tal, just to make sure.
|
|
|
Post by spiff on Feb 17, 2007 15:39:21 GMT -5
After changing the delay in line 235 of IEC_driver.c from 5 us to 20 us it works flawlessly ;D
Still haven't done anything to tune the RC oscillator, but I might look into it some more when I decide to make an actual PCB instead of having it wired up on my STK500 development board.
|
|
|
Post by rrolison on Feb 17, 2007 20:26:46 GMT -5
This is what I use to fine tune the internal oscillator. It divides the clock by 10,000 and produces a pwm on the MISO line. A scope or a frequency counter is used to measure the output. 730hz would equal 7.30mhz... I trimmed my OSCCAL value to get the cpu to run @7.60mhz ;------------------------------------------------------------------------------------------- jmp RESET ; Reset Handler jmp RESET ; IRQ0 Handler jmp RESET ; IRQ1 Handler jmp RESET ; IRQ2 Handler jmp RESET ; Timer2 Compare Handler jmp RESET ; Timer2 Overflow Handler jmp RESET ; Timer1 Capture Handler jmp RESET ; Timer1 CompareA Handler jmp RESET ; Timer1 CompareB Handler jmp RESET ; Timer1 Overflow Handler jmp RESET ; Timer0 Compare Handler jmp RESET ; Timer0 Overflow Handler jmp RESET ; SPI Transfer Complete Handler jmp RESET ; USART RX Complete Handler jmp RESET ; UDR Empty Handler jmp RESET ; USART TX Complete Handler jmp RESET ; ADC Conversion Complete Handler jmp RESET ; EEPROM Ready Handler jmp RESET ; Analog Comparator Handler jmp RESET ; Two-wire Serial Interface Handler jmp RESET ; Store Program Memory Ready Handler ;------------------------------------------------------------------------------------------- .include "m32def.inc" ;------------------------------------------------------------------------------------------- Reset: ;------------------------------------------------------------------------------------------- ldi r16,high(RAMEND) ; Main program start out SPH,r16 ; Set Stack Pointer to top of RAM ldi r16,low(RAMEND) ; out SPL,r16 ;------------------------------------------------------------------------------------------- ldi ZH, 0x00 ; Fill entire block of ram with 0's 0060-0860 ldi ZL, 0x60 clr r0 Erasing1: st Z+,r0 cpi ZL,0x60 brne Erasing1 cpi ZH,0x08 brne Erasing1 ;------------------------------------------------------------------------------------------- ldi r16,0xC4 ; Original Byte was BF out OSCCAL,r16 ;------------------------------------------------------------------------------------------- sbi DDRB,6 MainLoop: sbi PORTB,6
ldi r22,0x6F ldi r24,0x13 rcall Delay
cbi PORTB,6
ldi r22,0x6D ldi r24,0x13 rcall Delay
rjmp MainLoop ;------------------------------------------------------------------------------------------- ;---------------------------------------------------------------------------------- ; Delay routine (overhead = 20 Atmel Clocks: determined by using delay of 0) ;---------------------------------------------------------------------------------- Delay: lsr r22 ; 1 brlo Delay_1 ; 1/2 Delay_1: lsr r22 ; 1 brsh Delay_2 ; 1/2 nop ; 1 rjmp Delay_2 ; 2 Delay_2: inc r22 ; 1 inc r24 ; 1 Delay_3: nop ; 1 dec r22 ; 1 brne Delay_3 ; 1/2 nop ; 1 ldi r22, 0x3F ; 1 dec r24 ; 1 brne Delay_3 ; 1/2 ret ; 4 ;-------------------------------------------------------------------------------------------
;------------------------------------------------------------------------------------------- .exit ;-------------------------------------------------------------------------------------------
|
|
|
Post by andydtv on Feb 24, 2007 15:34:17 GMT -5
I've also just completed building a MMC2IEC - its such a sweet and elegant little device.
I've gotten a "load error" one time though - if that happens more often, i'll try that OSCCAL calibration too.
P.S. Any chance to get some sort of fast loader support for this?(I guess I'm too spoiled by PC ...) A specific MMC2IEC fastloader would be sufficient; perhaps we could use the DTV user port for parallel transfers?
|
|
|
Post by spiff on Feb 24, 2007 18:41:27 GMT -5
I've gotten a "load error" one time though - if that happens more often, i'll try that OSCCAL calibration too. I talked to LarsP about this. After changing the timing slightly he did some tests with anything from 7 to 9MHz and it worked without problem. So it should be fairly forgiving. From time to time I get a "file not found" error - ususally when I try to load a directory. I think this might be related to resetting the DTV without resetting the MMC2IEC, but I am not sure. In any case, resetting the MMC2IEC with a LOAD"<<",8 solves the problem. P.S. Any chance to get some sort of fast loader support for this?(I guess I'm too spoiled by PC ...) A specific MMC2IEC fastloader would be sufficient; perhaps we could use the DTV user port for parallel transfers? I guess these options are all possible, although they may be somewhat difficult to implement. Also, you will have to either load the fast loader on the DTV before using the device, or install a new kernel in the DTV which has the fast-loader routine built-in. Unfortunately this will most likely create conflicts with the DTV kernel that handles the flash file system.
|
|
|
Post by jsaily on Feb 25, 2007 0:23:38 GMT -5
Spiff, the same thing is evident with 1541-III. You need to reset the flash drive AFTER resetting the DTV. That's why we included a switch to reset the PIC processor manually. I know MadModder has experimented in getting an automatic IEC reset connected to the DTV reset.
|
|
|
Post by andydtv on Feb 25, 2007 4:28:02 GMT -5
I guess these options are all possible, although they may be somewhat difficult to implement. Also, you will have to either load the fast loader on the DTV before using the device Yes, thats what i though - like in good old 1541 days, first load the (small) fastloader, then load the (big) program. That way compatibility wouldn't be touched, because without fastloader you would just use the normal IEC-connection.
|
|
|
Post by racob on Mar 9, 2007 1:01:12 GMT -5
Hello,
Haven't done any programming on AVR...with Lar's board, can someone give me some pointers where to start (after building the project of course). I am looking at the source, haven't done this either but is willing to spend time learning it...(I quess this is th ebeauty of it--learning with the help of the expert).. 1. I see a hex file..is this all I need to program the AVR 2. Do I need a programmer unit or what is the best, simplest way... I see Spiff's "lab"...that is way to "hi-tech" but I have some hardware/software knowledge... so please help me with some pointers where to begin....
I looks like this is my alternative to Pyrofer's since he is no selling for now.. Thanks
|
|
|
Post by gmoon on Mar 9, 2007 7:57:40 GMT -5
Here's a nice intro to AVR programming with ISP (In System Programming.) The MMC2IEC board includes an ISP connector. www.instructables.com/id/E5H5UDWB5UEUKIKV8V/Includes both Linux and Windoz info. You would need a working parallel port for the programmer. Note: the ISP cable used here is a DAPA five-pin type; the ISP pinout on the MMC2IEC is a six-pin (std Atmel STK500 cable.) But the AVR lines used are the same for both, except for VCC, which you don't need. Wire the correct par port pins to the 6-pin connector (ignoring VCC) and you'll be fine. You can buy a 6-pin cable that works without the STK500 dev board, but making your own is easy.... Here's a description of the DAPA cable, but a somewhat safer design (a few current limiting resistors added): www.linuxfocus.org/English/November2004/article352.shtml
[NOTE: without the VCC pin the board needs to be powered externally during programming. But you'd need power anyway . Get the 3.3v directly from the DTV.]
|
|
|
Post by racob on Mar 9, 2007 9:11:26 GMT -5
thank you gmoon..i will be busy this next couple of week..I will follow you leads...thank you so much
|
|
|
Post by gmoon on Mar 9, 2007 9:33:46 GMT -5
One more thing, racob:
The MMC2IEC page states that a normal ATmega32 (5V) works fine with 3.3V at 8 mHz for this project. I'm not sure that ISP programming (without the STK500 dev board) will be 100% reliable at 3.3V.
Best use a low-power IC--ATmega32L. It's only a bit more expensive, and still works fine @ 5V, too. DON'T connect the MMC2IEC to 5V--the MMC/SD cards can't handle it... But the 32 or 32L controllers could.
If you made your own PCB (or even just a perfboard proj) you could design it for the 40-pin dip package. Much bigger, but you could socket the chip and remove it, if you have problems.
|
|
|
Post by spiff on Mar 9, 2007 13:43:26 GMT -5
The MMC2IEC page states that a normal ATmega32 (5V) works fine with 3.3V at 8 mHz for this project. I'm not sure that ISP programming (without the STK500 dev board) will be 100% reliable at 3.3V. I had no L-version, so I also used the 5V ATmega32, and have had no problems running it at 3.3V. I use an STK500 for programming via ISP, with the board programmed at 3.3V, and had no problems with this either, so it is not an issue with writing to the flash. The only problem that might occur is if the device is powered by 3.3V and the programming signals are 5V. I guess this is where the current-limiting resistors in the more advanced programmer some to their right.
|
|
|
Post by gmoon on Mar 9, 2007 14:42:04 GMT -5
I use an STK500 for programming via ISP, with the board programmed at 3.3V, and had no problems with this either, so it is not an issue with writing to the flash. With the parport DAPA cable I've had the occasional problem at 8mhz+, even @ 5V. Given the the variety of parallel ports, your mileage may vary . I'm sure the STK500 is solid. Like to get a Dragon myself, but it doesn't seem to be well-supported in Linux yet...
|
|
|
Post by racob on Mar 10, 2007 1:10:57 GMT -5
It is kinda funny to say that I have to order my parts first from DIGIKEY..since our source here don't stock these parts locally (I am from BC, Canada -- we have more computer stores than electronic parts stores)...thanks for the help...I will have time to learn more about these AVRs until my parts arrive..and yes, I did order the 40pin package...thanks GMoon
|
|
|
Post by andydtv on Mar 10, 2007 5:19:52 GMT -5
I assume that the "L" AVRs, like many processors nowadays, are just a matter of selection.
E.g. they produce AVRs, test some, and if those tested work fine on low voltages, they are labeled "L". The one without "L" are either not tested (which should be most) or failed the test (which shouldn't happen too often if the chips are all produced the same).
So if you don't sell the units and don't need 1000% reliability, 5v version should be fine if you can't find the 3.3v version.
This is just what i assume, i don't have any facts on it.
Mhhh.... just an idea ... did someone using a 3.3v type encounter those occasional "load errors" as well?
|
|