FlexProp: a complete programming system for P2 (and P1)

evanh

@ersmith said:
We might be able to solve this by inverting the data and using ENCOD to search for the start bits within the 28 bit window. Re-synchronizing could be a pain though. For now I think I will drop back to the traditional 8 bit per character method. I did really like the 28 bit receive because it gave us a much bigger leeway for starting the receive code, but the problems with synchronization are a bit scary.

I did exactly that but withdrew the code posted because it is really limited to just two characters at a time if there is more than one stop bit, or gaps. The end of smartpin's shifter will chop up anything more.

Christof Eb.

@ersmith said:
@evanh I think the real problem isn't so much stop bits but what I will for lack of a better term call "idle bits" -- time when there is no data on the wire. If the data is coming at full speed the existing code works fine (at 8N1). If it's coming very slowly then it works fine too (there is only one actual character in each period of 28 bits). It's when the data is coming quickly but not quite at full speed that things break down -- we get 8 real data bits, a stop bit, then some number of idle bits (time when the signal is high because there is no transmission), and then a new start bit. The number of idle bits is unpredictable .

We might be able to solve this by inverting the data and using ENCOD to search for the start bits within the 28 bit window. Re-synchronizing could be a pain though. For now I think I will drop back to the traditional 8 bit per character method. I did really like the 28 bit receive because it gave us a much bigger leeway for starting the receive code, but the problems with synchronization are a bit scary.

Thank You very much for the solution! Works.
Christof

evanh

Christof,
Were you always attempting to use two stop bits?

Christof Eb.

@evanh said:
Christof,
Were you always attempting to use two stop bits?

Oh, yes, it did not occur to me, that somebody might have put the synchronising mechanism out of order.
Here is a picture from a Rodney Zaks book about interfaces. They did not even bother to give the stop bits the same length as the databits, they are longer.

When I finally understood the problem, I used Teraterm with 1 stop bit. It seemed to work most of the time. I only once had some strange behaviour in that week.

