Using hsersetup in automatic background mode

[pjrebordao]

If using the hardware serialin in automatic mode, I suppose there's no way to restrict the amount of scratchpad area used ?

Part of those 128 bytes (20X2) could be useful somewhere else...

 

[Goeytex]

If using the hardware serialin in automatic mode, I suppose there's no way to restrict the amount of scratchpad area used ?

Part of those 128 bytes (20X2) could be useful somewhere else...

Of course there is a way. If you are only expecting x bytes of data, then process the data and reset the hserptr to zero.
You can use as many or as few bytes of the SP memory as you want (within the limitations of the size of the data packet).

 

[pjrebordao]

Obvious... Thanks

 

[Morganl]

That workaround can only be used when there is no more receiving during processing of the input.
I am thinking on using it where i never know when there will be more bytes coming in...

I am going to use a 40X2, so 1024 bytes scratchpad.
Is all that scratchpad being used, for background receive?
I am hoping it will only use a byte pointer, so 256 first bytes, but i failed to find in manual.

 

[srnet]

I am going to use a 40X2, so 1024 bytes scratchpad.
Is all that scratchpad being used, for background receive?
I am hoping it will only use a byte pointer, so 256 first bytes, but i failed to find in manual.

Yes, all 1024 bytes.

ptr on the 28X2/40X2 is a word variable, if it was only a byte variable you would not be able to use it to access all the scratchpad.

Explained on page 12 of the manual - 'Variables - Scratchpad'

 

[inglewoodpete]

[daydreams]It would be a really nice firmware change if the scratchpad available for hSerin could be restricted to a range eg 64, 128 or 256 bytes. I imagine the range could by specified as parameter/s on the hSerSetup command.[/daydreams]

What's the chances, Technical?

 

[hippy]

It is technically possible to have the size of the HSERIAL background buffer programmatically selectable but that would require a firmware change. The real questions are whether it is necessary, adds anything useful or is worth the effort.

The X2 parts have 256 bytes of variable/RAM so it is difficult for me to see how or when having more than that would be useful or necessary if using background receive. Perhaps some example of practical necessity would help.

There may be other ways to control scratchpad usage to keep some bytes free such as handling the 'hserflag' interrupt and resetting 'hserptr'.

 

[Buzby]

.... The X2 parts have 256 bytes of variable/RAM so it is difficult for me to see how or when having more than that would be useful or necessary if using background receive. Perhaps some example of practical necessity would help.

There may be other ways to control scratchpad usage to keep some bytes free such as handling the 'hserflag' interrupt and resetting 'hserptr'.

I too can't see the need for *more* hser scratchpad, but can think of when I might need less. Practical necessity is when you use hser and hi2c at the same time, both using the scratchpad, and resetting hserptr during the hser interrupt worked a treat to keep the two lots of data apart.

 

[Morganl]

As this is a device used for education, it should teach how to to things, and that is ring buffer.
Resetting a pointer for a background recieve service hoping there will be no recieve for a period is teaching stupidity!
Simple solution: make hserptr a byte pointer, and 28X2 and 40X2 devices have a 256 byte ring buffer.
Reset it if you like russian roulette

 

[srnet]

As this is a device used for education, it should teach how to to things, and that is ring buffer.

Is it not already a ring buffer, and a 1024 byte one ?

 

[Morganl]

Is it not already a ring buffer, and a 1024 byte one ?

Ah yes.
I meant to say it should be possible to use it as ring buffer for hserial, while still having scratchpad available for other uses.
-Especially the hi2c slave recieve buffer would be very nice to have at the same time.

 

[Goeytex]

As this is a device used for education, it should teach how to to things, and that is ring buffer.
Resetting a pointer for a background recieve service hoping there will be no recieve for a period is teaching stupidity!

No, stupidity is being dogmatic and assuming only one way to do something while demanding others to comply. If I know the packet is 32 bytes and I know the packet will be sent every 200ms, then resetting the pointer is perfectly OK. It also means that SP memory above location 32 can be used for other purposes.

Presuming that one must "hope" that there will be no more data received is teaching the ignorant notion that all applications are the same and that data is never received in a timed manner. Further stupidity.

 

[Morganl]

Sorry i sounded too harsh.
As a design engineer and repair guy i have seen too many *ready* solutions fail as they did not live up to the stated spec in application, but possibly did in the environment their designer had.
If you know your system and nothing you have no control of will send to you, naturally that would be OK.

 

[BESQUEUT]

As this is a device used for education, it should teach how to to things, and that is ring buffer.
Resetting a pointer for a background recieve service hoping there will be no recieve for a period is teaching stupidity!
Simple solution: make hserptr a byte pointer, and 28X2 and 40X2 devices have a 256 byte ring buffer.
Reset it if you like russian roulette

100 % OK with you !!!
But lots of examples for background receive do that....
And others do nothing more than a looping pause...
that is (to my mind) another stupidity : if you have nothing to do, why are you using background receive ?
I did try to receive data at 4800 bauds, do some filtering, and re-send some data at 19200
That simply not work, because serial transmit is not compatible with background receive !

 

[BESQUEUT]

If I know the packet is 32 bytes and I know the packet will be sent every 200ms, then resetting the pointer is perfectly OK. It also means that SP memory above location 32 can be used for other purposes.

Suppose only one byte missing due to communication problem, restarting of emiter,...
You will reset after first byte of second packet,...