The UART approach is simple and works in many places without needing a special "i2c as a device" driver. Like on a Pi, Beagle or MIPS SoC etc.
Loading a Prop over UART does not take so long but if you feel the need for speed them go for the i2c solution.
Isn't there a generic Linux i2c driver that could be used? Or does a custom driver need to be written?
Anyway, I'm not going to "go for" anything since I have no hardware design experience. I'm waiting for someone like OBC to make a board with both a P1 and an ARM chip on it. One request though, I'd like to be able to reprogram both the P1 and the ARM on-board.
Isn't there a generic Linux i2c driver that could be used? Or does a custom driver need to be written?
Anyway, I'm not going to "go for" anything since I have no hardware design experience. I'm waiting for someone like OBC to make a board with both a P1 and an ARM chip on it. One request though, I'd like to be able to reprogram both the P1 and the ARM on-board.
First, I don't care if there is an IDE at all. I have an editor I am perfectly happy with and I can type command lines if necessary. All I need is a toolchain for both processors and I think those are already available.
Isn't there a generic Linux i2c driver that could be used? Or does a custom driver need to be written?
Actually I have no idea. Perhaps that is a solved problem already. I'm terribly lazy and will go with whatever works with least effort. Good old UART is everywhere.
I'm waiting for someone like OBC to make a board with both a P1 and an ARM chip on it.
Quite so. A dream I have had for many years now. Problem is, which ARM? Some might want an M3 embedded type device others might want a chip capable of running a full up Linux OS.
I'd like to be able to reprogram both the P1 and the ARM on-board.
Do you mean a self hosting ARM system like a Pi or Beagle?
Actually I have no idea. Perhaps that is a solved problem already. I'm terribly lazy and will go with whatever works with least effort. Good old UART is everywhere.
Actually, I wouldn't mind an excuse for writing a custom Linux driver. I haven't done that in a while. :-)
Quite so. A dream I have had for many years now. Problem is, which ARM? Some might want an M3 embedded type device others might want a chip capable of running a full up Linux OS.
I would prefer an Mx series processor either programmed to the bare metal or with a simple RTOS. The RaspPi and BeagleBone already exist. No need to duplicate them.
[/quote]
Do you mean a self hosting ARM system like a Pi or Beagle?[/QUOTE]
Sorry, all I meant is that I want a hardware programming interface for each chip. A place to plug in a PropPlug for the P1 and JTAG or whatever is used to program the ARM. In fact, I guess you could just use the ARM to program the Propeller so maybe only a debug interface for the ARM would be sufficient. I didn't mean I wanted the tools themselves to run on the target hardware.
First, I don't care if there is an IDE at all. I have an editor I am perfectly happy with and I can type command lines if necessary. All I need is a toolchain for both processors and I think those are already available.
I didn't mean to upset you, if I did. I was only thinking it'd be nice if the IDE, or whatever, could compile both P8x and ARM.
GCC is part of a toolchain, like Propgcc and such, and what I was thinking was that it could compile the P8x code, and somehow embed that into the ARM code so that the ARM could serve that to the P8x. In retrospect, it's not so easy.
I didn't mean to upset you, if I did. I was only thinking it'd be nice if the IDE, or whatever, could compile both P8x and ARM.
GCC is part of a toolchain, like Propgcc and such, and what I was thinking was that it could compile the P8x code, and somehow embed that into the ARM code so that the ARM could serve that to the P8x.
I'm somewhat new at this so yeah, I dream.
You didn't upset me. I'd be happy for an IDE to be available. I'm just saying it wouldn't be a requirement for me to make use of the board. You could easily embed P1 code as binary in an ARM executable and have the ARM download the code into the P1. I don't see any problem with that at all. This could all be done with OBC's MMC board except that it doesn't have a programming interface for the PIC32 chip.
So in an ARM/Prop board what does the Prop do? Is it just a dumb terminal?
I'd like to think it handles most of the time critical/deterministic things, like driving a display, or, in my case, firing fuel injectors and ignition coils on time.
So in an ARM/Prop board what does the Prop do? Is it just a dumb terminal?
No, what I wanted to do with OBC's MMC was to run a compiler for an interactive C-like language (like the "notc" language I've been playing with) on the PIC32 and run the generated code on the P1. Might also use the PIC32/ARM/whatever as a file server to eliminate the need to run a big chunk of code like FSRW or the PropGCC filesystem code on the P1 itself. The Propeller would do all of the realtime.
No, what I wanted to do with OBC's MMC was to run a compiler for an interactive C-like language (like the "notc" language I've been playing with) on the PIC32 and run the generated code on the P1. Might also use the PIC32/ARM/whatever as a file server to eliminate the need to run a big chunk of code like FSRW or the PropGCC filesystem code on the P1 itself. The Propeller would do all of the realtime.
That makes sense, and newer variants like M7 ARM, would pair well with Prop. (P1 or better, P2)
Isn't there a generic Linux i2c driver that could be used? Or does a custom driver need to be written?
This would likely need a custom one, as it needs to be a slave, and 'look' just like the BOOT EEPROM
Another approach could be to 'OR' manage a EEPROM., so the ARM programs it while holding the Prop in RST, then releases the Prop to load from the i2c memory.
That would just need a standard i2c master on the ARM, likely to be much more common..
An FRAM FM24W256 could be an option here ?
Of course, somehow the ARM still needs to talk to a running Prop, so the fastest-serial is likely needed anyway.
I guess both could be supported, as it needs just one ARM pin to over-rule EE load and Serial boot instead.
An appeal of a Normal-loaded Prop (ex EE) , is it can do more watchdog tasks in a full system, but the over-rule step could be good for design iterations.
Does anyone have numbers on the relative load speeds, of i2c-emulated-EEPROM, vs fastest supported serial speed ?
basic serial tops out around 1152Kbps. I2C can it a bit more than 4x that, I think.
This would likely need a custom one, as it needs to be a slave, and 'look' just like the BOOT EEPROM
Another approach could be to 'OR' manage a EEPROM., so the ARM programs it while holding the Prop in RST, then releases the Prop to load from the i2c memory.
That would just need a standard i2c master on the ARM, likely to be much more common..
An FRAM FM24W256 could be an option here ?
Of course, somehow the ARM still needs to talk to a running Prop, so the fastest-serial is likely needed anyway.
I guess both could be supported, as it needs just one ARM pin to over-rule EE load and Serial boot instead.
An appeal of a Normal-loaded Prop (ex EE) , is it can do more watchdog tasks in a full system, but the over-rule step could be good for design iterations.
Interesting you mention FRAM. I don't think there are ARM FRAM chips out there- MSP430FR are the only MCU's using FRAM, I think. Some ARM chips do provide for external memory interfaces so that is an option, I suppose.
And it appears I have managed to derail the thread... or at least bring it back on-topic, as per the thread's title.
Recently I've read a little bit about Forth and stack machines and was pretty intrigued. The fact that Forth can act as an OS and interactive dev environment is pretty darn neat, while allowing quite high-level looking code to be written despite being little more than a macro assembler. It really seemed like a great solution to the resource starved microcomputers of the late 70s early 80s. That said, I haven't delved into it very deeply, so my knowledge is quite rudimentary.
I know practically nothing about C and even less about how the compiled code looks like, but it's my understanding that it, as well as various other HLLs utilize variable and call return stacks, so a stack machine or Forth kernel is suitable for running such languages (is this grounds for calling me a heretic?). So, what does the Tachyon kernel bring to the table for languages other than Forth? I obviously don't know the answer, but Peter and others claim good performance (to say nothing of the flexibility), so how does it stack up to the various _MMs? Options are always good.
Is there a need for interactive programming environments? "Need" might be a strong word, but it's probably safe to say that's part of the allure of Forth, Python, etc. Even if compiling and uploading code to a uC is quick, I don't think anyone would disagree that it would be nicer if it wasn't necessary, and that being able to prod at the code in real-time certainly has its benefits.
If Forth code can be made as simple as in MJB's last blinky example, then there's certainly a valid use for newbies as well, it's just a matter of getting the word out there (which is probably the hardest part!).
The world is a big place, so no matter what, there's room for Tachyon. I wish I had the time and skills to help out, because based on the little bit that I know about it, I think it's a cool project. One of the things I was hoping to do was create a 7+1 (7 cog, 1 stack machine core) P1V derivative, where the stack machine core would be used for big code, but alas, my progress in learning verilog has been slow due to the aforementioned lack of time.
Although the thread is not really about languages or about using an ARM .... However, I married an ARM chip to a Prop many years ago in different products but I used both serial UART methods and I2C but for some strange strange reason many people think that serial is limited to 115.2kb? That's only really true for actual +/- RS232 levels that take too much time to slew through the voltages (including RS232's ancient built-in 300 ohm spec'd limit) vs logic levels etc which are not limited so (hence where I avoid them if I can). Also FDS always seems to be the first and only object ever used and it is very limited even at 115.2k but I just use my own objects that run up to 4Mbps.
The reason I also use I2C is that the ARM normally supports slave mode so the Prop can talk to it like any other peripheral with registers etc plus I use the ARM to directly load the Prop's code into its EEPROM or emulate a EEPROM at boot. So the ARM controls the Prop's reset. This makes sense as the ARM has a lot of Flash memory where it can hold the image(s) for the Prop.
Here's a shot of the original proto I did which had an LPC2148 mounted under the board but of course these days I'm more inclined to use something like the STM32F407 etc.
BTW, I'm still abstaining from getting too involved in this thread, but it's interesting to read, if only now someone (else) would actually try out some of these ideas etc
EDIT: Here's a grainy old video of that same LPC2148 on it's own bit-bashing VGA itself while running a "breakout game" in Forth during the syncs and generating sound etc.
Although the thread is not really about languages or about using an ARM .... However, I married an ARM chip to a Prop many years ago in different products but I used both serial UART methods and I2C but for some strange strange reason many people think that serial is limited to 115.2kb? That's only really true for actual +/- RS232 levels that take too much time to slew through the voltages (including RS232's ancient built-in 300 ohm spec'd limit) vs logic levels etc which are not limited so (hence where I avoid them if I can). Also FDS always seems to be the first and only object ever used and it is very limited even at 115.2k but I just use my own objects that run up to 4Mbps.
The reason I also use I2C is that the ARM normally supports slave mode so the Prop can talk to it like any other peripheral with registers etc plus I use the ARM to directly load the Prop's code into its EEPROM or emulate a EEPROM at boot. So the ARM controls the Prop's reset. This makes sense as the ARM has a lot of Flash memory where it can hold the image(s) for the Prop.
Here's a shot of the original proto I did which had an LPC2148 mounted under the board but of course these days I'm more inclined to use something like the STM32F407 etc.
BTW, I'm still abstaining from getting too involved in this thread, but it's interesting to read, if only now someone (else) would actually try out some of these ideas etc
EDIT: Here's a grainy old video of that same LPC2148 on it's own bit-bashing VGA itself while running a "breakout game" in Forth during the syncs and generating sound etc.
That board looks interesting although a bit more than I had hoped for. I'd be happy with something at the level of an ActivityBoard with an ARM chip on it. I don't really need all of those peripherals for the experiments I wanted to run. Did you ever make a board with both an P1 and an ARM?
David, Peter's board does have a Propeller chip and an ARM chip.
In Peter's message he says "Here's a shot of the original proto". I thought that meant that the board got to the prototype stage but was never completed. In any case, I'm sure it would be quite expensive as it has lots of peripherals on it. I was looking for a simpler board with an P1 and an ARM or even PIC32 that is actually available for purchase.
In Peter's message he says "Here's a shot of the original proto". I thought that meant that the board got to the prototype stage but was never completed. In any case, I'm sure it would be quite expensive as it has lots of peripherals on it. I was looking for a simpler board with an P1 and an ARM or even PIC32 that is actually available for purchase.
Well the shot was of the original proto but I do have more boards that you are welcome to if you like. I'm sending a shipment of IoT5500s to D.P. soon so I can throw one in there for you so then it's just the cost of local postage if that's ok by D.P. Sort it out or D.P. gets to keep it
Later on next year maybe I will release an add-on for the IoT5500 with an M4 instead of the stack on Prop option, and these boards are very small at under 1"sq with microSD and SPI Flash. Check the IoT5500 thread for more details.
Actually, talking about the IoT5500 with it's Prop board so that it is scarcely bigger than the magjack, is the fact that it can be used to offload all the networking and filesystem and since it is running Forth (as opposed to "coded in xxx") it is very flexible in how it handles commands and scripts since the host system is actually talking Forth to it, even if it doesn't know it.
BTW, when I do a proto that means I could have a hundred boards sitting waiting or in the case of the IoT5500 it's only 1,000 boards!
Well the shot was of the original proto but I do have more boards that you are welcome to if you like. I'm sending a shipment of IoT5500s to D.P. soon so I can throw one in there for you so then it's just the cost of local postage if that's ok by D.P. Sort it out or D.P. gets to keep it
Later on next year maybe I will release an add-on for the IoT5500 with an M4 instead of the stack on Prop option, and these boards are very small at under 1"sq with microSD and SPI Flash. Check the IoT5500 thread for more details.
Actually, talking about the IoT5500 with it's Prop board so that it is scarcely bigger than the magjack, is the fact that it can be used to offload all the networking and filesystem and since it is running Forth (as opposed to "coded in xxx") it is very flexible in how it handles commands and scripts since the host system is actually talking Forth to it, even if it doesn't know it.
BTW, when I do a proto that means I could have a hundred boards sitting waiting or in the case of the IoT5500 it's only 1,000 boards!
That sounds great! Thanks for the offer. Also, I've been following your IoT5500 project. That will be interesting as well when it becomes available.
If you need that then a RaspberryPi with Bill Henning's P1 board could be used today. I was thinking of an ARM that isn't running Linux.
I'm not a Linux fan myself. Still, self-hosting does require some sort of OS, even if it's the development environment running 'solo', which is possible. Apple ][+ booted up into Applesoft Basic; they were comparatively capable in their time.
I'm not a Linux fan myself. Still, self-hosting does require some sort of OS, even if it's the development environment running 'solo', which is possible. Apple ][+ booted up into Applesoft Basic; they were comparatively capable in their time.
My apologies for cluttering up Peter's topic.
I'm thinking of something like the EspruinoBoard board except that the compiler would run on the ARM but the generated code would run on the P1. I'm still expecting this to be an interactive environment like the Espruino and it could very well target Peter's Tachyon VM. At the very least, it would target a PASM VM.
Comments
The UART approach is simple and works in many places without needing a special "i2c as a device" driver. Like on a Pi, Beagle or MIPS SoC etc.
Loading a Prop over UART does not take so long but if you feel the need for speed them go for the i2c solution.
Anyway, I'm not going to "go for" anything since I have no hardware design experience. I'm waiting for someone like OBC to make a board with both a P1 and an ARM chip on it. One request though, I'd like to be able to reprogram both the P1 and the ARM on-board.
One IDE to rule them all!!!
Yeah, I'll shut up.
[/quote]
Do you mean a self hosting ARM system like a Pi or Beagle?[/QUOTE]
Sorry, all I meant is that I want a hardware programming interface for each chip. A place to plug in a PropPlug for the P1 and JTAG or whatever is used to program the ARM. In fact, I guess you could just use the ARM to program the Propeller so maybe only a debug interface for the ARM would be sufficient. I didn't mean I wanted the tools themselves to run on the target hardware.
GCC is part of a toolchain, like Propgcc and such, and what I was thinking was that it could compile the P8x code, and somehow embed that into the ARM code so that the ARM could serve that to the P8x. In retrospect, it's not so easy.
I'm somewhat new at this so yeah, I dream.
Imagine each cog drives one cylinder.
That makes sense, and newer variants like M7 ARM, would pair well with Prop. (P1 or better, P2)
Does anyone have numbers on the relative load speeds, of i2c-emulated-EEPROM, vs fastest supported serial speed ?
This would likely need a custom one, as it needs to be a slave, and 'look' just like the BOOT EEPROM
Another approach could be to 'OR' manage a EEPROM., so the ARM programs it while holding the Prop in RST, then releases the Prop to load from the i2c memory.
That would just need a standard i2c master on the ARM, likely to be much more common..
An FRAM FM24W256 could be an option here ?
Of course, somehow the ARM still needs to talk to a running Prop, so the fastest-serial is likely needed anyway.
I guess both could be supported, as it needs just one ARM pin to over-rule EE load and Serial boot instead.
An appeal of a Normal-loaded Prop (ex EE) , is it can do more watchdog tasks in a full system, but the over-rule step could be good for design iterations.
Interesting you mention FRAM. I don't think there are ARM FRAM chips out there- MSP430FR are the only MCU's using FRAM, I think. Some ARM chips do provide for external memory interfaces so that is an option, I suppose.
And it appears I have managed to derail the thread... or at least bring it back on-topic, as per the thread's title.
Wasn't my intention but.....
I know practically nothing about C and even less about how the compiled code looks like, but it's my understanding that it, as well as various other HLLs utilize variable and call return stacks, so a stack machine or Forth kernel is suitable for running such languages (is this grounds for calling me a heretic?). So, what does the Tachyon kernel bring to the table for languages other than Forth? I obviously don't know the answer, but Peter and others claim good performance (to say nothing of the flexibility), so how does it stack up to the various _MMs? Options are always good.
Is there a need for interactive programming environments? "Need" might be a strong word, but it's probably safe to say that's part of the allure of Forth, Python, etc. Even if compiling and uploading code to a uC is quick, I don't think anyone would disagree that it would be nicer if it wasn't necessary, and that being able to prod at the code in real-time certainly has its benefits.
If Forth code can be made as simple as in MJB's last blinky example, then there's certainly a valid use for newbies as well, it's just a matter of getting the word out there (which is probably the hardest part!).
The world is a big place, so no matter what, there's room for Tachyon. I wish I had the time and skills to help out, because based on the little bit that I know about it, I think it's a cool project. One of the things I was hoping to do was create a 7+1 (7 cog, 1 stack machine core) P1V derivative, where the stack machine core would be used for big code, but alas, my progress in learning verilog has been slow due to the aforementioned lack of time.
The reason I also use I2C is that the ARM normally supports slave mode so the Prop can talk to it like any other peripheral with registers etc plus I use the ARM to directly load the Prop's code into its EEPROM or emulate a EEPROM at boot. So the ARM controls the Prop's reset. This makes sense as the ARM has a lot of Flash memory where it can hold the image(s) for the Prop.
Here's a shot of the original proto I did which had an LPC2148 mounted under the board but of course these days I'm more inclined to use something like the STM32F407 etc.
BTW, I'm still abstaining from getting too involved in this thread, but it's interesting to read, if only now someone (else) would actually try out some of these ideas etc
EDIT: Here's a grainy old video of that same LPC2148 on it's own bit-bashing VGA itself while running a "breakout game" in Forth during the syncs and generating sound etc.
While I was writing... you were writing:)
Sorry
Rich
Well the shot was of the original proto but I do have more boards that you are welcome to if you like. I'm sending a shipment of IoT5500s to D.P. soon so I can throw one in there for you so then it's just the cost of local postage if that's ok by D.P. Sort it out or D.P. gets to keep it
Later on next year maybe I will release an add-on for the IoT5500 with an M4 instead of the stack on Prop option, and these boards are very small at under 1"sq with microSD and SPI Flash. Check the IoT5500 thread for more details.
Actually, talking about the IoT5500 with it's Prop board so that it is scarcely bigger than the magjack, is the fact that it can be used to offload all the networking and filesystem and since it is running Forth (as opposed to "coded in xxx") it is very flexible in how it handles commands and scripts since the host system is actually talking Forth to it, even if it doesn't know it.
BTW, when I do a proto that means I could have a hundred boards sitting waiting or in the case of the IoT5500 it's only 1,000 boards!
I can see use-cases where an A9 and an R4F on board with the P8X could be useful.
My apologies for cluttering up Peter's topic.