To have strong reliable foundations is very much more important for me than top speed. I do understand, that some very special things like Megayume cannot be achieved with P2 without heavy overclocking. But for most other applications reliability is much more important. (Parallax is now going to sell their arcade thingy, I don't know how they will handle it, if only 9 of ten sold items can do the 3xxMHz in that housing. 72h burn in ???)
I always produce bugs myself. To find them it is crucial to be sure, that the compiler and it's code do not bring new problems. I am not happy that Chip is inventing new things for his SPIN2 all the time, which naturally bring in new risks for new bugs.
Cheers, Christof

evanh

Cool. A simple yes works too.

Christof Eb.

@evanh said:
Cool. A simple yes works too.

Well, yes and no. I am aware, that you must have put a lot of effort into optimizing this routine. Therefore I feel a duty to explain, why in my opinion the simpler, straight forward method is better.
Sorry!
Have a good day!

evanh

I only wanted clarification. It hadn't been clear that you were using two stop bits.

evanh

To respond to your concerns, that little few instructions actually performed better than I had anticipated. I'm suitably impressed with how effective it is. Of course it has limitations though. A hard rule on single stop-bit being one of them.

Christof Eb.

Hi,
there is some strange thing going on with FlexProp and booting from SD card using _BOOT_P2.BIX.
With TAQOZ booting from SD card works very stable every time after a reset signal or after a software reset. So this is possible with the kiss hardware.
With FlexProp and it's file system, this does only work sometimes. Neither with a reset signal nor with a software reset.
Power off-wait-on seems to work every time.
I am assuming this must come from the status of the SPI bus?
Is the reason known?
Is there something, that I must/can do before software reset, like bring the SPI signals in some specific state?
In my opinion a stable booting would be very good!
Christof

evanh

Is the ROM boot loader loading anything when it fails? I'm guessing not but always good to ask. I suspect either the boot check is not seeing the SD card, or the SD card is not acting on the subsequent CMD0. SD cards can get confused and stop responding until power cycled. And since there is no software control for doing a power cycle, it can be lost until someone cuts the power to the whole board.

So, yes, there maybe a solution to preventing such SD card lock-ups, but it will depend on leaving the card in a useful state before the reset happens. Achieving this will likely be a long winded process to resolve.

First thing is to be sure this is happening. Ideally get a recording of the SPI boot pins from the reset onward when it failed to boot.

evanh

Or provide instructions on your setup, and a sample program, for us to replicate.

Rayman

Kiss has 25mhz crystal as I recall. That would be my first suspect…

Some things seem to depend on 20 MHz crystal…

Christof Eb.

Thanks, for the answers @Rayman and @evanh .
At the moment I don't want to invest too much time here. Did some experiments switching CS and the other pins to input, which did not help.

Ariba

The KISS Board does not have the series resistor between the SD-DO pin and P58. Without a Release procedure, the DO pin remains active high after commands and this prevents the access of the Flash at booting.
To release the DO pin (make it tristated), you need to set CS high and apply about 32 clocks at the SD-Clock pin.

Andy

Christof Eb.

@Ariba said:
The KISS Board does not have the series resistor between the SD-DO pin and P58. Without a Release procedure, the DO pin remains active high after commands and this prevents the access of the Flash at booting.
To release the DO pin (make it tristated), you need to set CS high and apply about 32 clocks at the SD-Clock pin.

Andy

Hi Andy,
unfortunately your receipt seems not to work? Or is there anything else, what I must do?
Thanks a lot,
Christof

void releaseSD( void ){
   _pinh(60); // CS high
   for(int i=0;i<65;i++) {
      _waitx(500);
      _pinnot(61); // CLK
   }
}

void _bye(void) { // reboot
   printf("\n Releasing SD \n                   \n");
   releaseSD();
   printf("\n Rebooting \n                   \n");
   _reboot();
}

evanh

Best to call umount("/sd"); first. That clears all the smartpin configs. I doubt that's the issue though.

Christof Eb.

@evanh said:
Best to call umount("/sd"); first. That clears all the smartpin configs. I doubt that's the issue though.

Tried but had no luck.

Wuerfel_21

With the new Spin2 structure stuff, I wonder if it's now possible to use / make available libc structs in Spin?
With my emulators I currently have a nasty fsadapter.c file that's used to call stat() (requires a given struct stat buffer) and also to read fields of struct dirent. Would be neat to do it in Spin directly.

Wuerfel_21

I am finding out that all the subobject struct stuff from v49 isn't implemented at all yet (despite v51 being ostensibly supported)

ersmith

@Wuerfel_21 said:
With the new Spin2 structure stuff, I wonder if it's now possible to use / make available libc structs in Spin?
With my emulators I currently have a nasty fsadapter.c file that's used to call stat() (requires a given struct stat buffer) and also to read fields of struct dirent. Would be neat to do it in Spin directly.

Probably it's possible, but would be a fair amount of work. Why not just use C directly?

@Wuerfel_21 said:
I am finding out that all the subobject struct stuff from v49 isn't implemented at all yet (despite v51 being ostensibly supported)

Care to give an example?

Wuerfel_21

@ersmith said:

@Wuerfel_21 said:
With the new Spin2 structure stuff, I wonder if it's now possible to use / make available libc structs in Spin?
With my emulators I currently have a nasty fsadapter.c file that's used to call stat() (requires a given struct stat buffer) and also to read fields of struct dirent. Would be neat to do it in Spin directly.

Probably it's possible, but would be a fair amount of work. Why not just use C directly?

Because using Spin for the main program is nicer.

@Wuerfel_21 said:
I am finding out that all the subobject struct stuff from v49 isn't implemented at all yet (despite v51 being ostensibly supported)

Care to give an example?

OBJ foo: "foo" ' <- this has a struct bar
CON STRUCT foobar = foo.bar ' <- :(

error: syntax error, unexpected '=', expecting '('

ersmith

@Wuerfel_21 said:

OBJ foo: "foo" ' <- this has a struct bar
CON STRUCT foobar = foo.bar ' <- :(

error: syntax error, unexpected '=', expecting '('

Thanks for pointing this out. I missed the = possibility in struct definitions, which was easy to add. Implementing access to subobjects everywhere was not so easy but I think it's working now.

Wuerfel_21