That time-consuming serin, serrxd, hserin? 12 bytes

[phoenix70]

I have a scale, which transmits up to 19,200, N8, 1, I connect to the PICAXE 20x2, at 9600, I want to repeat this information in another display, and print, header, and footer, and other things. Everything works fine, but apparently the instruction SERIN, SERRX create a delay to execute, and multiplexing is slow and blinking.

....

main:
ptr=1
serrx (control), @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc

works poorly and slow
----------------------------------------
ptr=1
serrx (control), @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc, @ ptrinc

main:


If I run it once, works perfect, but does not update

This is because it is linear programming?, As could fix it?

 

[hippy]

If the program runs once it indicates that "SERRX" ( SERRXD one presumes ) is receiving the data and storing it correctly and your program is later processing it as required. It is unclear where the problem you have is but does sound like it is related to the program flow, timing or synchronisation with the data being received.

Data cannot be received unless waiting in "SERRX" and other code ( such as that which may multiplex a display ) cannot run while it is doing so. The best option would perhaps be to use HSERIN to background receive the data then process that once received.

 

[phoenix70]

Thanks Hippy, Your website, has served me very helpful and the of phanderson

If I put the serrxd within the cycle, is delayed and the displays are flashing, if the serrxd cycle bag and let it take the data once, it works perfectly but does not update ..

If I put the hserin, not time consuming in the program every time you take the 12 bytes?

How would I know that I already have the 12 bytes? to process the information?

If I use hserin, I can use let pinsB% 000000x? B.7 as I do ?

 

[MartinM57]

...multiplexing is slow and blinking....could I fix it?

Perhaps. But it may be very hard, which is why specialist multiplexing chips exist (MAX7219 etc). Any PICAXE commands that take some time to process will take away the ability for the PICAXE to multiplex the displays at the same time.

You will have to do one or more of:
- using the maximum SETFREQ you can (e.g 64 Mhz, but that is only on some 3.3v X2 parts)
- minimising all other code
- making the multiplexing code as absolutely efficient as possible.

If you want a perfect solution where the PICAXE is multiplexing so well that you never get any flicker, but can still run other commands like serin etc - then I think you will find it very hard/impossible.

 

[phoenix70]

thanks for answering, I analyzed many examples in the thread with the maxim 7219 and is very powerful, and I think that is the solution, but here in Venezuela I fail to buy it. Try increasing the speed to m32 and m64, but the serrxd works to 9600, and must pass m8, in that time, he loses the multiplex, besides the scale communicates to 9600, and so use SERIN, the time will load the data the same, because the capture of 9600, I will try to hserin, but now I am not sure how to handle the decimal point with 7 bits, not 8 bitscomo it did before, because B.6 is hserin.

Any suggestions are welcome, I was thinking 74,373 or 74,374 on each display

 

[hippy]

If I put the serrxd within the cycle, is delayed and the displays are flashing, if the serrxd cycle bag and let it take the data once, it works perfectly but does not update ..

That is probably because SERRXD only ever executes one, after reading the first data the multiplex is entered but no further data is ever read.

Of course, if you wait for data, that slows down the multiplex loop to when data may arrive causing flicker. If you don't wait for data then you miss it.


If I put the hserin, not time consuming in the program every time you take the 12 bytes?

There will be some impact on the code but the time taken should be minimal. It depends on how you handle the data received.


How would I know that I already have the 12 bytes? to process the information?

You will need to track the 'ptr' and 'hserptr' variables to determine when 12 bytes have been received, or count received bytes. You can either check when each character is received in interrupt or check the required number of bytes have been received within the multiplex loop.

Within the multiplex loop will be better otherwise interrupt handling can (1) extend the time any particular multiplexed digit is illuminated for, leading to uneven brightness and rippling of the display, and (2) lead to changing the display data while displaying the data though that can be minimised and avoided.


If I use hserin, I can use let pinsB% 000000x? B.7 as I do ?

It appears you are using the 20X2 so using HSERSETUP will require the use of B.6 (RX) and C.0 (TX). This may mean having to reallocate your signalling lines and redesign your hardware to suit that. Whenever HSERSETUP is used it does remove the associated RX and TX pins from general purpose use.

 

[phoenix70]

ok, thanks, I'll work a while and tell them the results

 

[phoenix70]

hello friends, I have a doubt with hserin, and make it work in background mode, time consuming and certainly not the PICAXE, but information I have it all messy and I can not filter it.

The scale continuously sends me the following story:

$02$20<8bytes> $20KG

something like this:

$02 100.85 KG to 9600 bps

My problem is I can not take the data, since everything is very fast, with hserptr, @ptr, @ptrinc, how can I find the data and associate them to a variable and always be there?

if I used hserin 0,12 but it would be perfect , but not background, I need to take 12 of the 127 bytes of fixed scranpath forever.