Cubloc comparison
-
- Posts: 4
- Joined: 08 January 2006, 22:27 PM
Cubloc comparison
I apologize if this isn't the place to discuss it. I was on the verge of ordering an cubloc from comfile when I came across the ZBasic. As far as I can tell these are directly competing products. The ZBasic has a better version of BASIC, with procedures and functions rather than GOSUBS, but does not have the Ladder logic. The devices themselves seem more similar than different.
What are your opinions of the relative merits of the ZBasic and Cubloc?
What are your opinions of the relative merits of the ZBasic and Cubloc?
ZBasic is much better than Cubloc. What else is there?
Without knowing much about Cubloc other than reading their webpage, I would say that ZBasic is more general purpose. Cubloc is useful for PLC programmers used to ladder logic but if you didn't need that why bother with the other disadvantages.
Without knowing much about Cubloc other than reading their webpage, I would say that ZBasic is more general purpose. Cubloc is useful for PLC programmers used to ladder logic but if you didn't need that why bother with the other disadvantages.
Mike Perks
-
- Posts: 4
- Joined: 08 January 2006, 22:27 PM
The way I read their manual you still need to use GoSub to call the subs and functions.Ragamuffin wrote:Posting a correction: Cubloc does have subroutines and functions, so both languages are structured at that level.
I prefer Zbasic's approach to COM ports but can see that some might like the fact that while Cubloc has fewer COM ports (2 total) they do have 12V RS232.
Cubloc has twice as much memory and RAM but is much slower.
I think their touchscreen is pricey. I prefer ezLCD-02.
I had thought that the ZX com ports were fully RS-232 compliant. Is this not true?dhouston wrote: they do have 12V RS232.
Cubloc has twice as much memory and RAM but is much slower.
I think their touchscreen is pricey. I prefer ezLCD-02.
Well, there is not much you can do about program memory limitations in the ZX, but if you need more RAM for user data, then add SPI Fram or an SPI SD/MMC card!
SPI FRAM probably would work fine on the hardware SPI channel because it can suspend transactions if the CS pin is deselected (if my memory serves me). The SPI interface for the SD/MMC can not tolerate losing CS. So, on the ZX, I had to use the S/W SPI interface which I found to be slower than the HARDWARE I2C. The I2C FRAM is considerably faster, in my testing, than the software SPI SD card. Like a factor of 100? But the largest I2C FRAM is 256K bits (32K bytes), whereas my antique disposable test-bed SD card is 8 megabytes (only accessible in 512 K byte sectors)
If you really need more program memory AND more data memory, then your only recourse (I think) is to go down to the native hardware. I have found that the very structured design on ZBasic is VERY easy to convert to C. In this manner, you could use one of the big ATMega chips with tons of program memory, and reasonably large RAM, and unencumbered hardware SPI so you can get the full hardware SPI speed even opn the SD/MMC cards.
-Tony
It is not true. All of the Com ports are compliant with regard to timing and frame format but none of them are fully compliant with regard to signalling levels.I had thought that the ZX com ports were fully RS-232 compliant. Is this not true?
The RS-232 standard specifies that a logic 1 (also called "mark") be represented as a voltage between -3 and -15 volts and that a logic 0 (also called "space") be represented as a voltage between +3 and +15 volts. Note that this is "negative logic" because logic 1 is represented by the most negative voltage.
For Com3 to Com6, the data is transmitted using so-called TTL levels (nominally zero and 5 volts). The levels are positive logic if non-inverted mode is used and negative logic if inverted mode is used.
For Com1, the ZX-24 transmits using negative logic but the "mark" level is nominally zero volts and the "space" level is nominally 5 volts. This is essentially the same as the BX-24, Basic Stamp and many other Stamp-format microcontrollers. Even though the "mark" level is not standard-compliant, most PCs will recognize it as a mark.
The non-compliance of the mark transmit level is documented in the manual.
- Don Kinzer
Actually, for the ZX-24 you could remove the AT25256A (or lift pin 1) and add an external 25HP512 giving you 64K of program memory. It would probably be simpler to just use the ZX-40 or ZX-44 and use the 25HP512 in place of the AT25256A.Well, there is not much you can do about program memory limitations in the ZX.
See about97.html for more information.
I have some samples of the ST Micro M95512 part that is pin compatible with the AT25256A. This part could be used to build some special 64K versions of the ZX-24.
- Don Kinzer
IIRC correctly there are some limits on writing to the Atmel chip. I think you have to write a whole page. The ST chip has a byte write mode.
That was the reason I designed the piggyback board to handle an additional SOIC8 EEPROM although I was interested in more data storage rather than more program memory.
That was the reason I designed the piggyback board to handle an additional SOIC8 EEPROM although I was interested in more data storage rather than more program memory.
It is true that the 25HP512 is page-write only. The ZX devices can be field-configured to use page-write devices and to use devices with various page sizes. (The page size is only important when writing.)
Even with page-write devices, the ZX (unlike the BX series) still supports PutEEPROM() and writeable Program Memory data items. If configured for a page-write device, the ZX performs a read-modify-write operation on the page(s) being written to.
The ST part is byte-writeable but there is an availablility issue. I have not found any supplier that stocks them. I can purchase them directly from ST Micro but the minimum order is an entire reel.
Even with page-write devices, the ZX (unlike the BX series) still supports PutEEPROM() and writeable Program Memory data items. If configured for a page-write device, the ZX performs a read-modify-write operation on the page(s) being written to.
The ST part is byte-writeable but there is an availablility issue. I have not found any supplier that stocks them. I can purchase them directly from ST Micro but the minimum order is an entire reel.
- Don Kinzer
It might be useful to develop a comparison chart for all of the BasicStamp pin compatible controllers.
I'm aware of...
Hmmm. NTSC (and PAL) video would be a nice feature to add to the ZX-24.
I'm aware of...
- BasicStamp
BasicStamp2
BasicAtom
BX-24
BX-24p
CB220
ZX-24
Hmmm. NTSC (and PAL) video would be a nice feature to add to the ZX-24.
-
- Posts: 4
- Joined: 08 January 2006, 22:27 PM
That would be excellent! Maybe the comparison should be broken down like this..
Core microcontroller
Which controller?
Memory?
Speed?
On-board hardware
RS232 format?
Counters?
Hardware PMW?
Hardware IO?
etc
Operating system
Interrupts?
Multitasking?
Microcontroller specific library functions (IO, etc)?
Development environment
BASIC language capabilities?
BASIC library functions (Strings, FP math, etc)?
IDE quality?
Overall performance
Speed benchmarks?
Any other ideas?
Core microcontroller
Which controller?
Memory?
Speed?
On-board hardware
RS232 format?
Counters?
Hardware PMW?
Hardware IO?
etc
Operating system
Interrupts?
Multitasking?
Microcontroller specific library functions (IO, etc)?
Development environment
BASIC language capabilities?
BASIC library functions (Strings, FP math, etc)?
IDE quality?
Overall performance
Speed benchmarks?
Any other ideas?
These are all great lists guys but realistically who is going to do all of comparison work and quite honestly why bother?
The closest I know anyone got to doing a comparison is the article (http://home.austin.rr.com/perks/micros/Articles/) I wrote over a year ago on why I choose the BasicX platform. As I read it again I would change some things slightly and replace BasciX with ZBasic. Otherwise I think it explains my criteria fairly well.
In my article "Introduction to ZBasic", I break up microcontroller architectures into four categories that I compare and contrast. At a deeper level it really only makes sense to compare microcontrollers within and not across a particular category.
The closest I know anyone got to doing a comparison is the article (http://home.austin.rr.com/perks/micros/Articles/) I wrote over a year ago on why I choose the BasicX platform. As I read it again I would change some things slightly and replace BasciX with ZBasic. Otherwise I think it explains my criteria fairly well.
In my article "Introduction to ZBasic", I break up microcontroller architectures into four categories that I compare and contrast. At a deeper level it really only makes sense to compare microcontrollers within and not across a particular category.
Mike Perks
huh...
CB220 has Modbus support for PLC users...
CuTOUCH for Touchscreen...
Baseboards for Plug-N-Play Relays...
well...
I do admit the ZBasic is faster in execution time from
what i've been hearing...
anyways, i think this Zbasic is kinda cool...
Wait till my MAXbasic comes out...
I hope...
CuTOUCH for Touchscreen...
Baseboards for Plug-N-Play Relays...
well...
I do admit the ZBasic is faster in execution time from
what i've been hearing...
anyways, i think this Zbasic is kinda cool...
Wait till my MAXbasic comes out...
I hope...