SpinSemi M16_24 project questions

Started by MetalGuy, January 29, 2018, 04:08:10 AM

Previous topic - Next topic

MetalGuy

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.

MetalGuy

I don't see any takers but here are couple of pics of the problem:





upload a photo on internet



Rob Strand

#2
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.


Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#3
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.






Rob Strand

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.

Send:     . .- .-. - .... / - --- / --. --- .-. -

Rob Strand

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.
Send:     . .- .-. - .... / - --- / --. --- .-. -

Rob Strand

#6
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. 
Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#7
Thanks for your help! It seemed to work :)





There are some cheap 87C52 types on ebay so now we have to figure out which one is OK for this project.

Rob Strand

#8
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]

Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#9
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.

Rob Strand

#10
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.
]

Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#11
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.


Rob Strand

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.
Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#13
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.


Ice-9

#14
Edit- Sorry my post was surplus to requirements and the solution already posted  :icon_wink:.
www.stanleyfx.co.uk

Sanity: doing the same thing over and over again and expecting the same result. Mick Taylor

Please at least have 1 forum post before sending me a PM demanding something.

Rob Strand

#15
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
--------------------------------------------------------------

Send:     . .- .-. - .... / - --- / --. --- .-. -

Rob Strand

#16
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.
Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

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.

Rob Strand

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.

Send:     . .- .-. - .... / - --- / --. --- .-. -

MetalGuy

#19
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 :)