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

ersmith

I've uploaded a new FlexProp release (7.2.1) to github -- it's been on my Patreon page for a while, so if you got it from there no need to upgrade.

This release fixes quite a few bugs, mainly in parsing of new Spin2 features like structs.

avsa242

Hey Eric,

How are pointers to structures meant to be used when they're declared as VARs?
For example, say I have this:

'toplevel.spin2
CON
    struct window_s(...
        byte current_line, ...
        byte line[100)

VAR
    window_s this_window    ' memory for the text window
    window_s that_window    ' memory for the text window
    window_s other_window    ' memory for the text window

OBJ
    win: "textwin"

PUB main()
    win.set_window_handle(@this_window)
    'or
    win.set_window_handle(@that_window)
    'or
    win.set_window_handle(@other_window)

'textwin.spin2
CON
    struct window_s(...
        byte current_line, ...
        byte line[100)

VAR
    ^window_s pwindow    ' pointer to the currently set window

PUB set_window_handle(p_win)

    pwindow := p_win ' xxx this isn't quite right


PUB do_window_things()

    pwindow.current_line := 1

I hope you get the gist of what I'm trying to do above. I think I'm just not getting the syntax quite right, but I couldn't find any examples of similar usage in the official spin2 docs or flexspin docs.
What I'd like to do is have the real structure/buffer defined in the app, and just be able to point the child object to a specific one at runtime (but assigned to a VAR so it can be reused until changed, not as a parameter to a method).

Thanks!

ersmith

To modify the pointer itself (rather than the thing pointed to) you have to do:

PUB set_window_handle(p_win)
    [pwindow] := p_win

This syntax wasn't my idea, believe me but it's what Chip decided on.

avsa242

Thanks! That's it.
How would you recommend handling structures that are defined with members that are arrays of a size meant to be defined by the user at the top level? At first I was thinking the structure definition could have a maximum allowed size and the parent object creating an instance of it could just define it with a smaller size, but then realized that couldn't work. The case that brought this on is similar to my example structure window_s above, but using a CON to define the size. Since both the child object and the top level have access to the same structure definition (I #include the file that defines it in both the child and the top-level), they both have their own constant used to define the size. It's tricky, because the child object could have a different value. The only way it all seems to work is to also override those with the same values as the parent. I feel like I'm starting to tread on ground similar to what you helped me out with awhile back with the overrides and object pointers causing a bit of a mess.

ersmith

@avsa242 I'd have to see your specific use case (it sounds complicated), but in general I would suggest either:

(1) Use a #define in the top level to define the array size, and export that with #pragma exportdef so all the children see it; or

(2) Make sure the parent overrides CON for the size in all of its children (and that they in turn pass that down to their children). But this is somewhat more likely to go wrong, I think.

For flexspin's purposes there is no difference betwen objects and structs, so you could put everything into an objects (and use the ^win notation for pointers to objects). I'm not sure if that would help you or not.

ersmith

I should look at porting BASIC's interface objects over to Spin2 -- they're really useful abstract objects that can match any class that has a certain set of methods (kind of like traits in Rust, if you're familiar with those). They're probably what you really want, since they would allow the child objects to access methods of the parent without having to know the details of the parent's data structures and layouts.

I don't suppose you'd want to use BASIC for this project instead of Spin?

avsa242

Re: BASIC Nah, that's okay, thanks It's something I'd like to make reusable but written in spin2. The interface concept does sound intriguing though...I take it it's not something that could be used across the two languages (i.e., this 'object' would be written in BASIC, but the app would still written in spin2) due to the differences?
I'm not really familiar with Rust, but traits sounds like it might be part of the broader inheritance feature that some languages have?

Attached is a short demo of the object. It's an early attempt at creating a scrollable text window that could be used with any display driver that has the right i/o interfaces (just uses puts() and newline() for now).