Search results for:

Hey,

I was using ctrl-c when I wanted to break out of the interactive editor when connected via terminal. That worked great, so far. (BTW, that simple interactive mode is the coolest thing since years. Could ignore/convert special chars, as it doesn't handle them very well, but other than that, so damn perfect.)

Now I have that cc3000 on my Espruino board (1v63), ctrl-c does a power cycle for the cc3000 and won't let me out of the editor anymore.

Any other way to exit the editor (without equalizing the bracket levels or deleting all lines).
And that power cycling, bug or feature?

Yes, that's where I looked at. Darn pin.
I really thought I would get around that toolchain thing :)
I would like to have it run on my Mac natively, but that would mean less optimized compilers.

(Bold suggestion: As doing our own builds seems part of the game right now, do you think it would be feasible (for you, ideally :) to provide the community with a working toolchain image for Virtual Box or something? After all, we only need a software solution that creates the .bin and then would be able to use our native environment to upload it to the board.)

Other than that, is there a reason why the CC3000 does not allow for setting it up with any SPI plus the additional pins like it's already the case for displays and other devices? Any special needs for that module?

Best and thanks
Stev

It's probably best to look up ST's own bootloader - the impression I got was that it looks on all serial ports, so you may be able to hook up to USART2 and use that instead.

That's a nice clue. Will look into that.

Well, I thought, after my probs with the serial ports on my Mac, that going platform independent could also be accomplished by putting the files on a SD card and having one of the espruinos flashing the other. At least now that we have that streaming file io.

Ok, there goes the convenience :) The connector looked so promising similar to the one of the HY board. Still, there should be enough pins on the HY board due to its original display's need and even the original Espruino might just have enough pins left, as I only need two SPI sets plus those data lines right now. Would be nice if it would run with the original Espruino board.

What's the actual speed of the display when using your driver code? The one that comes with the HY is neatly fast and fun, especially to use compared to the SPI-only ILI I use with Gordon's board right now (because of the CC3000). Behaves more like a Etch-a-Sketch than a display.

Hi,

The HY32 boards have a Prolific 2303 USB2Serial converter on board that connects to the serial port used by the bootloader. I wonder if it would be feasible to use another Espruino to talk to the serial port behind the 2303 directly to upload a firmware file (now that we have that streaming file access) or tinker with the flash.

Anybody who can say if I could just connect to the TX/RX lines behind the 2303 without frying anything while still being able to talk to the bootloader serial port?

Right now I have really no feeling (or spec) to judge what I can do to those pins and what I shouldn't.

Thanks
Stev

Hey,

I'd like to connect my CC3000 to my HY-MiniSTM32V 3.2 and wonder if and how this would work best. Or at all.

I saw that while the boards have pin declaration files in the source, the CC3000 Pins seem to be hardwired in the CC3000 includes.

Now, since the CC3000 uses CS, EN and IRQ lines in addition to the SPI lines and the defined IRQ-Pin (B6) is also used by the touch screen, I wonder if there is any conflict (or if there can be multiple IRQs handled by the same line. Sorry if this might be a stupid question).

I see that we can now have SPIs on any pin combo but the CC3000 class still seems not to be configurable. And since I don't want to fry anthing...

So, anyway, how would I connect the CC3000 to the HY32? Or would I have to do a custom build?

Cheers
Stev

Hey,

Cool.
Is it pin compatible, so that I just can replace the original one?
And could I drive it using the Espruino-Board instead (I found thy HY32 so convenient, as I didn't have to care about packaging the components and didn't have to look at the connector specs.). I would happily swap the large board for Gordon's.

Cheers
Stev

Funny. As I usually use the functional notation. Only since working with the touchscreen code I used the direct function declaration because the touchscreen examples were written that way :)

Notation-wise it might make sense to differentiate them (named function vs function var with anonymous function), but I don't know what JSs spec actually says.

