The standard uart buffer is in flashforth 5 on the scamp3 31 bytes. Is it posible to enlarge this buffer?
Or is it posible to write my own interrupt driven buffer, without any conflict with the one now installed for handling the uart receive?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It should possible to install your own UART RX routines but it is not trivial. You have provide your own version of RX1, RX1? and the interrupt routine. And these have to be installed after every restart using a turnkey word.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder why you would you need a larger interrupt buffer ?
Normally the application will empty the interrupt buffer to its own buffer using KEY and the scamp is quite fast to do that. Or do you have a very slow application ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm interfacing the esp-01 with a scamp. Will use the AT commands, and the response in my case calling a timeserver is greater than 31 characters. After sending the command I will wait until the OK promt or ERROR promt is send back. maby yoy have other sugestions to solve this? Cheers Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wont to read the timeserver, he send via esp-01 a stream of ascii data. My first idee was to put all in the uart buffer, and from there extract te time and date. Have no thoughts about going another direction. Are you thinking about an another way to extract?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You cannot use the interrupt buffer to store data. Your task as a application programmer is to empty the interrupt buffer as fast as possible into your application buffer using KEY and KEY? or ACCEPT (which uses KEY and KEY?)
If the stream of data ends in a newline you can use ACCEPT to receive the data into your own buffer. If the data ends in some other way you must write your version of ACCEPT to receive your custom data. I think I have an example of receiving NMEA data somewhere. I'll try to find it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The data the ESP01 sends over the UART consists of multiple parts.
Each part is terminated with a cr and lf.
However, Accept stops at the first received cr or lf.
I want to place the entire received data in a buffer, textBuf (255 characters).
Is there a solution for this in Flashfort?
Thanks in advance.
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
:append( addr len str -- )>rr@dupc@+1+\ addr len end+1swap>rr@cmover>r>dupc@rot+swapc!;ramcreatemesg256allot:getmesgtib20accepttibswapmesgplacetib20accepttibswapmesgappend;
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you cam read with rx1.
0 value index
begin index 255 < while rx1? if rx1 textbuffer index + c ! index 1 + to index then repeat
it's not tested, but you can test and improve and it will work.
you can think other similar alternatives.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As answer on your question, when I make a WiFi connection with AT command there are 3 or 4 parts, but I have seen with the analyser the time between the parts are different, and unpredictable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was just wondering if you for a specific request get a specific amount of reponses. If it is a variable amount you must find a way to handle that.
There is no timeout in ACCEPT so calling it from the main task would block it if there is no data coming in.
I would put the ACCEPT calls in a background task and take each response into a separate buffer in a round robin fashion. Then with help of some global variables the main task can analyze the buffers and take whatever action is needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a question about receiving the answer from the esp01. I get several chunks of code terminated with cr/lf. But how to stop the loop of reading the charachters from the uart, to go furher with the program. The gap (ms) between the data chunks is also not constant. Have no clou how to break out this kind of loop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The best way would be to write an accept version that supports a timeout. I don't have code for that.
Or you could put ACCEPT in a background task as I explained earlier.
One way would be to check with KEY? if there is a character waiting and after that call ACCEPT, then ACCEPT should not hang if just the string is terminated with a newline.
:accept2( addr len -- len)key?ifacceptelse0then;
Last edit: Mikael Nordman 2025-08-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An additional note on using ACCEPT. The IO must be initialized to use RX1 and RX1? for it to work with the serial port and after using it changed back to the USB connection to use RXU RXU? TXU.
In order for ACCEPT not to echo everything it receives ( which would mess up the esp01 I suspect), EMIT should be configured to DROP instead of TX1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
:accept2( addr len -- len)key?ifacceptelse0then;:>uart1[']rx1'key![']rx1?'key?![']drop'emit!;:>usb[']rxu'key![']rxu?'key?![']txu'emit!;ramcreateresp132allotramcreateresp232allotramcreateresp332allotramcreateresp432allot:connects'AT+CONNECT,"bla",bla'sendcommand100msresp11+31accept2resp1c!100msresp21+31accept2resp2c!100msresp31+31accept2resp3c!100msresp41+31accept2resp4c!;>uart1connect>usb\ check results in resp buffers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The standard uart buffer is in flashforth 5 on the scamp3 31 bytes. Is it posible to enlarge this buffer?
Or is it posible to write my own interrupt driven buffer, without any conflict with the one now installed for handling the uart receive?
No, it is not possible without recompiling FF.
It should possible to install your own UART RX routines but it is not trivial. You have provide your own version of RX1, RX1? and the interrupt routine. And these have to be installed after every restart using a turnkey word.
I wonder why you would you need a larger interrupt buffer ?
Normally the application will empty the interrupt buffer to its own buffer using KEY and the scamp is quite fast to do that. Or do you have a very slow application ?
I'm interfacing the esp-01 with a scamp. Will use the AT commands, and the response in my case calling a timeserver is greater than 31 characters. After sending the command I will wait until the OK promt or ERROR promt is send back. maby yoy have other sugestions to solve this? Cheers Jan
I do not understand your problem. How are you using KEY or ACCEPT ?
Could you describe the procedure in more detail.
I wont to read the timeserver, he send via esp-01 a stream of ascii data. My first idee was to put all in the uart buffer, and from there extract te time and date. Have no thoughts about going another direction. Are you thinking about an another way to extract?
You cannot use the interrupt buffer to store data. Your task as a application programmer is to empty the interrupt buffer as fast as possible into your application buffer using KEY and KEY? or ACCEPT (which uses KEY and KEY?)
If the stream of data ends in a newline you can use ACCEPT to receive the data into your own buffer. If the data ends in some other way you must write your version of ACCEPT to receive your custom data. I think I have an example of receiving NMEA data somewhere. I'll try to find it.
Here is an example of how to receive a NMEA message and parse the comma limited data into separate buffers for each data field. I think you could do something similar. The second link has some bug fixes.
https://sourceforge.net/p/flashforth/mailman/message/34747305/
https://sourceforge.net/p/flashforth/mailman/message/34775915/
You could also use your own buffer with ACCEPT instead of TIB to receive the data.
Last edit: Mikael Nordman 2025-08-08
Mikael,
Thanks again for your response.
The data the ESP01 sends over the UART consists of multiple parts.
Each part is terminated with a cr and lf.
However, Accept stops at the first received cr or lf.
I want to place the entire received data in a buffer, textBuf (255 characters).
Is there a solution for this in Flashfort?
Thanks in advance.
Jan
Do you know how many parts there are in a message ?
You can call ACCEPT multiple times and copy the data to your own buffer.
Here is an example.
you cam read with rx1.
0 value index
begin index 255 < while rx1? if rx1 textbuffer index + c ! index 1 + to index then repeat
it's not tested, but you can test and improve and it will work.
you can think other similar alternatives.
As answer on your question, when I make a WiFi connection with AT command there are 3 or 4 parts, but I have seen with the analyser the time between the parts are different, and unpredictable.
I was just wondering if you for a specific request get a specific amount of reponses. If it is a variable amount you must find a way to handle that.
There is no timeout in ACCEPT so calling it from the main task would block it if there is no data coming in.
I would put the ACCEPT calls in a background task and take each response into a separate buffer in a round robin fashion. Then with help of some global variables the main task can analyze the buffers and take whatever action is needed.
I have a question about receiving the answer from the esp01. I get several chunks of code terminated with cr/lf. But how to stop the loop of reading the charachters from the uart, to go furher with the program. The gap (ms) between the data chunks is also not constant. Have no clou how to break out this kind of loop.
The best way would be to write an accept version that supports a timeout. I don't have code for that.
Or you could put ACCEPT in a background task as I explained earlier.
One way would be to check with KEY? if there is a character waiting and after that call ACCEPT, then ACCEPT should not hang if just the string is terminated with a newline.
Last edit: Mikael Nordman 2025-08-16
An additional note on using ACCEPT. The IO must be initialized to use RX1 and RX1? for it to work with the serial port and after using it changed back to the USB connection to use RXU RXU? TXU.
In order for ACCEPT not to echo everything it receives ( which would mess up the esp01 I suspect), EMIT should be configured to DROP instead of TX1.
So maybe this would be feasible.