ZBasic Forum

My first project with a ZX-40 , in this case a ZX-40r
Does this look correct ?

ZX-40r , mega1284P , Pin's
5. Output only
6. Inp. Capt. Timer3
9. Reset
10. Vcc
11. GND
12. XTAL1
13. XTAL2
14. Com1 RX
15. Com1 TX
16. Com2 RX
17. Com2 TX
20. Input Capture
30. AVcc
31. GND
32. ARef
33-40. ADC

All other pins normal Input & Output ( and Output with pullup (20-50k) ) .
Maximum Sink / Source 20mA per pin ( 100mA / port ) , combined 200mA .

Pin 5 , Output only .
Input Capture pin20 . ( ZX-40r also pin6 )
I2C , SDA pin23 , SCL pin22 .
16bit PWM , ch1 pin19 , ch2 pin18 , ch3 pin7 , ch4 pin8 .
8bit PWM . ch1 pin21 , ch2 pin20 .


Another question ,
Has anyone used serial switching ?
I need 3x serial TX and 1x RX .
I figured i'll wire Com1 TX to a serial logger , Com1 RX to a GPS , Com2 TX to a digital switch like the MAX393 and feed the NC output to a 5.7" serial color display and the NO output to a 4x20chr display both with same baudrate and control the debug.print destination with one output pin .

I replaced a ZX-24a to ZX-24r and modified the program to use a hardware comport to read GPS data , much more reliable results . ( with my slow code ... )
Apparently opening software comports should be avoided if possible ...

Thanks again !

kurakaira wrote:Does this look correct ?

Your list looks good. One note about pin 5 is that the output-only limitation applies only if you plan to use SPI. In that case, you'll need at least one pin for the slave select output and pin 5 could serve that purpose. If you don't use SPI, pin 5 can be a general purpose I/O pin.

kurakaira wrote:I need 3x serial TX and 1x RX.

For transmit-only applications a demultiplexer/decoder like the 74xx138 works fairly well. The A, B and C inputs select which of the outputs Y0-Y7 is active. Input G1 is tied high and one of G2A, G2B is tied low and the other is connected to the USART output. The 74xx139 could also be used, providing 4 outputs. This works best if all of the transmit channels have the same baud rate but it can be made to work with different baud rates if the receive side of the USART isn't used.

If you decide to use the demultiplexing idea, you'll have to monitor the serial channel status (see StatusCom()) and wait until all serial data has been transmitted before changing the channel select for the demultiplexer.

If you were using a native mode device, you could write your own ISRs for the second serial channel and integrate the coordination of the demultiplexer switching and multiple output queues into the ISR. Another native mode option is to use direct bit-banged serial output. This works best if you are using high baud rates because interrupts are disabled for the duration of each character transmitted.

kurakaira wrote:Apparently opening software comports should be avoided if possible ...

As with anything else, use of the software UART channels has advantages and disadvantages. Since they are entirely interrupt driven, you must be careful to not perform other operations that cause interrupts to be disabled for long periods of time. Moreover, opening one or more software UART channels imposes an interrupt load on the system with interrupts occurring at 4 times the highest supported baud rate.

Well as it happens i have had a 74hct138 chip in my hand the whole morning for a different project with a ZX-24r ...
It didn't occur to me i could also use it like a serial switch ...
I used one for saving pins on the ZX-24 , driving 8 MAX6675 K-Type to Digital converter CS pins . ( Eight exhaust temperature readings on a Corvette with 2 turbos ... )

Back to the problem ,
In my project i am using CountTransitions with a 100ms window to read a hall RPM sensor , Does this affect hardware Comports ?
What do You recommend ,
Option 1 :
Com1 TX Logger , 19.2k
Com2 TX 5.7" Color TFT , a lot of data , update 2Hz , 19.2k
Com2 RX GPS 2Hz , 19.2k
Com3 TX 4x20chr display , low amount of data , update 2Hz , baud 9.6k / 19.2k

