From: Michael H. <kor...@ya...> - 2013-08-30 17:53:18
|
Thanks to all that replied to my shockingly newbie question! I googled more and found the answers I needed. I love SDCC! But all of my work with SDCC so far has been Z80 because I've worked with Z80 for well over 25 years now. I wanted to switch to more modern chips. I liked the Atmel 89C55WD because it has four IO ports plus 24K flash and 256 SRAM. It seemed to be darn cheap for all of what it has built in. But now that I need more SRAM, I have to give up two ports. That's OK for my current project. But if anyone wants to suggest an alternative part before I begin development of this project then I am all ears. The project is to provide a simple web server that allows turning 8 relays on or off. I am intending to use the ENC28J60. I've found code written for it using AVR and I am in the process of rewriting it for AT89C55WD. I am trying to do it so that it's portable to almost any 8051. If anyone has already done ENC28J60 code for the 8051 series, I'd love to see it. Mike ________________________________ From: "sdc...@li..." <sdc...@li...> To: sdc...@li... Sent: Friday, August 30, 2013 4:57 AM Subject: Sdcc-user Digest, Vol 87, Issue 3 Send Sdcc-user mailing list submissions to sdc...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/sdcc-user or, via email, send a message with subject or body 'help' to sdc...@li... You can reach the person managing the list at sdc...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Sdcc-user digest..." Today's Topics: 1. Re: Debugging under Eclipse (Erik Petrich) 2. Re: Debugging under Eclipse (Erik Petrich) 3. Re: [SL. Hdcc-user] Debugging under Eclipse (Ervin) 4. AT89C55WD (8051) question about external SRAM (Michael Hawkins) 5. Re: AT89C55WD (8051) question about external SRAM (Dave McGuire) 6. Re: AT89C55WD (8051) question about external SRAM (Maarten Brock) ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Aug 2013 18:03:54 -0500 (CDT) From: Erik Petrich <epe...@iv...> Subject: Re: [Sdcc-user] Debugging under Eclipse To: Stefan Falk <fal...@gm...> Cc: sdc...@li... Message-ID: <alp...@je...> Content-Type: text/plain; charset="utf-8" On Tue, 6 Aug 2013, Stefan Falk wrote: > Hey guys, it's me again! > ? > Trying to get rid of the need of Keil I am trying to be able to debug a > program that was compiled under the SDCC. > ? > The program runs on a eval-board which communicates with a server.? > I can communicate with this server by bridgeing some .dll files which then > allows me to do stuff like this: > ? > // a java plugin > server.getDevice.getPc(); > server.getDevice().getAllRegisters(); > ? > and so on.. > But all this would only make sense if I was able to "highlight" that line on > wich the PC at the moment is. > ? > Keil generates a table like: > ? > ? C:C006H ? ? ? ? LINE# ? ? ? ? 60 ? C:C009H ? ? ? ? LINE# ? ? ? ? 62 ? > C:C00FH ? ? ? ? LINE# ? ? ? ? 63 ? C:C014H ? ? ? ? LINE# ? ? ? ? 64 > ? > so if the PC == 0xC006 line 60 in the corresponding .c file would be > highlichted. > ? > Can anyone provide me some guideline how I could manage this under Eclipse? > ? > - I got a plugin > - I can receive all ?C information > - I (technically) can debug in Eclipse already (but without useful > visualisation) > ? > but > - I can not associate the PCs address with a specific line of a .c or .asm > file to highlight it in Eclipse > ? > Is there already an easy way how one could do this? If not, where can I get > a description about > how I can filter these information from the files that will be generated > using the "--debug" option? > ? > Okay, I know this is not a small request from me but I'd be glad about > anything that could? > help me since getting so far really took me a lot.? > ? > Thank you very much and best regards, > Stefan There used to be a link on the SDCC web page that described the .cdb file format that has debugging information, including the line/address relationships. I'm not sure what happened to i, but I'll tell you the part you need to know. The .cdb file is a plain text file with one debugging record per line. The lines that begin "L:C" are the records with the address of a particular "L"ine of "C" source. This is followed by the source filename and line number, both separated by the "$" symbol. Then there are two other fields that aren't particularly important, also separated by a "$" symbol. At the very end is a ":" symbol and the hexadecimal address associated with that line (although there is no prefix explicitly denoting the use of hexadecimal). So for example, the line: L:C$sample.c$32$1$16:51 indicates that the code associated with line 32 of sample.c begins at address 0x51 in memory. Although I have no idea how to integrate this with Eclipse, it should be fairly simple to translate the line/address information in the .cdb file to the format that Keil generated using a convenient scripting language of your choice. Erik ------------------------------ Message: 2 Date: Tue, 6 Aug 2013 19:21:05 -0500 (CDT) From: Erik Petrich <epe...@iv...> Subject: Re: [Sdcc-user] Debugging under Eclipse To: Stefan Falk <fal...@gm...> Cc: sdc...@li... Message-ID: <alp...@je...> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On Tue, 6 Aug 2013, Erik Petrich wrote: > There used to be a link on the SDCC web page that described the .cdb file > format that has debugging information, including the line/address > relationships. I'm not sure what happened to it, but I'll tell you the > part you need to know. Found it; it was moved to the wiki: http://sdcc.sourceforge.net/mediawiki/index.php/CDB_File_Format Erik ------------------------------ Message: 3 Date: Wed, 07 Aug 2013 17:35:36 +0800 From: Ervin <erv...@16...> Subject: Re: [Sdcc-user] [SL. Hdcc-user] Debugging under Eclipse To: sdc...@li... Message-ID: <hww...@em...> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... ------------------------------ Message: 4 Date: Thu, 29 Aug 2013 12:19:45 -0700 (PDT) From: Michael Hawkins <kor...@ya...> Subject: [Sdcc-user] AT89C55WD (8051) question about external SRAM To: "sdc...@li..." <sdc...@li...> Message-ID: <137...@we...> Content-Type: text/plain; charset="us-ascii" Please excuse my newbie questions. I am working on a project that will use an 89C55WD which is an Atmel 8051 variant. I need more than the 128/256 bytes of RAM. I have seen that 8051 supports up to 64K or external RAM. These two articles describe adding 64K of RAM. http://www.8052.com/tutmemor.php http://www.mikroe.com/chapters/view/65/#ch2.4 Is support built into SDCC for using the external 64K of RAM? Are there any flags or switches that I need to use to use external RAM instead of built in 128/256 RAM bytes? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 5 Date: Thu, 29 Aug 2013 15:55:15 -0400 From: Dave McGuire <mc...@ne...> Subject: Re: [Sdcc-user] AT89C55WD (8051) question about external SRAM To: sdc...@li... Message-ID: <521...@ne...> Content-Type: text/plain; charset=ISO-8859-1 On 08/29/2013 03:19 PM, Michael Hawkins wrote: > Please excuse my newbie questions. We've all gotta start somewhere. > I am working on a project that will use an 89C55WD which is an Atmel > 8051 variant. > > I need more than the 128/256 bytes of RAM. I have seen that 8051 > supports up to 64K or external RAM. Yes it does. > These two articles describe adding 64K of RAM. > > http://www.8052.com/tutmemor.php > http://www.mikroe.com/chapters/view/65/#ch2.4 > > Is support built into SDCC for using the external 64K of RAM? Are there > any flags or switches that I need to use to use external RAM instead of > built in 128/256 RAM bytes? How the external RAM is implemented in hardware is not visible from firmware. Just add it as you normally would, and tell SDCC to put stuff there, and you're good to go. You can also use mcs51 implementations that have on-chip memory in that address space, transparently. I've done bunches of work with the Philips (erm, NXP) P89C66x chips, for example, which have "external" RAM implemented in that fashion. -Dave -- Dave McGuire, AK4HZ New Kensington, PA ------------------------------ Message: 6 Date: Fri, 30 Aug 2013 10:41:58 +0200 From: "Maarten Brock" <sou...@ds...> Subject: Re: [Sdcc-user] AT89C55WD (8051) question about external SRAM To: sdc...@li... Message-ID: <522...@so...> Content-Type: text/plain; charset=US-ASCII Hello Michael, SDCC will not magically start using the external memory when it runs out of internal. You have to place your variables there using the __xdata keyword. Or if you're lazy you can use the large memory model which places everything in external ram. Also have a look at --xram-loc and --xram-size to tell sdcc how much memory you have and where it is located. If the hardware is not yet set in stone I suggest to also look at other microcontrollers which have "external ram" internally. This frees up many IO pins. Welcome to the 8051 Maarten > On 08/29/2013 03:19 PM, Michael Hawkins wrote: > > Please excuse my newbie questions. > > We've all gotta start somewhere. > > > I am working on a project that will use an 89C55WD which is an Atmel > > 8051 variant. > > > > I need more than the 128/256 bytes of RAM. I have seen that 8051 > > supports up to 64K or external RAM. > > Yes it does. > > > These two articles describe adding 64K of RAM. > > > > http://www.8052.com/tutmemor.php > > http://www.mikroe.com/chapters/view/65/#ch2.4 > > > > Is support built into SDCC for using the external 64K of RAM? Are there > > any flags or switches that I need to use to use external RAM instead of > > built in 128/256 RAM bytes? > > How the external RAM is implemented in hardware is not visible from > firmware. Just add it as you normally would, and tell SDCC to put stuff > there, and you're good to go. > > You can also use mcs51 implementations that have on-chip memory in > that address space, transparently. I've done bunches of work with the > Philips (erm, NXP) P89C66x chips, for example, which have "external" RAM > implemented in that fashion. > > -Dave > > -- > Dave McGuire, AK4HZ > New Kensington, PA > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------ ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ------------------------------ _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user End of Sdcc-user Digest, Vol 87, Issue 3 **************************************** |
From: Dave M. <mc...@ne...> - 2013-08-30 17:58:15
|
On 08/30/2013 01:53 PM, Michael Hawkins wrote: > Thanks to all that replied to my shockingly newbie question! I googled > more and found the answers I needed. I love SDCC! But all of my work > with SDCC so far has been Z80 because I've worked with Z80 for well over > 25 years now. > > I wanted to switch to more modern chips. I liked the Atmel 89C55WD > because it has four IO ports plus 24K flash and 256 SRAM. It seemed to > be darn cheap for all of what it has built in. > > But now that I need more SRAM, I have to give up two ports. That's OK > for my current project. But if anyone wants to suggest an alternative > part before I begin development of this project then I am all ears. > > The project is to provide a simple web server that allows turning 8 > relays on or off. I am intending to use the ENC28J60. I've found code > written for it using AVR and I am in the process of rewriting it for > AT89C55WD. I am trying to do it so that it's portable to almost any > 8051. If anyone has already done ENC28J60 code for the 8051 series, I'd > love to see it. An IP stack in an 8051 will be a good trick. If you can pull it off, I'll be impressed; please publish your code. ;) I've used the ENC28J60, but not with an 8051 or with SDCC. Nice chip all around, though. An 8051 implementation that I've worked with a lot is the Philips/NXP P89C66x family. They have some on-chip "external" RAM. I've done several commercial and hobby projects with that chip, and SDCC, with great results. -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: jon <jo...@jo...> - 2013-08-30 18:35:36
|
On Fri, 2013-08-30 at 10:53 -0700, Michael Hawkins wrote: > Thanks to all that replied to my shockingly newbie question! I googled > more and found the answers I needed. I love SDCC! But all of my work > with SDCC so far has been Z80 because I've worked with Z80 for well > over 25 years now. > > I wanted to switch to more modern chips. I liked the Atmel 89C55WD > because it has four IO ports plus 24K flash and 256 SRAM. It seemed to > be darn cheap for all of what it has built in. If your going to go modern then why not use an ARM core. STM32 for example. I used to program Z80 on CP/M, then Z80 on embedded boards. These days I don't bother with anything much smaller than a full ARM board with Linux. The price of ARM SOC is so low, compare a beagle board or Raspberry Pi or one of the generic ARM boards what other hardware you can buy for the money and its a no contest. Plus having a linux kernel gives me networking, filesystems, displays etc. For small jobs I use Microchip PIC. I often combine an ARM board and PIC and offload anything real time parts onto the PIC then use a serial channel back to the ARM board for communication. The PIC had great real world I/O and in the years i've used them I have never had one fail in service. Jon PS The raspberry Pi is good board to experiment but a poor choice for real products. |
From: roelof 't H. <ro...@it...> - 2013-08-30 18:37:36
|
On Fri, 2013-08-30 at 13:58 -0400, Dave McGuire wrote: > An 8051 implementation that I've worked with a lot is the Philips/NXP > P89C66x family. They have some on-chip "external" RAM. I have used and still use the p89v664 which replaces the p89c668. But nxp is a bad choice at the moment when it comes to 8052 microcontrollers. The are dumoing the whole line so it seems. the p89v664 is not listed on the website anymore :-( Got to buy me some from my distributor for future use like repairs and so on. roelof |
From: Dave M. <mc...@ne...> - 2013-08-30 22:54:33
|
On 08/30/2013 02:18 PM, roelof 't Hooft wrote: >> An 8051 implementation that I've worked with a lot is the Philips/NXP >> P89C66x family. They have some on-chip "external" RAM. > > I have used and still use the p89v664 which replaces the > p89c668. But nxp is a bad choice at the moment when it > comes to 8052 microcontrollers. The are dumoing the whole > line so it seems. the p89v664 is not listed on the website > anymore :-( > Got to buy me some from my distributor for future use like > repairs and so on. That sucks, those are really good processors. Well I kept enough from my last employer that I'll have plenty for my own projects. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: Michael H. <kor...@ya...> - 2013-08-30 18:50:39
|
Jon, thanks for the feedback. The product I am developing has zero need for anything except Ethernet/IP/primitive web server and 8 low voltage relays. The device will retail for 99 bucks USD. So it has to be absolutely minimal. The AT89C55WD will do fine even if I have to add a 6264 for an extra 8K of RAM. The ENC28J60 is darn cheap too. I shall need 8 transistors and eight relays. it all goes into a simple box. So I don't want any of the Rasberry Pi or other types of entire SBC's. I've used the TS7200 type LINUX boards for other more complex products that require an entire OS and numerous ancillary hardware. That's not what I am building this time around. Mike ________________________________ From: jon <jo...@jo...> To: Michael Hawkins <kor...@ya...>; sdc...@li... Sent: Friday, August 30, 2013 2:20 PM Subject: Re: [Sdcc-user] Alternates to Atmel 89C55WD On Fri, 2013-08-30 at 10:53 -0700, Michael Hawkins wrote: > Thanks to all that replied to my shockingly newbie question! I googled > more and found the answers I needed. I love SDCC! But all of my work > with SDCC so far has been Z80 because I've worked with Z80 for well > over 25 years now. > > I wanted to switch to more modern chips. I liked the Atmel 89C55WD > because it has four IO ports plus 24K flash and 256 SRAM. It seemed to > be darn cheap for all of what it has built in. If your going to go modern then why not use an ARM core. STM32 for example. I used to program Z80 on CP/M, then Z80 on embedded boards. These days I don't bother with anything much smaller than a full ARM board with Linux. The price of ARM SOC is so low, compare a beagle board or Raspberry Pi or one of the generic ARM boards what other hardware you can buy for the money and its a no contest. Plus having a linux kernel gives me networking, filesystems, displays etc. For small jobs I use Microchip PIC. I often combine an ARM board and PIC and offload anything real time parts onto the PIC then use a serial channel back to the ARM board for communication. The PIC had great real world I/O and in the years i've used them I have never had one fail in service. Jon PS The raspberry Pi is good board to experiment but a poor choice for real products. |
From: Alan C. de A. <ac...@gm...> - 2013-08-30 20:25:26
|
Hi Michael, Hmm, Atmel 89C55WD cost about same (or higher) price of Freescale Kinetis microcontrollers: http://www.mouser.com/Search/Refine.aspx?Keyword=kinetis&Ns=Pricing|0&FS=True These Kinetis are ARM Cortex-M0 and its power consumption is very low. I'm currently using KL25Z128 running a POSIX RTOS called NuttX and I'm impressed with both (Microcontroller and RTOS). This is just my opinion (my 2 cents). Best Regards, Alan On 8/30/13, Michael Hawkins <kor...@ya...> wrote: > Jon, > > thanks for the feedback. The product I am developing has zero need for > anything except Ethernet/IP/primitive web server and 8 low voltage relays. > > The device will retail for 99 bucks USD. So it has to be absolutely minimal. > > The AT89C55WD will do fine even if I have to add a 6264 for an extra 8K of > RAM. > > The ENC28J60 is darn cheap too. > > I shall need 8 transistors and eight relays. > > it all goes into a simple box. > > So I don't want any of the Rasberry Pi or other types of entire SBC's. I've > used the TS7200 type LINUX boards for other more complex products that > require an entire OS and numerous ancillary hardware. That's not what I am > building this time around. > > > Mike > > > > ________________________________ > From: jon <jo...@jo...> > To: Michael Hawkins <kor...@ya...>; > sdc...@li... > Sent: Friday, August 30, 2013 2:20 PM > Subject: Re: [Sdcc-user] Alternates to Atmel 89C55WD > > > On Fri, 2013-08-30 at 10:53 -0700, Michael Hawkins wrote: >> Thanks to all that replied to my shockingly newbie question! I googled >> more and found the answers I needed. I love SDCC! But all of my work >> with SDCC so far has been Z80 because I've worked with Z80 for well >> over 25 years now. >> >> I wanted to switch to more modern chips. I liked the Atmel 89C55WD >> because it has four IO ports plus 24K flash and 256 SRAM. It seemed to >> be darn cheap for all of what it has built in. > If your going to go modern then why not use an ARM core. STM32 for > example. > > I used to program Z80 on CP/M, then Z80 on embedded boards. These days I > don't bother with anything much smaller than a full ARM board with > Linux. The price of ARM SOC is so low, compare a beagle board or > Raspberry Pi or one of the generic ARM boards what other hardware you > can buy for the money and its a no contest. Plus having a linux kernel > gives me networking, filesystems, displays etc. > > For small jobs I use Microchip PIC. I often combine an ARM board and > PIC and offload anything real time parts onto the PIC then use a serial > channel back to the ARM board for communication. The PIC had great real > world I/O and in the years i've used them I have never had one fail in > service. > > Jon > > PS The raspberry Pi is good board to experiment but a poor choice for > real products. |
From: Philipp K. K. <pk...@sp...> - 2013-08-30 21:16:46
|
Am 30.08.2013 19:53, schrieb Michael Hawkins: > Thanks to all that replied to my shockingly newbie question! I googled > more and found the answers I needed. I love SDCC! But all of my work > with SDCC so far has been Z80 because I've worked with Z80 for well over > 25 years now. > > I wanted to switch to more modern chips. I liked the Atmel 89C55WD > because it has four IO ports plus 24K flash and 256 SRAM. It seemed to > be darn cheap for all of what it has built in. Did you consider the STM8? It provides a nice architecture at PIC-prices. Or a Z80-variant, such as the Z180 or Rabbit? Philipp |
From: Philipp K. K. <pk...@sp...> - 2013-08-30 21:21:41
|
Am 30.08.2013 20:20, schrieb jon: > For small jobs I use Microchip PIC. I often combine an ARM board and > PIC and offload anything real time parts onto the PIC then use a serial > channel back to the ARM board for communication. The PIC had great real > world I/O and in the years i've used them I have never had one fail in > service. What are the advantages of the PIC compared to STM8? Philipp |
From: Henry H. <he...@pe...> - 2013-08-30 22:12:09
|
I've only lightly dabbled with them myself, but a trusted friend told me he's found the STM8's peripherals to be a real weak spot, which is unfortunate since the STM32 peripherals are pretty strong. On Fri, Aug 30, 2013 at 2:21 PM, Philipp Klaus Krause <pk...@sp...> wrote: > Am 30.08.2013 20:20, schrieb jon: >> For small jobs I use Microchip PIC. I often combine an ARM board and >> PIC and offload anything real time parts onto the PIC then use a serial >> channel back to the ARM board for communication. The PIC had great real >> world I/O and in the years i've used them I have never had one fail in >> service. > > What are the advantages of the PIC compared to STM8? > > Philipp > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: <ge...@ot...> - 2013-08-30 22:51:24
|
IMHO - I would skip the effort of porting an IP-Stack to 8051 uC-Architecture if it is only about a small volume product and would use a Hardware TCP/IP-Stack like W5500 from wiznet - and keep the sw simple. According the STM8 - i am using the device in one of my projects and like it very much 3,6 MBaud SPI and 921kBaud RS-232 are done with no problems whatsoever (using SDCC) - I cant say much about I2C as I didn´t use it till now. Georg > I've only lightly dabbled with them myself, but a trusted friend told > me he's found the STM8's peripherals to be a real weak spot, which is > unfortunate since the STM32 peripherals are pretty strong. > > On Fri, Aug 30, 2013 at 2:21 PM, Philipp Klaus Krause <pk...@sp...> wrote: >> Am 30.08.2013 20:20, schrieb jon: >>> For small jobs I use Microchip PIC. I often combine an ARM board and >>> PIC and offload anything real time parts onto the PIC then use a serial >>> channel back to the ARM board for communication. The PIC had great real >>> world I/O and in the years i've used them I have never had one fail in >>> service. >> >> What are the advantages of the PIC compared to STM8? >> >> Philipp >> >> >> ------------------------------------------------------------------------------ >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! >> Discover the easy way to master current and previous Microsoft >> technologies >> and advance your career. Get an incredible 1,500+ hours of step-by-step >> tutorial videos with LearnDevNow. Subscribe today and save! >> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft > technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Dave M. <mc...@ne...> - 2013-08-30 22:57:08
|
On 08/30/2013 02:20 PM, jon wrote: >> Thanks to all that replied to my shockingly newbie question! I googled >> more and found the answers I needed. I love SDCC! But all of my work >> with SDCC so far has been Z80 because I've worked with Z80 for well >> over 25 years now. >> >> I wanted to switch to more modern chips. I liked the Atmel 89C55WD >> because it has four IO ports plus 24K flash and 256 SRAM. It seemed to >> be darn cheap for all of what it has built in. > If your going to go modern then why not use an ARM core. STM32 for > example. > > I used to program Z80 on CP/M, then Z80 on embedded boards. These days I > don't bother with anything much smaller than a full ARM board with > Linux. The price of ARM SOC is so low, compare a beagle board or > Raspberry Pi or one of the generic ARM boards what other hardware you > can buy for the money and its a no contest. Plus having a linux kernel > gives me networking, filesystems, displays etc. ...and a rather dramatic amount of complexity to control eight relays. Good heavens. I think I need a stiff drink after reading that. -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: jon <jo...@jo...> - 2013-08-31 05:11:56
|
On Fri, 2013-08-30 at 18:56 -0400, Dave McGuire wrote: > On 08/30/2013 02:20 PM, jon wrote: > >> Thanks to all that replied to my shockingly newbie question! I googled > >> more and found the answers I needed. I love SDCC! But all of my work > >> with SDCC so far has been Z80 because I've worked with Z80 for well > >> over 25 years now. > >> > >> I wanted to switch to more modern chips. I liked the Atmel 89C55WD > >> because it has four IO ports plus 24K flash and 256 SRAM. It seemed to > >> be darn cheap for all of what it has built in. > > If your going to go modern then why not use an ARM core. STM32 for > > example. > > > > I used to program Z80 on CP/M, then Z80 on embedded boards. These days I > > don't bother with anything much smaller than a full ARM board with > > Linux. The price of ARM SOC is so low, compare a beagle board or > > Raspberry Pi or one of the generic ARM boards what other hardware you > > can buy for the money and its a no contest. Plus having a linux kernel > > gives me networking, filesystems, displays etc. > > ...and a rather dramatic amount of complexity to control eight relays. > Good heavens. I think I need a stiff drink after reading that. Ah you say that but if the application is "ethernet controlled relays" then : 1) For small volumes the cost is low, probably lower than making your own PCB with a piffy micontroller with tacked on ethernet. I have done this several times and I stand by the statement "tacked on". 2) The software is piss easy to debug and can be self hosting for tweaking. Requirement is an SSH or telnet client from any old machine. I don't even bother to take a laptop to client sites as I can always install a free windows ssh client (putty) when I arrive at the customers, MAC and linux already have one as default. 3) Did I mention the price ? 4) The relay application for example would not really require much in the way of custom software. The GPIO lines can be toggled from user space, an HTTP server with a few line of user script, I really do mean a few lines <10 in total maybe for a basic: http://myboard/realay.cgi?realy=4&state=on style interface. I use Microcontrollers for some things but my personal rule of thumb is that if the application requires ethernet then just use an ARM board. Its not like you can ever run out of power with a typical >=500MIPS, >=256MB RAM, >=2GB of backing storage etc. Power consumption is a non issue as well. An older CPU style with some peripherals and a linear regulator is on a par with a modern ARM board if using a switching regulator (buck converter). Also if power is a concern you can underclock the ARM boards typically just by tweaking a register or two using a utility. It sounds mad, but from the developers point of view the "complexity" is far far far less. I could knock up a basic ethernet controlled 8 channel relay box in about an hour, make it first rate in 5. It would take me much longer to lay out a PCB. I no longer develop on strip board, work of the devil ! An ARM board is much less complex than unpacking and setting up my PIC dev kit and get all the ducks lined up to start work. For low volume I would buy pre-build modules from the far east. http://www.ebay.co.uk/itm/RASPBERRY-Pi-Model-B-revision-2-0-Board-512MB-RAM-The-Very-Latest-/170939155187?pt=UK_Computing_Other_Computing_Networking&hash=item27ccc482f3 http://www.ebay.co.uk/itm/ItS7DC-DC-Converter-Buck-Step-down-Module-Voltage-LED-Power-3A-12V-To-5V-3-3V-/141049238853?pt=UK_BOI_Electrical_Test_Measurement_Equipment_ET&hash=item20d7309545 http://www.ebay.co.uk/itm/New-8-Channel-5V-Relay-Module-Board-for-Arduino-PIC-AVR-MCU-DSP-ARM-UK-/151105724470?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item232e9a6036 http://www.ebay.co.uk/itm/231025835930?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 For a higher volume product I would use an STM32 with built in ethernet (not linux) an "RJ45 socket and magnetics" module on a custom PCB with buck converter PSU section. This would be a reasonable compromise between cost and complexity and much more powerful than a typical PIC/Atmel ethernet combo and less problematic. Just my 2c worth :-) Other may agree to differ.... Jon |
From: Michael H. <kor...@ya...> - 2013-08-31 13:51:10
|
The 8051 has built in support for bank switching. The Z80 does not. SDCC has support for 8051 bank switching. Z80 bank switching (and for other CPU's that don't natively support it) is usually done with a simple latch circuit. Why can't SDCC provide Z80 with bank switching support? If I had to do it myself, what files in the Z80 would I need to modify? Which files in 8051 provide the bank switching? Mike |
From: Philipp K. K. <pk...@sp...> - 2013-08-31 14:38:53
|
Am 31.08.2013 15:51, schrieb Michael Hawkins: > The 8051 has built in support for bank switching. > > The Z80 does not. > > SDCC has support for 8051 bank switching. > > Z80 bank switching (and for other CPU's that don't natively support it) > is usually done with a simple latch circuit. > > Why can't SDCC provide Z80 with bank switching support? If I had to do > it myself, what files in the Z80 would I need to modify? Which files in > 8051 provide the bank switching? sdcc provides some support. See the section on named address spaces in the manual. Esentially, you have to provide a function that switches to a specific bank, and tell sdcc which variable is meant to go into which bank. Then sdcc will insert the function calls for you. Philipp |
From: Dave M. <mc...@ne...> - 2013-08-31 17:30:28
|
On 08/31/2013 01:11 AM, jon wrote: > On Fri, 2013-08-30 at 18:56 -0400, Dave McGuire wrote: >> On 08/30/2013 02:20 PM, jon wrote: >>>> Thanks to all that replied to my shockingly newbie question! I googled >>>> more and found the answers I needed. I love SDCC! But all of my work >>>> with SDCC so far has been Z80 because I've worked with Z80 for well >>>> over 25 years now. >>>> >>>> I wanted to switch to more modern chips. I liked the Atmel 89C55WD >>>> because it has four IO ports plus 24K flash and 256 SRAM. It seemed to >>>> be darn cheap for all of what it has built in. >>> If your going to go modern then why not use an ARM core. STM32 for >>> example. >>> >>> I used to program Z80 on CP/M, then Z80 on embedded boards. These days I >>> don't bother with anything much smaller than a full ARM board with >>> Linux. The price of ARM SOC is so low, compare a beagle board or >>> Raspberry Pi or one of the generic ARM boards what other hardware you >>> can buy for the money and its a no contest. Plus having a linux kernel >>> gives me networking, filesystems, displays etc. >> >> ...and a rather dramatic amount of complexity to control eight relays. >> Good heavens. I think I need a stiff drink after reading that. > > Ah you say that but if the application is "ethernet controlled relays" > then : > > 1) For small volumes the cost is low, probably lower than making your > own PCB with a piffy micontroller with tacked on ethernet. I have done > this several times and I stand by the statement "tacked on". > 2) The software is piss easy to debug and can be self hosting for > tweaking. Requirement is an SSH or telnet client from any old machine. > I don't even bother to take a laptop to client sites as I can always > install a free windows ssh client (putty) when I arrive at the > customers, MAC and linux already have one as default. > 3) Did I mention the price ? > 4) The relay application for example would not really require much in > the way of custom software. The GPIO lines can be toggled from user > space, an HTTP server with a few line of user script, I really do mean a > few lines <10 in total maybe for a basic: > http://myboard/realay.cgi?realy=4&state=on > style interface. > > I use Microcontrollers for some things but my personal rule of thumb is > that if the application requires ethernet then just use an ARM board. > Its not like you can ever run out of power with a typical >=500MIPS, >> =256MB RAM, >=2GB of backing storage etc. > > Power consumption is a non issue as well. An older CPU style with some > peripherals and a linear regulator is on a par with a modern ARM board > if using a switching regulator (buck converter). Also if power is a > concern you can underclock the ARM boards typically just by tweaking a > register or two using a utility. > > It sounds mad, but from the developers point of view the "complexity" is > far far far less. I could knock up a basic ethernet controlled 8 > channel relay box in about an hour, make it first rate in 5. It would > take me much longer to lay out a PCB. I no longer develop on strip > board, work of the devil ! > > An ARM board is much less complex than unpacking and setting up my PIC > dev kit and get all the ducks lined up to start work. > > For low volume I would buy pre-build modules from the far east. > http://www.ebay.co.uk/itm/RASPBERRY-Pi-Model-B-revision-2-0-Board-512MB-RAM-The-Very-Latest-/170939155187?pt=UK_Computing_Other_Computing_Networking&hash=item27ccc482f3 > http://www.ebay.co.uk/itm/ItS7DC-DC-Converter-Buck-Step-down-Module-Voltage-LED-Power-3A-12V-To-5V-3-3V-/141049238853?pt=UK_BOI_Electrical_Test_Measurement_Equipment_ET&hash=item20d7309545 > http://www.ebay.co.uk/itm/New-8-Channel-5V-Relay-Module-Board-for-Arduino-PIC-AVR-MCU-DSP-ARM-UK-/151105724470?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item232e9a6036 > http://www.ebay.co.uk/itm/231025835930?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 > > For a higher volume product I would use an STM32 with built in ethernet > (not linux) an "RJ45 socket and magnetics" module on a custom PCB with > buck converter PSU section. This would be a reasonable compromise > between cost and complexity and much more powerful than a typical > PIC/Atmel ethernet combo and less problematic. > > Just my 2c worth :-) Other may agree to differ.... Well...I work as a design engineer, usually on industrial control applications. Complexity is the enemy of stability, and unnecessary complexity is a design flaw...that's my usual mindset. Cost is often a secondary consideration for anything other than bulk consumer electronics. When a bug in someone else's huge volume of code can result in a multi-hundred-ton machine to jerk in the wrong direction and kill people, and it comes down on ME, I don't want anything but the bare minimum on the board that controls it. -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: jon <jo...@jo...> - 2013-08-31 19:41:51
|
> > > > Just my 2c worth :-) Other may agree to differ.... > > Well...I work as a design engineer, usually on industrial control > applications. Complexity is the enemy of stability, and unnecessary > complexity is a design flaw...that's my usual mindset. Cost is often a > secondary consideration for anything other than bulk consumer > electronics. When a bug in someone else's huge volume of code can > result in a multi-hundred-ton machine to jerk in the wrong direction and > kill people, and it comes down on ME, I don't want anything but the bare > minimum on the board that controls it. > Yes, I hope you design my medical equipment and fly by wire boxes. But in the example I was giving the task was an Ethernet driven 8 channel relay. I built such a box a while back, its used to control mains lights. So far its run for 5+ months with no problems, but the application does not required a high reliability, its not directly a safety critical system. If it fails it needs fixing but nobody has died. You can tend to make unwise or rash decisions if you miss understand complexity, risk, provability and testability. Lets take complexity for example. I designed and built (commercially) a CCTV system based on embedded linux. The complexity is HIGH, in fact its huge.... you have a Linux kernel, 6MB of additional source - none of it proven or formally tested.... it depends for its function on at least 12 user space packages. This is millions of lines of code, some quite poor (I wrote that), some mature (other packages) some stable (linux kernel). As it happens this systems have run of 5 years, they fail only when the hardware fails, complexity is not the enemy of stability but is the enemy of provability and testability ! It might have been unreliable, you can't tell in advance - a percentage of the testing was in the field so to speak. For some applications I use a watchdog processor monitoring I/O (PIC for example, good stable choice) with a few hundred lines of C. Plus an ARM linux box... in this design the PIC is used to watch over and second guess the control system. The control system can then be a sprawling mess with networking and back end databases all kinds of unprovable stuff. The PIC will catch unwise I/O events and halt the system. This half way house design is very effective. You spend the time and effort on the PIC code to test it and as much as possible prove it. Its not required to build everything to one tolerance, I have met people with that attitude, most design for defence. Also most are the type of people who piss away a month writing something in assembler just to have it cough in the field with a unchecked buffer overrun that wasn't caught in testing ..... You can move the sliders around between complexity, provability, cost, speed of development... the best outcome is the compromise that suits the task, it nearly always is a compromise. Jon |
From: Steven D. <st...@do...> - 2013-08-31 20:34:00
|
If it wasn't ethernet based I'd just use Sparkfun's 24 pin DIP arduino on a really dinky board - total cost likely <50$ US - but ethernet does throw a wrinkle into it. And in Eagle right now designing a board with Sparkfun's little toy - a daughter board (Pi Plate - I hate the Arduino shield, Pi plate, Beaglebone bone names) :-) My design takes in a hall sensor (speed), GPS data (time, position, altitude), multi-axis accelerometer, OBD-II interface, A/D conversion for car sensors - oil pressure/temperature, water temp, fuel flow, air flow, exhaust temp (multi cylinder) etc - all so I can cross the finish line on time :-) ____________ Steven Donegan SSCC/NORC Life Member, Car #86 www.sscc.us ________________________________ From: jon <jo...@jo...> To: sdc...@li... Sent: Saturday, August 31, 2013 12:41 PM Subject: Re: [Sdcc-user] Alternates to Atmel 89C55WD > > > > Just my 2c worth :-) Other may agree to differ.... > > Well...I work as a design engineer, usually on industrial control > applications. Complexity is the enemy of stability, and unnecessary > complexity is a design flaw...that's my usual mindset. Cost is often a > secondary consideration for anything other than bulk consumer > electronics. When a bug in someone else's huge volume of code can > result in a multi-hundred-ton machine to jerk in the wrong direction and > kill people, and it comes down on ME, I don't want anything but the bare > minimum on the board that controls it. > Yes, I hope you design my medical equipment and fly by wire boxes. But in the example I was giving the task was an Ethernet driven 8 channel relay. I built such a box a while back, its used to control mains lights. So far its run for 5+ months with no problems, but the application does not required a high reliability, its not directly a safety critical system. If it fails it needs fixing but nobody has died. You can tend to make unwise or rash decisions if you miss understand complexity, risk, provability and testability. Lets take complexity for example. I designed and built (commercially) a CCTV system based on embedded linux. The complexity is HIGH, in fact its huge.... you have a Linux kernel, 6MB of additional source - none of it proven or formally tested.... it depends for its function on at least 12 user space packages. This is millions of lines of code, some quite poor (I wrote that), some mature (other packages) some stable (linux kernel). As it happens this systems have run of 5 years, they fail only when the hardware fails, complexity is not the enemy of stability but is the enemy of provability and testability ! It might have been unreliable, you can't tell in advance - a percentage of the testing was in the field so to speak. For some applications I use a watchdog processor monitoring I/O (PIC for example, good stable choice) with a few hundred lines of C. Plus an ARM linux box... in this design the PIC is used to watch over and second guess the control system. The control system can then be a sprawling mess with networking and back end databases all kinds of unprovable stuff. The PIC will catch unwise I/O events and halt the system. This half way house design is very effective. You spend the time and effort on the PIC code to test it and as much as possible prove it. Its not required to build everything to one tolerance, I have met people with that attitude, most design for defence. Also most are the type of people who piss away a month writing something in assembler just to have it cough in the field with a unchecked buffer overrun that wasn't caught in testing ..... You can move the sliders around between complexity, provability, cost, speed of development... the best outcome is the compromise that suits the task, it nearly always is a compromise. Jon ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Maarten B. <sou...@ds...> - 2013-08-31 20:21:13
|
Hello, > Am 31.08.2013 15:51, schrieb Michael Hawkins: >> The 8051 has built in support for bank switching. >> >> The Z80 does not. Neither the (original) 8051 nor the Z80 have built in support for bank switching. I'd almost say that bank switching by definition goes beyond built in support of the processor core. However there are derivatives that do support it. >> SDCC has support for 8051 bank switching. SDCC supports code memory bank switching for 8051. >> Z80 bank switching (and for other CPU's that don't natively support it) >> is usually done with a simple latch circuit. >> >> Why can't SDCC provide Z80 with bank switching support? If I had to do >> it myself, what files in the Z80 would I need to modify? Which files in >> 8051 provide the bank switching? For the 8051 bank switching is handled by crtbank.asm. But the calls are generated by src/mcs51/gen.c. To add support for Z80 you'd have to modify src/z80/gen.c. There is also support needed in src/z80/main.c to compensate for the extra required stack space. > sdcc provides some support. See the section on named address spaces in > the manual. > Esentially, you have to provide a function that switches to a specific > bank, and tell sdcc which variable is meant to go into which bank. Then > sdcc will insert the function calls for you. > > Philipp Named address spaces can provide data memory bank switching. This is not implemented for 8051. Maarten |
From: Philipp K. K. <pk...@sp...> - 2013-09-01 08:57:22
|
Am 31.08.2013 22:21, schrieb Maarten Brock: > > For the 8051 bank switching is handled by crtbank.asm. But the calls are > generated by src/mcs51/gen.c. To add support for Z80 you'd have to modify > src/z80/gen.c. There is also support needed in src/z80/main.c to > compensate for the extra required stack space. To anyone wanting to implement code bank switching for the Z80, I would suggest to implement it for the Rabbits first, since they have special call and return instructions for inter-bank calls. > > Named address spaces can provide data memory bank switching. Note that, while sdcc in many places handles code and constant data the same, this is not true here: Named address spaces will work with constant data. > This is not > implemented for 8051. AFAIR the named address spaces do not require support in the back-end, and should work with any port (but the function for switching between banks has to be supplied by the user). I currently don't see how it would be useful for the mcs51 though, unless someone uses custom bank hardware to extend the memory space. Philipp |