Please tell me this is the answer

[meenbombs]

I used the ZX-328l extensively a few years back but some customer requirements have pushed me to using PicBasic Pro. I have loathed my existence since. I have been chomping on the bit to move to something I hate less and the Zbasic generic target license seems to be it. I have a few questions that might help people in my boat that don't have a ton of time to try this out hoping it would be a great replacement.
1. My experience with the N devices was positive in that once you called a pin and put it high that was it. There was no setting ports, turning off comparaters or any of that extra garbage that constitutes half of my debugging time. Is that still true with the Generic target setup here or did Don just make it really easy if you were using N devices?

2. If I remember correctly USART was done by interrupts regardless of the pin used. Was that and is that still the case? Everytime I use any type of serial comms on the PIC I want to stab myself in the hand. I have much more favorable memories of doing serial commands with the ZX devices.

3. Are there limitations to using functions native to the AVR but might not necessarily be supported by Zbasic?

I guess in a nutshell, is this generic target version of ZBasic the AVR equivalent of PBP and will it generally afford me the same capabilities? I already know ZBasic as I remember is much easier to use and doesn't require memorizing the uC's datasheet. This forum is also much nicer as the PBP forum is full of grouches. I would love to make the switch but I really can't afford to take the time to switch and then find out in the middle of 5 concurrent projects that it isn't going to work for me. Thanks in advance.

[dkinzer]

Is that still true with the Generic target setup here or did Don just make it really easy if you were using N devices?

Creating a ZBasic application for a generic target device is essentially the same as doing so for a ZX device. The difference is that for ZX devices some configuration parameters (e.g. clock frequency, RTC frequency, presence of a bootloader, etc.) are pre-determined whereas with a generic target device you have to specify those parameters.

2. If I remember correctly USART was done by interrupts regardless of the pin used. Was that and is that still the case?

For each USART that the particular AVR has, the pins on which the RxD and TxD signals are applied/output are fixed so there is no concept of setting the particular pin to be used. That said, it is true that the serial I/O for USARTs is interrupt driven and interaction with the USART is by way of queues (add characters to the output queue to send, read characters from the input queue for receive).

3. Are there limitations to using functions native to the AVR but might not necessarily be supported by Zbasic?

I'm not sure what you mean here. Not all hardware features of every AVR are supported by ZBasic System Library routines. Even so, you can access such features by accessing the device registers directly or by adding C, C++ or assembly language code to your application to do so.

I guess in a nutshell, is this generic target version of ZBasic the AVR equivalent of PBP and will it generally afford me the same capabilities?

To the extent that it is supported by the hardware, you can do everything on a generic target device that you can do on a ZX device. As a simple example, if you have an application for a ZX-328n you should be able to have it running on an ATmega328P generic target in a very short time - all that is necessary is to specify the configuration parameters (most of which can be identical to those of the ZX-328n).

[meenbombs]

Thanks Don. This sounds like exactly what I need then. Your answer saying I could access the registers and/or add assembly answers the question you didn't quite understand. You understood it perfectly and answered the question. I don't have any projects currently using ZX devices to move to a generic target but the next development cycle I have will more than likely be done with Zbasic for generic and not PBP. Thanks again.

[dlh]

2. If I remember correctly USART was done by interrupts regardless of the pin used. Was that and is that still the case? Everytime I use any type of serial comms on the PIC I want to stab myself in the hand. I have much more favorable memories of doing serial commands with the ZX devices.

Even with software UARTs, ZBasic handles serial comms buffered and in the background.

I, too, use PBP extensively but only for limited, dedicated tasks using the smaller chips like the 8 and 14 pin PICs where they have advantages (e.g. accurate internal oscillators) over the equivalent AVRs.

[meenbombs]

Thank you for that input. The USART in the background makes me happy because using anything but the hardware USART in PBP makes writing code to do something while waiting for serial commands like juggling plates.

My spirit is a little crushed about your revelation on the AVR's internal oscillators being worse. I too depend on the internal oscillator for my 8 and 18 pin projects. It sounds like I will have to keep the PBP around for those projects. I guess I can't have everything. Thanks for the insight though. That has surely saved me a good bit of time.

[dlh]

Thank you for that input. The USART in the background makes me happy because using anything but the hardware USART in PBP makes writing code to do something while waiting for serial commands like juggling plates.

Most of the newer PICs allow you to configure RXD & TXD on two sets of pins which allows use of the hardware EUSART module and other hardware features (MSSP1 module) like I2C or SPI. Most have ample memory for their pincount and also allow self-writing so even the 8 pin 12F1840 can use the free ds30 bootloader.

My biggest complaint with PBP is that they do not provide native functions for hardware I2C & SPI (Don has spoiled me. ) and the frequent paid upgrades to get support for new PICs. I've been investigating Great Cow Basic which has open source support for both PICs and AVRs but it is still rather primitive.

[dkinzer]

My spirit is a little crushed about your revelation on the AVR's internal oscillators being worse.

I don't have any direct experience with PIC internal oscillators but research suggests that although the PIC internal oscillators might be factory calibrated to a more accurate level, both PIC and AVR oscillators can be field calibrated to achieve a good accuracy. However, both PIC and AVR oscillators will vary with temperature (I haven't checked the coefficients) so use in other than stabilized temperature environments may be problematic regardless of which chip you use.