or Option 2 :
Com1 TX Logger 19.2k
Com2 RX GPS 2Hz 19.2k
Com2 TX to 74138

74138 Y0 5.7" Color TFT , a lot of data 19.2k
74138 Y1 4x20chr display , low amount of data , update 2Hz , baud 19.2k

Other than the serial there is not much more processor consuming except the CountTransitions ...
The RPM is very important ( and should be updated at least 4Hz ) and it is read with a Hall sensor . There are 10 gaps on the flywheel and the RPM varies between 0-8500 rpm ...
The InputCapture is better when reading rpm information from an ecu since it is a 50/50 pwm signal , but i would not use it here . or should i ?

Thanks !

kurakaira wrote:In my project i am using CountTransitions with a 100ms window to read a hall RPM sensor , Does this affect hardware Comports ?

Perhaps, depending on the baud rate. The hardware serial ports generate an interrupt for every character received and two interrupts for every character sent. Having interrupts disabled for 20 or more bit times may result in characters being dropped on the receive side. CountTransitions() keeps interrupts disabled for the entire counting period so using a 100mS window would potentially cause problems with a serial channel running at 200 baud or higher.

Here are some alternate ideas for determining the frequency of an external signal without disabling interrupts for long periods of time:

• Use a spare timer in the ZX and configure it to be clocked by the external signal (T1 B.1 for Timer1 and T3 D.0 for Timer3). In operation, you would initialize the counter, let it count for a pre-determined period of time, disable the timer and read the TCNT register.
• Use an external counter chip such as the 4020 (14-bit), 4024 (7-bit), 4040 (12-bit) clocked by the external signal. The idea is the same as above but using these counters requires some extra care because they are ripple counters, meaning that the count outputs typically have invalid transient states. You probably also need to add some gating circuitry so that you can essentially disable the clock while you're reading the outputs.
• Use a native mode device and write your own ISR for pin change interrupts. In operation, you would enable a pin change interrupt for a pre-determined amount of time on the pin to which you're feeding the external signal and have the ISR increment a counter variable on each interrupt.
• Depending on the frequency range of the signal, you may be able to use InputCaptureEx() to record the data from a series of transitions and then analyze the high and low times to determine frequency.

kurakaira wrote:What do You recommend

Once you remove the 100mS disabling of interrtups, Option 1 should work fine. If you can reduce the baud rate on the 4x20 display, that would reduce the interrupt load on the system. If that is not possible, Option 2 may be a better choice.

kurakaira wrote:There are 10 gaps on the flywheel and the RPM varies between 0-8500 rpm

Does that mean, then, that the frequency of the RPM signal varies over the range of 0Hz to about 1420Hz? Is the duty cycle constant? What is the minimum high or low time over the RPM range? If the duty cycle is constant at 50%, the minimum high or low time would be about 350uS. Using the divide-by-1024 prescaler would give you 70uS resolution and InputCapture() would not overflow until the speed was below 1RPM.

Problem ...
I did implement the 74hct138 and it works nicely , so far ...
But i used pin6 , 7 , 8 to drive leds trough a transistors .
The ZX does not start after powerup if pin 7 is low !?
If i have pins 6 & 8 connected everything works , but if i have pin 7 connected ( reads 0.05v between ground and floating led input ) the ZX wont start .
My bad , or something to do with the ZX missing its external ram ?

kurakaira wrote:The ZX does not start after powerup if pin 7 is low !?

My guess is that pin 5 is also low. On the 40-pin VM mode ZX devices, having pins 5 and 7 low at startup is the trigger to enter emergency VM update mode. Depending on what you have connected to those two pins, it may be sufficient to add a pullup resistor to ensure that at least one of them is high at startup.

As usual , You were correct .
Pin5 was MAX6675 ChipSelect.
I added a 10k pullup to pin7 and now it works !
Thank You !
I will post more info when i get to program the rest ... RPM readings and such ..
I wired the rpm hall to pin20 , i will proceed with InputCapture ... having given it a little thought , it is the best course of action .
I'll be in touch ,,,