Parallax Ubicom Scenix SX and PIC16C54/57

Comments

• DaveJenson Posts: 370

  2017-06-21 17:02

  You do realize that all that info is OLD, right?
  It probably still works, but the world has moved on....
• Mike Green Posts: 23,101

  2017-06-21 17:28

  Parallax still has a stock of SX48BD-G but, once they're gone, "that's all folks". More will never be made. That's fine for limited hobby use, but nothing to base a product on.
  
  The SX48 was (is) a nice microcontroller, but the world has indeed moved on.
  
  I'm still confused about what you're asking. Parallax has long settled on its vision. The Flip and BlocklyProp are examples of where they're going. They still make and sell the BS1 and various flavors of BS2 for those who are interested and will do so as long as people will buy them and the parts to make them are still available.
• microcontrolleruser Posts: 1,194

  2017-06-21 17:28

  
  You betcha!
  
  This means there is no need for Parallax do anything about an Assembler or C Compiler.
  
  It is all right there.
  
  64 dollar question is whether this will work the other way.
  
  If you can take SX editor code and program it into 16C54 and even better yet an F54.
• microcontrolleruser Posts: 1,194

  2017-06-21 17:32

  
  Mike
  
  This fits in with what you just said.
  
  It's a lot of work to do this C54 thing.
  
  A good comprimise is the Stamp2SX to get a taste of what Ubicom SX's are like.
  
  
• microcontrolleruser Posts: 1,194

  2017-06-21 17:35

  
  Mike
  
  'I'm still confused about what you're asking.'
  
  I spent a lot of type digging this info up.
  
  Now someone can program with the Parallax SX Editor and
  
  crossover to PIC Assembler and C.
  
  I think that is very worthwile.
  
  What is the Parallax direction thing? Not relevant to this discussion.
• Mike Green Posts: 23,101

  2017-06-21 17:42 edited 2017-06-21 17:59

  The PIC processors are not identical to the SX processors. Most of the instructions are the same and many of the control registers are the same or similar, but you can't take an arbitrary SX program that uses a lot of the features of the SX processor, download it to a PIC16F54 and have it work.
• microcontrolleruser Posts: 1,194

  2017-06-21 17:46

  
  Mike
  
  You do have excellent ideas about beefing up the Propellor compilers.
  
  If you can get the Propellor to do what you want it to do that is great.
  
  I am just a stick in the mud about single processor.
  
  For 10 cents I would use the Propellor.
  
  The Spin manual is 5 star.
  
  My colleague loved PEKit.
  
  I just cannot handle the multi processor angle that does not transfer to PIC.
  
  It's heading too far up one river.
  
  
• microcontrolleruser Posts: 1,194

  2017-06-21 18:06

  
  Mike
  
  'Look at the Wikipedia articles on the early PIC processors vs. the SX processors.'
  
  Where's that?
  
  In the link above it has macros to use the Scenix SX with MPLAB.
  
  I'm curious about going the other way.
  
  Using PIC 16C54 with SX Editor.
  
  Anyhow. I'm looking at a DIY SX programmer.
  
  It looks pretty advanced. Found some left over SX Key's for $59.95 but dragging my feet on that.
  
  Ebay had what looked like 2 SX keys and some SX boards plus some Stamp 1 hardware.
  
  Went for $80. Whose to say if I had bid whether it would have gone higher though.
• Mike Green Posts: 23,101

  2017-06-21 19:20

  The nice thing about a carefully designed multiprocessor (like the Propeller) is that you can use a single processor or more than one processor and it all behaves well. Usually the additional processor(s) are used to provide the equivalent of peripheral processors like UARTs, servo (PWM) controllers, video output, floating point processors. Usually the communication between processors is done via shared (hub) memory locations. I've written PASM programs and used a TV as a debug monitor. Specific locations in the video text buffer corresponded to points in my PASM program. I had a short subroutine that copied a character to an offset in the video text buffer. I'd do: "MOV dbgchar,#'X'" then "MOV dbgoffset,#20" and "CALL dbgentry". The first MOV provides the character and the second MOV provides the offset in the video buffer which was typically 40 characters per line x 24 lines. I used the standard video text driver from the Propeller Object Exchange and there was a Spin shell which started the video driver in one cog and my PASM program in the cog initially used for the Spin interpreter. At that point, the video driver is doing its thing, the other six cogs are idle and my PASM program has complete control of its cog.
• microcontrolleruser Posts: 1,194

  2017-06-21 20:20

  
  Mike
  
  Will keep you posted about progress with Parallax Ubicom/PIC project.
  
  Need to get a programmer and start working with some of this.
  
  Thank you for the Propellor info!