I just remember that in a coding context/script, direct function declarations are parsed befor the actual script execution while the var = function(){} notation is a executed as part of the normal execution sequence (making the former being present/declared for code positioned before the function declaration, while the latter wouldn't).

Also, in espruino, when I do a

touch

i'll get

=function (x,y) { ... }

in both cases. And both objects can be combined with additional methods.

Just was that thing that left me confuse about the copying vs. referencing idea for function(object)s and wanting to be able to delete that callback . Because once you screwed it...

As far as callbacks, if you do:
function touch(x,y) {
...
}
require("Touchscreen").connect(touch);
Then you can redefine the touch function, either by just entering it again, or by
typing edit("touch").

Hm. That's exactly what's not working (and the problem I meant when mentioning not being clear when copying function code vs referencing functions).

When I do this like in your example above, I can edit the touch function, but it will not have any effect, as the original one seems to be "submitted" and stays active.

If I instead use a double reference like

function touch(x,y) {doTouch(x,y);}
function doTouch(x,y) {console.log(x+"/"+y);}
require("Touchscreen").connect(touch);

, I can redefine doTouch effectively using edit().

That's where I stumbled and wondered if I somehow could delete the original callback.

Good to know about 'this' in the timers/handlers.
I am really just sorting things out right now and sometimes don't know if it's JS-specific or specific to Espruino's environment. Like how to create a top level var from within another object's method... which I probably shouldn't, anyway.
I guess, I look at that object-tree and I am missing the reference to its root...

I just was playing around. Now that the board seems to work, I'd like build some touch UI on top of it and that were my first steps last night, when I realized that calling the connect function again would result in adding watches, not deleting the former. Just wanted to get rid of the older ones and see where I would put the switching of "active" screen areas.

You're probably right about the re-init, so I'll try to put the picking behind that one callback.

I still seem to have to re-polish my JS skills. Right now I always end up with code copied into handlers when I just want to pass a reference to a function and I still have no idea on how to access/create "top-level"/global vars from within a handler. Is there a name/reference for the Espruino top level object (the one I get with "this" when in the shell)? Or maybe that's just the wrong pattern to communicate between handlers and set up a system.

BTW: Also I see a growing number of "LCD = {}" entries when I look into the var with dump(). I can do multiple "delete LCD" to get rid of them, but neither do I know where the come from, nor how multiples of them can exist be created in the first place.

So. Arrived at the JS level, at last :)

Hey. Yes, i guess changing the module code is they best way to go. I tried to figure out the watch id before. Cumbersome.

Thanks.

Stev

Hi,

it might just be a bit late today, but how do I remove a callback for the Touchscreen that I have set in the connect method? I see that it creates a watch. Can that be referenced?

(i could reference another function from there, but i wonder if I ever get rid of that original connect handler)

Stev

Hm. The colors and brightness change a lot depending on the angle and the greys, or partially lit colors (e.g. when you draw a gradient) tend to create line flicker.

Full colors and black are ok though.

But you're probably right, when you say that this is what you get for the price (unfortunately the next quality step comes with a big jump in price). Still I wonder if there might be some good kickstarter/community projects coming up that might be as useful as the cc3000 and wiznet. It's an important part of interaction with the world. So, just a wish for now :)

@Gordon

BTW, I am not so enthusiastic about that display anymore, now that I have it running :)
So if you consider sourcing some nice display and touch that runs well with your own board, I would consider that a big win. (After all, I never had any trouble uploading the latest build to your own boards :)

Cheers
Stev

@Gordon
At least I get the bins onto the board now :) I can get around the zeros by lowering the chunk size to 128 or something. Using the same chunk size for writing to the board.

I will look into that serial issue in more detail later on, and maybe get the original script to work reliably with the board. I have collected a few alternative serial drivers for OS X and might also look into Xojo's serial handling (which I used to be cross platform, but it seems to have its own "characteristics" and best practices that need to be obeyed).

Still, I now can confirm that in your builds/files 1.48 is the last working version (the ones after don't react to any of the USB serial ports and don't display anything on boot) and that alexrlopez86's build of 1.62 boots up the board, displays the bootup text on screen and allows access via both USB serial ports. Perfect. For now.

I haven't had the time to look at his code, so I can't say right now, whether it's his changes to the USB flags, or just his own build that make it work. But it boots up the board, so I can finally come back to the actual usecase :)

