@evanh: Thanks for the bug report, a fix is checked in.
@Rayman : Thanks for the bug reports. I'll add strtok to the library in the next release, I forgot that it was missing. The problem with http_process_handler was a bug in initializing the uri_buf array; the statement uint8_t uri_buf[MAX_URI_SIZE]={0x00,}; was creating a huge number of assignments that was blowing up the register allocator. I'll look into that, but the work-around is to remove the initialization (={0x00,}) and insert an explicit memset(uri_buf, 0, sizeof(uri_buf) at the start of that function. I don't know why your other problems are happening, but perhaps it's related to this.
@ersmith Thanks! This code has several things I've never seen before, that being one of them. I guess the idea there is to just initialize the first element to zero? To make a zero length string maybe?
I'm not a big fan of this code as it's abstracted to the point that I can't follow it. But, maybe I'll give it one more try...
The WiFi Module is connected to the P2 via a serial link. This link has a max speed of 921600. Even though it is running at WiFi speeds it can only send and receive data at link speed.
@chintan_joshi : as Mike said, FlexProp just uses the WX Wifi as a kind of wireless serial link. Parallax may have some documentation on their website that says what other features are available; I'm not sure.
@evanh : thanks for the bug report, it's fixed in github source code now.
This line still doesn't work:
printf(" MAC : %02X:%02X:%02X:%02X:%02X:%02X\n", net_info.mac[0], net_info.mac[1], net_info.mac[2], net_info.mac[3], net_info.mac[4], net_info.mac[5]);
Also, I just noticed that I'm supposed to implement a 1 sec counter:
/*
* @brief HTTP Server 1sec Tick Timer handler
* @note SHOULD BE register to your system 1s Tick timer handler
*/
void httpServer_time_handler(void);
I don't think we have a 1s Tick timer handler, right?
Think I can hack with _getsec() though...
@Rayman said:
@ersmith Actually got the Wiznet code to compile after that change, thanks!
It is actually working now, but this structure initialization doesn't work:
Why do you think it doesn't work? It seems to for me (see the program listing below).
This is another strange thing that I haven't seen before... Visual Studio flags all the . as errors. But, when I looked it up, seems like it's legit.
That is odd; the declarations look legit to me, although that kind of struct initialization is a "newer" feature of C (introduced in C99, I think, so not that new!)
@Rayman said:
This line still doesn't work:
printf(" MAC : %02X:%02X:%02X:%02X:%02X:%02X\n", net_info.mac[0], net_info.mac[1], net_info.mac[2], net_info.mac[3], net_info.mac[4], net_info.mac[5]);
Again, why do you say it doesn't work? What happens when you try it? It works in my test program (again, see below).
@Rayman said:
Also, I just noticed that I'm supposed to implement a 1 sec counter:
/*
* @brief HTTP Server 1sec Tick Timer handler
* @note SHOULD BE register to your system 1s Tick timer handler
*/
void httpServer_time_handler(void);
I don't think we have a 1s Tick timer handler, right?
Right, that's definitely going to be a problem. You'll have to somehow arrange for the httpServer_time_handler() function to be called periodically. Not sure how you'll manage that, as we don't have a timer interrupt.
Here's the test program that I used to try the struct initialization and printf:
#include <stdio.h>
#include <stdint.h>
typedef enum
{
NETINFO_STATIC = 1, ///< Static IP configuration by manually.
NETINFO_DHCP ///< Dynamic IP configruation from a DHCP sever
}dhcp_mode;
/**
* @ingroup DATA_TYPE
* Network Information for WIZCHIP
*/
typedef struct wiz_NetInfo_t
{
uint8_t mac[6]; ///< Source Mac Address
uint8_t ip[4]; ///< Source IP Address
uint8_t sn[4]; ///< Subnet Mask
uint8_t gw[4]; ///< Gateway IP Address
uint8_t dns[4]; ///< DNS server IP Address
dhcp_mode dhcp; ///< 1 - Static, 2 - DHCP
}wiz_NetInfo;
/* Network */
static wiz_NetInfo net_info =
{
.mac = {0x00, 0x08, 0xDC, 0x12, 0x34, 0x56}, // MAC address
.ip = {192, 168, 1, 2}, // IP address 192.168.1.2
.sn = {255, 255, 255, 0}, // Subnet Mask
.gw = {192, 168, 1, 1}, //RJA {192, 168, 11, 1}, // Gateway
.dns = {192, 168, 1, 1}, //RJA {8, 8, 8, 8}, // DNS server
.dhcp = NETINFO_STATIC //NETINFO_DHCP //RJA // DHCP enable/disable
};
void main() {
printf(" MAC : %02X:%02X:%02X:%02X:%02X:%02X\n", net_info.mac[0], net_info.mac[1], net_info.mac[2], net_info.mac[3], net_info.mac[4], net_info.mac[5]);
}
I compiled it with flexspin -2 foo.c. The output looks like:
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
MAC : 00:08:DC:12:34:56
Eric
While testing the HD Audio ADC/DAC code I found a problem with floating point in Spin2. Here is a simplyfied code that shows the problem:
_clkfreq = 160_000_000
var
long a,b, fc
pub main()
fc := 0.2
testit(20.0, 30.0)
debug(udec(a), udec(b))
pub testit(fa, fb)
a := round(fa *. fc)
b := round(fb *. fc)
in testit() the arg2 (fb) is saved in a variable _var01, but the float routines __system___float_mul or __system___float_tointeger seems to overwrite this variable with zero, so b results always in zero.
@Rayman said:
This line doesn't work either:
static uint8_t g_http_socket_num_list[HTTP_SOCKET_MAX_NUM] = { 0, 1, 2, 3 };
When you say it "doesn't work", what exactly do you mean? Do you get a compile error? Or is it a runtime error? If the latter, what exactly are the symptoms?
@Ariba : thanks for the bug report, Andy -- the leaf function detection code was missing the Spin2 case where the function needs to call out to floating point support routines. This should be fixed in the github source repo now.
I'm pretty sure malloc is thread-safe. Though it achieves this by locking, so if you do lots of malloc/free it will die.
Also, I'm pretty sure the SD card is restricted to the cog that mounted it. Cog 0 is not special in that regard. Wonder how hard it'd be to make that properly thread-safe.
@Rayman said:
@ersmith Are the rules for what a non-main cog can't do documented?
I think they can't do malloc or access sd card, is that right? Anything else?
AFAIK all the cogs are symmetric (so they can all malloc). However, the hardware is set up so that in practice only one cog can write to any particular pin, including the SD card pins, so only the cog that first mounts the SD card can access it; similarly for all other devices. The exception is the serial port; there's some hackery in the libraries to allow all the cogs to write to that, but I don't think it can generalize to other pins, or at least not without a high cost.
@Rayman said:
@ersmith Are the rules for what a non-main cog can't do documented?
I think they can't do malloc or access sd card, is that right? Anything else?
AFAIK all the cogs are symmetric (so they can all malloc). However, the hardware is set up so that in practice only one cog can write to any particular pin, including the SD card pins, so only the cog that first mounts the SD card can access it; similarly for all other devices. The exception is the serial port; there's some hackery in the libraries to allow all the cogs to write to that, but I don't think it can generalize to other pins, or at least not without a high cost.
What I did to share access to PSRAM between two cogs in MegaYume was to enable P_INVERT on the select pin, use a lock to control access and make sure that the data lines are returned to input mode after each cog is done. Assuming the latter is already done, the only overhead would be adding a lock.
@Wuerfel_21 said:
What I did to share access to PSRAM between two cogs in MegaYume was to enable P_INVERT on the select pin, use a lock to control access and make sure that the data lines are returned to input mode after each cog is done. Assuming the latter is already done, the only overhead would be adding a lock.
That would be good practice for the default SD port in general since that also allows a driver to co-exist for the SPI Flash chip on those same pins as well.
@Rayman : I think I found the initilaization problem, arrays weren't being padded out to long boundaries when initialized, so the 6 byte "mac" array was throwing everything else off. That'll be fixed in the next release (it's fixed in the github source repo now).
@ersmith Having a strange issue (I think) with strtok()...
My program contains a .spin2 file in which I'm storing resources, like a small .png file.
It appears that the first call to strtok() corrupts the second long in the .png file.
No idea how this is possible.
This is the part that seems to do it:
if (*scan == '\0') {
strtok_scanpoint = NULL;
return(NULL);
}
In particular, the line: strtok_scanpoint = NULL; (Ok, I might be wrong about this line being the problem !!!!)
I can avoid this by adding some data before the .png file, but seems this needs fixing.
@Rayman : Can you tell what data is being written into the .png file data? Is it 4 0 bytes, or just one? Are you sure the parameters to strtok() are correct?
( Entering terminal mode. Press Ctrl-] to exit. )
Starting
*1a1*
1- PNG: 89 50 4e 47 d a 1a a
image at: 13104
String: StrTok Test String
2- PNG: 89 50 4e 47 4c b 1 0
Nexttok= StrTok
So, you don't need the hardware to reproduce this...
I'm guessing it's another strange array initialization somewhere...
Comments
@evanh: Thanks for the bug report, a fix is checked in.
@Rayman : Thanks for the bug reports. I'll add strtok to the library in the next release, I forgot that it was missing. The problem with http_process_handler was a bug in initializing the uri_buf array; the statement
uint8_t uri_buf[MAX_URI_SIZE]={0x00,};
was creating a huge number of assignments that was blowing up the register allocator. I'll look into that, but the work-around is to remove the initialization (={0x00,}
) and insert an explicitmemset(uri_buf, 0, sizeof(uri_buf)
at the start of that function. I don't know why your other problems are happening, but perhaps it's related to this.@ersmith Thanks! This code has several things I've never seen before, that being one of them. I guess the idea there is to just initialize the first element to zero? To make a zero length string maybe?
I'm not a big fan of this code as it's abstracted to the point that I can't follow it. But, maybe I'll give it one more try...
Hello @ersmith Is there any reference or sample code or library available to use Parallax WX Wi-Fi Module in P2 using Flexprop?
@chintan_joshi
The WiFi Module is connected to the P2 via a serial link. This link has a max speed of 921600. Even though it is running at WiFi speeds it can only send and receive data at link speed.
Mike
Eric,
Found a mismatch in the lutRAM function system - Appears is still using the pre-reserved assumption of 0 for copy target.
Produces the following .p2asm:
@chintan_joshi : as Mike said, FlexProp just uses the WX Wifi as a kind of wireless serial link. Parallax may have some documentation on their website that says what other features are available; I'm not sure.
@evanh : thanks for the bug report, it's fixed in github source code now.
@ersmith Actually got the Wiznet code to compile after that change, thanks!
It is actually working now, but this structure initialization doesn't work:
/* Network */
static wiz_NetInfo g_net_info =
{
.mac = {0x00, 0x08, 0xDC, 0x12, 0x34, 0x56}, // MAC address
.ip = {192, 168, 1, 2}, // IP address 192.168.1.2
.sn = {255, 255, 255, 0}, // Subnet Mask
.gw = {192, 168, 1, 1}, //RJA {192, 168, 11, 1}, // Gateway
.dns = {192, 168, 1, 1}, //RJA {8, 8, 8, 8}, // DNS server
.dhcp = NETINFO_STATIC //NETINFO_DHCP //RJA // DHCP enable/disable
};
This is another strange thing that I haven't seen before... Visual Studio flags all the . as errors. But, when I looked it up, seems like it's legit.
This line still doesn't work:
printf(" MAC : %02X:%02X:%02X:%02X:%02X:%02X\n", net_info.mac[0], net_info.mac[1], net_info.mac[2], net_info.mac[3], net_info.mac[4], net_info.mac[5]);
Also, I just noticed that I'm supposed to implement a 1 sec counter:
/*
* @brief HTTP Server 1sec Tick Timer handler
* @note SHOULD BE register to your system 1s Tick timer handler
*/
void httpServer_time_handler(void);
I don't think we have a 1s Tick timer handler, right?
Think I can hack with _getsec() though...
Trying this:
uint32_t get_httpServer_timecount(void)
{
return _getsec();
//RJA return httpServer_tick_1s;
}
Why do you think it doesn't work? It seems to for me (see the program listing below).
That is odd; the declarations look legit to me, although that kind of struct initialization is a "newer" feature of C (introduced in C99, I think, so not that new!)
Again, why do you say it doesn't work? What happens when you try it? It works in my test program (again, see below).
Right, that's definitely going to be a problem. You'll have to somehow arrange for the httpServer_time_handler() function to be called periodically. Not sure how you'll manage that, as we don't have a timer interrupt.
Here's the test program that I used to try the struct initialization and printf:
I compiled it with
flexspin -2 foo.c
. The output looks like:which is exactly what I would expect.
This line doesn't work either:
static uint8_t g_http_socket_num_list[HTTP_SOCKET_MAX_NUM] = { 0, 1, 2, 3 };
Seems like it should though...
Eric
While testing the HD Audio ADC/DAC code I found a problem with floating point in Spin2. Here is a simplyfied code that shows the problem:
in testit() the arg2 (fb) is saved in a variable _var01, but the float routines __system___float_mul or __system___float_tointeger seems to overwrite this variable with zero, so b results always in zero.
Andy
When you say it "doesn't work", what exactly do you mean? Do you get a compile error? Or is it a runtime error? If the latter, what exactly are the symptoms?
Instead of 0,1,2,3 I get 0,0,28,280
I just posted code in new thread
There, I overwrite those values to get code to work
https://forums.parallax.com/discussion/174977/wiznet-official-driver-working-flexc/p1
@Ariba : thanks for the bug report, Andy -- the leaf function detection code was missing the Spin2 case where the function needs to call out to floating point support routines. This should be fixed in the github source repo now.
@ersmith Are the rules for what a non-main cog can't do documented?
I think they can't do malloc or access sd card, is that right? Anything else?
I'm pretty sure malloc is thread-safe. Though it achieves this by locking, so if you do lots of malloc/free it will die.
Also, I'm pretty sure the SD card is restricted to the cog that mounted it. Cog 0 is not special in that regard. Wonder how hard it'd be to make that properly thread-safe.
AFAIK all the cogs are symmetric (so they can all malloc). However, the hardware is set up so that in practice only one cog can write to any particular pin, including the SD card pins, so only the cog that first mounts the SD card can access it; similarly for all other devices. The exception is the serial port; there's some hackery in the libraries to allow all the cogs to write to that, but I don't think it can generalize to other pins, or at least not without a high cost.
What I did to share access to PSRAM between two cogs in MegaYume was to enable
P_INVERT
on the select pin, use a lock to control access and make sure that the data lines are returned to input mode after each cog is done. Assuming the latter is already done, the only overhead would be adding a lock.That would be good practice for the default SD port in general since that also allows a driver to co-exist for the SPI Flash chip on those same pins as well.
@Rayman : I think I found the initilaization problem, arrays weren't being padded out to long boundaries when initialized, so the 6 byte "mac" array was throwing everything else off. That'll be fixed in the next release (it's fixed in the github source repo now).
@ersmith Thanks! And, thanks for the strtok(). Just in time. My version from the web seems to randomly crash for some reason...
@ersmith Having a strange issue (I think) with strtok()...
My program contains a .spin2 file in which I'm storing resources, like a small .png file.
It appears that the first call to strtok() corrupts the second long in the .png file.
No idea how this is possible.
This is the part that seems to do it:
In particular, the line: strtok_scanpoint = NULL; (Ok, I might be wrong about this line being the problem !!!!)
I can avoid this by adding some data before the .png file, but seems this needs fixing.
@Rayman : Can you tell what data is being written into the .png file data? Is it 4 0 bytes, or just one? Are you sure the parameters to strtok() are correct?
It is 4 bytes. Pretty sure it's a hub address. In later calls, it's NULL (four zeros).
After first call, the data is : $b8, $28, $01, $00
after a later it's all zeros...
I don't imagine it would help, but here's the source:
@Rayman : Thanks for the file. I can see that the offset in the generated assembly is bad, but I have no idea why. I'll try to debug it.
I moved the test code to the start of main() and it still does it:
output:
So, you don't need the hardware to reproduce this...
I'm guessing it's another strange array initialization somewhere...
@Rayman : I think I've fixed the initialization problem in the current github source code. Are you able to build it from source?
Thanks for your help in tracking this down!