[dlh]

Let me toss one more thing into the mix for consideration when planning new projects. This is preliminary with details still to be resolved but I don't think I'm talking out of school.

I've been working with http://YourDuino.com and have persuaded them to supply their Arduino Mega1280 PCB both as is and with the Mega2560 processor installed (only difference is memory size) and both will come with socketed crystals making it simple to use them with ZBasic. Amongst other features are 4 highspeed hardware USARTs (plus the standard complement of ZBasic software UARTs). This may mean you'll have less need for auxiliary boards like the shields I designed for my Zarduino project before learning of the generic license. (Geez, had I known then what I know now...)

http://davehouston.org/Zarduino.htm

[meenbombs]

My spirit is a little crushed about your revelation on the AVR's internal oscillators being worse.

I don't have any direct experience with PIC internal oscillators but research suggests that although the PIC internal oscillators might be factory calibrated to a more accurate level, both PIC and AVR oscillators can be field calibrated to achieve a good accuracy. However, both PIC and AVR oscillators will vary with temperature (I haven't checked the coefficients) so use in other than stabilized temperature environments may be problematic regardless of which chip you use.

I have hundreds of products out with PICs using the internal oscillator and using the USART at 2400 with Xbees, VMusic2s, and serial LCD displays and have no problems. On that account I am happy with the internal oscillator of the PIC but I wouldn't run anything faster than 2400. I have had problems at 9600 and suspect issues at 4800 may have been oscillator related.

[meenbombs]

Thank you for that input. The USART in the background makes me happy because using anything but the hardware USART in PBP makes writing code to do something while waiting for serial commands like juggling plates.

Most of the newer PICs allow you to configure RXD & TXD on two sets of pins which allows use of the hardware EUSART module and other hardware features (MSSP1 module) like I2C or SPI. Most have ample memory for their pincount and also allow self-writing so even the 8 pin 12F1840 can use the free ds30 bootloader.

My biggest complaint with PBP is that they do not provide native functions for hardware I2C & SPI (Don has spoiled me. ) and the frequent paid upgrades to get support for new PICs. I've been investigating Great Cow Basic which has open source support for both PICs and AVRs but it is still rather primitive.

Thank you for that tidbit. I will eventually look into that. I am also sick and tired of finding significant errors in the PIC datasheets. I just took a $400 beating on circuit boards that are now coasters because the 16F1827 datasheet says all porta pins have pull ups and only one of them does. This isn't the first mistake (or the tenth) I have seen in the datasheets that has negatively affected my delivery times or pocketbook so I am sick of PICS for that reason as well. Don't even get me started on ANSEL vs ADCON.

[dlh]

I have hundreds of products out with PICs using the internal oscillator and using the USART at 2400 with Xbees, VMusic2s, and serial LCD displays and have no problems. On that account I am happy with the internal oscillator of the PIC but I wouldn't run anything faster than 2400. I have had problems at 9600 and suspect issues at 4800 may have been oscillator related.

Several people, whom I consider expert (e.g. Darrel Taylor), report running newer PIC EUSARTs trouble free at 115200 using the internal oscillator. I've run older ones at 19200 using DEBUG.

[meenbombs]

I have hundreds of products out with PICs using the internal oscillator and using the USART at 2400 with Xbees, VMusic2s, and serial LCD displays and have no problems. On that account I am happy with the internal oscillator of the PIC but I wouldn't run anything faster than 2400. I have had problems at 9600 and suspect issues at 4800 may have been oscillator related.

Several people, whom I consider expert (e.g. Darrel Taylor), report running newer PIC EUSARTs trouble free at 115200 using the internal oscillator. I've run older ones at 19200 using DEBUG.

That is good info to know and I will probably play with those a little more in the future to see if I can replicate their success. Are there any reports of people having that type of success with AVR internal oscillators?

[dlh]

Are there any reports of people having that type of success with AVR internal oscillators?

I have BasCOM AVR but haven't worked with the smaller AVRs in several years. In those days most people recommended external crystals or resonators. Don probably has more recent knowledge or you can check at http://AVRFreaks.net.

The newest PICs have a rather sophisticated internal oscillator. For example, see FIG 5.1 in the PIC12F1840 datasheet.
http://www.microchip.com/wwwproducts/De ... e=en549758

[stevech]

The newest PICs have a rather sophisticated internal oscillator. For example, see FIG 5.1 in the PIC12F1840 datasheet.
http://www.microchip.com/wwwproducts/De ... e=en549758

Oh no, the PIC word!
The part referenced above with its 256 bytes of RAM, no real stack pointer, and the cursed PIC memory paging, remains at the bottom of the list of chips I'd choose. For many of us, it's an 8 bit AVR versus a Cortex M0/M3, depending on the need. The price difference is small.

[dlh]

The part referenced above with its 256 bytes of RAM, no real stack pointer, and the cursed PIC memory paging, remains at the bottom of the list of chips I'd choose. For many of us, it's an 8 bit AVR versus a Cortex M0/M3, depending on the need. The price difference is small.

Most Basic compilers for PIC hide all that ugliness. And, I used PICs in a recent project so it would be hardware compatible with PICAXE for those so inclined.

BTW, I see Mikrobasic has a compiler for ARM, now.