holidays over, back to work :)
@ficeto thanks will merge everything today
finally started building the board manager package...
@ficeto any documentation on the range of frequencies users can pass into
analogWriteFreq?
i suppose it's hard to give exact numbers because that will depend on the number of active channels... still, some ballpark values would be good
also why do we need aliases for timer functions? is there any use case to override them?
https://github.com/ficeto/Arduino/commit/2a2e05f1c5ea4d9af61df230aa7be893b8eeff54#diff-b16a3a11ea70335895fed0659b955f74R63
https://github.com/ficeto/Arduino/commit/2a2e05f1c5ea4d9af61df230aa7be893b8eeff54#diff-b16a3a11ea70335895fed0659b955f74R63
no, to be honest did not quite uderstand why there are any, but did it while I was messing with it thinking of memory issue somewhere
you know those things you do when you have no clue what is going on... :D
and while doing it I saw a method I did not see used anywhere
and that was the init method missing from the board init
removed them
:) okay
@iggr I want to ask you what is the difference in using the lwip's tcp methods and Espressif's espcon ones
I started looking into the tcp server stuff, hunting for wasted time and memory
espconn is a wrapper over lwIP
not the best one
upload speed is about 10 times slower than download
has many bugs (they published sources at some point)
sure thing, but has one advantage
more than one client can be connected at a time
and more than one server can be run at a time
we can have more than one with lwIP as well.
it's just a limitation of my webserver library
can not handle them simultaneously though
and kills the connection on send
we can't because arduino world is single-threaded and blocking
maybe you can help me out make those things possible
okay, I think we can do that for the webserver...
single thread has nothing to do with this
point is when I send a packet, not to block untill ack on that packet
so other packet can be received and handled
well not SD Card reads obviously, but many other API calls can go through
have a telnet server for example providin Serial-like stream, while the web server is also running
sure. let me think about this a bit how to handle multiple connections in terms of API...
I put some also last night.. I came up so far with this:
have the server have an option to close the connection on send
then handle on the client side only the client when it has data
just like it is now
but some callbacks involved so nothing blocks
that is the only advantage in the espcon stuff
now what actually happens is that connection get's opened (accepted), but nothing can go though while another is handled
so if something large comes in... buffers go to hell and watchdog kills it all
ESP8266WebServer::handleClient() should not exist, instead, should be triggered on client data or connect if data needs to be send to the client immediately (hello from the server)
also for fragmentation I was thinking of something like ::beginTransaction()//::endTransaction() stuff
::endTransaction(true) to close the client maybe (HTTP)
is Serial.rx still having issues?
I haven't checked it
i suppose something's wrong with pin function on RX pin, because that was the only thing that changed
but i fixed that...
mkay
i'm just cleaning up my udp/mdns stuff. will commit and check hardwareserial next.
damned it is failing and I checked all changes I have made
it is literally the same exact code
tried erase_flash? :)
hahahahaha
oh, wait, do dump_flash before that...
I have a spare terminal open just for that
what command should I use for 512K flash
esptool.py -p /dev/tty.usbserial-A9G7ZHP5 read_flash 0 0x80000 /tmp/dumb.bin
that was
dump.bin :smile:
ok so the dump looks fine
there are a couple of block of data left over from previous sketch
but they were starting from the next block address
then erase_flash should not resolve issue
so should not be an issue at all
nope
in my implementation I also set RX FIFO TimeOut and Overflow interrupts
but those were not set in the previous implementation and I left it as is
but rx was working at some point so perhaps that's not the issue
i actually had this RX issue once, let me check my commits log...
it does trigger the watchdog after a second or so once I transmit something
found it
what was it? i've just rolled back to the version from April 26, and it works.
Current non-working:
void ICACHE_RAM_ATTR uart_interrupt_handler(uart_t* uart) {
// -------------- UART 0 --------------
uint32_t status = U0IS;
if(Serial.isRxEnabled()) {
if(status & (1 << UIFF)) {
while(true) {
int rx_count = (U0S >> USTXC) & 0xff;
if(!rx_count)
break;
while(rx_count--) {
char c = U0F & 0xff;
Serial._rx_complete_irq(c);
}
}
U0IC = (1 << UIFF);
}
}
if(Serial.isTxEnabled()) {
if(status & (1 << UIFE)) {
U0IC = (1 << UIFE);
Serial._tx_empty_irq();
}
}
// -------------- UART 1 --------------
status = U1IS;
if(Serial1.isRxEnabled()) {
if(status & (1 << UIFF)) {
while(true) {
int rx_count = (U1S >> USTXC) & 0xff;
if(!rx_count)
break;
while(rx_count--) {
char c = U1F & 0xff;
Serial1._rx_complete_irq(c);
}
}
U1IC = (1 << UIFF);
}
}
if(Serial1.isTxEnabled()) {
status = U1IS;
if(status & (1 << UIFE)) {
U1IC = (1 << UIFE);
Serial1._tx_empty_irq();
}
}
}
current working:
void ICACHE_RAM_ATTR uart_interrupt_handler(uart_t* uart) {
// -------------- UART 0 --------------
if(Serial.isRxEnabled()) {
while(U0IS & (1 << UIFF)) {
Serial._rx_complete_irq((char)(U0F & 0xff));
U0IC = (1 << UIFF);
}
}
if(Serial.isTxEnabled()) {
if(U0IS & (1 << UIFE)) {
U0IC = (1 << UIFE);
Serial._tx_empty_irq();
}
}
// -------------- UART 1 --------------
if(Serial1.isRxEnabled()) {
while(U0IS & (1 << UIFF)) {
Serial1._rx_complete_irq((char)(U1F & 0xff));
U1IC = (1 << UIFF);
}
}
if(Serial1.isTxEnabled()){
if(U1IS & (1 << UIFE)) {
U1IC = (1 << UIFE);
Serial1._tx_empty_irq();
}
}
}
FifoFull should be cleared on each byte read
It's likely not the reason, because this is an older working version:
if(status & UART_RXFIFO_FULL_INT_ST) {
while(true) {
int rx_count = (READ_PERI_REG(UART_STATUS(0)) >> UART_RXFIFO_CNT_S) & UART_RXFIFO_CNT;
if(!rx_count)
break;
while(rx_count--) {
char c = READ_PERI_REG(UART_FIFO(0)) & 0xFF;
Serial._rx_complete_irq(c);
}
}
WRITE_PERI_REG(UART_INT_CLR(0), UART_RXFIFO_FULL_INT_CLR);
}
anyway, I like your new version — it's much more compact
however... seems like you are reading just one character per interrupt
no
i'm actually checking for the interrupt after each read
and releasing the routine only after the flag clears
the fact that I'm clearing it, does not mean that it's cleared
that's why it's in the while loop
right... and the interrupt will trigger while there's more than 1 char in fifo
okay. makes sense.
yes
ficeto/Arduino@9436222
i hope you didn't roll in the main branch
no, i just reverted some files locally
merging your pull...
why did you move Adafruit library from esp8266 to common libraries?
was not me
ah right i see
sorry
merged the wrong way :)
:D
i put it there because it also work in the normal arduino
transparent tcp socket <=> UART server is working charms :)
will put up an example
are you sending each character separately?
noooo :D
would help to disable Nagle for this case
#include <ESP8266WiFi.h>
#define DBG_OUTPUT_PORT Serial1
#define MAX_SRV_CLIENTS 1
const char* ssid = "nbis-test";
const char* password = "1234567890";
WiFiServer server(21);
WiFiClient serverClients[MAX_SRV_CLIENTS];
/*
WiFiServer wwwserver(80);
void handleWWWClients(){
WiFiClient wwwserverClient = wwwserver.available();
if(!wwwserverClient) return;
while (wwwserverClient.connected() && !wwwserverClient.available()) delay(1);
while(wwwserverClient.available()) DBG_OUTPUT_PORT.write(wwwserverClient.read());
wwwserverClient.print("HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\nConnection: close\r\n\r\nHello!\r\n");
}
*/
void handleClients(){
uint8_t i;
if (server.hasClient()){
for(i = 0; i < MAX_SRV_CLIENTS; i++){
if (!serverClients[i] || !serverClients[i].connected()){
if(serverClients[i]) serverClients[i].stop();
DBG_OUTPUT_PORT.print("Client Connected At: "); DBG_OUTPUT_PORT.println(i);
serverClients[i] = server.available();
return;
}
}
//no free spot
WiFiClient serverClient = server.available();
serverClient.stop();
}
for(i = 0; i < MAX_SRV_CLIENTS; i++){
if (serverClients[i] && serverClients[i].connected()){
if(serverClients[i].available()){
while(serverClients[i].available()) Serial.write(serverClients[i].read());
}
}
}
}
void messageAll(uint8_t * data, size_t len){
for(uint8_t i = 0; i < MAX_SRV_CLIENTS; i++){
if (serverClients[i] && serverClients[i].connected()){
serverClients[i].write(data, len);
delay(1);
}
}
}
void setup() {
Serial.begin(115200);
DBG_OUTPUT_PORT.begin(115200);
DBG_OUTPUT_PORT.setDebugOutput(true);
DBG_OUTPUT_PORT.print("\n");
WiFi.begin(ssid, password);
DBG_OUTPUT_PORT.print("Connecting to "); DBG_OUTPUT_PORT.println(ssid);
uint8_t i = 0;
while (WiFi.status() != WL_CONNECTED && i++ < 20) delay(500);
if(i == 21){
DBG_OUTPUT_PORT.print("Could not connect to"); DBG_OUTPUT_PORT.println(ssid);
while(1) delay(500);
}
DBG_OUTPUT_PORT.print("Connected! IP address: ");
DBG_OUTPUT_PORT.println(WiFi.localIP());
server.begin();
//wwwserver.begin();
DBG_OUTPUT_PORT.println("Server started");
}
void loop() {
handleClients();
//handleWWWClients();
if(Serial.available()){
size_t len = Serial.available();
uint8_t sbuf[len];
Serial.readBytes(sbuf, len);
messageAll(sbuf, len);
}
}
yeah... did not see exposed method for that?
it's not exposed from ClientContext and WifiClient, need to pull it through
it's a lwIP function
i saw it in the headers
there should be a timeout somewhere also, or shuld I implement that myself?
idle_timeout
how you want me to name that new method? nagle sounds bad to me
setNoDelay(bool) seems better
i'd vote for disableNagle(bool disable)
because i would not have to go into sources to see what this setNoDelay does
but... NODELAY is what it is in terms of TCP naming and people not familiar with lwip
right, forgot about that
in all languages I have used to implement sockets it TCP_NODELAY
okay then, setNoDelay(bool enabled)
holly cow it's fast!
would help to disable Nagle for this case
told ya :)
ficeto/Arduino@380c3f5
now I can put to use those shitty 8 pin modules I have a few of...
i imagine hacking a wifi arduino uploader would be a breeze
um.. what's the point disabling it for server pcb?
it's never actually used for data transfer AFAICT
that is actually where it should be and is disabled in my sketch
I imagine that the client should inherit that
at least that is how it is on a normal OS
you create a socket server and flag it with no_delay
core_esp8266_wiring_pwm.c:(.text+0x12c): undefined reference to `qsort'
removing libc without implementing qsort broke stuff :)
yeah...
it's why I added libc
but libc has many not compiling and buggy functions in our case
have a better qsort?
and what are those functions?
asking because I did not run into any
better not sure but i have some qsort function neeed to search it
anything that uses malloc and free :)
we have those redefined, don't we?
because it links to malloc and free from newlib which don't work
Links2004/Arduino@d050ced
in this commit are some of the errors
some are ok but the most not
sure, find that qsort and let's take a look
and linking a lib that have code inside witch is not or not in half working is a bad idea from my point of view
actually for N<=8 insertion sort should be faster
better implement or copy the working/needed functions
so we can just have pwm_insertion_sort
hehe inlined bubble sort beats almost everything
static __inline__ int _qsort(uint16_t *d, uint16_t l){
uint16_t i, j;
for (i = 1; i < l; i++) {
uint16_t tmp = d[i];
for (j = i; j >= 1 && tmp < d[j-1]; j--)
d[j] = d[j-1];
d[j] = tmp;
}
}
ficeto/Arduino@fdbd40d
lots of mds compile errors
includes missing
fixed
sorry
esp8266/Arduino@1862e0d
thanks :)
what is Fatal exception (9):
it in the new SPI things
SPIClass::writeBytes
triggered by write to SD
@Links2004 any thoughts?
it's actually in SPIClass::writeBytes_
at my test (yesterday) the SD was working, will check SPI one moment
what I did is upload a file
so that is multypacket
I have a dump and the address of failure if you are interested
yes :)
40214c9c <_ZN8SPIClass11writeBytes_EPhh>:
40214c9c: f0c112 addi a1, a1, -16
40214c9f: 01e9 s32i.n a14, a1, 0
40214ca1: ff5b21 l32r a2, 40214a10 <_ZN8SPIClass5beginEv+0x64>
40214ca4: 03ed mov.n a14, a3
40214ca6: ff5b31 l32r a3, 40214a14 <_ZN8SPIClass5beginEv+0x68>
40214ca9: 0161d2 s32i a13, a1, 4
40214cac: 3109 s32i.n a0, a1, 12
40214cae: 0261c2 s32i a12, a1, 8
40214cb1: 74d040 extui a13, a4, 0, 8
40214cb4: 0020c0 memw
40214cb7: 02c8 l32i.n a12, a2, 0
40214cb9: 10cc30 and a12, a12, a3
40214cbc: ff4c56 bnez a12, 40214cb4 <_ZN8SPIClass11writeBytes_EPhh+0x18>
40214cbf: 112dd0 slli a2, a13, 3
40214cc2: ffa005 call0 402146c4 <_ZN8SPIClass11setDataBitsEt$isra$0>
40214cc5: dd3b addi.n a13, a13, 3
40214cc7: 41d2d0 srli a13, a13, 2
40214cca: 0c2d mov.n a2, a12
40214ccc: fff351 l32r a5, 40214c98 <_ZN8SPIClass7write32Ej+0x28>
40214ccf: fff161 l32r a6, 40214c94 <_ZN8SPIClass7write32Ej+0x24>
40214cd2: 000306 j 40214ce2 <_ZN8SPIClass11writeBytes_EPhh+0x46>
40214cd5: 346a add.n a3, a4, a6
40214cd7: 3e3a add.n a3, a14, a3
40214cd9: 0338 l32i.n a3, a3, 0
40214cdb: 221b addi.n a2, a2, 1
40214cdd: 0020c0 memw
40214ce0: 0439 s32i.n a3, a4, 0
40214ce2: 425a add.n a4, a2, a5
40214ce4: 743020 extui a3, a2, 0, 8
40214ce7: 1144e0 slli a4, a4, 2
40214cea: e79d37 bne a13, a3, 40214cd5 <_ZN8SPIClass11writeBytes_EPhh+0x39>
40214ced: ff4821 l32r a2, 40214a10 <_ZN8SPIClass5beginEv+0x64>
40214cf0: ff4931 l32r a3, 40214a14 <_ZN8SPIClass5beginEv+0x68>
40214cf3: 0020c0 memw
40214cf6: 0248 l32i.n a4, a2, 0
40214cf8: 204430 or a4, a4, a3
40214cfb: 0020c0 memw
40214cfe: 0249 s32i.n a4, a2, 0
40214d00: 0020c0 memw
40214d03: 0248 l32i.n a4, a2, 0
40214d05: f78437 bany a4, a3, 40214d00 <_ZN8SPIClass11writeBytes_EPhh+0x64>
40214d08: 3108 l32i.n a0, a1, 12
40214d0a: 21c8 l32i.n a12, a1, 8
40214d0c: 11d8 l32i.n a13, a1, 4
40214d0e: 01e8 l32i.n a14, a1, 0
40214d10: 10c112 addi a1, a1, 16
40214d13: f00d ret.n
40214d15: 000000 ill
40214cd9: is the address
Upload: START, filename: /test.jpg
Fatal exception (9):
epc1=0x40214cd9, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea8b6, depc=0x00000000
may an null ptr to the writeBytes_ function data parameter is not checkted
can you add a test and check again?
if(!data) {
os_printf("NULL PTR in writeBytes_ ");
return;
}
sure
same thing
data is not null
Upload: START, filename: /test.jpg
Fatal exception (9):
epc1=0x40214ced, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea8d6, depc=0x00000000
mmm for the moment no idea so more debug out :)
void SPIClass::writeBytes_(uint8_t * data, uint8_t size) {
while(SPI1CMD & SPIBUSY) {}
// Set Bits to transfer
setDataBits(size * 8);
volatile uint32_t * fifoPtr = &SPI1W0;
uint32_t * dataPtr = (uint32_t*) data;
uint8_t dataSize = ((size + 3) / 4);
os_printf("[SPIClass::writeBytes_] data: 0x%08X size: %d dataSize: %d\n", data, size, dataSize);
delay(100);
while(dataSize--) {
*fifoPtr = *dataPtr;
dataPtr++;
fifoPtr++;
}
SPI1CMD |= SPIBUSY;
while(SPI1CMD & SPIBUSY) {}
}[SPIClass::writeBytes_] data: 0x3FFE9E5C size: 64 dataSize: 16
[SPIClass::writeBytes_] data: 0x3FFE9E9C size: 64 dataSize: 16
[SPIClass::writeBytes_] data: 0x3FFEA9EA size: 64 dataSize: 16
Fatal exception (9):
epc1=0x40214cf9, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea9ea, depc=0x00000000
ok the debug out looking good can you add fifoPtr too
data: 0x3FFE9E94 size: 64 dataSize: 16 fifo:0x60000140
data: 0x3FFEA8EE size: 64 dataSize: 16 fifo:0x60000140
Fatal exception (9):
epc1=0x40214cf5, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea8ee,
ok all ptr looking good data from ram and fifo pointing to the SPI HW FIFO registers.
can you move the debug function in to the while may some callculation go wrong, but at the moment i dont have any idea what there can go wrong.
and use dataPtr for data in the while ;)
lower speed was no help
you can reduse the delay its only ro get the debug msg out before the error
fifo: 0x60000168 64x5
fifo: 0x6000016C 64x4
fifo: 0x60000170 64x3
fifo: 0x60000174 64x2
fifo: 0x60000178 64x1
fifo: 0x6000017C 64x0
fifo: 0x60000140 64x15
Fatal exception (9):
epc1=0x40214cfa, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea8ce, depc=0x00000000
after the x is the dataSize?
yes
"0x6000017C 64x0" is a working write but why the next new write call fails make no sense for me.
tried another file
same thing
at the same place
and 64x15 again
can you uploade the sketch some where, then i setup an ESP tomorrow and do some testing. for the moment i have no idea where the error is coming from.
currently i use the function with the LCD and all is working fine there i send 150kB at one.
currently i use the function with the LCD and all is working fine there i send 150kB at one.
sketch is an example in the latest git
has the files for the SDcard there as well
you go to http://espip/edit
and you will find the uploader and all there
ok then i test it tomorrow
you are writing 4 bytes at a time
what if the packet is not even number of bytes?
fatal exception (9) is unaligned memory read/write
SD Card initialized.
Upload: filename: /reivilo.png
Upload: data: 4
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 1460
Upload: data: 29
Upload: data: 1460
Fatal exception (9):
epc1=0x40214cf5, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffea817, depc=0x00000000
when an uneven packet like that "29" comes in, the problem shows
excvaddr=0x3ffea817
reading a dword from unaligned address
@igrr Do you want me to discuss changes to get support for progmem here?
I suppose we need to bring back FlashStringHelper, right?
yes, it really is just a fake pointer type so that unique methods are called instead of the const char* variant ones.
The key to the solution is ICACHE_RODATA_ATTR and that program RAM and ROM require to be fetched by 32bits.
in PgmSpace.h, the important defines become
#define PROGMEM ICACHE_RODATA_ATTR
#define PGM_P const char *
#define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s); &__c[0];}))
Then the pgmread* need to fetch by 32bits and return the requested bytes.
If all the abstraction methods that end in underscore P are put back, it should just work. Already tested the ICACHE_RODATA_ATTR and fetching from it.
If you fetch by less than 32bits (address is not 32 bit aligned) it will cause an processor exception.
okay, sounds perfect
ok, I will put together a push
(sorry pull)
I was thinking about using user-defined literals instead of F() macros as that would give you an opportunity to create a lazy-initialized RAM copy of the string and use all the regular methods. But haven't implemented anything, so let's go with your proposal.
@Links2004 here's the story mate
I reworked the POST parser to push to the sketch callback 1024 bytes every time, but the last
so your function works now
on another note, the SD lib always writes 512 byte bocks,regardless of the data size (thus the 1024 size i picked)
I have no clue what's in the rest of the bytes, but that and the fact that you write 4 bytes in a fifo reg, brings that error