Hi,
Let me tell you first that I don't know even basic coding so stay with me and my noob questions.
I have basic knowledge how to generate and insert the hex file into a PIC using Pickit2 programmer (MPLAB, from an existing ASM file) and basically that's it.
I wanted to build the SpinSemi M16_24 project with 99 presets from a long time only to find out now that dealing with 8051 uCUs is not quite the same thing as dealing with PICs. I tried to generate a hex file from the FV1_V1.asm file using the Mide-51 software but the original file produced 4 errors so no hex is generated and I'm not competent to figure out how to fix that. So I have the following questions:
1/ Can someone generate (from the existing files at SpinSemi's website) ready to insert hex file for this project or correct the errors in code?
http://spinsemi.com/app_download/M16_24_PROGRAMS.zip
2/ Is this 8051 OK for that project:
http://uk.farnell.com/microchip/at89c51ed2-rltum/microcontroller-mcu-8-bit-8051/dp/2695490
If not which of the Farnell's stock would you recommend?
3/ What is the most simple way to program the 8051 considering that this is an incidental project for me. What I found is this:
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
http://www.8051projects.info/resources/usb-8051-avr-programmer.23/
I have the PCB drawn already so if anyone is interested I can post it here.
Thanks in advance.
I don't see any takers but here are couple of pics of the problem:
(https://image.ibb.co/fNGJym/Errors1.jpg) (https://imgbb.com/)
(https://image.ibb.co/bukBJm/Errors2.jpg) (https://imgbb.com/)
upload a photo on internet (https://imgbb.com/)
FYI: I'm not familiar with the project and I can't remember all the 8051 variants off the top of my head anymore. In fact there an enormous number of variants from the basic 8051. The basic 8051 is so far behind the times which is why there are so many variants.
Just to get you started. That project requires an 8051 with a second counter CTR2; that's the comment and mod52 written at the top of the file. In fact it may require an 8052 because that has the extra counter.
http://www.prevailing-technology.com/publications/supportcenter/What%20Is%20the%20Difference%20Between%20an%208051,%208052,%208031,%208032,%2080C320,%20and%20an%20E5.htm
Error(4): The first error is an include file which defines the registers for the "8052". It looks like the syntax is wrong.
Error(144)(145)(147): These are occurring because the assembler doesn't know about the extra registers. The it doesn't know about the extra registers because of the previous error.
So what you need to do is:
- work out the syntax to include a file for your compiler
- find the register/processor definition file corresponding to an 8052.
As for the precise processor to use I'm not sure. The top of the file says 8k. But 8k of what ROM or RAM?
The original 8051's only had 128 *bytes* of RAM and I think the 8052's has 256 bytes of RAM.
For the Atmel devices I think the 8052's with the flash are AT89C52 something like that probably with a few variations with suffix letters. So it could an AT89C52 with 8K of flash.
Thanks for your reply but I don't have the competence to fix the code.
With my limited knowledge I also noticed an inconsistency on the schematic. It says any 8051 but the AT89C51 is strikethrough text and there's the (87C52SBBB) which is 8052 type (?). On the pic on their site the chip shown is P89LY51RD - 8051 type. It looks like at some point they upgraded to 8052 but obviously forgot to fix the code.
(https://image.ibb.co/d73R16/805xuCU.jpg) (https://imgbb.com/)
(https://image.ibb.co/hDUc8m/M16_24_pix.jpg) (https://imgbb.com/)
What assembler are you using?
ASEM-51?
If so go here,
http://plit.de/asem-51/download.htm
and get the file
"MCU files"
Inside the zip file is a folder MCU.
Then inside that folder is a whole stack of xxxx.MCU files.
Maybe start by getting the the 8052.MCU file.
Now you will have to bear with me until I can work out the syntax to include the register definitions file.
OK found it,
http://plit.de/asem-51/derivat.htm#MCUFILES
For now change line 4 to:
$NOMOD51
$INCLUDE (8052.MCU)
Put the file 8052.MCU with the source files and see how you go.
Quote87C52SBBB) which is 8052 type (?)
It definitely is an 8052 family device. I'll need to look it up to find out what's special about it.
Here's a data sheet. It's made by NXP (Philips).
http://datasheetz.com/data/Integrated%20Circuits%20(ICs)/Microcontrollers/568-1248-datasheetz.html
Page 4 has the list of devices.
You probably don't want a 87C52SBBB as that is one time programmable. The 80C52SBBB is ROM. I don't know what technology the ROM is.
Thanks for your help! It seemed to work :)
(https://s18.postimg.org/6srzle4xx/Hex_File.jpg) (https://postimg.org/image/6srzle4xx/)
There are some cheap 87C52 types on ebay so now we have to figure out which one is OK for this project.
QuoteThanks for your help! It seemed to work
Great.
See my edit on the last post about the 87xxxx.
[Sorry another Edit:
If you aren't going to do anything to the code the 87xxx might be OK.
If something stuffs up then you can't reprogram it.
The Atmel devices are definitely Flash based and you can reprogram them many times, and quickly]
I would prefer an erasable version because there's no guarantee it will work from the first time. From what I understand from datasheets it's the 80C51 family of uCUs (erasable) where 51 means 4k ROM, 52 - 8k, 54 - 16k and 58 - 32k.
Maybe I should install a PLCC SMD socket to be able to try different uCUs until it works.
Does the board you have match the PCB you posted above?
Do you have a link to PCB + schematic?
Here's what I have worked out.
1) The PCB pic you posted shows
P89LV51RD2BBC
In the datasheet I could only find info on
P89LV51RD2FBC
The package is a TQFP44 (similar to LQFP44).
We know that's an 8051 so it's not suitable.
If the PCB pic you posted is what you have then what we learn from this
is you need a TQFP package. It looks like 44 pin so that means TQFP44 or LQFP44.
2) The schematic extract you posted says any 8051 with a second counter, which means
an 8052 family device. It also shows 8K ROM.
It does not indicate RAM. I'm assuming 256 bytes.
It does not indicate an EEPROM requirement; some devices have this.
So based on those requirements I found this,
www.keil.com/dd/docs/datashts/philips/p89c5xx2_ds.pdf
In that datasheet the LQFP44 version is
P89V52X2FBD
The datasheet indicates it is a drop in replacement for 89C52.
Now my only concerns at this point are:
- If you can't program in circuit, how are you connect the programmer to the device?
If you have to buy some sort of carrier socket for a TQFP44/LQFP44 it might be expensive.
- You will have to make sure the programmer can support the specific device.
Beyond that it looks like the requirements could be met with other devices. So depending
on what devices you can source you might have to switch to another brand.
--------------------------
[Edit:
This one looks OK too.
P89C52X2BBD
https://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/P89C51,52,54,58.pdf
It might be cheaper. I think the P89V52 has onboard EEPROM and the P89C52 doesn't.
Also I found out BBD means 0 to +70C and FBD means –40 to +85. Either will work.
]
Thanks again for your comments.
All about this project is available on SpinSemi's site including the PCB layout which I redrew (accommodating for 0805 SMDs) and will upload it somewhere for reference:
http://www.spinsemi.com/mixer_application.html
After some digging it looks like this one will fit unless I missed something:
http://uk.farnell.com/w/search?range=inc-in-stock&st=AT89C51R&supply-voltage-min=2.7v&mcu-case-style=lcc|vqfp&sort=P_PRICE
According to datasheet it has plenty of ROM, 3 counters etc. and is fully 80C52 compatible. I missed the part about programming in circuit but I'll dig further.
I drew a version of the PCB to be used with PLCC SMTsocket so I'm not stuck with the wrong one after it's already soldered. Pins for in circuit programming are available on the PCB.
Last thing is to figure out is the most simple way of inserting the hex file into the uCU preferably without building a new programmer. Rumors are Pickit2 can be tricked to do that but I'll investigate further.
One thing I didn't get was whether you get only the wet processed signal from this module but adding an external mix circuit is not going to be a problem.
Now that I see USB ISP USBASP Atmel programmers on Ebay starting from dollar and a half I might as well get one if it works with this chip.
QuoteAccording to datasheet it has plenty of ROM, 3 counters etc. and is fully 80C52 compatible. I missed the part about programming in circuit but I'll dig further.
Looks good. Not sure why they label it '51 when it looks like a '52. I've used both Philips and Atmel (not that particular one) devices before and had no issues.
Quote
I drew a version of the PCB to be used with PLCC SMTsocket so I'm not stuck with the wrong one after it's already soldered. Pins for in circuit programming are available on the PCB.
No big deal just get what fits your PCB.
QuoteLast thing is to figure out is the most simple way of inserting the hex file into the uCU preferably without building a new programmer. Rumors are Pickit2 can be tricked to do that but I'll investigate further.
The devices I've used before were all programmed off-board. In fact many years ago I started to design a programmer for these devices. In general the programming procedure uses a lot of pins compared to modern devices. There were special requirements for pull-ups on some pins, and some devices were slightly different than others. I have this vague memory that some could be programmed with a 5V supply but others needed 12V. You might have more luck using the devices that have 5V programming (maybe Atmel?). Also, I don't know if some of the newer devices are easier to program.
A lot of modern devices are programmed with JTAG which doesn't use many pins and is fairly universal across chips. The 80C51 etc chips I know of don't have this.
Unfortunately I'm just that little bit out of touch with it so I can't make good suggestions.
Keep digging and see what you come up with.
Thanks for the links. If I get a chance I'll have a look over it and see if I can find anything out about programming.
It seems like dealing with 8051/2 uCU is a real PITA maybe because these were the early days I guess.
After some more digging I see the AT89C51RD2 being recommended which is ICSP and can be programmed directly from the serial COM port using simple external setup:
https://forum.allaboutcircuits.com/threads/at89c51-programmer.104033/
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
In SpinSemi's project the chip runs at 3V3 so maybe changing those zeners to 3V6 will be necessary less the power from the COM port. Or maybe I''ll use a socket and program it off board.
What I noticed on the schematic however was the ICSP connects to MOSI, MISO and SCK pins while the pins on SpinSemi's schematic use TXD, RXD and /PSEN pins.
Edit- Sorry my post was surplus to requirements and the solution already posted :icon_wink:.
Quote8051/2 uCU is a real PITA maybe
Yeah it was a bit of a pain and programmers were expensive and often large devices costing say $1000 to $4000 back in 1990. Microchips PIC programmer (around 1994) was one of the first small programmers, more like what you see today. I often did 8051 development on DS5000 devices which were serially programmable, very similar to the one you found.
QuoteIt seems like dealing with 8051/2 uCU is a real PITA maybe because these were the early days I guess.
After some more digging I see the AT89C51RD2 being recommended which is ICSP and can be programmed directly from the serial COM port using
That looks more modern. You have done well.
Quote
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
In SpinSemi's project the chip runs at 3V3 so maybe changing those zeners to 3V6 will be necessary less the power from the COM port. Or maybe I''ll use a socket and program it off board.
The basic idea looks good here and yes definitely change the zeners to a lower voltage. I'd be tempted to increase the 4.7ks to at least 10k. I'd even try 47k to 100k but it might be tricky for you to debug if it doesn't work. I don't like the micro output going back to the serial connection if the serial gets mis-wired it can connect high voltages directly to an unprotected micro pin.
QuoteWhat I noticed on the schematic however was the ICSP connects to MOSI, MISO and SCK pins while the pins on SpinSemi's schematic use TXD, RXD and /PSEN pins.
Here's where we get into details and problems. The programmer you posted has three serial signals, data IN, data OUT and a separate clock; this is call SPI. However, the Atmel device uses a different form of serial. It only has two wires TXD (data out from mpu) and RXD (data in from mpu). It doesn't have a clock. The timing and the format of the TXD and RXD signal let you get the data without a clock (a hardware block called a UART does this job) So in short the two types of serial signals are not compatible.
Just for your information there is a procedure to get the device in and out of ICSP. How this is done will vary from processor to processor. You also get incompatibilities in the signal senses like one will reset when RST is high and another when RST is low. Then there's the ordering some of the other programming signals.
Putting those details aside for now.
The next step is to find a programming system that uses standard serial (using a UART) to program the device.
This programmer looks like it has the capability to do it but it is not clear that it actually supports that mode of serial.
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
I currently going down this road, it might be a free/diy programmer:
https://www.edaboard.com/showthread.php?t=19273
http://ecee.colorado.edu/~mcclurel/AT89C51RC2_FLIP_Programming_Guide.pdf
http://www.microchip.com/developmenttools/productdetails.aspx?partno=flip
So far I can only find this connection diagram (the second one)
https://web.archive.org/web/20100214162210if_/http://atmel.com/dyn/resources/prod_documents/C51_Hardware_Connections.pdf
It is as basic as you could get. It would be possible make minor changes to use diodes and resistors like the previous circuit.
The weird thing is it has no signal for RESET, /PSEN, EA.
I can only think of building a small circuit which uses a push button to put the micro
into ICSP programming mode, then after that you run the software to program.No enough sleep or something. The third schematic has those signals.
--------------------------------------------------------------
FYI I wrote out this summary of what the AT89C51RD2 device require.
page number refer to the datasheet pages (pages written at the bottom of the pdf)
p93 Has 3 programming modes
1. ISP Programming via on chip UART and built-in bootloader
2. User Software calling boot rom routines
3. Parallel Programming mode
ISP Programming Mode:
1) Entering ISP Programming Mode
p100, 24.6.4 Activating ISP Bootloader
RST = 1 ;hold in reset
EA=1, PSEN = 0 then RST = 1 -> 0 ; falling edge of reset enters ISP Programming Mode
Then set PSEN = 1 just after falling edge of Reset (as PSEN is an output)
Device now waits for serial.
2) Serial Set-up
p102, 24.7.1 Serial configuration
Device waits for an upper case "U" to do autoboard rate detection (Fig 24.7)
Once detected, programming can commence.
The serial transfer uses a UART so the signals are self clocked,
they do not have a separate clock line.
3) Exit programming mode
There's no procedure as such. The micro is actually running code
during programming so a Reset or power cycle will just cause the micro
to boot normally and run the user's program.
4) Data Format
p102, 24.7.2 Intex Hex format data
--------------------------------------------------------------
The AT89C51RD2 processor you found should work and the FLIP programming software should be able to program it (However if the crystal frequency doesn't result in accurate enough baud rates the autobaud detect can fail.)
It just occurred to me there's another option. Choose another processor. One that has SPI based ICSP. In that case you can use the programmer from:
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
And the Pony programming software. I noticed the Pony software lists support for the AT89S8252 and AT89S53 micros. (I haven't checked those processors are suitable for the Spin board.)
At this point I have no preference to offer, it was just another angle that came to mind.
Thanks for the links and detailed comments. It looks like the AT89S8252 will be easier to program and it's also half the price of AT89C51RD2. I'm definitely going to use a PLCC socket until I get it to work or if chip replacement will be necessary.
QuoteAT89S8252 will be easier to program
Yes, it's looking that way. From what I can see it's got 8K Flash and supports counter 2.
OK, now before I order some parts and the PCB let's summarize:
1/ Final uCU choice (for now) - AT89S8253 (12k flash)
2/ Programming (on an external socket, UCC-5V) using serial port programmer and PonyProg:
http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html
3/ AT89S8253 programming pins:
1 - MOSI
2 - MISO
3 - SCK
4 - RST
4/ Good luck with all that :)
QuoteOK, now before I order some parts and the PCB let's summarize:
I checked it all against the datasheet and it looks good.
During my checking I found some other issues.
The PonyProg doesn't specifically say it supports AT89S8253 (only AT89S8252 and AT89S53)
There are posts about it, some quite old like 2008/2009,
https://duckduckgo.com/?q=pony+programmer+AT89S8253&ia=web
I cannot see any resolutions. I supposed if it worked no one would complain.
However, the fact it isn't on PonyProgs list of supported devices is of concern.
When checking I also noticed the AT89S8252 and AT89S53 are only 5V devices.
So they probably won't work on your board at 3.3V.
What a pain! The pain comes the from need for DIY a programmer that works.
OK now I'm confused. I downloaded the C++ source code for the PonyProg.
Inside the file at89sxx.cpp there is code which is handling processors AT89S8253,
AT89S8252, AT89S51 and AT89S52.
For the processors AT89S51, AT89S52 and AT89S8253 there is an extra test which is
checking something to do with the EEPROM. This check could fail (I'm not saying it will fail).
Whereas the AT89S8252 has no such check, so there is no potential to fail the check.
It could be checking something simple like some aspect of the device has been locked in some way
on previous programmings so you can reprogram it (or part of it) after that.
I'd have to go digging deeper into the code to decipher the meaning and without
any devices to play with that might take a long time.
I can conclude these possibilities:
- The AT89S8253 is supported.
- The AT89S8253 is in the process of being supported but at this point in time it doesn't work because
of some pending issues.
- Some AT89S8253's work and some don't.
- The AT89S8253 is not supported.
We need to find a post or something saying it now works or doesn't work.
In this paper the guy implies he can program an AT89S8253 using PonyProg,
http://es.elfak.ni.ac.rs/Papers/Stepenisni%20automat.pdf
Using PonyProg starts on page 30. Then on page 33 he says to select AT89C53 from the menu to program the AT89C8253.
Translation: "Slika 19. Selection of the type of microcontroller (AT89C53 corresponds to AT89C8253)"
EDIT 1:
But then I see,
http://www.edaboard.com/thread7930.html
Now the guy might just be reading the menu options to determine what is supported. I don't know.
EDIT 2: There is hope
http://ponyprog.sourceforge.net/phorum/read.php?2,728,738
In my version of PonyProg (2.08d Beta Apr 2 2017) I see AT89S8253 in the list of devices so I'd assume it's supported.
QuoteI see AT89S8253 in the list of devices so I'd assume it's supported
OK good. There was some probably some transitional period where the software changed.
That might explain why there's no recent posts asking about AT89S8253 support.
Digging still going on. It looks like Avrdude supports Pickit2 and can be used to program the AT8938253. Somebody wrote a definition file for it:
http://www.edaboard.com/thread76766.html
Pickit2 to AVRISP pins:
http://www.expkits.com/userfiles/images/urun_foto/pk2avrisp1.jpg
I installed Avrdude added AT8938253 definition it to the CONF file and now it appears in the list of devices (used Avrdudess for GUI). I'll have all parts for the next weekend so first test results are expected in a week or so.
QuoteI installed Avrdude added AT8938253 definition it to the CONF file and now it appears in the list of devices (used Avrdudess for GUI). I'll have all parts for the next weekend so first test results are expected in a week or so.
That would be very cool if it works There's a good chance it will unless the hardware (or software) has something specific that makes it incompatible.
Concerning the code and compiling the hex file now that we choose the AT89S8253 shouldn't the 89S8253.MCU file be included instead of the 8052.MCU?
QuoteConcerning the code and compiling the hex file now that we choose the AT89S8253 shouldn't the 89S8253.MCU file be included instead of the 8052.MCU?
It's usually safer to use a specific definition file. However, I suspect both will probably build (and work).
There's a base-line set of functionality which is common to many processors. If you only use those common feature's you will find the definition file isn't so critical. However each processor has it's quirks, a special feature, a special register, an extra timer, banked memory. It's when you start using these you really need a definition file that is specific as possible.
It looks like the 89S8253.MCU file didn't work and build failed. I compiled an Excel file with 8052, 89S8253 and MOD52 for comparison and from what I can there are see some differences in definitions which I can't tell if they are crucial or not.
(https://s18.postimg.org/95jbskdth/89_S253.jpg) (https://postimg.org/image/95jbskdth/)
Below is a link to the table:
https://ufile.io/ww6bg
Differences (rows number in the table):
14-15
86-88
I see the problem(s).
1) line 33
The 89S8253.MCU uses the name SCK but so does the code. So there is a conflict.
2) The others
89S8253.MCU doesn't use the symbols dph and dpl.
It uses dp0h and dp0l ; it does that because has a dp1h and dp1l so they wanted to make the names clear.
It's probably easier to just use 8052.MCU.
If you really want to use 89S8253.MCU then there's a few ways to do it. The fixes just create work for you. If you aren't going to modify the code and take advantage of the 89S8253 features, using 8052.MCU is easier.
So as you can see trying to do the "right thing" often creates trouble!
Using some deduction this is what I did from the top:
1/ Open the asm file in MIDE51 and from Device menu choose 89S8253 (I guess that's what the $include line does?).
2/ Hit F9 (Build). I get the following error:
(https://s18.postimg.org/r3mffags5/Error1.jpg) (https://postimg.org/image/r3mffags5/)
3/ Since smod52 line is illegal let's delete it and hit f9 again. Now I get the same error less row #4 (the $mod52 line) which is gone.
Scrolling down to 145-147 I noticed that rcap2h, rcap2l and t2con are not declared in the ports and registers sections.
(https://s18.postimg.org/rhnreuql1/Error2.jpg) (https://postimg.org/image/rhnreuql1/)
Also I see 0C9H against T2MOD (row146). What if I replaced rcap2h, rcap2l and t2con similarly like this:
(https://s18.postimg.org/pseo6f879/Error3.jpg) (https://postimg.org/image/pseo6f879/)
4/ Hit F9. HEX file is generated without errors! I don't know if all this is not wrong though.
Quote3/ Since smod52 line is illegal let's delete it and hit f9 again. Now I get the same error less row #4 (the $mod52 line) which is gone.
Scrolling down to 145-147 I noticed that rcap2h, rcap2l and t2con are not declared in the ports and registers sections.
Also I see 0C9H against T2MOD (row146). What if I replaced rcap2h, rcap2l and t2con similarly like this:
You shouldn't have to to do this it's all caused by the smod52 line failing.
You need to removed the smod52 line and replace it with the two lines I mentioned in the earlier part of the thread. When you fix that everything will work.
Your way works as well :)
Quoteur way works as well
OK cool. I guess the main thing is you shouldn't have to modify the code.
Quote1/ Open the asm file in MIDE51 and from Device menu choose 89S8253 (I guess that's what the $include line does?).
I'm not sure what that does. It shouldn't override $includes. However, note that the IDE has other modules like the simulator and it might tell the simulator and other components what processors to emulate - that's where you really do care what processor your are running on.
After many hours of reading and testing no luck programming the chip so far. It turns out that this is a very tricky one. After so many experiments with different setups I might as well have damaged it so I ordered couple of more just in case.
QuoteAfter many hours of reading and testing no luck programming the chip so far. It turns out that this is a very tricky one. After so many experiments with different setups I might as well have damaged it so I ordered couple of more just in case.
Hmmm.
Is it failing during program? ,or, does it appear to program and the code doesn't run?
If it is the later then make sure the entry point is being set correctly.
Forgot to ask what, what programming methods did you try?
I tried using Pickit2 which is supported by Avrdude and Ponyprog with a serial adapter as already discussed previously. Also tried several different software packages (I don't even remember the names). It turns out the 8253 the programming sequence (according to the datasheet) is different from 8252 and others from the 89S series. Bottom line is the software failed to communicate with the chip. In PonyProg if I select S53 for example it would read it but it won't write it.
The serial cable I had by hand turned out to be a null modem cable so there's a chance that higher than 5V levels were applied to the chip that's why I ordered two more to eliminate the possibility of trying to program a baked chip. After that a regular cable didn't work either.
I ordered an USBasp programmer for couple of bucks from Ebay which according to forums can do the job but we'll see.
I can find someone who will program the chip for me just to make sure the code is OK but I don't want to quit yet.
QuoteI tried using Pickit2 which is supported by Avrdude and Ponyprog with a serial adapter as already discussed previously. Also tried several different software packages (I don't even remember the names). It turns out the 8253 the programming sequence (according to the datasheet) is different from 8252 and others from the 89S series. Bottom line is the software failed to communicate with the chip. In PonyProg if I select S53 for example it would read it but it won't write it.
Looks like you have been hard at it.
From what I can see the 8253 is closer to the S52. The 8253 has some extra modes but if you don't use them it looks close. The other wierd thing is from what we both found is Ponyprog should work. If the cable is wrong then there's no hope of it working.
If you can *read* the device then the chip might not be fried as the read pin is the one that would get fried. Having said that I've seen some pretty weird behaviour from fried micro's. Whatever weird-assed behaviour they throw-up no longer phases me.
QuoteThe serial cable I had by hand turned out to be a null modem cable so there's a chance that higher than 5V levels were applied to the chip that's why I ordered two more to eliminate the possibility of trying to program a baked chip. After that a regular cable didn't work either.
Hard to predict what will happen after that.
QuoteI ordered an USBasp programmer for couple of bucks from Ebay which according to forums can do the job but we'll see.
I can find someone who will program the chip for me just to make sure the code is OK but I don't want to quit yet.
Not a bad idea. No doubt you will get it working. It only takes one thing wrong to stuff you up. The trouble is out of the 10 things that could be wrong you have to try to find it.
Here's an update to the current state of the project. There are bad news and good news. The bad news are not as bad as the good are good :)
All my attempts to program the chip miserably failed. I got the USBasp programmer for couple of bucks from Ebay however the stock firmware can't do the job and needs to be flashed. The one that can allegedly program the chip can be found here:
http://www.circuitvalley.com/2011/06/usb-8051-avr-microcontroller-programmer.html
I tried using the simple serial programmer to flash the USBasp but i couldn't get it to work. So I thought if I was going to invest more time into this I needed at least to know if the whole thing is going to work and decided to put the "how to program it myself" issue to the side. A local electronic parts retailer directed me to a computer tech who could program the chip for me.
It turned out that both chips survived all my experiments and now they were ready to go into the already assembled PCB.
Now here's the good news. After powering up the board everything worked from the first time which makes official the AT89S8253 as replacement in SpinSemi's project. Credits also go to Rob who helped to compile the hex file. I'll post it later together with a PCB drawing.
What you should know if you're burning your own is there are 4 fuses that must be specified.
Fuse1 (Serial Programming Fuse): This fuse enables/disables the serial programming mode (ISP). - enable - 0
Fuse2 (x2 Mode Selection Fuse): This fuse enables/disables the internal x2 clock mode. - disable - 1
Fuse3 (User Row Access Fuse): This fuse enables/disables writing to the programmable user row. - enable - 0
Fuse4 (Clock Selection Fuse): This fuse selects between an external clock source and a quartz crystal as the clock input - select quartz crystal - 1
I haven't admitted defeat on programming the chip so after I figure out how to flash the USBasp I'll keep trying.
The module outputs only the wet signal so a buffer/mixer circuit will have to be added.
There's one small thing. When rotating the encoder clockwise the preset numbers go down and vice versa so I was wondering if this was the wrong type of encoder I'm using or I just need to swap the lines?
After many many hours of digging, reading and experiments I can finally declare SUCCESS!
I'm not going to describe the whole ordeal because it's a novel material but post the solution that finally worked.
1/ Hardware
Get an USBasp programmer for couple of bucks from Ebay or elsewhere. The one I got had the Atmega8A. Some of the revisions however have Atmega48 or 88. I don't
know if the new firmware works on those so maybe it will be a good idea to check with the seller first which Atmega is used in their version of USBasp.
Mine was marked as USBasp V2.0 from LC Technology.
ATTENTION! The stock firmware is not able to program the AT89S series of uCUs! In order to enable it to program the
AT89S8253 chip it needs to be flashed with a custom made firmware. The one from the link posted previosly claims
to be able to do that but in fact it doesn't. The final working solution was found on a german forum here (answer from 23.06.2009 22:16):
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.mikrocontroller.net%2Ftopic%2F140310&edit-text=
2/ Flashing the USBasp
Flash the USBasp using the firmware HEX file attached (before that you have to enter programming mode by shorting the JP2 jumper).I did that using
PonyProg and a simple serial programmer I built myself and as described and linked to earlier in the thread. Another way to do it is to buy 2 pcs USBasp that can flash each other.
Make sure you use the recommended fuse settings: Hfuse - c9, Lfuse - 9f. For direct editing of the AVR fuse bits refer to this fuse calculator:
http://www.engbedded.com/fusecalc/
3/ Interfacing USBasp to AT89S8253
To connect USBasp to AT89S8253 I built a simple 10pin connector to PLCC44 socket interface on a perfboard adding to the socket a 100n cap across positive and
negative (ground) rails and also a 6MHz crystal coupled with 2x22pf ceramic caps. The chip was powered from the 10pin connector (set the USBasp JP1 target jumper to 5V).
4/ Software
I used ProgISP v1.72.
Open the program and choose AT89S8253.
In order to define the configbits click here:
(https://s18.postimg.org/fs9xzxp5x/Config_Bits_Set.jpg) (https://postimg.org/image/fs9xzxp5x/)
Tick them accordingly:
(https://s18.postimg.org/4soqoagqd/Config_Bits.jpg) (https://postimg.org/image/4soqoagqd/)
Click on "Command" (on the right vertical window).
To check if the software communicates with the chip click "Read flash".
Load the SpinSemi16_24_AT89S8253.hex flash file.
In the window to the right, click "Write flash":
(https://s18.postimg.org/vrsliy31x/Write_Flash.jpg) (https://postimg.org/image/vrsliy31x/)
Done.
The chip was tested to work properly in the demo board.
The modified USBasp firmware and AT89S8253 flash file can be found here (will be deleted after 30 days so if anyone can recommend a more permanent solution let meknow):
https://ufile.io/ofxvx
I'm still working on a PCB that will fit into a 1590B enclosure and I'll post them later when I'm done.
Couple of mods to the software came to mind so I'll need your help again Rob :)
With the help of a friend of my friend the code was modified so when you rotate the encoder the next program becomes active without the LCD blinking and the need to press the button to activate the program. Below is a link to the modified hex file:
https://ufile.io/dwuiy
The experimental board I made wasn't able to fit it in the 1590B but it fitted very well in a 1550B.
The In/Out Mix section together with the jacks is mounted on a separate PCB. I'm drawing another PCB that will be smaller and will have the Mix section integrated.
(https://s31.postimg.org/8obnzotk7/FX99.jpg) (https://postimg.org/image/8obnzotk7/)
Thanks for the update. I missed your posts since I don't monitor this group.
You had a real battle on your hands but your persistence paid off!