Somebody said...
The real point is that you can currently download C compilers for the MAC platform for most of the other micros out there so why not just switch to another micro if you are a MAC user.
There are no Basic compilers for the other micros for the Mac. If you're deciding based on the language you want to work in, then you're stuck.
Somebody said...
I still think there would be an interest in creating a universal PBasic compiler. Something like Eclipse, maybe use Eclipse.
Eclipse is an IDE. The compiler is an entirely different beast. It would be used only as a component of the IDE. By creating the tools as standalone and chainable you can use whatever IDE environment you want to use.
I have built a Mac IDE for in-house use to program PIC and AVR MCUs in C and assembler (using GNU tools)... the only thing needed to handle a SX would be the tool-chain - assembler, compiler, and programmer/debugger plugin. I think I have enough info in my SX-Key kit's manuals to do a simple assembler and compiler in C/FLEX/YACC; but what I would need would be the protocol to talk to the SX-Key & Blitz to build the programmer/debugger plugin.
My IDE drives standard C command-line tools, as well as Cocoa bundles (loaded as plugins), so the assembler and compiler would be cross-platform (OS X, Linux, BSD, and Windows). The only Mac-specific component would be the programmer/debugger plug-in; and that's just because one would want a GUI on the debugger (the PIC and AVR programmers are command-line tools; I don't currently have debugger/ICE support for them).
My understanding of the existing PC SX IDE is that SASM and the SX/B compiler are already separate command-line executables; so I think that a modern C version should be just a drop-in replacement?
For that matter, it could be likewise extended with tool-chains for the BS1/2 and Prop...
Should any such effort materialise and be fruitful, I would be willing to release the tools free to users/owners of SX-keys/Blitzen...
...to the programming specs for the SX-Blitz. The Blitz doesn't let you debug, just program, but if you can get your program to handle that much, along with assembly etc, then you're ahead of the game. In addition, read my posts earlier in this thread for my recomendation on what the Mac community should create to demonstrate a market presence.
Yes, I did read the entire thread, and I did see that... it's the debugging protocol that I need. Otherwise, I think I have all the bits required...
What I have is the SX-Key, not the Blitz - I think the programming protocol is the same?
As far as I'm concerned, there's plenty of market demand - specifically, ME! So, I am going to put some effort into this... it's fruitfulness remains to be seen, however (won't know until ya' try, ya know?). At this point, I think that resource commitment from Parallax should be minimal to zero, so perceived market demand on their part should be close to irrelevant (as they aren't out hardly anything for this effort). Potential upsides for them - besides possibly picking up more Mac-using engineers, and thus more volume sales of SX chips - include a modern tool-chain based on C/LEX/YACC. Potential downsides include having to figure out what to do with all that extra profit from selling so many SXen...
The primary possible showstopper would be if the debugging protocol is timing dependent... because I use a USB-Serial adapter, I can't nail down the timing in the same way that I could if it was a 16550 or such UART being directly driven by the CPU. But, if it's like the programming protocol - just a byte-stream, then it should be easy to do...
I am running the Windows XP version of the SX IDE on my Macbook Pro (Intel) right now. Perfectly. All it takes is $49 to Parallels (http://www.parallels.com) for their VM. I have successfully run Windows 2000, Windows XP, Ubuntu Linux 6.06, Debain (latest whatever it is), and SuSE 10. Typcial problems in a lot of VMs with USB devices seem to non-existent--at least for the Parallax stuff. I haven't tested whetehr they have the Garmin software working yet. I can work with my SX, BS2, and Javelins all just fine. The Javelin USB baord works, but so do the RS-232 boards using and IO Gear USB-Serial converter (http://www.iogear.com/main.php?loc=product&Item=GUC232A). I haven't tried but Keyspan's converters probably work as well. Finally, we can run Windows in a Window and use Parallax tools. Of course until the Intel-based desktops come out, you have to either use a Mac-tel laptop or an actual PC. But if you have that Mac-tel UNIX latop, Parallels is THE way to go. Good luck!
Daniel,
I hope you realize that more than 90% of the Macs running OSX have a G3, G4 or a G5 processor. Apple has been building PowerPC based Macs for the 13 years, while the Intel Macs are less than 7 months old.
I realize this. Parallels is a viable option and will beceom more so. No one mentioned it so I felt someone should. Architectures move on. Yes it is a pain and represents a rapid depreciation of hardware. Just so you know I have a Dual G5 1.8 Ghz that is 1/3 slower in linpack and PyStones than my Macbook Pro! So don't think I don't feel the pain. But I upgraded teh graphics card and it works fine for Final Cut Studio, Photoshiop, and APerture so I'll keep it for a few years longer.
But one thing is certain--PPC numbers are not going to grow much more at this point and therefore, if vendors aren't supporting PPC today, they'll have less and less reason to do so going forward. It is an unfortunate reailty we all must face. Apple has made it clear that the PPC line is a dead end. But personally, I chose to still buy a Mac and run Linux and WIndows virtually rather than by a Win-tel system. Everyone has to make their own choice and live with it--just like politics and religion. Best of luck what ever you decide. This forum is better informed for my posting and I stand by it. Good luck.
As a side note remember Parallels Desktop for Mac's MSRP is $79.99 (if you purchase it now it's $49.99) and Windows Home is $189.82 (Amazon - Microsoft Windows XP Home Edition with Service Pack 2)
So while Parallels is a great way to run the SX IDE it will cost you $269.81 or $239.81 if you junp on it now and this assumes you have a intel macintosh. The above solution hammerhead74000's has outlined is free. and supports PIC and AVR MCUs.
As long as hammerhead74000 programmed his IDE with xcode and gcc then he should be able to compile his IDE on Intel and PCC Mac's with a few modifications. Using one IDE to program all major MCUs would be a great solution and I wouldn't need to shell out $239.81 just to run the SX IDE (plus a intel macintosh at $599 since I don't have one).
I look forward to seeing your finished product hammerhead74000.
Cannot argue with the price of the solution you favor I'd like it better also though there is still a lot of Windows and Linux software I find the Parallels VM useful for. I just had to buy the Parallels VM for $49.95 though--already had an OEM copy of XP I am not using on a PC and Lnux is free on the web.
As for hammerhead74000's design--an Appkit (Cocoa) GUI shell running command-line tools is how Xcode operates as well and is a great, flexible and extensible design. If he hadn't already created it, I would have suggesed he look as using teh Netbeans or Eclipse IDEs which run cross-platform on the patlforms he mentions. I'd offer to help out, but he already did the part I know a little about--The UNIX and OSX programming part
Until Parallax develops tools for the Mac (if ever) you may want to buy a used PC to run the tools.· Used PCs can be found for next to nothing at garage sales, flea markets, etc.· I know that PCs can share folders over a network.· Maybe a Mac can share a folder with a PC.· If so, you can keep your source files on the Mac.· If a Mac cannot share folders with a PC, then you could keep the source files on a flash drive that can be carried with you.· I carry a flash drive on my key ring with me all the time.
I had been putting off ordering the SX and Propeller dev boards primarily for this reason, I hate working on the PC I have since it is in a room where CNC machines are. The Mac is my favorite format and naturally it is at a nice workstation etc etc. This thread prompted me to look into ways to remote control the pc as I need to learn the other chips, so I recalled a few years ago I experimented with this remote desktop stuff linked below that works really well. Any $50 pc stuck in a closet will do the job, and it beats the heack out of VPC in my opinion, I couldn't do that route, drove me crazy.
Remote Desktop is tolerable as far as speed, I haven't used Timbuk2 or parallels, but this is free and works fine.
Sorry if I missed this as an option in the thread already, but this is the next best thing to mac programming for sx and prop.
Dave, thanks for the link on remote Desktop. Good catch! I've been using OS X since beta and office on Mac longer than that and *never* heard of this before. I even tried VNC with Cygwin once. I think using a dedicated PC is a better choice than a VM for micon development work since I can leave the PC connected 24x7 for mointoring nad data collaction purposes.
The one caveat is that I cannot tell if this data stream is encrypted from thebrief collateral I have seen. So I'd suggest using this on a local network (LAN) only since it is possible most if not all the data is exchanged in clear text. Let me emphasize that I don't know this for sure, but unitl we find out pays to be cautious: my G5 runs Apache as a web server through a DMZ and I get probed by outside systems on many IP ports every few minutes--its a dangerous world out there. Fortunately, I think Apple's firewall and secutrity are pretty good (though not perfect). I'd also suggest the IP ports used (once we figure them out) be disabled in you firewall to ensure your PC don't get 'owned by a hax0r' from the far reaches of internet It is my personal bias, but I view PCs as dangerous sysems to leave on the internet unattended. I will only use a PC on internet in a VM so I can delete it is something happens and I keep no personal data in the VM.
>> As long as hammerhead74000 programmed his IDE with xcode and gcc then he should be able to compile his IDE on Intel and PCC Mac's with a few modifications.
My primary development machine has been an Intel iMac since February; and it already runs natively. No modifications were required; except to change the platform to (PPC + x86). Couldn't have been easier.
Although it is possible for some configurations to use Xcode to do MCU development, it's a pain to setup, and when I started development on my IDE, ProjectBuilder (Xcode's predecessor) wasn't up to the task -- so I built mine.
>> Until Parallax develops tools for the Mac (if ever)
Given their previous (understandable) statements, and the fact that I am cooking something up, I doubt that they will.
>> Maybe a Mac can share a folder with a PC.
That's easiest to set up; just go to System Preferences, click on Sharing, and turn on Windows Sharing. However, constantly transferring one's code from one machine to the other to download to the SX gets old, fast...
I'm afraid that I've not been able to make too much progress lately, though; as I haven't spent hardly any time on the project (there was an unexpected death in my family ). However, before disaster struck; I did get to spend several hours on it, and have the core of the assembler done. I hope to continue this effort in the coming months, and share my developments with you folks as they happen.
I will definitely buy Parallax chips if I can develop for them on a Mac. I have Mac and PC laptops, but with OSX as popular as it is, there is almost no reason to use the PC. I am just getting into microcontroller programming- I have a few things I need to build for work that I now realize I can easily design myself. I think I could probably get my job done on a multitude of chip platforms, but all other things equal, the advantage would certainly go to the platform that doesn't make me carry another computer.
All things aren't equal, though, and if the OS X tools for Basic Stamp don't do what I need, I will probably just lug out the PC. But I'd be happier on a Mac!
watts said...
All things aren't equal, though, and if the OS X tools for Basic Stamp don't do what I need, I will probably just lug out the PC. But I'd be happier on a Mac!
One thing that MacBS2 won't do is give you a memory map, but that's not a showstopper. At one point I thought I needed a memory mapper so I slogged through and figured out how to interface with the Mac tokenizer. I got to the point where I can compile source and get the memory map but other projects have taken priority. If anyone wants my hideous jumble of code they're welcome to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
i recently bought a MacBookPro, 2.0 GHz with @ GB RAM and 100 GB HD. I ran up Apple's BootCamp and installed WinXPPro on a 25 GB partition formatted with FAT32 instead of NTFS. I have all of my uSB/serial drivers working perfectly, expecially thae FTDI drivers used by Parallax. So far as I can see the Basic Stamp, Javelin, PDB, SX-Key, and some TI's FET debuggers, Microchip's PICStart+ are all working with no gotcha's yet discovered.
With the Win partition formatted in FAT32 I can read/write from/to it from the Mac-side readily. For example, the other day, I downloaded the new SX-Key version and saved it right into the "Shared Files" folder of the Windows partition. I later booted to windows and installed it.
I have found the need to shutdown/re-boot to go from Mac to Win and vice-versa to be only a small inconvenience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
See the K107 Serial LCD Controller at www.wulfden.org/k107/
>> I have found the need to shutdown/re-boot to go from Mac to Win and vice-versa to be only a small inconvenience.
I find it to be a big one... which is why I have a copy of Parallels on my Intel iMac, and just picked up a copy of W95+USB for it (most tools work OK under 95)... haven't tried the SX tools on it yet though.
But, I like working with native OSX tools better - which is why I'm building my tool-chain...
The way I have it split up is this:
Preprocessor does file inclusion and macro expansion (for both assembler and high-level language files).
Compiler generates assembler from high-level source.
Low level assembler generates hex files from assembler source (handles single-opcode instructions only; multi-opcode instructions are implemented as macros).
The programmer/debugger plugin handles the SX-Key interfacing tasks to actually get your code onto the MCU.
The assembler is almost complete - it assembles code, handles assemble-time expression evaluation, forward references and generates hex and list files, but needs a few more opcodes added to the opcode table.
The parser for the compiler is complete; but I have not built the processor-specific code generator back-end yet.
Both the preprocessor and programmer/debugger have not yet been written.
BTW --- the compiler is designed such that it can be retargeted to other architectures (such as the Propeller, or some sort of VM); one need only to add the appropriate back-end codegen for that CPU.
Any news on the tool chain? It's just that I've started on an eclipse IDE plug-in for SX assembly language and it would be nice to use a somewhat portable command-line assembler as backend...
If there has been no progress: would you consider open-sourcing what you have now?
Darco -- I'm probably a bit out of my depth here, but can you describe in more detail how you set up the gpasm downloads to run on Max OS X? I'd love to get off my Win machine for SX programming. Also, in looking over some of the documentation it is unclear if Rev. E and F of the Key are supported, but the Blitz seems to be (I have a Key, not a Blitz).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
I had to hack a bit on gsxprog to get it to work properly. I've attached the sources (which include an intel binary, for your convenience).
gpasm works pretty well out of the box, although it helps to have the attached header. (the original version of the header was taken from the SERVID. I fixed a few errors.)
GPASM is a PIC assembler, and can compile code for the SX microcontrollers because the SX is similar to a PIC. However, this means that the syntax of the assembly is like that of a PIC, not like that from the parallax SX assembler.
I was considering writing a translator program, but never got around to it.
Jamesx I also have a sweet Mac Laptop that I use to research robotics, draw schematics, and post stuff on Parallax forums
It's an iBook G4
I have a huge windows from 1997 no one wants in the garage to program my SX's
It would be GREAT if Macnerds could have an SX chip compiler
SO we could take a break from PICS and AVR microcontrollers
PLEASE!
If there are people willing to help me test GSASM on intel and PPC macs I am more than willing to make it compile and work on both systems, most of it should already work, darco Im going to take a look at your hacks and include them in to GSASM. It would allow you to not have to use PIC asm syntax, the more people that show interest the faster I will churn out code, so far I am working for myself with one other person that I know is happy to see releases. Testing is simple, compile programs with GSASM and send me the source and hex output so I can see what is going on, if it wont work at all I have an intel mac and PPC that I can use, I just have to get accounts on both boxes.
That should be fine, you will just need to give GSASM the device name of the usb2serial, not sure how it is mapped out in mac but I know it will just be a standard device node, programming a chip may or may not actually work, if it doesn't I will have to sit down and play with it more. Keep in mind the code may not even compile, I sent you a PM with more information.
bunni said...
If there are people willing to help me test GSASM on intel and PPC macs I am more than willing to make it compile and work on both systems, most of it should already work, darco Im going to take a look at your hacks and include them in to GSASM. It would allow you to not have to use PIC asm syntax, the more people that show interest the faster I will churn out code, so far I am working for myself with one other person that I know is happy to see releases. Testing is simple, compile programs with GSASM and send me the source and hex output so I can see what is going on, if it wont work at all I have an intel mac and PPC that I can use, I just have to get accounts on both boxes.
Just for fun I thought I'd give a whirl to compile this on XP with CygWin. The only problem I ran into was having no cfmakeraw. I found a link that gave me the code I needed here. I just added the code for the cfmakeraw function to sxkey.c and compiled. I also had to add .exe to the strip command since CygWin executables are like that coming out of gcc. I suppose I could have just renamed gsasm.exe to gsasm.
If I get a chance I'll give a run at actually using it later today. Should you decide to add CygWin support I may be able to help when it comes time for your GUI stuff. I've used FLTK for some time and it would be an excellent choice for your project. The license is compatible with yours and it is already cross platform compilable with the GCC toolchain as its build mechanism.
Mark
Post Edited (CableGuy67) : 12/29/2007 9:26:48 PM GMT
Mark, I have someone just beginning to write a GUI for me right now using GTK. I really just want to output something fast that works, worrying later about cross platform usage. I took a look at FLTK and it looks pretty good, if I cant get GTK to run with everything AFAIK it should work on all platforms without too many issues, we will see what happens. Please post the modified sxkey.c so I can add that in sometime.
bunni said...
Mark, I have someone just beginning to write a GUI for me right now using GTK. I really just want to output something fast that works, worrying later about cross platform usage. I took a look at FLTK and it looks pretty good, if I cant get GTK to run with everything AFAIK it should work on all platforms without too many issues, we will see what happens. Please post the modified sxkey.c so I can add that in sometime.
-Kris
If you follow the link in my post it will take you to a page that has the function body in it. I didn't want to post it here as I would have had to post the whole thing (to honor the license text in the code) but it is just a snip that accesses the termios struct. I just prototyped cfmakeraw at the top and plunked the function body near the end of sxkey.c
RE: GUI
No sweat, you have an open source project. I bookmarked your project page and will keep an eye out when I have time. I never had much luck with GTK (due to my dev setup) but if I get ambitious I'll look at your GTK code and strip the important stuff into a FLTK front end. Thanks for your efforts to date. If you have a simple ASM file for testing post it somewhere with the associated circuit and I'll run some tests with my CygWin version. I'm just starting off with the micro stuff so I'm using SX/B with the IDE but the C/C++ stuff I'm much more comfortable with. [noparse]:)[/noparse]
Mark
Post Edited (CableGuy67) : 12/29/2007 10:26:50 PM GMT
Comments
There are no Basic compilers for the other micros for the Mac. If you're deciding based on the language you want to work in, then you're stuck.
Eclipse is an IDE. The compiler is an entirely different beast. It would be used only as a component of the IDE. By creating the tools as standalone and chainable you can use whatever IDE environment you want to use.
Post Edited (sanguish) : 4/12/2006 4:11:05 AM GMT
My IDE drives standard C command-line tools, as well as Cocoa bundles (loaded as plugins), so the assembler and compiler would be cross-platform (OS X, Linux, BSD, and Windows). The only Mac-specific component would be the programmer/debugger plug-in; and that's just because one would want a GUI on the debugger (the PIC and AVR programmers are command-line tools; I don't currently have debugger/ICE support for them).
My understanding of the existing PC SX IDE is that SASM and the SX/B compiler are already separate command-line executables; so I think that a modern C version should be just a drop-in replacement?
For that matter, it could be likewise extended with tool-chains for the BS1/2 and Prop...
Should any such effort materialise and be fruitful, I would be willing to release the tools free to users/owners of SX-keys/Blitzen...
Not sure if you have read this entire thread or not. In a post from April 27 (I think) I provided this link:
www.parallax.com/sx/sxblitz_protocol.asp
...to the programming specs for the SX-Blitz. The Blitz doesn't let you debug, just program, but if you can get your program to handle that much, along with assembly etc, then you're ahead of the game. In addition, read my posts earlier in this thread for my recomendation on what the Mac community should create to demonstrate a market presence.
Thanks, PeterM
What I have is the SX-Key, not the Blitz - I think the programming protocol is the same?
As far as I'm concerned, there's plenty of market demand - specifically, ME!
The primary possible showstopper would be if the debugging protocol is timing dependent... because I use a USB-Serial adapter, I can't nail down the timing in the same way that I could if it was a 16550 or such UART being directly driven by the CPU. But, if it's like the programming protocol - just a byte-stream, then it should be easy to do...
I hope you realize that more than 90% of the Macs running OSX have a G3, G4 or a G5 processor. Apple has been building PowerPC based Macs for the 13 years, while the Intel Macs are less than 7 months old.
But one thing is certain--PPC numbers are not going to grow much more at this point and therefore, if vendors aren't supporting PPC today, they'll have less and less reason to do so going forward. It is an unfortunate reailty we all must face. Apple has made it clear that the PPC line is a dead end. But personally, I chose to still buy a Mac and run Linux and WIndows virtually rather than by a Win-tel system. Everyone has to make their own choice and live with it--just like politics and religion. Best of luck what ever you decide. This forum is better informed for my posting and I stand by it. Good luck.
So while Parallels is a great way to run the SX IDE it will cost you $269.81 or $239.81 if you junp on it now and this assumes you have a intel macintosh. The above solution hammerhead74000's has outlined is free. and supports PIC and AVR MCUs.
As long as hammerhead74000 programmed his IDE with xcode and gcc then he should be able to compile his IDE on Intel and PCC Mac's with a few modifications. Using one IDE to program all major MCUs would be a great solution and I wouldn't need to shell out $239.81 just to run the SX IDE (plus a intel macintosh at $599 since I don't have one).
I look forward to seeing your finished product hammerhead74000.
Don Myers
As for hammerhead74000's design--an Appkit (Cocoa) GUI shell running command-line tools is how Xcode operates as well and is a great, flexible and extensible design. If he hadn't already created it, I would have suggesed he look as using teh Netbeans or Eclipse IDEs which run cross-platform on the patlforms he mentions. I'd offer to help out, but he already did the part I know a little about--The UNIX and OSX programming part
Remote Desktop is tolerable as far as speed, I haven't used Timbuk2 or parallels, but this is free and works fine.
Sorry if I missed this as an option in the thread already, but this is the next best thing to mac programming for sx and prop.
http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=Article_RDC
The one caveat is that I cannot tell if this data stream is encrypted from thebrief collateral I have seen. So I'd suggest using this on a local network (LAN) only since it is possible most if not all the data is exchanged in clear text. Let me emphasize that I don't know this for sure, but unitl we find out pays to be cautious: my G5 runs Apache as a web server through a DMZ and I get probed by outside systems on many IP ports every few minutes--its a dangerous world out there. Fortunately, I think Apple's firewall and secutrity are pretty good (though not perfect). I'd also suggest the IP ports used (once we figure them out) be disabled in you firewall to ensure your PC don't get 'owned by a hax0r' from the far reaches of internet
My primary development machine has been an Intel iMac since February; and it already runs natively. No modifications were required; except to change the platform to (PPC + x86). Couldn't have been easier.
Although it is possible for some configurations to use Xcode to do MCU development, it's a pain to setup, and when I started development on my IDE, ProjectBuilder (Xcode's predecessor) wasn't up to the task -- so I built mine.
>> Until Parallax develops tools for the Mac (if ever)
Given their previous (understandable) statements, and the fact that I am cooking something up, I doubt that they will.
>> Maybe a Mac can share a folder with a PC.
That's easiest to set up; just go to System Preferences, click on Sharing, and turn on Windows Sharing. However, constantly transferring one's code from one machine to the other to download to the SX gets old, fast...
I'm afraid that I've not been able to make too much progress lately, though; as I haven't spent hardly any time on the project (there was an unexpected death in my family
All things aren't equal, though, and if the OS X tools for Basic Stamp don't do what I need, I will probably just lug out the PC. But I'd be happier on a Mac!
chris watts
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
With the Win partition formatted in FAT32 I can read/write from/to it from the Mac-side readily. For example, the other day, I downloaded the new SX-Key version and saved it right into the "Shared Files" folder of the Windows partition. I later booted to windows and installed it.
I have found the need to shutdown/re-boot to go from Mac to Win and vice-versa to be only a small inconvenience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
See the K107 Serial LCD Controller at
www.wulfden.org/k107/
I find it to be a big one... which is why I have a copy of Parallels on my Intel iMac, and just picked up a copy of W95+USB for it (most tools work OK under 95)... haven't tried the SX tools on it yet though.
But, I like working with native OSX tools better - which is why I'm building my tool-chain...
The way I have it split up is this:
Preprocessor does file inclusion and macro expansion (for both assembler and high-level language files).
Compiler generates assembler from high-level source.
Low level assembler generates hex files from assembler source (handles single-opcode instructions only; multi-opcode instructions are implemented as macros).
The programmer/debugger plugin handles the SX-Key interfacing tasks to actually get your code onto the MCU.
The assembler is almost complete - it assembles code, handles assemble-time expression evaluation, forward references and generates hex and list files, but needs a few more opcodes added to the opcode table.
The parser for the compiler is complete; but I have not built the processor-specific code generator back-end yet.
Both the preprocessor and programmer/debugger have not yet been written.
BTW --- the compiler is designed such that it can be retargeted to other architectures (such as the Propeller, or some sort of VM); one need only to add the appropriate back-end codegen for that CPU.
If there has been no progress: would you consider open-sourcing what you have now?
After compiling, I use gsxprog to program the SX chip with my blitz.
Post Edited (darco) : 11/13/2007 9:43:15 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
gpasm works pretty well out of the box, although it helps to have the attached header. (the original version of the header was taken from the SERVID. I fixed a few errors.)
GPASM is a PIC assembler, and can compile code for the SX microcontrollers because the SX is similar to a PIC. However, this means that the syntax of the assembly is like that of a PIC, not like that from the parallax SX assembler.
I was considering writing a translator program, but never got around to it.
Post Edited (darco) : 11/14/2007 7:17:08 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
It's an iBook G4
I have a huge windows from 1997 no one wants in the garage to program my SX's
It would be GREAT if Macnerds could have an SX chip compiler
SO we could take a break from PICS and AVR microcontrollers
PLEASE!
http://sourceforge.net/projects/gsasm
-Kris
Post Edited (bunni) : 12/29/2007 6:03:10 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
-Kris
Just for fun I thought I'd give a whirl to compile this on XP with CygWin. The only problem I ran into was having no cfmakeraw. I found a link that gave me the code I needed here. I just added the code for the cfmakeraw function to sxkey.c and compiled. I also had to add .exe to the strip command since CygWin executables are like that coming out of gcc. I suppose I could have just renamed gsasm.exe to gsasm.
If I get a chance I'll give a run at actually using it later today. Should you decide to add CygWin support I may be able to help when it comes time for your GUI stuff. I've used FLTK for some time and it would be an excellent choice for your project. The license is compatible with yours and it is already cross platform compilable with the GCC toolchain as its build mechanism.
Mark
Post Edited (CableGuy67) : 12/29/2007 9:26:48 PM GMT
-Kris
If you follow the link in my post it will take you to a page that has the function body in it. I didn't want to post it here as I would have had to post the whole thing (to honor the license text in the code) but it is just a snip that accesses the termios struct. I just prototyped cfmakeraw at the top and plunked the function body near the end of sxkey.c
RE: GUI
No sweat, you have an open source project. I bookmarked your project page and will keep an eye out when I have time. I never had much luck with GTK (due to my dev setup) but if I get ambitious I'll look at your GTK code and strip the important stuff into a FLTK front end. Thanks for your efforts to date. If you have a simple ASM file for testing post it somewhere with the associated circuit and I'll run some tests with my CygWin version. I'm just starting off with the micro stuff so I'm using SX/B with the IDE but the C/C++ stuff I'm much more comfortable with. [noparse]:)[/noparse]
Mark
Post Edited (CableGuy67) : 12/29/2007 10:26:50 PM GMT