So, maybe you can incorporate the changes? Or just do a build with your tool chain?He seems to have archived the complete checkout with changes, so it might not be that much of a task. Thanks again for all your responses to the weird serial port probs. Kept me looking at the issue.

And thanks again to alexrlopez86, keep the builds coming :) (Have you tried whether a build on your toolchain without any changes would create a running build?).

Cheers
Stev

Short update:

I managed to flash my board from my mac using the mentioned tinker tool.

However, i found:

The boot button on one of the boards being defective.

The CRC seed (Bootloader version 0x22) seems different from that in the python script.

The Serial device having "late" bytes coming in, filling the buffer but not triggering a "data available" event. (Have to determine on what level that bug occurs)

Zeros being added to memory readouts for readout chunks sizes close to 256 Bytes (sometimrs resulting in some 400 Bytes instead of the expected 256)

I used a very controlled (and unoptimized approach) for flashing the data onto the board which took 2h or so because of all the waits and checks, but the board now boots into 1.45.

I'll see what i can take from that, test it on another machine and do some profiling on the delays to get a more optimized version .

Still hope that it's something stupid that can be fixex easily, however.

Will switch the boot0 switch, too ...

Gordon,

I agree that your board is fun and reliable, especially cool with the HM-10, and I recommend it to anybody I meet. But since I needed that touch screen instead of the power saving and battery features (which are amazing) right now...

Whitelit meaning the display just being white and lit when plugging in a USB cable. Before it played the colorful touch screen demo the board comes preinstalled with.

USB ist the correct one, as its the only one that shows up as a usb serial port. (and that's only if you install the PL2303 drivers for Mac OS X. Not sure if that was mentioned anywhere.) And of course it erased the flash successfully, so...

I coded a quick tool to see what's going on on the Serial Port, and it seems that some responses by the board are coming in too slow. Not sure if it's the board or the driver or some weird flow control issue that's the problem here. From what I saw, I would guess that the Python script might get confused when it gets incomplete input or the last bytes from an earlier command. I also get additional zero values at the end when reading board memory in larger chunks. Very weird.

I'll see if I can make the tool write something to the board and have the board flashed using the tool, now that have most of the talking to the board in place.

If anybody has an alternative driver (I have the PL2303_MacOSX_v1.5.1.pkg running under Mavericks), please let me know.

Frankly I see the HY3.2 as an interesting board, and I'd love to pay a licence fee for Espruino (and read your disclaimer in the readme) if Espruino would be supported on this useful board that doesn't seem to come with any those "not for product development" licences if I understand it correctly.

Whitelit my both boards yesterday anyway, when trying to reflash them using my macbook.

Don't even know what to try next nor why it failed :/ So erase seems to have worked... Despite the script saying otherwise.

Would "stlink" do the task instead of that python script?

What can we do to have all the processes becoming more stable and maybe even supported?

hey gordon,
the 1v44 file does not seem to exist at the location you posted.
1v41, then 1v45 exist.

There's a http://www.espruino.com/files/espruino_hystm32_32_vc_1v43_beta.zip though.

Heh. The video seems to show Magician's hands with all those moves. Still waiting for something to vanish/appear. Now you see it... :)

Would be nice to have that fix in the next build and maybe your 23.4. build somewhere where it actually downloads (I know, complains... But still, I seem to get only single bits from that link above)

Thanks for looking into into fixing that USB thing.

Guess that was me. Some false assumption about the time on hand. Then again, if waiting works that well...

Hey Gordon,

Thanks. Always impressed how you handle forum and coding.

I remember that you mentioned using some special compiler to create smaller binaries. Any info on that one, and is it crucial for anything related to the hy3.2?

Stev

Hey,

i've got some time on my hands again. My HY 3.2 boards arrived, and I wanted to see if there's any progress on this problem and what the current thread for this board might be.

I would look at setting up a tool chain and trying to fix the problem, if there's nobody else working on it so far. Any hints/links/recipes for setting up the tool chain would be appreciated, though.

Cheers
Stev